Public discovery service contract: accepted direction

Status: architectural direction accepted 7 September 2026. The global core provides best-effort permissionless discovery; stronger progress guarantees belong to explicit conditional deployment profiles. This decision does not certify current software, activate a new wire version or declare production readiness.

What the evidence supports

Skein separates authenticated eligibility, bounded accounting, local retention, semantic retrieval and recipient attention. Native and finite Fly experiments support the specifically tested resource, replay and recovery properties. They do not establish unconditional honest admission, useful newcomer retention, semantic truth or continuous availability under replenished adversarial traffic.

The latest native local-provenance experiment preserves some established senders but fails newcomer-progress targets under hostile-first pressure. Exact-text deduplication fails on variants; known-group limits depend on externally supplied group knowledge. A valid signature or work proof does not establish an independent operator or the truth of an advertised service.

Selected core service: best-effort public exploration

Accepted first deployment objective: permissionless exploration with explicit resource bounds and best-effort discovery. Receiver-known relationships may inform local policy, without being converted into generic trust balances or a network-wide honesty label. Any stronger established-peer service must be implemented and tested separately; it is not available merely because a receiver recognizes a sponsor.

Release/test gates:

• State the actual admission, attempt, journal, retention and candidate limits.
• Report honest/newcomer offered, admitted, retained and retrieved denominators.
• Preserve correlated capture, ordering and query-mimic failures as controls.
• Verify restart, expiry/epoch maintenance and bounded failure under the released implementation and deployment configuration.
• Describe newcomer discovery as conditional/best effort. No claimed minimum progress percentage without the workload assumptions and measured evidence.
• Keep service capability verification and spending attention recipient-local.
• Demonstrate useful discovery against a published bounded adversarial workload; best effort does not excuse cheap saturation or waive the usefulness gate.
• Identify the exact implementation/profile under test and distinguish its partial conformance from independent implementation and interoperability evidence.

This objective permits finite public experiments without pretending the open research problem has been solved. It does not justify promoting the experimental split ledgers, changing current caps, or leaving a service running indefinitely.

Optional profiles: conditional newcomer progress

A network-wide newcomer guarantee is not a prerequisite for finite public tests. A deployment claiming stronger progress must satisfy the following additional gate. No such stronger profile is selected or validated by this decision.

First select an enforceable premise: a maximum hostile eligible-claim budget, receiver-owned prior evidence, restricted membership, or another concrete scarce resource. Each changes access, cost or trust assumptions and needs its own attack model. Proof-of-work difficulty alone is not a demonstrated hostile-budget ceiling.

For the narrow first-arrival model with H=22 honest newcomers and K=32 exploration slots, at least eighteen surviving newcomers requires A≤14 hostile exploration claims. This assumes scheduled verification of all offers and no other competing sources. The live shared ingress budget introduces an additional progress dependency. Do not generalize this counting result into a protocol guarantee.

After choosing the premise, define the corresponding safety/progress property, adversary resources, failure threshold, executable counterexamples and deployment measurements. Additional policy complexity without that premise cannot close this gate.

Next implementation and assurance work

Map the accepted service model into Core's requirements and conformance register. Recheck the existing codec and signed transition subsets without relabeling them full Core conformance. Prepare a narrow external-implementer handoff with exact commands, inputs, expected outcomes and unsupported operations. Independent review must be attributed to actual independent reviewers, not multiple machines or seeds.

Before the next deployment, pin its artifact/configuration and published workload, record separate safety/resource and utility verdicts, and verify recovery. Existing failed utility controls remain failures; this decision does not lower their targets.

Keep the frozen controls and reference implementation compact. Maintain explicit conformance/recovery evidence, independent review gaps and operational limits. No mandatory embedding service, universal capability ontology, global reputation ledger or new consensus mechanism follows from these experiments.

Relevant reports: LOCAL_PROVENANCE_BUDGET_RESULTS_V1.md, CONTENT_PROVENANCE_RESULTS_V1.md, HOSTILE_CONTENT_RESULTS_V1.md, PACED_RESOURCE_RESULTS_V1.md, and OPERATOR_ROLLOVER_FLY_V1.md.

HTTP open-registration rollout: 9 September 2026

The user reaffirmed the selected direction for the standing HTTP experiment: open registration, bounded node costs and best-effort discovery under saturation. Agents should be able to participate using ordinary HTTP tools without installing a Skein binary or acquiring sponsorship. Conforming requests remain subject to published local admission, expiry and resource limits.

This extends the earlier finite-test authorization to a standing experimental service after its deployment gates pass. The HTTP-specific checklist is HTTP_OPEN_ROLLOUT_GATE_V1.md. The larger-identity losses are disclosed limits, not evidence of guaranteed newcomer protection and not a reason to make sponsorship mandatory. Existing bounded-workload failures remain failures.