Durable Result Identity and Availability Separation

This live case asks whether Buildchain v4 Stage Capsule exposed a portable principle or a strong product-specific composition:

When a durable result may be reused, must identity, retention commitment, observed availability, transport, and qualification remain independently addressable?

Current result

candidate: Durable Result Identity and Availability Separation
status: provisional
minimum closure: analytically plausible
deletion test: not run outside Buildchain
fuse test: partial in Buildchain shadow qualification
dogfood: six founding-ecosystem shadow campaigns; no production reuse

Buildchain’s exact Wave 2 merge demonstrates that the separation is coherent, provider-neutral, cross-process, and testable on three operating systems. It does not establish that the responsibility is irreducible from KFD-1, KFD-2, KFD-7, existing cache/provenance systems, or an adopter-owned Domain Profile.

Case surfaces

Claim boundary

This case opens qualification only. It does not allocate a KFD number, make Buildchain terminology normative, qualify cross-domain transfer, certify Buildchain v4, enable production Stage Capsule reuse, or select promotion over subsumption, rejection, or no-new-kfd.

The case is limited to the cited public repository evidence; private discussion and unretained runner payloads are outside its evidence cut.

Genesis: From Cache Hit to Defensible Reuse

Initial observer

The initial observer was evaluating Buildchain v4 recovery after a late build stage failed. The familiar objects were an action key, cached bytes, an artifact locator, a retention policy, and a build result.

From that position, the problem looked like reliable cross-run caching.

Perspective transformation

The observer changed to the successor process that must decide whether it may safely reuse a retained result after time, process, platform, policy, and provider state have changed.

From that position, one apparent cache fact separated into several questions:

What exact result is this?
Was anyone committed to retain it?
Is it available and intact now?
Where can it be retrieved?
Is it still qualified for this exact purpose?

Buildchain Stage Capsule made those questions independently variable and computed reuse only from explicit roots and an explicit evaluation clock.

Why genesis is not qualification

Action cache and content-addressed storage already separate action metadata from output bytes. Provenance already binds outputs to production inputs and processes. KFD-1, KFD-2, and KFD-7 already require non-drifting facts, fact-bound trust, and visible degraded coordinates.

The new observation may therefore be a portable principle, a direct composition of existing KFDs, a Buildchain-specific Domain Profile, or only a particularly careful cache protocol. This cut preserves all four outcomes.

This reconstruction is limited to public repository evidence; private discussion and unretained hosted-runner payloads are outside the cut.

KFD Method Trace

KFD-1

The Candidate preserves one exact Buildchain source cut and treats identity, availability observations, and future qualification cuts as welded surfaces that cannot drift together silently.

KFD-2

Reuse is a claim assessed from exact roots and explicit current facts. A digest, promise, location, or prior pass cannot substitute for present evidence and residual risk.

KFD-4

The observer changes from the producer that just completed a stage to the successor process deciding whether the result remains usable after conditions changed.

KFD-5

Buildchain supplies genesis and founding dogfood, not promotion. Existing KFD composition, Buildchain Profile, prior-art composition, and no new KFD remain live alternatives.

KFD-7 and KFD-13 boundaries

Stage Capsule records product-domain facts and supports recovery action; it is not a new action coordinate or Project Cut. A future principle must preserve those authorities rather than absorb them.

KFD-6 boundary

No autonomous discovery claim is made. Human judgment selected the pressure field; the agent reconstructed public evidence, alternatives, and falsifiers.

Ontology Alternatives

The question is not whether Stage Capsule is useful. It is where the durable separation belongs.

Hypothesis	Normative owner	Main risk
New KFD principle	KFD defines the cross-domain separation; adopters map it	Promotes a build-cache pattern before transfer is proved
Existing KFD composition	KFD-1, KFD-2, and KFD-7 already imply the rule	Leaves a repeatedly reconstructed responsibility unnamed
Buildchain Domain Profile	Buildchain owns Stage Capsule and its exact fields	Similar failures recur in unrelated domains
Infrastructure composition	Action cache, CAS, provenance, and storage policy	Locators or policy are still mistaken for current evidence

Proposed semantic split

result identity
  != retention commitment
  != observed availability
  != transport coordinate
  != reuse assessment

Qualification may be bound into result identity by exact root while remaining an independently inspectable authority. Physical co-location is allowed; semantic substitution is not.

Forbidden fusion

A content root must not prove present availability.
A retention promise must not prove successful custody.
A transport locator must not become result or storage authority.
Historical qualification must not prove current purpose fitness.
One successful restore must not authorize provider or production effects.

Conditional Distinguishability

Deletion experiment

Hold fixed the result content, action or transformation, qualification, store, provider, and receiver purpose. Remove the explicit separation between identity, retention, current availability, transport, and reuse assessment.

Deletion matters only if a participant then makes a different unsafe decision or must materially reconstruct one of these facts from mutable provider state, logs, convention, or operator memory. Cleaner schema design is not sufficient.

Buildchain demonstrates likely deletion pressure through missing, expired, partial, corrupt, quarantined, root-mismatch, cross-platform, cross-stage, and drift campaigns. A non-build fixed-root deletion witness remains absent.

Fuse experiment

The responsibilities are operationally distinguishable when, with the same result identity:

a retention commitment expires without changing historical bytes;
availability changes from present to missing or corrupt;
a transport locator moves without changing result identity;
qualification becomes insufficient for a new purpose;
a receiver rejects reuse while preserving the historical result;
two stores report different availability without creating two results.

Buildchain’s shadow contract supports these variations. Qualification must show that at least one unrelated adopter also needs them and cannot obtain the same decisions from ordinary content-addressed storage plus policy.

Current verdict

The candidate is sufficiently distinguishable to incubate, not to number. Product evidence is strong; cross-domain irreducibility and redundancy against existing KFDs remain unresolved.

Propagation Boundary

If the principle transfers, one small decision surface could serve build stages, agent checkpoints, scientific pipelines, model or dataset custody, and backup restoration:

identify exact result
  -> inspect retention commitment
  -> observe current availability and transport
  -> assess qualification for this purpose and time
  -> restore or rebuild without rewriting history

The hypothesis remains unverified. Domains may have different custody, privacy, authority, or liveness requirements; some have no meaningful retention promise. A general KFD must allow absent or unsupported coordinates to remain explicit instead of forcing Buildchain’s schema onto them.

Durable Result Identity and Availability Reviews

An independent exact-commit genesis review was completed by kungfu-origin for commit 5b05f24f69ea2f293c21eec0b830d6e60eec7868 on PR 337. It approves retaining this exact incubating, pre-number Candidate genesis and its KFD-5 cut. It does not qualify or promote the Candidate, allocate a number, authorize a terminal disposition, or make Buildchain normative.

The retained machine-readable review evidence and Self-Conformance lifecycle pair are:

evidence/self-conformance/reviews/durable-result-identity-availability.genesis.json;
evidence/self-conformance/transitions/durable-result-identity-availability-genesis.request.json;
evidence/self-conformance/transitions/durable-result-identity-availability-genesis.report.json.

No independent qualification review has been completed. A later qualification review should evaluate:

whether the Candidate states a portable responsibility rather than a Buildchain schema;
whether KFD-1, KFD-2, KFD-7, and KFD-13 redundancy is treated seriously;
whether action cache, CAS, provenance, registry, and retention-policy prior art can reproduce the same decisions;
whether the Buildchain evidence is accurately bounded as shadow-only and first-party;
whether deletion and fuse tests demand changed decisions rather than model elegance;
whether non-build transfer and independent implementation are real gates;
whether promotion, subsumption, rejection, and no-new-kfd remain equally admissible outcomes.

Durable Result Identity and Availability Separation

Status and Candidate relationships

Product genesis is retained without promoting the Candidate