The reference implementation of Open Personal Context.
Open Personal Context is an open specification for how a person's context is typed, deliberately disclosed and verifiably accounted for across AI assistants and services. Autonym is its reference implementation and steward.
Autonym is a general-purpose personal context system. It is designed to let a person keep one record they control, choose what each assistant or service receives, and review anything a service contributes before it is added.
The aim is a reference anyone can check without asking: read the specification here, connect an assistant to a sandbox record of synthetic data, run the conformance suite against your own implementation, and run the same server locally or on your own host. The specification is published; the sandbox, the conformance suite, local mode and self-hosting are planned and not released.
Bindings for PDPP, MCP and REST. The reference implementation is not released.
// Draft MCP tool call from an assistant holding an L1 grant
{
"name": "get_context",
"arguments": {
"domains": ["communication", "agent"],
"max_level": "L1"
}
}Illustrative draft. Not verified against a released server, and subject to change.
Data access is not the same as context
Existing standards are increasingly good at storing personal data, granting access and moving records between services. Open Personal Context starts where those layers stop.
It gives portable meaning to personal context: facts, preferences, activities, inferences and temporary situations, together with their provenance, confidence, validity and sensitivity.
It then resolves what is relevant now before anything is shared.
The same person does not need to reveal the same thing to every service
Open Personal Context lets a person set a standing disclosure level for each recipient and context domain.
A travel assistant might receive a useful rendering of travel preferences. A streaming service might receive entertainment tastes. Neither needs unrestricted access to the underlying context store.
The provider compiles the policy server-side and returns only the approved rendering.
Your context
| Recipient | Domain and level | Receives |
|---|---|---|
| Travel service | TravelL2Named | Approved travel rendering |
| TV service | ViewingL1Preferences | Approved viewing rendering |
| AI assistant | Several domainsL3Identified | Approved broad rendering |
Illustrative example of planned behaviour.
Every disclosure should leave a receipt
Open Personal Context records every successful context disclosure with a signed receipt, in a user-visible, tamper-evident history.
The aim is simple: you should be able to see who received what, for what purpose and when.
Where a grant requires previously disclosed context to be deleted after revocation, Open Personal Context also defines a purge request and recipient acknowledgement. The acknowledgement records the recipient's assertion that the purge was completed; it is not presented as proof that every downstream copy has vanished.
Build on open plumbing. Standardise the missing layer.
Open Personal Context is designed to reuse, profile or map to adjacent standards rather than duplicate them. Each one it uses has an adoption record saying the version pinned, what is taken and what is extended.
- PDPP Core provides the grant model: purpose, selection, expiry and revocation. The PDPP binding maps every grant to it.
- Linked Web Storage / Solid is an optional storage binding, informative in this edition, for an implementation that chooses it.
- MCP and REST are the bindings that expose Open Personal Context to agents and applications.
- HCP and AI-memory standards are adjacent work that Open Personal Context maps or aligns with where semantics overlap.
Open Personal Context focuses on the layer above: typed context, effective-context resolution, graded disclosure, receipts, purge accountability and provenance-preserving contribution.
References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.
Choosing something to watch
Choosing something to watch is the first worked example. Communication, work and other context belong in the same record.
A person asks an assistant for something to watch tonight. Their record holds identity, work and viewing entries. The journey is the same for every recipient:
- Keep one record. Each entry carries its provenance and validity, so progress through a series says when it was last confirmed.
- Choose what is relevant. For this request the person includes the entries that help, such as lasting viewing preferences, their progress and a communication preference recorded for work. An unrelated work note stays out. Tonight's mood and the time available travel with the request, not the record.
- Check exactly what will be sent. The provider compiles the view for that recipient, and the person can inspect exactly that view before it is shared. It carries no omitted values, internal identifiers or counts of what was left out.
- Use it with an assistant. The recipient reads that view under its grant, and the read is recorded as a receipt.
- Change or stop future access. A changed selection produces a new view. Revocation stops further reads; a copy already sent remains a copy.
Services can contribute as well as read. A streaming service can propose a viewing event, and the person approves or declines it. Approval records an observation. It does not change a stated taste or mark a title as liked.
The underlying storage could be Solid/LWS or another conformant store. The authorisation could be carried through PDPP. The personal-context semantics and disclosure behaviour are defined by Open Personal Context.
The browser demonstration shows this journey as a simulation with fictional data. What it checks
Illustrative example of planned behaviour, with fictional data.
A profile, not another silo
Open Personal Context is intended to be implementable without Autonym.
Conformance is claimed per capability, as a provider or as a recipient:
- Provider capabilities: Core, Write, Portable, Delegated
- Recipient capabilities: Read, Contribute, Reciprocal
A formal claim writes the name out in full, for example "Open Personal Context Core provider". Every MUST and SHOULD in the normative text maps to a stable check in the conformance manifest, or to the reason no suite can test it, and the manifest shows which checks have executable library tests, which have the reference implementation's integration tests and which are still pending.
Autonym is the reference implementation and project steward, not the only place Open Personal Context data can live.
Where each part stands
| Part | Where it stands |
|---|---|
| Draft specification | Published. Edition 1.0-draft-1 of Open Personal Context is published on this site: the core, the PDPP, MCP and REST bindings, the vocabulary, the conformance manifest with its statement audit and test vectors, an adoption record for every standard it uses and a worked example for media. |
| Disclosure compiler | Implemented as a library. A tested library in the reference repository selects and renders what a recipient may receive under a grant. No service uses it yet: there is no authenticated read or stored grant, and no receipt is issued for a read. |
| Reference implementation | Planned. The server, a sandbox of synthetic records, a demo recipient, a public conformance runner, local mode and a self-host bundle, built in phases with the specification first. None of them is released. |
| Interactive demonstration | Browser simulation. A browser-only demonstration with fictional data walks through the watch example: choosing what a recipient receives, checking the exact text, reviewing a proposed event and stopping future access. It is a simulation, not a service. |
Now
Edition 1.0-draft-1 of Open Personal Context is published, with a PDPP binding, an adoption record for every standard it uses and a worked example for media. The schemas, the scope grammar, a disclosure compiler library, a signature verifier library and published test vectors exist, and a browser demonstration uses fictional data.
Next
The reference implementation, specification first: the vocabulary and the compiler, then encrypted storage and the log, authorisation on PDPP Core, and the read path with signed receipts.
After that
Testable by a stranger: the same server locally and self-hosted, a sandbox of synthetic records on autonym.me, a demo recipient and a public conformance runner. Then the repositories open for review.
Later
Contribution and purge, moving a record between hosts, importing from assistant exports, and launch readiness before real accounts open. Family features, emergency cards and the recipient registry are reserved for a later version.
Personal context should travel without becoming public property.
Store it where you choose. Authorise it using open standards. Share only the rendering you approved. Keep a record of every disclosure.