@oxdeai/conformance 1.3.1 → 2.0.0

package/CHANGELOG.md

@@ -7,6 +7,94 @@ This project follows Semantic Versioning.
 
 ---
 
+## [2.0.0] - Unreleased
+
+**Baseline for this entry:** the published `@oxdeai/conformance@1.3.1` npm artifact
+(2026-03-08).
+
+> ⚠️ `1.5.0` appears in this changelog and as the Git tag `conformance-v1.5.0` but
+> **was never published to npm**. `1.3.1` is the last released artifact and is the
+> baseline used here. The `1.5.0` entry below is retained as historical record of
+> the source change, not of a release.
+
+The vector corpus is this package's public contract, and it has roughly doubled
+since the last published artifact.
+
+### Breaking
+
+- **The suite now targets the `@oxdeai/core` 2.0 line.** The dependency is an exact
+  pin, so a build of this package validates the 2.0 protocol surface and cannot be
+  used to validate a `core@1.x` implementation. Implementers tracking the 1.x line
+  must stay on `@oxdeai/conformance@1.3.1`.
+- Vector regeneration under the trusted-time engine changed expected values wherever
+  a vector's evaluation depended on time. Existing vector expectations captured
+  against the 1.3.1 engine will not match.
+
+### Added
+
+Nine vector families that did not exist in the published `1.3.1` artifact:
+
+- `trusted-time.json` — trusted-time freshness semantics
+- `clock-semantics-verification.json`
+- `delegation-verification.json`, `delegation-chain-verification.json`,
+  `delegation-parent-hash.json`, `delegation-signature-verification.json`
+- `signed-krl-verification.json` — `SignedKRLV1`
+- `key-lifecycle-verification.json`
+- `profile-c-state-verification.json`
+
+Also added: the `validate:trusted-time` entry point and the trusted-time conformance
+runner.
+
+### Changed
+
+- The validator no longer reads `OXDEAI_ENGINE_SECRET` from the environment; both
+  `extract-vectors` and `validate` use `CONFORMANCE_ENGINE_SECRET` unconditionally,
+  so the suite is deterministic regardless of shell environment.
+- Delegation chain and signature verification run on an independent recomputation
+  path rather than through an engine call.
+
+### Packaging
+
+- An explicit `files` field is declared. The artifact now ships `vectors/`, the
+  compiled validator, README, CHANGELOG and LICENSE only. It no longer ships
+  TypeScript sources, `tsconfig.json`, the Go/Python harness directory, or compiled
+  test files — the harnesses remain in the repository and are run from source.
+- `prepack` now rebuilds before packing.
+- `repository` (with `directory`), `homepage` and `bugs` are declared for npm
+  provenance.
+
+---
+
+## [1.5.0] - 2026-03-30
+
+### Changed
+
+- Secret constant made deterministic; `engine_secret` env var override removed from validator.
+- Conformance vectors regenerated with 32-char secret to meet enforced minimum-length requirement.
+- `envelope-001` hashes updated after `deepMerge` non-mutation correction in `@oxdeai/core`.
+- DelegationV1 chain and signature verification moved to independent recomputation path (no engine call).
+
+### Notes
+
+- Protocol vector behavior has changed from `1.4.0` — vectors are not backward-compatible with the `1.4.x` line.
+- Protocol stack alignment: `@oxdeai/core@1.6.1`, `@oxdeai/sdk@1.3.2`.
+
+---
+
+## [1.4.0] - 2026-03-25
+
+### Changed
+
+- Version-line release alignment for `@oxdeai/conformance@1.4.0`.
+- Package metadata updated for the `1.4.x` publication line.
+
+### Notes
+
+- No conformance vector or validator semantic changes from `1.3.1`.
+- Frozen protocol behavior remains unchanged; this release keeps the package line current with the published metadata.
+
+---
+
 ## [1.3.1] - 2026-03-08
 
 ### Changed

package/LICENSE

@@ -0,0 +1,213 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+ 
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+ 
+
+   1. Definitions.
+ 
+    http://www.apache.org/licenses/LICENSE-2.0
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.
+ 
+
+OxDeAI
+Copyright 2026 OxDeAI contributors
+
+This product includes software developed by the OxDeAI project
+(https://github.com/oxdeai/oxdeai).
+
+

package/README.md

@@ -1,6 +1,6 @@
 # @oxdeai/conformance
-
-Conformance vectors and validator for the OxDeAI protocol.
+Conformance vectors and validator for the OxDeAI execution-time authorization protocol.
+Ensures implementations reproduce deterministic AuthorizationV1 artifacts and boundary verification (fail-closed).
 
 ## Purpose
 `@oxdeai/conformance` verifies that an implementation matches the frozen protocol behavior for a specific version.
@@ -8,10 +8,12 @@ Conformance vectors and validator for the OxDeAI protocol.
 Passing validation means the implementation reproduces expected deterministic artifacts (hashes, statuses, and verification outputs) from frozen vectors.
 
 ## Version Coupling
-- `@oxdeai/conformance@1.3.x` targets protocol/core `1.3.x` behavior.
+- `@oxdeai/conformance@2.0.0` targets `@oxdeai/core@2.0.0` behavior.
 - Use matching major/minor protocol versions when validating.
 
 ## Included Vector Sets
+
+### Core protocol (pre-v1.3)
 - `intent-hash.json`
 - `authorization-payload.json`
 - `snapshot-hash.json`
@@ -22,7 +24,142 @@ Passing validation means the implementation reproduces expected deterministic ar
 - `authorization-signature-verification.json`
 - `envelope-signature-verification.json`
 
-Current validator assertion count: `94`.
+### DelegationV1 (v1.3+)
+- `delegation-parent-hash.json` - `delegation_parent_hash = SHA256(canonical_json(AuthorizationV1))`; key-order invariance (I1)
+- `delegation-verification.json` - `verifyDelegation()` field-level checks: expiry, scope narrowing, delegatee, policy, replay, trust-missing
+- `delegation-chain-verification.json` - `verifyDelegationChain()` chain checks: hash binding, delegator, parent expiry, expiry ceiling, single-hop, policy binding
+- `delegation-signature-verification.json` - Ed25519 signature path: valid, tampered sig, wrong kid, tampered field, expired
+
+### Profile C - Semantic State Verification (v1.5+)
+
+- `profile-c-state-verification.json` - models selected Profile-C state-hash comparisons (guard step 10), separately from actual guard integration: `computeStateHash(liveState)` compared against the committed `state_hash` in the authorization.
+
+Eight vectors covering:
+
+| Vector | Mode | Expected outcome |
+|--------|------|-----------------|
+| `profile-c-001` | `live-state-match` | `ok` - same state at signing and verification |
+| `profile-c-002` | `live-state-mismatch` | `state-hash-mismatch` - state advanced between signing and execution |
+| `profile-c-003` | `hash-strategy-mismatch` | `state-hash-mismatch` - provider hash committed, Core algorithm at verification |
+| `profile-c-004` | `compute-throws` | `compute-error` - `computeStateHash` throws; execution blocked fail-closed |
+| `profile-c-005` | `toctou-stale-state` | `state-hash-mismatch` - TOCTOU: state advanced since authorization was issued |
+| `profile-c-006` | `encoding-b-live-state-match` | `ok` - Encoding B (Sift-compatible) + matching state |
+| `profile-c-007` | `encoding-b-live-state-mismatch` | `state-hash-mismatch` - Encoding B + stale state |
+| `profile-c-008` | `encoding-b-hash-strategy-mismatch` | `state-hash-mismatch` - Encoding B + strategy mismatch |
+
+Two hash strategies modelled:
+
+| Strategy | Algorithm |
+|----------|-----------|
+| `core` | `sha256HexFromJson` (Core-native) |
+| `provider` | SHA-256 of `"PROVIDER:" + canonicalJson(state)` (simulates external provider hash) |
+
+Encoding B vectors (`profile-c-006` through `profile-c-008`) exercise the Sift-compatible wire format (`alg="ed25519"`, `expires_at`, base64url signature) combined with live-state semantic verification.
+
+### Key Lifecycle (v1.5+)
+
+- `key-lifecycle-verification.json` - exercises `keyIsActiveAt`, `findKeyInKeySets`, and `AUTH_KEY_INACTIVE` / `AUTH_KID_UNKNOWN` enforcement across all key status and time-window states.
+
+Ten vectors covering:
+
+| Vector | Mode | Expected outcome |
+|--------|------|-----------------|
+| `key-lifecycle-001` | `key-active` | `ok` - active key, no time constraints |
+| `key-lifecycle-002` | `key-revoked` | `AUTH_KEY_INACTIVE` - revoked key rejected |
+| `key-lifecycle-003` | `key-not-before-future` | `AUTH_KEY_INACTIVE` - key not yet active |
+| `key-lifecycle-004` | `key-not-after-past` | `AUTH_KEY_INACTIVE` - validity window expired |
+| `key-lifecycle-005` | `key-valid-window` | `ok` - explicit `not_before`/`not_after` window active |
+| `key-lifecycle-006` | `key-expired-window` | `AUTH_KEY_INACTIVE` - `not_after` in the past |
+| `key-lifecycle-007` | `key-retired-within-window` | `ok` - retired key accepted during dual-sign overlap window |
+| `key-lifecycle-008` | `key-retired-past-window` | `AUTH_KEY_INACTIVE` - retired key, window closed |
+| `key-lifecycle-009` | `key-revoked-valid-window` | `AUTH_KEY_INACTIVE` - revocation overrides valid time window |
+| `key-lifecycle-010` | `wrong-kid-known-issuer` | `AUTH_KID_UNKNOWN` - correct issuer, unknown kid |
+
+### Clock Semantics (v1.5+)
+
+- `clock-semantics-verification.json` - exercises strict zero-tolerance expiry enforcement (`now < expiry`) and `issued_at` informational-only semantics for both wire encodings.
+
+Five vectors covering:
+
+| Vector | Mode | Expected outcome |
+|--------|------|-----------------|
+| `clock-001` | `last-valid-second` | `ok` - `now = expiry - 1`, last valid second |
+| `clock-002` | `one-past-expiry` | `AUTH_EXPIRED` - `now = expiry + 1`, no grace period |
+| `clock-003` | `verifier-clock-behind` | `ok` - `now < issued_at`, `issued_at` not enforced as lower bound |
+| `clock-004` | `encoding-b-last-valid-second` | `ok` - Encoding B (`expires_at`), `now = expires_at - 1` |
+| `clock-005` | `encoding-b-verifier-clock-behind` | `ok` - Encoding B, `now < issued_at` |
+
+Clock model: **strict zero tolerance**. Valid iff `now < expiry`. No skew parameter, no grace period. Issuers must build delivery latency into the expiry window. See `authorization-v1.md §17`.
+
+### SignedKRLV1 Verification (v1.6+)
+
+- `signed-krl-verification.json` - exercises `verifySignedKrl` across all verification paths for the `SignedKRLV1` protocol artifact.
+
+Nine vectors covering:
+
+| Vector | Mode | Expected outcome |
+|--------|------|-----------------|
+| `krl-001` | `valid` | `ok` - signature verifies, not expired |
+| `krl-002` | `invalid-signature` | `KRL_SIG_INVALID` - tampered signature |
+| `krl-003` | `expired` | `KRL_EXPIRED` - `now >= not_after` (strict zero-tolerance) |
+| `krl-004` | `malformed-revoked-kids` | `KRL_MALFORMED` - `revoked_kids` is a string, not an array |
+| `krl-005` | `duplicate-revoked-kids` | `KRL_MALFORMED` - duplicate entries in `revoked_kids` |
+| `krl-006` | `unknown-signing-kid` | `KRL_UNKNOWN_SIGNING_KID` - kid not in trusted KRL signing key set |
+| `krl-007` | `signing-key-inactive` | `KRL_SIGNING_KEY_INACTIVE` - key found but `keyIsActiveAt` returns false |
+| `krl-008` | `unsupported-alg` | `KRL_UNSUPPORTED_ALG` - `signature.alg != "Ed25519"` |
+| `krl-009` | `version-regression` | `KRL_VERSION_REGRESSION` - `krl_version` less than previous accepted value |
+
+Signing domain: `OXDEAI_KRL_V1`. KRL signing fixture key (`krl-2026-01`, issuer `krl.issuer`) is distinct from the AuthorizationV1 / DelegationV1 signing fixture key to exercise trust-domain separation.
+
+**Coverage scope:** TypeScript / `@oxdeai/core` conformance runner. The separate docs SignedKRL corpus is consumed by the root Go/Python harnesses. These are distinct corpora, not a projection or mirror.
+
+### Trusted-Time Semantics (v2.0+)
+
+- `trusted-time.json` - exercises the trusted-time freshness gate (`docs/spec/core/trusted-time-v1.md`) end to end: issuance, velocity, tool-window, and replay evaluation under trusted `evaluationTime`, plus protocol-domain and malformed-input rejection.
+
+44 vectors, 1 assertion each, run via a dedicated `runTrustedTimeConformance` harness (`src/trustedTimeConformance.ts`) rather than the generic vector-comparison path used by the sets above.
+
+Current validator assertion count: `262` (re-run `pnpm -C packages/conformance validate` for the live figure before relying on this number).
+
+### Adapter ops required for DelegationV1
+
+| Op | Input | Output | Independence |
+|----|-------|--------|--------------|
+| `delegation_parent_hash` | `{ parent: AuthorizationV1 }` | `{ parent_auth_hash: hex }` | Full - SHA256 + canonical JSON |
+| `verify_delegation` | `{ delegation: DelegationV1, opts }` | `{ status, violations, policyId }` | Full - no crypto required |
+| `verify_delegation_chain` | `{ parent, delegation, opts }` (inline) | `{ status, violations }` | Full - hash recomputation + structural checks |
+| `verify_delegation_signature` | `{ parent, delegation, opts }` (inline) | `{ status, violations }` | Full - chain checks + Ed25519 via test key material |
+| `verify_delegation_chain_case` | `{ id: string }` | `{ status, violations }` | Lookup (frozen) |
+| `verify_delegation_signature_case` | `{ id: string }` | `{ status, violations }` | Lookup (frozen) |
+
+The optional `packages/conformance/go-harness` driver (not root vector CI; Python adapter blocked by #306) uses `verify_delegation_chain` and `verify_delegation_signature`
+with inline `input` from the vector files. Those operations are designed to recompute
+`SHA256(canonical_json(parent))`, perform the chain-level structural checks,
+and (for signature cases) perform Ed25519 verification using the test key
+material embedded in `opts.trustedKeySets`. Lookup ops are retained for
+compatibility but not used by the harness runners.
+
+### Coverage distinction
+
+The `Cross-language?` column reports what `pnpm test:vectors:go` and
+`pnpm test:vectors:py` actually execute, not what is portable in principle.
+Those commands exercise three corpora: canonicalization-v1 (11 vectors),
+Profile-C state verification (8), and SignedKRLV1 (9) - 28 assertions per
+language. Everything else is TypeScript-only today.
+
+| Layer | What it covers | Cross-language? |
+|-------|---------------|-----------------|
+| `delegation-parent-hash.json` | Hash stability, I1 key-order invariance | TypeScript only - portable in principle (SHA256 + canonical JSON), but not exercised by `test:vectors:go` |
+| `delegation-verification.json` | Field checks, expiry, scope, replay, trust-missing | TypeScript only - portable in principle (no crypto required), but not exercised by `test:vectors:go` |
+| `delegation-chain-verification.json` | Chain structural checks (hash binding, delegator, expiry ceiling, policy) | TypeScript only - Go and Python adapters exist in `go-harness/` but are not exercised by `test:vectors:go`; the Python adapter fails at import (#306) |
+| `delegation-signature-verification.json` | Ed25519 verification path | TypeScript only - Go and Python adapters exist in `go-harness/` but are not exercised by `test:vectors:go`; the Python adapter fails at import (#306) |
+| `key-lifecycle-verification.json` | Key status (active/revoked/retired), `not_before`/`not_after` windows, wrong-kid rejection | TypeScript only - portable across any `verifyAuthorization` implementation, but `validate.ts` is its only consumer |
+| `clock-semantics-verification.json` | Strict zero-tolerance expiry, `issued_at` informational, Encoding A + B boundary pins | TypeScript only - portable, no crypto required, but `validate.ts` is its only consumer |
+| `trusted-time.json` | Trusted-time freshness gate: issuance, velocity, tool-window, replay under `evaluationTime`; protocol-domain and malformed-input rejection | TypeScript only (dedicated `runTrustedTimeConformance` harness) |
+| `profile-c-state-verification.json` | Generated Profile-C representation; preserved signed fixtures and expected-result projection | TypeScript consumes this projection; Go/Python consume the docs authority. Same eight cases, not independent corpora. |
+| `delegation.property.test.ts` (D-P1–D-P5) | PBT over scope / hash / mutation | TypeScript only |
+| `guard.delegation.property.test.ts` (G-D1–G-D3) | Guard PEP delegation path | TypeScript only |
+| `cross-adapter.test.ts` (CA-1–CA-10) | Cross-adapter equivalence, I6 | TypeScript only |
 
 ## Usage
 From repo root:
@@ -35,9 +172,12 @@ pnpm -C packages/conformance validate
 Expected success output includes:
 
 ```text
-Conformance passed: 94 assertions
+Conformance passed: 262 assertions
 ```
 
+(This figure moves as vectors are added. Treat the live `pnpm validate` output
+as authoritative, not this number.)
+
 ## Adapter Contract
 The validator is built around a pluggable adapter (`ConformanceAdapter`) so non-TypeScript runtimes can be checked against the same vectors.
 
@@ -50,9 +190,81 @@ An adapter must provide deterministic implementations for:
 
 Reference adapter: `@oxdeai/core` (implemented in `src/validate.ts`).
 
+## Verification Artifact Scope
+
+![Verification envelope flow](../../docs/diagrams/verification-envelope-flow.svg)
+
+Conformance checks deterministic behavior for artifacts and verifiers used in this flow (snapshot, audit, authorization, envelope, and verification status outputs).
+
+Diagram source/editing policy:
+- [`docs/diagrams/README.md`](../../docs/diagrams/README.md)
+
+## Profile-C authority and generated representation
+
+`vectors/profile-c-state-verification.json` is generated solely from
+`docs/spec/test-vectors/profile-c-state-verification.json`. Edit the authority,
+then run `pnpm project:profile-c` from the repository root.
+`pnpm verify:corpus-authority` checks semantic and exact-byte consistency without
+writing files. Build/prepack use the committed projection and do not copy either
+vector tree. See [corpus authority](../../docs/conformance/corpus-authority.md).
+The remaining package corpora retain their own frozen authorities.
+
 ## Freeze Policy
 Vectors are frozen per protocol version.
 
 - Do not regenerate vectors for the same protocol version after behavior changes.
 - Any behavior-impacting change requires a new protocol/versioned vector release.
 - Regeneration is allowed only when intentionally producing a new version baseline.
+
+## Interoperability Profiles
+
+OxDeAI defines three interoperability profiles. Conformance coverage maps directly to profile requirements:
+
+| Profile | Description | Vector sets required |
+|---------|-------------|----------------------|
+| A | Core-native `AuthorizationV1` | Core protocol + DelegationV1 |
+| B | External provider wire-compatible (Encoding A and Encoding B accepted) | Core + authorization-signature vectors |
+| C | Semantic state verification via `computeStateHash` | Core + DelegationV1 + Profile C state vectors (selected cases, not full deployment proof) |
+
+Profile C now has **executable conformance coverage** via `profile-c-state-verification.json` (15 assertions).
+
+Key lifecycle enforcement (Profile A/B/C) is covered by `key-lifecycle-verification.json` (20 assertions): active, revoked, retired (within/past window), `not_before`/`not_after` time windows, and wrong-kid rejection.
+
+Clock semantics (all profiles) are covered by `clock-semantics-verification.json` (10 assertions): strict zero-tolerance expiry, `issued_at` informational-only, Encoding A and Encoding B boundary pins.
+
+See [External Provider Interoperability Profile](../../docs/spec/interoperability/external-provider-profile.md) for the full profile specification, wire encoding reference, and fail-closed rules.
+
+## Using OxDeAI Conformance from Other Languages
+
+Conformance vectors are the behavioral truth source for protocol compatibility.
+
+Rust, Go, and Python implementations should validate their verifier/engine behavior against these vectors.
+Passing conformance means the implementation is behaviorally aligned with the OxDeAI protocol profile for that version line, including executable interoperability coverage where applicable.
+
+Profile C vectors (`profile-c-state-verification.json`) require a `computeStateHash` integration point. Cross-language harnesses must supply a compatible hash function to exercise those vectors.
+
+Related implementer docs:
+
+- [`docs/verification/multi-language.md`](../../docs/verification/multi-language.md)
+- [`docs/conformance/conformance-vectors.md`](../../docs/conformance/conformance-vectors.md)
+- [`docs/spec/interoperability/external-provider-profile.md`](../../docs/spec/interoperability/external-provider-profile.md)
+- [`packages/conformance/go-harness`](./go-harness)
+
+## Scoped results
+
+Conformance PASS is limited to the declared `evidenceScope`. The package validator
+emits `{ result, passed, failures, evidenceScope }`; after building, run
+`node dist/src/validate.js --json` for JSON-only stdout. The dedicated trusted-time
+CLI also accepts `--json`, and `runTrustedTimeConformance` adds `evidenceScope` to
+its returned summary. Existing counts and failure exit codes are unchanged.
+
+Coverage uses exact registry evidence mappings and actual passing cases;
+`excludedClaims` is the registry complement, not a handwritten list. Coverage
+means only the listed `supports` statements, never whole-protocol conformance or
+proof of all claim obligations. Reference-generated expectations remain bounded
+by the #325 provenance audit. No assurance class or signed attestation is added.
+
+Builds bundle a metadata snapshot so installed packages can report explicit
+exclusions and source identifiers without the repository checkout. See
+[the schema and limitations](../../docs/conformance/evidence-scope.md), including
+snapshot freshness, direct diagnostic harnesses and deployment exclusions.