Hearsay

A model guessed something about her health. Her passport saved it as a fact. Hearsay fixes the write path.
Today, an inference looks exactly like a fact you typed. Hearsay quarantines it. The passport launders inference into fact.
Panel A: The read path has 5 controls. The write path has one free-text string. Maya approves a guess at 1:14am.
Panel B: The API call is rejected for missing provenance, resubmitted with the inferred enum, and auto-quarantined.
Panel C: When Maya corrects a fact, a retraction broadcasts to all apps. The third row (No Response) is the point.
Summary: Four provenance classes, four rules, and one required enum on the suggest endpoint. Plus Version One scope.

Identity track · Build lane

The AI Passport's read path has five controls: exact fields, a declared purpose, a duration, an approve/edit/deny decision, and a receipt. The write path has one free-text string and one tap.

Hearsay adds a provenance class to every field, blocks apps from upgrading a guess into a fact, quarantines inferences that land in sensitive categories, and makes a correction travel to every app that already read the old value.

Inspiration

At 1:14am an assistant proposes a memory write to Maya's passport: suggest: "managing a chronic sleep condition".

It was derived from a heart-rate variability trend and a pattern of morning meetings cancelled at short notice. No clinician was involved. Maya has never typed a word about her health into anything.

She has approved eleven memory requests this month, mostly about coffee and commuting. She taps approve.

Her record, one minute later:

Field	Value	Status
diet	vegetarian	fact
commute	cycles to work	fact
health	managing a chronic sleep condition	fact

Two she typed. One a model guessed. Nothing in the record distinguishes them.

Three weeks later a recruiting assistant preparing a screening call, an insurance quoting tool, and a travel agent all read it as fact.

Nothing here required a breach, a malicious app, or a dark pattern. Every component behaved exactly as designed.

Inside one app, a bad inference dies with the app. Inside a passport, it becomes globally authoritative. The passport does not only carry context. It launders inference into fact.

The user or group affected

Every passport holder, and acutely anyone whose sensitive attributes are inferable from ordinary connector data, health, immigration status, financial distress, pregnancy, sexual orientation, criminal record.

Maya is 24 and job-hunting. She connected Gmail, Calendar, Strava and Whoop because that is the point of a passport. She did not consent to a health record. She consented to better scheduling.

What it does

How AI Passport is used

Every field carries one of four provenance classes, and the class travels with the value.

Class	Meaning	Example
`declared`	The holder typed it	"I am vegetarian"
`attested`	A third party signed it	An employer confirms employment dates
`observed`	A hard event exists in a connector	A flight is booked on 3 Sep
`inferred`	A model concluded it	"Probably anxious about money"

Four rules run on top.

1. No upward laundering. A write inherits the lowest class among its inputs. An app that reads an inferred field cannot re-propose the result as observed. This is taint tracking for personal facts, and declassification requires the holder, not the app. Without it, a guess becomes true by circulation: three apps re-assert it and the fourth reads consensus.

2. Inferences decay. Every inferred field carries a mandatory TTL. Renewal requires evidence from a source the original write did not use, so an app cannot refresh its own guess forever.

3. Sensitive categories are quarantined. Apps cannot request inferred values in a sensitive category at all, the API refuses rather than asking the user to approve. Quarantined items are never bundled with other fields, never readable by any app under any grant, released one at a time with their own purpose, and deleted after 30 days if untouched.

4. Corrections travel. Editing or deleting a field broadcasts a retraction to every app in that field's receipt log. Each returns purged, acknowledged with a stated retention period, or nothing. The holder sees which is which.

The call, today:

suggest: "managing a chronic sleep condition"

The same call, under Hearsay:

POST /passport/suggest
400  PROVENANCE_REQUIRED

{
  "field":        "health.conditions",
  "value":        "chronic sleep condition",
  "provenance":   "inferred",
  "source_app":   "app_sleepcoach_v2",
  "derived_from": ["whoop.hrv_30d", "calendar.cancellations_30d"],
  "confidence":   0.61,
  "ttl":          "P30D"
}

409  QUARANTINED
{
  "category":          "sensitive.health",
  "shared":            false,
  "readable_by_apps":  false,
  "bundling":          "prohibited",
  "auto_delete_at":    "+30d"
}

What context, permission, proof or access is involved

The claim carried is not the fact itself but the basis for it. A requesting app receives the value, its provenance class and its age. It never receives the underlying evidence.

read:     ["knowledge.constraints"]
purpose:  "screening call prep"
duration: "session"

returns:
{
  "value":       "prefers morning-free scheduling",
  "provenance":  "inferred",
  "asserted_at": "2026-07-02",
  "expires":     "2026-08-01"
}

That is enough for an app to decide how much weight to give a value, and not enough to reconstruct the holder's private signals. The permission model is otherwise unchanged. What changes is that a purpose can no longer silently acquire a fact nobody asserted.

A class is a claim about evidence, not about truth. It verifies nothing. It preserves the ability to evaluate a fact later, and puts the cost of a bad guess back on whoever made it.

Who controls access

The holder, at three levels.

Some things are not grantable at all: the quarantine tray has no permission that opens it, and the evidence behind an inference is visible only to the holder. Below that, apps request fields with a purpose and duration exactly as they do now, and quarantined items are released alone, with their own purpose, or not at all.

Apps never gain the ability to raise the class of a field. Only the holder can promote an inference to a declared fact, and the way they do it is by typing it.

What can be revoked or changed

Any field, per app, plus a retraction that travels. Editing or deleting notifies every app in the field's receipt log.

App	State
Recruiting assistant	Purged
Insurance quoting tool	Acknowledged, 30d retention
Travel agent	No response

The third row is the point. The holder can see it, and apps that ignore retractions lose write access.

A retraction cannot un-read data and cannot un-train a model. Anyone who tells you otherwise is selling something. What it does is stop future reads, timestamp the withdrawal, and make any use after that timestamp a documented breach rather than a dispute about memory. It converts an unenforceable technical promise into an enforceable contractual one, and the lever behind it is market access.

How we built it

We started from the developer documentation rather than the brief. The event describes the passport as "verified context and permissions," which suggests a credential wallet. It is not. It is a personal context record with a permissioned read/write loop: an app requests exact fields with a purpose and a duration, the holder approves, edits or denies, scoped context returns as JSON, the app may propose a durable memory write, and every read and proposed write leaves a receipt. Reading the actual API is what surfaced the asymmetry between the two paths.

From there the build was a specification rather than a demo:

The schema. Four provenance classes, the required fields on suggest (provenance, source_app, derived_from, confidence, ttl), and the 409 QUARANTINED response shape, all expressed in the passport's existing vocabulary so it drops into the endpoint that already ships.
The three passport moments, drawn as screens: the write as the API accepts it today, the same write under Hearsay, and the receipt with the retraction and its per-app state.
The threat model, which is what the schema is actually shaped by.

We deliberately did not build a running prototype. A half-working demo would have demonstrated less than a schema that a working engineer could implement on Monday, and the change we are proposing is one required enum, not an application.

Challenges we ran into

Risks and misuse concerns: The hard part of this project was not implementation. It was adversarial design: every rule we wrote created a way around itself, and the schema is the residue of closing those.

Laundering through derivation: an app reads an inference and writes the conclusion back as an observation. Closed by label inheritance.

Expiry evasion: an app refreshes its own guess on day 29, forever. Closed by requiring evidence from a source the original write did not use.

Consent fatigue: an app floods the holder until approval becomes reflex, which is exactly how Maya lost control at 1:14am. Closed by rate-limiting suggest, batching review weekly, and defaulting quarantine to deny. A design that relies on attention is not a design.

Third-party injection: the passport has a public page where other people can send you things. Someone sends content engineered to produce an inference about you. Closed by capping inbound third-party content at inferred and barring it from sensitive categories.

Prompt injection through connectors: an email in your inbox asserts a fact about you and the assistant proposes writing it. Same mitigation.

Class misreporting: an app declares observed when it means inferred. Closed by sampled audits of derived_from and loss of write access. Inheritance makes the lie useful only once.

Two risks belong to this design and are worth naming rather than hiding. The classifier deciding what counts as sensitive is itself an inference, so it must fail toward quarantine: a false positive costs one extra tap, a false negative costs a job or an insurance policy. And the quarantine tray would become the most sensitive object in the system if it retained what it rejected, which is why untouched items are deleted rather than archived.

One risk we are not solving. A single record read by everything is the highest-value target in the system, and provenance does nothing about concentration.

Accomplishments that we're proud of

We think the strongest thing in this entry is that it critiques the architecture instead of decorating it, and that the three judging criteria are the mechanism rather than sections appended to it. Privacy and risk is the quarantine. User control is who can raise a class and what can be revoked. Clear AI Passport use is one required field on an endpoint that already exists.

We are also proud of finding the argument that makes this urgent rather than nice to have. A company that assembles information bearing on a person's character or personal characteristics and furnishes it to third parties who use it for employment, insurance or credit decisions can meet the definition of a consumer reporting agency under the FCRA, and the FTC's stated position is that a disclaimer saying otherwise does not insulate you. The duty that attaches is reasonable procedures to assure maximum possible accuracy, plus dispute and correction rights — which is a one-line description of this proposal. Washington's My Health My Data Act reaches inferred health data, carries a private right of action, and requires that consent never be bundled with other consents, which is exactly the quarantine rule. California treats inferences used to build a profile as personal information subject to a right to correct. UK and EU rectification-notification duties point the same way.

Provenance is not a compliance cost. It is the thing that keeps a passport from becoming a consumer reporting agency by accident.

What we learned

Resisting cryptography was the hardest design decision. Our first sketches had signed attestations and selective disclosure. All of it was unbuildable inside the product that exists, and none of it addressed the actual failure, which is not that facts are unverified but that unverified facts are indistinguishable from verified ones. The fix turned out to be one enum.

Honest limits score better than confident ones. We rewrote the revocation section three times before admitting plainly that a retraction cannot un-read data. Saying so made the rest of the argument stronger, because it made clear what the receipt log is actually for.

A provenance class is a claim about evidence, not about truth. We spent a long time trying to make the system know what was true before realising that it does not have to. It only has to preserve the ability to evaluate a fact later, and put the cost of a bad guess back on whoever made it.

What's next for Hearsay

Version one is roughly two weeks inside the existing architecture.

provenance becomes a required enum on the suggest endpoint. Writes that omit it are rejected.
A sensitivity classifier and a quarantine tray. Deny by default, no bundling, no app read path, auto-delete at 30 days.
A provenance badge on every field in the passport UI and inside every receipt.

Deliberately not in v1: cryptographic attestation or an issuer network (attested is a reserved slot, not a deliverable); the full retraction acknowledgment protocol beyond broadcast and per-app state; automated auditing of derived_from; anything zero-knowledge.

Beyond that, the same mechanism read forwards is a commercial unlock rather than a safeguard. Enterprise support is one of the passport's two named verticals, and no enterprise buyer integrates a personal-data record they cannot audit. Every month of delay also makes provenance more expensive to retrofit, because it has to be applied to a record that is already populated.

This entry is for Maya, who needs to prove to every app reading her passport that a claim about her health was a model's guess and not a fact she stated, so she can correct it once and have the correction travel, without ever revealing the condition itself.