Portable Human Context

A candidate open standard for continuity across AI tools

Draft 0.2 · 14 October 2026 · EngramForge · Technical review draft

Abstract

Useful AI assistance depends on context accumulated over time: a person's goals, commitments, preferences, relationships, projects and corrections. That context can be scattered across conversations, source systems, employer workspaces and agent-specific memory. Reintroducing it costs effort; copying it indiscriminately creates a different problem. A portable record must retain who asserted it, when it applied, what remains uncertain, who controls it and where it may be used.

Portable Human Context (PHC) proposes an interoperable meaning and control contract for this information. A person organizes relevant memory through personas, customizes advisory preferences and restrictive guardrails, and authorizes specific recipients and purposes through verified identities. A receiving service preserves provenance and restrictions, quarantines ambiguous imports, and establishes fresh authority before making imported context available. The proposal reuses existing identity, authorization and tool transports. It does not create a universal human identifier, transfer old grants, promise truthful memory or control every copy after disclosure.

This paper describes a design and a validation program, not industry adoption or completed service qualification. The accompanying specification and conformance plan make the candidate requirements and evidence gaps reviewable. The separate experimental binding now provides a bounded JSON Schema, command-line and browser-local validators, negative tests, and a DEC integrity adapter. These are development tools; they do not establish a governed service or independent interoperability.

1. The human-context problem

A learning assistant benefits from knowing that a person is practicing Spanish twice a week. A project assistant benefits from the current decision, the rejected alternative and who approved the change. A household planner benefits from an agreed routine without necessarily needing private event titles. A professional may need client-specific context while being prohibited from moving it into a personal account. Health, financial, tax and estate examples introduce additional sensitivity, but the problem is broader than any one domain.

These examples contain several kinds of information. A preference is guidance. A historical observation may be accurate only for a date. An inference may be useful but disputed. A source may remain authoritative and need a fresh query. A third party may have rights that the person operating an assistant cannot waive. Treating every item as an interchangeable paragraph loses distinctions on which safe reuse depends.

Three common approaches address parts of the problem. A long transcript preserves detail but includes irrelevant and sensitive material and may obscure later corrections. An application-specific memory store can support continuity within that application's boundaries. A retrieval system can make source material easier to find. None of those mechanisms, by itself, establishes interoperable human authority, current permission, preserved provenance or safe migration. This is an architectural observation, not a claim that every existing product lacks these controls.

PHC's proposed unit of portability is therefore an attributed, versioned claim or context object with its applicable restrictions and lifecycle, rather than a raw transcript or an embedding. The original source can remain elsewhere. Portability includes knowing when a record must not be reused.

2. Personas make context relevant; identity makes actors accountable

Personal, Work, Client, Household and Learning are examples of personas. Applications may present them as profiles. They select relevant context and response preferences for a role. They do not create another identity, tenant, custodian, ownership claim or permission grant.

One record can belong to several authorized personas without being duplicated. Its source restrictions remain attached in each role. Removing a Work association cannot turn employer-controlled material into personal exportable memory. A Household persona does not prove a relationship or authorize access to another household member's records. Account linking and delegated authority require separate verified processes.

Customization has two distinct meanings. A preference such as “use brief explanations” advises an AI application. A restriction such as “use only these fields for this task until this time” narrows an already authorized operation. Deterministic access controls can enforce supported restrictions at the context service and controlled runner. A prompt asking an external app to behave a certain way cannot establish equivalent enforcement. The interface should state which boundary supplies each control.

Identity mediates access but does not supply it. Authentication identifies an owner, delegate, client or workload under an accepted issuer. The service then evaluates that actor's current authority for a recipient, purpose, operation, selected fields, processing route and duration. Read, contribute, confirm, share and take an external action remain separate decisions. An application that can propose a memory need not be able to read memory; one that can read a learning goal cannot silently rewrite it.

3. A useful first workflow

Consider a wholly synthetic learning example. Alex uses one application for a Spanish exercise. With a separate contribution grant, that application submits a reported statement: “Practice Spanish twice a week.” It supplies an authorized evidence reference and reported run information. The custodian records the authenticated producer separately from the producer's claims and places the proposal in a private review queue.

Alex confirms the proposal and associates it with Learning. Confirmation records Alex's decision; it does not change a reported statement into an independently observed fact. It creates no sharing authority. A second application receives the goal only after an applicable sharing decision names that recipient, the learning purpose, the allowed fields and the expiry. A financial-planning application with no such authority receives nothing, even if it knows the record identifier.

When Alex changes the schedule, the new canonical version invalidates the old summary and any dependent graph projection. The next authorized retrieval uses eligible current context. If Alex migrates custodians, the destination validates a recipient-bound bundle and reconstructs restrictions and identity mappings in quarantine. It does not replay the original apps' grants. The synthetic example illustrates those meanings without pretending to implement transport, cryptography or consent.

This first workflow deliberately makes successful reuse and denial equally visible. A demonstration that transfers a useful sentence while losing its restrictions would fail the proposal's objective.

4. Architecture and knowledge representation

The logical architecture separates canonical context, authority and derived views. Implementations choose a canonical store that can preserve the required records and consistency boundaries. A policy service evaluates current identity bindings, grants, custody, source rights, lifecycle and route eligibility. Adapters expose a common governed service through supported transports. Receipts record minimized decisions and disclosures. Background workers construct search indexes and summaries only from eligible inputs.

A knowledge graph is useful for relationships among people, goals, projects, events and claims. It supplements lists and search. Each edge is itself attributed context; neither an edge nor an endpoint grants access to the other. A relationship to a private person must not leak that person's name, record count or hidden existence through labels, traversal, pagination or aggregate results. Required endpoint and edge permissions are checked independently before traversal and before disclosure.

Generated context has explicit dependencies on source versions. A summary of two records inherits both sets of restrictions; if they cannot be satisfied together, that summary is ineligible. Embeddings are rebuildable derivatives, not the canonical meaning. A correction, deletion, changed source permission or narrowing policy can invalidate summaries, graph materializations, indexes, cached packages and queued work. Lineage needs enough protected dependency information for this check without exposing unauthorized parent details to a recipient.

W3C PROV provides a useful vocabulary for entities, activities and agents. PHC can map to that vocabulary, but the proposed core needs additional human-context distinctions, including assertion type, confirmation and current permission. It does not require an RDF store or treat a provenance graph as an authorization graph. S12

5. Capture from applications, agents and skills

Capture should be intentional and attributable. An integrating application can submit selected content through memory_propose, an owned completion hook or a registered source import. A connection to an MCP server does not grant access to the application's entire history or reveal conversations that were never submitted. Consumer-app support must be checked separately from developer-API support.

External content first becomes a proposal. The service checks independent contribution authority, source rights, supported types, size and classification. It treats statements, documents and skill descriptions as untrusted data. A reported user statement retains that label; an inference retains its inference label after confirmation. Unknown source references are not fetched automatically. A model-produced URL cannot authorize a new network destination.

An integrating agent is an ordinary registered client subject to the same rules. It can assemble a result candidate without submitting it as memory. Adoption is explicit; writing requires independent producer rights. If a future controlled runner executes an external action, it needs separate action authorization and relevant runtime controls. PHC memory access does not confer permission to send a message, transact or spend money.

DCER is an optional, scoped qualification extension. The implemented adapter verifies pinned DEC v0.1 structural, signature and chain evidence without asserting replay or granting access. Its admission decision must bind exact identity, release, method, purpose, runtime configuration and current trust/revocation status. Qualification can be an additional condition on a sensitive operation; it cannot replace consent or certify universal safety. Evidence about a completed run is distinct from prior release qualification used to admit the next read.

6. Portability and the standards landscape

PHC should reuse established mechanisms where their responsibilities fit. OAuth and OpenID Connect supply delegated authorization and identity mechanisms. MCP exposes tools and protected resources. A2A can coordinate agent tasks. None is replaced by this proposal. PHC specifies the meaning that must survive context exchange and the restrictions that must remain enforceable.

The researched MCP latest page resolves to the 2026-07-28 edition; its registration guidance prefers Client ID Metadata Documents and retains deprecated Dynamic Client Registration for compatibility. Each supported transport era still needs an exact tested binding. A transport's discovery or tool support does not demonstrate PHC semantics. S01

Emerging memory work offers useful ideas. The PAM paper describes portable agent-memory structures and provenance; any mapping to PHC would need tests for human custody and current authorization. SAMEP proposes shared agent memory, but its full-text evaluation labels performance results as projections. PHC should compare semantic round trips and failure behavior, not adopt unverified ecosystem or performance claims. This draft has not executed either system. S13

A receiving service must preserve supported restrictions, bind destination identities explicitly and quarantine unsupported or ambiguous material. The safe response to an unknown mandatory restriction is blocked use, not conversion to a friendly prompt. Optional advisory preferences can be omitted with a report; authority, source restrictions and lifecycle cannot be silently dropped. Credentials, private keys and live grants never enter a customer portability package.

The experimental 0.1.0 binding is a bounded development profile, not an interoperability claim. Migration from another format requires explicit mapping, loss analysis and compatibility tests. See the specification.

7. Threat model and honest limits

The service assumes that an external app, imported document, source assertion, metadata URL or model output can be malicious. A valid signature can establish attributable origin and integrity while the statement itself is false or unauthorized. The system also needs to address service compromise, operator misuse and recovery errors; protocol syntax alone cannot solve these threats.

OAuth security guidance, including redirect and issuer defenses, is a foundation rather than proof that the implementation is secure. Sensitive profiles may require qualified sender-constrained paths and stricter assurance. A broker protects its own hop; it cannot make an upstream bearer client end-to-end proof-of-possession capable. S02, S04

Expiry and revocation stop future authorized service access. Notices can request correction or deletion from known recipients and record acknowledgments, but receipt of a notice is not evidence of deletion completion. Public claims must state this distinction plainly.

8. Custody and recovery

PHC does not prescribe a database or cloud provider. Implementations must establish and test their storage, disclosure and recovery boundaries.

Recovery must reconcile deletion, correction, revocation and narrowing authority before affected context becomes available. Promotion of a standby requires verified fencing of the prior writer and disclosure paths, reconciliation of acknowledged safety events, and current authority. A timeout or failed health check alone is insufficient. Unknown safety state keeps affected compartments closed.

Three custody profiles need distinct descriptions. Managed encryption allows authorized service decryption and search. Confidential processing adds a validated attestation and key-release boundary under a stated threat model. Genuinely provider-blind local custody keeps plaintext and usable keys outside the provider's readable processing boundary and requires different search, synchronization and recovery behavior. Ordinary readable semantic/vector search in a managed database must not be labeled provider-blind end-to-end encryption. Sending plaintext from a confidential runtime to a hosted model is a new disclosure.

9. Evaluating interoperability and usefulness

The adoption hypothesis is that reliable reuse of a few valuable records, with understandable denials and migration, will be more persuasive than a broad format announcement. Start with one useful learning task, a reader, a separately authorized contributor and a forbidden destination. Then qualify another exact route and independently implemented receiving endpoint. Two registered clients or two adapters around one policy engine do not establish independent adoption.

10. Current scope

The accompanying kit provides a strict quarantine-document validator, a DEC integrity verifier and a reference qualification function. Service integration still requires authenticated identity and custody mappings, a cryptographic exchange profile, fresh authorization and lifecycle enforcement. Independent exporters and importers need to demonstrate preservation of meaning under unknown restrictions, identity ambiguity, correction and revocation, as well as successful transfer. See Draft status for verification and licensing limits.

The proposed standard's success condition is modest but demanding: an authorized recipient receives useful context with preserved meaning, and an unauthorized or semantically incompatible recipient does not receive it. That result remains to be demonstrated.