# Experimental PHC exchange binding

**0.1.0-draft · 14 October 2026 · Implemented offline validation profile**

This binding makes a deliberately bounded part of the PHC semantic proposal executable. Its format is `phc-exchange-experimental`, version `0.1.0-draft`, with schema identifier `urn:phc:experimental:exchange:0.1.0`. These are local experimental identifiers, not registered media types, OAuth authorization-detail types, or an adopted PHC release. The `experimental:` capability vocabulary is likewise local to this kit.

The semantic [specification](SPECIFICATION.md) remains the broader proposal. When this binding lacks a required semantic feature, the kit rejects it. It never converts a mandatory restriction to a preference. It accepts no credentials or grants as structural fields and performs no network resolution. Data hidden inside statement text cannot be comprehensively classified or detected as a secret.

## 1. What the utility actually does

The validator checks bounded JSON parsing, the included JSON Schema, and cross-object semantic consistency. A passing result is exactly `valid_for_quarantine` with `activation: blocked`. That means the document is a candidate for a receiving service's protected review flow. There is no import database, proof authentication, subject linking, replay ledger, revocation feed, trusted lifecycle checkpoint, or permission grant in this utility.

A production importer must independently establish origin, integrity, recipient binding, export authority, identity/custody mappings, classification semantics, safety sequence completeness, replay prevention and local policy. It must hold content in a protected compartment until those checks and required reviews complete. Its activation transaction must establish fresh local authority; historical confirmation is not local consent.

## 2. Grammar and limits

[exchange.schema.json](../schemas/exchange.schema.json) is the exact machine-readable grammar. Every listed object is closed to unknown properties. Schema changes require an explicit experimental version review; a successful parse does not make a document cryptographically trusted.

| Boundary | Limit or rule |
|---|---|
| Input | UTF-8; 1 MiB uncompressed; no BOM; no decompression performed |
| Parser | 32 nested container levels; 50,000 values; 16,384 UTF-16 units per string |
| Identifiers | 1–160 ASCII characters, exact and case-sensitive; no implicit normalization |
| Records / rules / tombstones / mappings | At most 256 each |
| Personas / identity mappings | At most 32 each |
| Statement | 1–4,096 Unicode code points, additionally subject to parser limit |
| Version / sequence | Safe JSON integers; version positive, checkpoint sequence nonnegative |
| Time | Real calendar date, whole seconds, `YYYY-MM-DDTHH:mm:ssZ`; no leap second or offset form |
| Import time | Explicit `--at` in reproducible tests; system UTC clock by default; zero skew in this offline profile |
| Relationships | Empty only; graph transport remains unimplemented |
| References | Opaque data; never fetched, followed, or executed |
| Errors | At most 32 codes/structural paths; no offending statement or unknown field name echoed |

Duplicate object keys are rejected after JSON escape decoding. Invalid Unicode, nonfinite numbers, oversized strings, excess depth and malformed JSON are rejected before schema validation. Numeric identifiers and arbitrary JSON policy scripts are excluded.

## 3. Attributed records and personas

The binding supports statement-bearing `fact`, `goal`, `preference` and `episode` records, with the four proposed assertion types and five nondeleted lifecycle states. A statement may still be false, malicious, historical or disputed. The source namespace must match the exporter and each record must have one corresponding source identity tuple, explicit custody, a versioned migration entry and a classification from the local experimental vocabulary.

Classification labels `ordinary`, `sensitive`, `restricted` are ordered only inside this experimental vocabulary. They are not legal categories or mappings to an employer's policy. Another vocabulary requires a new reviewed binding or explicit trusted mapping; this kit rejects it. All records in a bundle share the scoped lifecycle collection. Cross-custodian bundles are not admitted in this slice.

The binding preserves producer versus reported run/release information. Evidence is explicitly `unverified` or `unavailable`. A historical confirmation identifies the exact reviewed record version and timestamp; it neither changes an inference's assertion type nor activates the record. `user_stated` is preserved as a source claim pending destination verification, not authenticated by the validator.

Personas contain explicit record associations, advisory preferences and optional restrictions. They cannot carry grants. A cross-custodian persona association is rejected. One record's restrictions remain attached when associated with a persona.

## 4. Mandatory restrictions

Every rule has an origin, positive version, record scope, exact capability, typed operands and `mandatory: true`. Rules must be declared in `required_capabilities` and be attached to every record in their scope. Parent rules must also cover a derivative explicitly; merely dropping the parent's rule references fails validation.

| Capability suffix (`experimental:restriction-…:1`) | Meaning at the eventual service boundary |
|---|---|
| `purposes-subset` | Requested purpose appears in every applicable set |
| `processing-routes-subset` | Every actual processing destination is in the intersection |
| `operations-subset` | Requested operation appears in every applicable set |
| `recipients-subset` | Exact verified recipient appears in every applicable set |
| `not-after` | No new operation at or after the deadline |
| `review-required` | Recipient and record version have the required authorized share/export review |
| `export-forbidden` | Matched records cannot enter a customer portability export |
| `delegation-forbidden` | No downstream delegation; absence supplies no authority |
| `qualification-required` | Current, scope-matching qualification is an additional prerequisite |

The offline validator rejects explicit export prohibition, expired rule deadlines and incompatible export purpose. It validates the other rule operands and consistency but cannot prove enforcement or current review/qualification. Receivers must evaluate every applicable rule against the actual operation. A rule recognized by this library is not a qualified service capability.

## 5. Dependencies and lifecycle

Derivation parents must exist in the same bundle at exact versions, without cycles or different subject/custody/tenant boundaries. Derivatives cannot expand parent purpose sets, lower the local classification rank or remove parent restrictions. External/missing dependencies are blocked; partial import is unsupported. This deliberately conservative closure is stricter than a future authenticated external-lineage profile.

A tombstone carries no deleted plaintext. Its sequence cannot exceed the claimed checkpoint, its namespace must match, and a live record with the same identifier cannot coexist in the same package. The validator does not establish checkpoint completeness, compare with a destination high-water mark, execute deletions or ensure recovery safety. Those remain service obligations.

## 6. Utilities and results

```bash
node bin/phc.mjs validate examples/learning.json \
  --at 2026-10-14T12:30:00Z \
  --recipient synthetic-destination-custodian
node bin/phc.mjs digest examples/learning.json
npm test
```

Exit 0 means the requested check passed within its declared scope. Exit 1 means validation rejected the artifact. Exit 2 means usage, I/O or configuration failure. JSON diagnostics are emitted to stdout; usage text goes to stderr. The timestamp in the example is a fixed synthetic evaluation clock, not a suggestion to bypass real expiry.

The browser runs the same parser, schema evaluator and semantic validator inside a worker. Input is kept in memory, not posted to a server or saved in browser storage. The web host still serves normal page assets and may collect ordinary access logs. File inputs are size-checked and decoded as strict UTF-8. Use synthetic examples while the implementation is under review.

The small schema evaluator supports only the keywords used by checked-in PHC/DEC schemas and rejects unknown keywords when compiling. It is not a general-purpose JSON Schema implementation or independently certified validator. `contentEncoding` is an annotation; DEC signature decoding is enforced separately in the Node adapter. Consumers may use another 2020-12 validator for shape, but must retain duplicate-key/bounds parsing and cross-object checks.

## 7. Compatibility and open work

No migration adapter or down-conversion to another format is supplied. The original explanatory JSON remains separately labeled and fails this binding. There is no MCP/OIDC server, JWE/JWS migration envelope, network key retrieval, or public registry allocation. Graph exchange, multiple custody collections, external lineage, full crypto vectors and independent cross-language semantic round trips require subsequent profiles and tests. The 30 original service/conformance scenarios remain unrun as end-to-end cases; local unit evidence is reported separately.