External implementer handoff: discovery admission subset

Status: ready for an external implementation exercise, not Core certification. The accepted service model is best-effort public exploration. These suites verify specific bytes and local transitions; they do not establish discovery utility.

Implement from the contracts

Start with spec/core/README.md, spec/core/CLAIM_PROFILE.md, spec/core/TRANSITIONS.md and conformance/README.md. Read their assumptions, error precedence and exclusions before coding. The specification defines intended behavior. Report ambiguities rather than copying an unexplained Rust behavior.

The executable adapter consumes a JSON request on stdin and emits a JSON response on stdout; diagnostics use stderr. The harness starts an adapter process for each vector, enforces a five-second deadline and separate 64 KiB output caps. The exact test transport and operation schemas are in conformance/README.md. This is not a network protocol or a sandbox for an untrusted executable.

Implement in this order:

1. decode_open_cost and verify_ed25519: canonical preimage, SHA-256, exact unsigned integer handling, primitive verification and malformed input outcomes.
2. inspect_claim_wire: signed open-cost/sponsorship envelopes and internal binding. Authentication success explicitly does not claim current authorization.
3. admission_trace: local authorization, replay, conflicts, capacity, pinned policy and clean reopen using the fixed signed transition fixtures. This subset does not perform arbitrary power-loss injection or a network-wide agreement protocol.

Do not add global balances, reputation conversion or guaranteed storage in order to implement these operations. Do not claim independent implementation merely by running the supplied Rust adapter on another machine.

Run against a chosen executable

From the repository root, substitute an absolute path to the implementer's adapter. Use fresh output filenames so existing results remain unchanged.

python3 conformance/run.py --output outputs/external-codec.json /absolute/path/to/adapter
python3 conformance/run.py --suite conformance/claims-v1.json --output outputs/external-claims.json /absolute/path/to/adapter
python3 conformance/run.py --suite conformance/transitions-v1.json --output outputs/external-transitions.json /absolute/path/to/adapter

The current vectors contain 12 primitive/preimage cases, 14 signed-envelope cases, and six local transition traces containing 34 operations. Passing these counts is not a substitute for testing malformed request framing, generated sequences and additional cryptographic boundary cases.

Evidence to return

Record implementation author/organization, language, revision, build command, adapter hash, OS/architecture, exact vector hashes, raw results and deviations. Describe whether the author consulted the Rust implementation and whether libraries or codec code are shared. Independence is an attributable fact, not a test status. Report unknown operations, unsupported profile features and any spec ambiguities.

The supplied Rust adapter recheck is preserved under docs/results/service-contract-v1/. It is a control, not a second implementation. No external reviewer has been contacted or independent result obtained by preparing this handoff.

A same-author Python diagnostic adapter now covers the first two stages using cryptography 46.0.3: conformance/python_adapter.py. It agrees with Rust on the current vectors and a bounded mutation corpus, including weak-key cases that must be resolved before profile promotion. See docs/CROSS_LANGUAGE_AUTH_V1.md. It is not an independent-team implementation or an authorization/transition adapter.

The stricter candidate is separately specified in spec/core/STRICT_AUTH_PROFILE.md and tested by conformance/strict_python_adapter.py; see docs/STRICT_AUTH_RESULTS_V1.md. Identify which acceptance profile your adapter implements. Legacy suite agreement must not imply strict point/key acceptance.

Gates this does not close

Full Core conformance, general object serialization, public version negotiation, transport interoperability, independent-node topology, hostile-workload usefulness, power-loss durability, key recovery, and stronger progress guarantees remain separate work. A future deployment report must satisfy C-SERVICE-01 and identify the exact operations/profile tested. The new requirement currently has documentation coverage only; it is not an automatically certified service guarantee.

Native strict adapter

Build core_conformance with --features strict-auth and invoke the executable with --strict-auth. This mode supports decode_open_cost, verify_ed25519 and inspect_claim_wire, plus the strict admission_trace contract in conformance/STRICT_TRANSITIONS_V1.md; it refuses capacity/driver operations. Default mode preserves the legacy traces. The native and Python strict adapters agree on 6,108 retained cases; this is same-author cross-backend evidence, not independent implementation. See docs/NATIVE_STRICT_AUTH_V1.md for runtime scope and persisted-policy handling.

Epoch rollover subset

STRICT_EPOCHS_V1.md defines epoch_trace, supported in strict native mode. Four traces (28 steps) cover rollover, refusal without journal mutation, old-policy reopen rejection and restart replay. Use strict-epochs-v1.json with its separate fixture corpus. This supplements the eight strict admission traces; it does not provide independent-author or power-loss evidence.