# OCP 0.4 validation record

**Release:** 0.4 Portable AI History — Consolidated Editor's Working Draft  
**Validation date:** 13 August 2026  
**Evidence scope:** local reference materials only  
**System under test:** none

## Reproduce

From this directory, with Node.js 20 or later:

```text
npm ci
npm test
```

The checked-in dependency lock resolves Ajv 8.20.0, ajv-formats 3.0.1, and canonicalize 4.0.0. The synchronized machine reports record the exact Node runtime, platform, and architecture. Dependencies are not part of the publication package; `node_modules` must be recreated with `npm ci`.

Fixture generation and appendix synchronization are separate, intentional source-maintenance operations:

```text
npm run generate
npm run validate:semantics
npm run build:assertions
npm test
npm run sync:spec
```

Publication rendering uses the exact versions documented in `README.md` and the pinned packages in `requirements-docs.txt`. `npm run build:docs` emits both the DOCX and the LibreOffice-rendered PDF. The DOCX and release ZIP are normalized and reproduced byte-for-byte from identical frozen inputs on the recorded Python/zlib build. The PDF is rebuilt, hashed, and visually inspected; no cross-host byte-identity claim is made for LibreOffice output.

## Synchronized checked-in results

The following values come directly from the checked-in reports generated from this source tree:

| Check | Result | Evidence |
|---|---:|---|
| JSON Schema Draft 2020-12 compilation | 37 / 37 | `validation-report.json` |
| Complete positive examples | 32 / 32 | `validation-report.json` |
| Single-mutation negative examples rejected at declared rule | 45 / 45 | `validation-report.json` |
| Cross-object semantic reference vectors | 243 / 243 | `semantic-validation-report.json` |
| Registry, OpenAPI, and evidence-accounting gates | 29 / 29 | `validation-report.json` |
| Portable AI History profile cases | 25 / 25 | `portable-history-validation-report.json` |
| — positive / negative / hostile / round trip | 9 / 6 / 6 / 4 | `portable-history-validation-report.json` |
| Registered assertions with exactly one result | 134 / 134 | `conformance/assertions.json`, `conformance/assertion-results.json` |

Assertion-result status counts:

| Status | Count | Meaning in this release |
|---|---:|---|
| `executed_pass` | 0 | No identified implementation was exercised. |
| `executed_fail` | 0 | No identified implementation was exercised. |
| `partial_evidence` | 90 | One or more local schema or semantic reference-vector facets passed. |
| `manual_required` | 4 | The requirement needs deployed, human, parser, or equivalent non-fixture evidence. |
| `unavailable` | 3 | A required registered security profile and vectors do not exist. |
| `not_executed` | 37 | The assertion is registered without applicable evidence in this release. |

## What the harness checks

The harness compiles every discovered core/profile/binding/conformance schema, validates every positive example, rejects every negative example at its named schema location and keyword, runs typed cross-object comparisons and tamper vectors, accounts for every assertion, checks lifecycle/error/event/availability metadata, and prevents reference vectors from becoming implementation passes when `system_under_test` is null. The Portable AI History harness additionally checks conversation graph cycles/closure/missing parents/branches, artifact byte digests and disappearance transitions, adapter determinism and 16-case coverage, loss-code resolution, source-role isolation, critical/non-critical extension behavior, hostile corpora, round-trip comparison, and publication OpenAPI reference closure. Evidence identifiers are checked against the registered inventory. The current report format does not carry a complete source-input digest set or a freshness proof, so publication validation does not claim cryptographic provenance for report generation. A string identifier or fragment alone is not implementation evidence.

The semantic comparator checks exact immutable references; declaration-to-request and request-to-receipt-to-package containment; exact purpose objects; order-independent processing-recipient, role, and purpose-code sets; selector/view/time/retention/use/offline/proposal-right/delegation containment; accepted decision-to-result projections with `accepted_scope` and without `decision_ref`; package-local aliases; package integrity; source verification evidence; exact typed assurance evidence with causal SourceRecord chronology, authenticated evaluator-role binding, and an exact-declaration-keyed current policy result; offline signed-view construction; path/member rules; and profile authority boundaries.

The schema/semantic harness parses JSON with the host parser before schema evaluation. Publication QA separately scans every included JSON source and embedded appendix block before parsing, rejects duplicate member names including escape-equivalent keys, and self-tests that detector. That source-integrity gate is not a raw-input conformance corpus for a provider/client parser. It does not demonstrate an identified implementation rejecting a UTF-8 BOM, lone surrogates, non-finite numeric tokens, excessive inputs, or every numeric boundary; those facets remain partial until a raw-input, cross-language corpus is run against an identified implementation.

## Evidence boundary

Passing reference vectors establishes consistency of the checked-in artifacts only. It does not establish:

- a deployed provider, client, importer, or authorization service;
- interoperability between independent implementations;
- actual signing, encryption, key discovery, rotation, revocation, or recipient binding;
- parser sandboxing, decompression defenses, media safety, SSRF resistance, or prompt-injection containment in a model/tool runtime;
- human understanding, accessible consent, freedom from coercion, or lawful stewardship;
- recipient purpose, training, retention, forwarding, or deletion behavior;
- production security, legal compliance, standards-body adoption, or live human acceptance.

Remote Package Security (`SEC-001`, `SEC-002`) and Offline Package Protection (`XFR-004`) remain explicitly unavailable in `conformance/availability.json`. Example security-profile URIs are structural examples, not registered algorithms and not proof that cryptography ran.

Any future conformance report must identify its system under test, actor role, deployment boundary, exact version/profile set, evaluator, test time, inputs, observed outcomes, exceptions, and evidence digests. Only complete evidence for every required facet may produce `executed_pass`.
