# PHC candidate specification

**Draft 0.1 · 14 October 2026 · Normative proposal, not an implemented wire standard**

> Implementation companion: [BINDING.md](BINDING.md) defines an isolated experimental JSON grammar and offline checks. It does not enact this semantic proposal as an interoperable release or establish compatibility with other formats. Requirement IDs below remain stable.

## 1. Status, scope and conventions

This document defines proposed interoperable semantics for Portable Human Context. The capitalized terms MUST, MUST NOT, SHOULD, SHOULD NOT and MAY express candidate requirements in the BCP 14 sense. They do not assert implementation, certification or consensus. Requirement identifiers `PHC-Rxx` are stable within this draft for review and planned tests. The JSON field names below are a candidate abstract data model; no PHC media type, public namespace, executable schema or registered OAuth authorization-details type is allocated by this document.

The core covers attributed facts, goals, preferences, episodes, document references and bounded relationships. It excludes credentials, executable procedures, system policies, hidden chain-of-thought, arbitrary agent working state and authority to take external actions. A particular release can support fewer record kinds only through explicit capabilities and blocking loss rules.

Migration from another format requires an explicit mapping and evidence that mandatory meaning survives. Section 12 describes those compatibility obligations.

## 2. Actors and terminology

| Term | Meaning |
|---|---|
| Human subject | The person a claim concerns; not necessarily the operator, owner or author |
| Owner/controller | The actor with established authority to administer a bounded context collection; this term does not decide legal ownership |
| Delegate | A separately authenticated actor with verified limited authority; a relationship label alone is insufficient |
| Custodian | Service or organization responsible for a collection's storage and applicable policy |
| Tenant | An isolation and administration boundary; not interchangeable with a persona |
| Persona | Role-based association of context and preferences; `persona_profile_ref` distinguishes it from protocol/security profiles |
| Client | Registered application requesting a particular operation on behalf of an authorized actor |
| Producer | Authenticated contributor, distinct from its reported author, source, release and run |
| Processing recipient | Exact approved service/model/runtime destination that receives or processes context |
| Source | Attributed origin or evidence reference, with its own access rights and lifecycle |
| Restriction | A mandatory limitation or obligation on an otherwise authorized operation |
| Grant | Current service-held authority for a specific actor, recipient, operation, scope, purpose and duration |
| Derived context | A summary, inference, embedding, graph materialization or other output dependent on versioned inputs |
| Quarantine | Protected storage inaccessible to normal retrieval, synthesis, graph publication and client reads until reviewed eligibility is established |
| Qualification | Scoped evidence about an exact implementation/release/profile; never a grant or universal safety statement |

**PHC-R01 — Distinct authority.** Implementations MUST keep these roles distinct in their authority model. Authentication, persona membership, confirmation, registration and qualification MUST NOT create missing read, contribution, sharing or action authority. An untrusted payload MUST NOT select the active customer, tenant, custodian or authority generation.

## 3. Minimal exchange envelope

**PHC-R02 — Explicit envelope.** Every migration bundle MUST represent the following information without relying on a display name or free-text instruction to carry mandatory semantics. Other operation envelopes MAY be smaller under a separately specified binding, but MUST retain the semantics necessary for their operation.

| Candidate field | Type and required meaning |
|---|---|
| `format`, `format_version` | Exact, case-sensitive identifiers for the negotiated binding and semantic revision; not a marketing label |
| `bundle_ref` | Opaque identifier unique within a trusted exporting-custodian namespace; checked for replay |
| `exporter_ref` | Trusted namespace and exporter identity reference, resolved under local trust configuration |
| `intended_recipient_ref` | Exact destination custodian/service binding, protected with the payload |
| `issued_at`, `expires_at` | UTC timestamps; expiry strictly after issuance and valid at import admission |
| `export_purpose` | Typed purpose identifier with an agreed vocabulary/version; not arbitrary authority-bearing prose |
| `required_capabilities` | Unique exact capability identifiers and versions that the recipient must understand and enforce |
| `identity_mappings` | Protected claims and proposed mapping references for subject/custodian/tenant namespaces; no automatic account links |
| `records`, `personas`, `relationships` | Bounded selected objects authorized for export; empty collections are allowed where meaningful |
| `restrictions` | Typed mandatory rules, their controlling origin and scope, including inherited rules |
| `tombstones`, `lifecycle_checkpoint` | Scoped deletion/invalidation records and issuer/collection/sequence completeness information |
| `migration_map` | Source object/version to proposed destination mapping; unresolved mappings remain explicit |
| `proof_refs` | Protected references to integrity/origin evidence and export decision; no arbitrary key-fetch instructions |

The entire binding MUST define parser depth, object counts, string lengths, maximum uncompressed size, timestamp precision and cryptographic limits before it is enabled. Implementations MUST reject duplicate JSON object keys, malformed timestamps, invalid intervals, ambiguous identifiers and unsupported mandatory structure. Opaque IDs are not authority. Decimal amounts, if supported, MUST use decimal strings and explicit currency and effective dates; binary floating-point MUST NOT define monetary meaning.

Boolean declarations such as `credentials_included: false` do not prove content is safe. The exporter MUST construct an allowlisted projection and MUST NOT serialize live access/refresh tokens, source passwords, provider API keys, signing/decryption private keys or reusable grants. The importer MUST reject detected prohibited material and MUST NOT attempt to use it. It cannot guarantee detection of every secret hidden in natural-language content.

## 4. Records, provenance and derived context

**PHC-R03 — Attributed versioned records.** Each non-tombstone record MUST carry: a namespaced opaque ID; positive version or equivalent unambiguous revision; subject and custodian references; applicable tenant boundary; kind; assertion type; lifecycle state; typed content; provenance; observed/effective/review times; classification vocabulary/version and label; allowed-purpose constraints; policy/restriction references; and versioned derivation parents where present. Unknown classification meaning or ambiguous custody MUST block use.

The initial assertion types are `user_stated`, `reported_user_statement`, `observed` and `inferred`. A producer's claim that a person said something MUST be `reported_user_statement` unless a separately verified owner-entry channel establishes `user_stated`. `observed` describes the producer's attributed observation, not independent truth. Confidence MAY be included as a qualified extractor output; it MUST NOT be represented as a verified truth probability.

Provenance MUST distinguish the authenticated producer from reported source/author/release/run data. It MUST preserve source namespace, source version, evidence reference where authorized, and relevant transformation references. Protected evidence may stay at its source; omitting its content MUST NOT imply independent verification. Unresolved evidence MUST be marked unavailable. If current evidence/source validation is required by policy, unavailable evidence blocks eligibility.

**PHC-R04 — Confirmation and source integrity.** Confirmation MUST record the authorized reviewer, decision time and reviewed proposal/record version as protected evidence. It MUST preserve original assertion type and attribution. An edited inference remains an inference unless a distinct new assertion is explicitly recorded with its own provenance. Confirmation MUST NOT create sharing authority, including through an existing topic or persona selector. An explicitly reviewed applicable sharing decision is required for new content.

**PHC-R05 — Lineage and graph eligibility.** Derived context MUST identify relevant input versions and transformation provenance. Its effective restrictions MUST include all applicable source, custodian, record and lineage restrictions. Where the implementation cannot prove a narrower per-claim dependency set, it MUST conservatively inherit all input restrictions. Empty or incompatible allowed-purpose/recipient/route intersections make the derivative ineligible.

Graph edges and required endpoints MUST pass independent permission and current-version checks. Membership, labels, counts, traversal and source references MUST NOT reveal unauthorized objects. Correction, deletion or narrowing authority MUST invalidate dependent retrieval, summaries, graph projections, embeddings, caches and queued output before they can be disclosed again. A missing or ambiguous dependency cannot be treated as unrestricted. Public hashes of guessable personal facts MUST NOT be used as a substitute for private lineage storage.

## 5. Personas and preferences

**PHC-R06 — Role association only.** A persona MUST have a custodian-scoped ID, version, display label, explicit record associations and any additional restriction references. Preference entries MUST be typed and identified as advisory. A persona MUST NOT act as an owner, identity, tenant, grant or replacement classification. Associating, copying or moving a record MUST preserve its source/custodian/record/lineage restrictions; persona deletion MUST NOT remove them.

An association operation MUST recheck authority for the record and destination role. If custody forbids a transfer, a copy operation MUST NOT bypass that restriction. A persona switch MUST NOT silently expand, revoke or rebind a remote client's existing grant. Consumer clients SHOULD clear stale views and reject late responses from the prior account/persona context. Any portable persona labels and membership are themselves protected metadata.

Preferences such as tone and response length MAY be omitted by a receiver that does not support them, with an explicit compatibility report. They MUST NOT change deterministic allow/deny decisions. If a sender describes a preference as mandatory access policy, it MUST be represented as a supported restriction capability; putting it in preference text is insufficient.

## 6. Restrictions and capability negotiation

**PHC-R07 — Restrictive composition.** The effective decision is the intersection of current actor authority, grant, custodian/tenant policy, source and record rules, lineage restrictions, persona restrictions, purpose, time, route, lifecycle, suspension and required qualification. Any applicable denial wins. An empty intersection denies. An allowlist restricts an existing grant; it does not supply one. Owner preferences MUST NOT override mandatory organization or source controls.

Every portable restriction MUST identify a stable rule ID/version, controlling origin, scope, exact capability/version, typed operands and mandatory enforcement status. This draft proposes the following initial primitives; their final serialization and vocabularies remain release blockers.

| Candidate primitive | Deterministic proposed semantics |
|---|---|
| `operations_subset` | Requested operation must be in the set; all applicable sets intersect |
| `purposes_subset` | Exact registered purpose must be in every applicable set; aliases need reviewed mappings |
| `recipients_subset` | Exact verified recipient binding must be in every applicable set |
| `fields_subset` | Projection includes only allowed fields; hidden metadata follows its own applicable rules |
| `processing_routes_subset` | Every disclosed processing hop must use an approved exact route |
| `not_after` | No new use/disclosure at or after the earliest applicable deadline |
| `delegation_forbidden` | No downstream delegation; absence of this rule does not itself authorize delegation |
| `export_forbidden` | No customer portability export in the matched scope; backup rights are separately determined |
| `review_required` | A matching, version-bound authorized review must exist before the governed operation |
| `qualification_required` | Exact required profile, release/runtime binding and fresh trust/status must be verified |

No general script language, executable policy blob or model-interpreted rule is admitted as a core restriction. Residency, retention, deletion completion, action limits and stronger runtime controls require separately specified capabilities and evidence. A required promise about behavior beyond the recipient's enforceable boundary MUST block the operation; it cannot be advertised as enforced merely because terms or a prompt mention it.

**PHC-R08 — Fail closed negotiation.** Public discovery MUST be nonpersonal. It MAY advertise supported format versions, exact schema digests, restriction capabilities, supported record kinds, transports, processing/custody profiles, bounds and notice behavior. It MUST NOT expose customer names, record existence, counts, persona names or grants. A capability advertisement is a claim to test, not proof of qualification.

Participants MUST select an exact compatible binding and all required capabilities before release of protected content. Unknown, unsupported, malformed or unenforceable required rules MUST block the affected operation. A mandatory rule MUST NOT be relabeled advisory or dropped during retries/fallback. Unknown optional data MAY be preserved opaquely in quarantine or omitted with a report only when the selected binding proves that the omission cannot affect authority, provenance, lifecycle or meaning required for the operation.

Default import is atomic. A future partial-import capability MAY admit an explicitly reviewed closed subset only if every selected object's dependencies, restrictions and safety events are complete. It MUST report rejected objects without leaking unauthorized details. Uncertain dependency closure blocks the subset. No best-effort import may publish an orphaned derivative.

## 7. Identity and current authorization

**PHC-R09 — Verified binding.** Services MUST derive local subject/tenant/custodian bindings from validated server-side identity and authority records. OpenID Connect issuer and subject, with the application's validated client/audience and session context, are inputs to binding; matching email or display names MUST NOT merge identities. Pairwise or scoped identifiers SHOULD minimize cross-service correlation. Linking and migration require authenticated explicit flows and conflict handling.

Owner sessions, external agent/client credentials and source OAuth credentials MUST be separate. An ID token MUST NOT be accepted as a memory-resource access token. A source token MUST NOT authorize memory export; a client API key MUST NOT substitute for human authority. Issuer, audience, expiry, intended resource and the applicable credential profile MUST be validated on every protected request. Source, metadata and evidence URLs require trusted resolution and SSRF controls; imported URLs MUST NOT trigger unrestricted network access. Bindings MUST follow relevant current OAuth/OIDC security guidance. [S02–S05](SOURCES.md#s02-oauth-security)

**PHC-R10 — Bounded fresh decisions.** A grant MUST identify initiating actor/delegate, recipient client, operations, records/fields or bounded selection, purpose, processing destinations, expiry, policy version, authority generation and revocation-sensitive state. Delegation defaults to disabled; any permitted hop MUST be narrower and independently audience-bound. An endpoint MUST recheck current eligibility immediately before disclosure or mutation publication, including after asynchronous work. Pagination, continuation and session handles MUST be bound to actor, client, purpose, scope, epoch and expiry; possession of a handle is not authority.

A binding MUST declare maximum credential lifetime, current-state lease, revocation enforcement bound and clock-skew allowance. When current security/lifecycle state cannot be established within those bounds, the operation MUST stop. Streaming and background work MUST stop further publication when their authority becomes ineligible.

## 8. Contribution and lifecycle

**PHC-R11 — Reviewed contribution.** An external contribution MUST require independent contribution rights and enter a pending/quarantined state. It MUST NOT self-confirm, administer grants, delete canonical records or lower classifications. Source references MUST resolve only through previously authorized uploads or registered sources. Owner review MUST use the current proposal version; corrections MUST also name the expected canonical version. Reusing a producer-bound idempotency key with a different payload MUST conflict; retries of the same accepted payload MUST NOT duplicate the proposal.

**PHC-R12 — Lifecycle preservation.** Core states are `proposed`, `confirmed`, `disputed`, `stale`, `superseded` and deletion represented by a tombstone. An imported `confirmed` state is historical evidence pending local review; it is not local confirmation or eligibility. Disputed/stale content MUST NOT be silently promoted to current fact. Old versions and deleted content MUST be excluded according to the operation's lifecycle policy even if a stale index entry remains.

Correction MUST create a new version and invalidate dependent old outputs. A tombstone MUST identify the protected source namespace, record/version, deletion time and relevant safety sequence without requiring retained deleted plaintext. A lifecycle checkpoint MUST identify its issuer, collection and sequence semantics; sequence numbers from unrelated custodians MUST NOT be compared as a global order. Gaps, rollback or an unverified claim of completeness MUST block affected eligibility. Local mutations and required outbox/safety records MUST commit atomically or provide an equivalent proven consistency boundary.

**PHC-R13 — Notices and recovery.** Known-recipient correction/deletion notices MUST be authenticated, audience-bound, bounded, deduplicated and free of unnecessary content. Delivery acknowledgment MUST be recorded separately from asserted or verified recipient deletion completion. Acknowledgment MUST NOT be represented as recall of previously disclosed data.

A recovered service MUST apply applicable deletion, correction, revocation, identity-unlinking and narrowing-policy state before enabling affected context. If it cannot establish current safety state, it MUST keep affected compartments closed. Recovery grants require the declared authority-generation policy; old credentials MUST NOT silently revive. PHC does not mandate a cloud topology, but a claimed recovery profile MUST define and test its fencing and safety reconciliation boundaries.

## 9. Export, import and custody

**PHC-R14 — Authorized export.** Export MUST require current authority over each selected object, field, association and relationship, plus export permission under source/custodian rules. It MUST preserve all applicable restrictions and permitted provenance, or exclude the object with an authorized report. Export MUST NOT bypass employer or third-party custody by treating the signed-in person as universal owner. Fresh step-up requirements are binding-specific and MUST be declared. A successful export does not authorize the destination to disclose the data.

**PHC-R15 — Quarantined admission.** A receiving service MUST:

1. Apply bounded parsing/decryption and verify the selected integrity, confidentiality and trusted exporter profile without executing content or following untrusted key URLs.
2. Validate exact recipient binding, issuance/expiry, replay status, supported versions and mandatory capabilities.
3. Store protected data in quarantine; resolve subject, custodian, tenant, source, classification, restriction and lifecycle mappings under receiving policy.
4. Reject use when required meanings cannot be preserved. Record an authorized compatibility report with accepted/rejected objects, mappings and reasons.
5. Obtain fresh local review and authority as required. Preserve imported confirmation as provenance and create any local confirmation as a separate event.
6. Publish only eligible versions and separately authorized derivatives. Establish fresh grants before client disclosure; imported grants MUST NOT be replayed.

A quarantined object MUST NOT enter general vector/search indexes, summaries or externally visible counts. A restricted administrative preview MAY expose it only to separately authorized reviewers under the same confidentiality controls. A receiver unable to meet a required deletion or processing obligation MUST reject activation, not offer an unchecked acknowledgment.

**PHC-R16 — Cryptographic and custody binding.** Confidential customer export requires a separately approved recipient-bound encrypted and authenticated binding. Signing and encryption keys MUST have separate roles; trust anchors MUST come from controlled configuration. A signature proves attributable origin/integrity, not truth, consent, professional capacity or safe processing. Expiry protects admission/future access, not plaintext already decrypted by a recipient.

JCS canonicalization, signed payloads and recipient-bound JWE are relevant building blocks, not a complete PHC cryptographic profile. RFC 9864 updates RFC 8037, introduces fully specified JOSE `Ed25519`, and deprecates the polymorphic `EdDSA` identifier. A PHC exchange binding MUST settle exact algorithm identifiers, library support, canonical bytes and compatibility before release. This does not change upstream DEC identifiers or signed artifacts. [S06–S08](SOURCES.md#s06-jose-and-algorithm-update)

Managed decryption, attested confidential processing and provider-blind local custody MUST be advertised as distinct profiles. A service with ordinary readable semantic/vector search MUST NOT claim provider-blind E2EE. An attested runtime's disclosure to an external model MUST be evaluated as a processing route, not hidden behind the attestation claim.

## 10. Transport, receipts and errors

**PHC-R17 — Equivalent enforcement.** An MCP or HTTPS binding MUST invoke equivalent underlying authorization and lifecycle decisions. The candidate tool names are `context_query`, `memory_propose`, `proposal_status` and `receipt_get`; owner confirmation, grant administration, deletion and export remain outside agent tools. A structured result and its text fallback MUST derive from the same authorized object and MUST NOT disclose different fields. Native provider tool approval is not PHC owner confirmation or sharing consent.

**PHC-R18 — Minimized evidence.** A decision receipt MUST bind the operation, relevant actor/client, purpose, decision, time, policy/authority version, disclosed record versions or protected references, route and reason category where authorized. Receipts MUST distinguish requested, authorized and actually disclosed content. Receipts and denial reasons MUST NOT leak hidden existence or another recipient's activity. A failed operation MUST expose no protected payload as an error detail or model-visible credential.

Candidate common error categories are invalid credentials, unauthorized, opaque missing/not-visible handle, version/idempotency conflict, size limit, unsupported semantic mapping, rate/budget limit, and unavailable current security state. HTTP bindings can use 401/403/404/409/413/422/429/503 mappings and 202 pending result. Transport-specific authentication challenges MUST still follow their protocol. Precise internal diagnostics require separate authorized access.

## 11. Versions, extensions and conformance claims

**PHC-R19 — Explicit compatibility.** Every published binding MUST have immutable versioned artifacts and a compatibility matrix. A change that alters required interpretation, expands authority, changes cryptographic bytes/identifiers or permits a previously forbidden operation requires explicit compatibility review. Unknown required revisions fail closed. A downgrade MUST NOT remove mandatory meaning. Implementations MUST pin exact tested versions rather than claim support for a moving `latest` URL.

Extension identifiers MUST distinguish publisher namespace, capability name and version. Until governance chooses a registry and URI policy, identifiers in examples are local draft labels only. No extension may override core authority or lifecycle requirements. A public registry, if adopted, MUST contain nonpersonal definitions rather than customer facts or source identifiers.

**PHC-R20 — Bounded qualification claims.** A claim of conformance MUST identify exact implementation/release, binding, capabilities, custody/processing profile, applicable suite and evidence. Schema acceptance alone MUST NOT be called security, service or interoperability conformance. Unsupported mandatory capabilities are blocked/failing qualification, not passed skips. A qualification or DCER certificate MUST NOT substitute for current consent or claim universal safety.

## 12. Migration and compatibility

A format migration must include a complete field mapping, reversibility and loss analysis, executable schemas, valid and invalid vectors, cryptographic vectors and equivalent authorization results. A format name or similar field spelling does not establish shared meaning.

| Meaning to preserve | Compatibility obligation |
|---|---|
| Format and schema version | Use exact negotiated identifiers; do not silently rename a different format as PHC |
| Identity and custody | Preserve source namespaces and resolve destination bindings explicitly |
| Assertion and confirmation | Preserve authenticated versus reported provenance; confirmation remains historical evidence |
| Classification and restrictions | Preserve known mandatory meaning or block use; a policy reference alone is insufficient |
| Derivation | Resolve exact parent versions and inherited restrictions before derived use |
| Personas and preferences | Keep role associations and advisory preferences distinct from authority |
| Lifecycle and tombstones | Preserve deletion and invalidation without restoring deleted plaintext |
| Checkpoints and replay | Preserve scoped sequence/completeness semantics and prevent duplicate activation |
| Grants and credentials | Exclude live authority and secrets through allowlisted export construction |
| Cryptographic evidence | Verify the exact negotiated profile without altering signed bytes |

Down-conversion is permitted only for an explicitly reviewed subset whose required semantics are representable; otherwise it is rejected. Existing implementations may continue under their own accurately scoped contracts. This draft does not promise compatibility with another format or supply a migration adapter.

## 13. Areas requiring further specification

1. Define interoperable binding versions, registry namespace and complete schema grammar, including independent dependency closure and partial-import rules.
2. Review classification, purpose and restriction vocabularies; define verifiable mappings without weakening custody.
3. Specify identity-link/recovery evidence and clock, freshness, offline-use and revocation bounds per profile.
4. Select crypto identifiers and tested libraries; settle canonicalization, key resolution, rotation and replay vectors.
5. Implement and independently exercise the [conformance plan](CONFORMANCE.md), including failure paths and recipient obligations.
6. Define governance and conformance claim policies before operating a formal conformance program; see [Governance](GOVERNANCE.md) and [Draft status](RELEASE.md).