# PHC implementation guide

**Experimental integration guidance · 15 October 2026**

The validator kit checks documents and evidence within the limits described in the [binding](BINDING.md) and [DCER integration](DCER.md). Applications must supply authenticated service boundaries, current policy and lifecycle enforcement before imported context can be used.

## Integration points

1. **Export:** construct an allowlisted projection from currently authorized selected records. Preserve authenticated producer/source provenance, restrictions and lineage. Use the validator as a consistency gate before a separately specified signed and encrypted recipient-bound export. Never serialize live grants, credentials or reusable source handles.
2. **Import:** validate into isolated quarantine. Resolve identity, custody, classification and policy mappings through trusted service state. Reject unsupported mandatory capabilities and enforce replay and lifecycle barriers. Obtain fresh review and sharing authority, then recheck eligibility in the activation transaction.
3. **Qualified route admission:** resolve the exact client, release, method, runtime and profile from trusted registries. Verify pinned evidence and current trust, then assess qualification alongside current grants. A passing certificate cannot supply a missing grant. Do not accept client-provided trust snapshots.
4. **Evidence:** emit minimized decision, version and route references from actual service boundaries. Keep DEC artifacts and protected disclosure material separate. An outbox receipt does not imply delivery, deletion completion or deterministic replay.

## Service acceptance checks

| Boundary | Required service-side evidence |
|---|---|
| Quarantine isolation | Imported confirmed records remain absent from ordinary search, lists, graphs, counts and synthesis |
| Mapping | Matching email under different issuer/subject bindings cannot create an account link |
| Mandatory rules | Unknown routes or rules cannot be converted to prompt text or dropped on retry |
| Scope and version | Revocation and policy/record changes between parsing and activation prevent stale disclosure |
| Replay | An atomic accepted-bundle ledger prevents repeated activation |
| Qualification | Missing grants, changed release/model/runtime, stale status and revoked issuers deny access |
| Recovery | Restoring a backup cannot resurrect revoked grants, deleted records or old authority generations |

No production service boundary is established by the offline utilities alone. Pin a reviewed version of the kit and document supported capabilities; a moving branch is not a reproducible runtime dependency. Any migration from another format needs explicit mapping, loss analysis and independent tests.

Send implementation questions and interoperability findings to [research@engramforge.com](mailto:research@engramforge.com).