Validation results

Executed 16 September 2026 against the packaged source. These are internal engineering checks of a bounded development reference, not external certification or proof of production readiness.

Results

Check	Observed result	Scope
Python suite	182 passed	114 policy, 18 contract, 17 evidence, 4 cryptography, 18 service and 11 actual TLS/HTTP-boundary tests
Independently authored Node verifier tests	13 passed	Hostile parsing, signatures, authority, source confusion, manifests, claim deduplication and export preservation
JSON Schema checks	17 schemas compiled; 18 positive and 22 negative cases passed	Actual service lifecycle payloads plus structural mutations, using AJV 8.20.0
Independent client against live local HTTPS service	23 test groups passed	Discovery, free agreement, protected delivery, evidence/export, principal isolation and revocation
Gateway evidence instrumentation	No recorded failures	Final local integration run
Offline export verification	7 signed records and 1 agreement verified	No live service or private runtime needed; two distinct use-report records reduce to one claimed completed operation

The 182-test suite includes the original 114 policy implementation tests. Do not add the older policy package’s 130-check count to this suite and present that as nonoverlapping coverage. Schema acceptance/rejection cases are structural checks, not complete protocol conformance tests.

Raw results are retained in python-tests.txt, node-verifier-tests.txt, schema-results.json and the live client report. The sample export, separately retained public trust, offline report and transport report allow inspection and reproduction. The trust file contains public fixture material, not private credentials. Its recorded observation is internal test evidence, not a third-party timestamp.

Meaningful scenarios exercised

• Concurrent acceptance retries converge on one agreement and return the original receipt, including independently randomized valid ES256 signatures over identical payload bytes.
• Real child-process termination before commit leaves no accepted agreement; termination after commit preserves the original accepted result on restart.
• Wrong principals, foreign clients, altered offer digests, expired offers, malformed bodies, unknown tokens and unauthorized scopes are rejected.
• Removing live authority/capabilities/key uses fails closed. These tests do not implement or validate a production key-rotation workflow.
• GET, HEAD, range 206 and conditional 304 require current authorization and preserve distinct delivery classifications. Raw leading-slash aliases and duplicated critical headers are rejected at the actual HTTPS boundary.
• A signed false usage declaration remains a client claim. Anonymous spoofing cannot occupy the authenticated reporter namespace or attach itself to another client’s export.
• Owner exports include their gateway observations without exposing another principal’s agreements. Valid oversized exports return 413 rather than pretending an invalid request was submitted.
• Offline verification detects changed signatures/context and replacement trust. A separately retained ordered-record witness also detects deletion, insertion or reordering relative to the client-observed export. It does not prove that every real-world event was captured initially.
• Revocation blocks subsequent admission/token issuance while retaining the exact original acceptance receipt.

Reproduction

From the package root, with the dependencies described in the README:

python -m unittest discover -s tests -v
node --test verification/test_independent_client.mjs
python schema/verify.py --ajv /path/to/node_modules
python -m odexa_ref.demo --outdir ./run
node clients/independent_client.mjs \
  --verify-export ./run/export-evidence.json \
  --trust ./run/independent-trust.json \
  --outdir ./offline-check

The actual run used Python 3.12.14, cryptography 50.0.1, SQLite 3.53.1, Node.js 24.19.0 and AJV 8.20.0. A new run creates fresh keys, identifiers, timestamps and an ephemeral port, so its raw signatures will differ. Expected semantic outcomes remain the same. The sample export covers the pre-revocation portion of the workload; the live test report separately records successful revocation.

Limits of this evidence

The reference and client were authored separately within one AI-assisted team, not by independent external vendors. No public Internet deployment, load/availability benchmark, packet-capture egress audit, power-loss test, large fleet/edge deployment, key migration, external delegation or paid settlement was validated. The bounded schemas, verification rules and fixture are deliberately more conservative than a general commercial platform.

The client constrains destinations to the configured origin and the application has no external provider implementation. The integration used real TLS with an explicitly trusted temporary CA. No operating-system trust changes or insecure certificate bypass were used. No operational accounts, external messages, live sites or Google resources were changed.