Feature Proposal: Pinned Facts + Records — Durable User-Declared Context for Projects

ChatGPT Feature requests
1

Feature Proposal:

Pinned Facts + Records

— Durable User-Declared Context for Projects

Summary

Introduce a two-tier persistence model for ChatGPT Projects:

  1. Pinned Facts – small, user-declared, immutable facts that must always be included in relevant prompts.

  2. Records – structured, durable data artifacts (tables, CSVs, numeric series, documents) explicitly retained for longitudinal analysis.

Together, these address a fundamental limitation of current Projects: user-supplied data that appears to be stored and reusable can be silently summarized, deprioritized, or lost, undermining trust and sharply reducing the value of paid subscriptions.

This proposal applies across all domains: marketing, finance, engineering, research, writing, health, and more.

Problem Statement

Projects encourage users to treat ChatGPT as an ongoing analytical workspace. Paid users in particular rely on Projects to:

  • Maintain baseline assumptions

  • Accumulate data over time

  • Perform trend analysis

  • Avoid repeatedly re-entering foundational context

However, today:

  • Memory is heuristic and lossy

  • Facts may be summarized or compacted

  • Data tables are not durable

  • Users cannot audit what is retained

  • Verification through repeated success does not imply persistence

This creates capability ambiguity: Projects appear to support durable state, but do not reliably do so.

Why This Is a General Problem (Not Safety-Specific)

This affects any serious use case, including:

  • Marketing: ICP definitions, pricing assumptions, campaign metrics

  • Finance: historical figures, risk tolerances, modeling inputs

  • Engineering: constraints, versions, architectural decisions

  • Research: datasets in scope, hypotheses, measurements

  • Writing: canon, character facts, style rules

In all cases, users reasonably expect:

“If I explicitly tell the system this is foundational or provide structured data for ongoing use, it should persist unless I change or remove it.”

Today, that expectation is not met.

Proposed Solution: Two Explicit Persistence Classes

1.

Pinned Facts

— durable

context

2.

Records

— durable

data

They solve different problems and should not be conflated.

1. Pinned Facts (“Remember This Always”)

Purpose

To store small, foundational facts that must always be present when relevant.

Examples

  • “Target customer is mid-market healthcare companies (50–500 employees).”

  • “This project assumes AWS us-east-1 deployment.”

  • “All pricing analysis should assume annual contracts.”

  • “Writing style: concise, technical, non-marketing.”

User Trigger

Natural phrases:

  • “Remember this always”

  • “Always remember”

  • “This is foundational”

  • “Pin this”

Example Interaction

User:

“Remember this always: Our target customer is mid-market healthcare companies with 50–500 employees.”

Assistant:

Proposed Pinned Fact:

“Target customer: mid-market healthcare companies (50–500 employees).”

When should I use this automatically?

☐ Marketing analysis

☐ Pricing & positioning

☐ Strategy discussions

This fact will be included verbatim until you change or remove it.

[Pin it] [Edit] [Cancel]

Once confirmed, the wording is frozen.

Pinned Facts — Design Principles

  1. Pre-summarize, then freeze

    • Assistant proposes compact phrasing

    • User approves

    • No further summarization or normalization

  3. Scope-based deterministic inclusion

    • Included whenever scoped topics arise

    • Not subject to relevance heuristics

  5. Reserved token budget

    • Small, non-competitive prompt region

  7. User-only lifecycle control

    • Create / Edit / Remove

    • No silent changes

2. Records — Durable Data for Longitudinal Work

Purpose

To retain structured or semi-structured data for reuse, analysis, and comparison over time.

Examples

  • Tables of metrics (monthly KPIs, conversion rates)

  • Financial models or assumptions

  • Experimental results

  • Lab values or measurements

  • CSVs, spreadsheets, or extracted tables

  • Versioned documents relevant to a Project

Records are not context — they are data.

Records — Core Requirements

A. Explicit retention

  • Records are created intentionally (“Store this as a record”)

  • They are not summarized away

  • They persist until the user deletes or replaces them

B. Structured access

  • Records can be:

    • Listed

    • Retrieved

    • Queried

    • Compared over time

  • Assistant may analyze them, but must not modify them silently

C. Versioning / replacement semantics

  • New data can:

    • Append

    • Replace

    • Create a new version

  • User chooses the behavior

D. Visibility

Project → Records

  • Name

  • Type (table, CSV, doc)

  • Date added

  • Version history

  • Download / export

If users cannot see their records, they cannot trust them.

Interaction Between Pinned Facts and Records

  • Pinned Facts define assumptions and constraints

  • Records provide the data analyzed under those assumptions

Example:

  • Pinned Fact: “Analyze performance assuming SMB customers only.”

  • Record: “Q1–Q4 conversion metrics.csv”

This separation prevents misuse of Pinned Facts as a data store.

Transparency & Trust

Optional “Context Used” disclosure

For analytical responses:

Pinned context used: Target customer; pricing tier

Records used: Q1–Q4 metrics (v2)

This makes silent omission immediately visible.

Reliability Language (Honest and Defensible)

Documentation should state:

Pinned Facts and Records are intentionally retained and not subject to heuristic summarization.

They are designed for durability within Projects.

As with any software system, this is not a guaranteed archive, but it is a user-controlled retention mechanism distinct from conversational memory.

This avoids false guarantees while clearly differentiating from current behavior.

Free vs. Paid Differentiation (Essential)

This capability should be a paid-tier differentiator.

Rationale

  • Projects are a primary reason users subscribe

  • Without durable context and data, Projects underdeliver

  • Serious analytical users reasonably expect persistence

Suggested model

  • Free: Limited or no Records; minimal Pinned Facts

  • Paid: Multiple Pinned Facts, full Records retention, visibility, export

Without this, the value proposition of paid Projects is severely weakened.

What This Does Not Attempt

  • Perfect, SLA-level guarantees

  • Acting as a regulated system of record

  • Unlimited storage

The goal is intentional, user-controlled persistence, not infallibility.

Why This Matters

Without explicit persistence classes:

  • Projects feel unreliable

  • Users cannot distinguish durable vs ephemeral state

  • Verification does not imply retention

  • Trust erodes

  • Paid subscriptions lose justification

Pinned Facts + Records provide a clear mental model, a clear contract, and a clear reason to pay.

Closing

This proposal does not require new LLM capabilities.

It requires orchestration, lifecycle rules, and honest UX.

Together, Pinned Facts + Records would:

  • Restore confidence in Projects

  • Enable real longitudinal analysis

  • Eliminate capability ambiguity

  • Strengthen the paid tier in a defensible way

This is foundational infrastructure for professional use of ChatGPT.