Core idea: Reliance Before Closure separates workflow completion from decision readiness. It asks whether real evidence has bounded the unresolved futures relevant to one claim, whether that claim stays stable across those futures, and whether a proposed action fits inside the certified margin without changing the verdict.
The gap before closure
Many systems wait for a workflow-wide completion signal before allowing downstream use. That is conservative, but it can be coarser than the decision actually requires. A deployment may still be converging, a controller may still have work to do, or a distributed process may still be open even though the futures capable of changing one specific claim have already been constrained.
A favorable snapshot is not enough either. The unfinished future still matters until the system can justify which adverse paths remain possible. Reliance Before Closure works in that gap: it does not require global completion, but it also does not treat a current value as stable merely because it looks good now.
The relying object is smaller than the workflow
The profile is claim-relative. It asks whether one verdict remains stable over the unresolved futures that matter to that verdict. Other parts of the workflow may remain incomplete without affecting that narrower question.
The result is therefore not “the system is done.” It is support for one semantic claim, under one qualified future boundary and one declared trust profile, for use by a relying party that accepts those same identities.
From operational evidence to a relying decision
The project keeps four obligations separate because none can substitute for the others.
- Future boundary
- Which unresolved paths are still admissible, which have been excluded by evidence, and which remain explicit trust assumptions?
- Verdict stability
- Given that qualified boundary, how far can the claim move before its verdict flips?
- Action effect
- How much can the proposed action itself worsen the same claim, including qualified action-induced future expansion?
- Relying identity
- Do the certificate, action bound, and relying context agree on the exact claim, semantic profile, unit, boundary identity, and trust-profile identity?
Evidence-backed exclusions remain distinct from accepted trust assumptions. If an unknown path could still worsen the claim and has neither been evidenced away nor explicitly accepted under the named trust profile, the system does not manufacture a positive margin.
For the frozen scalar profile THRESHOLD_SLACK_V0, a verified stability certificate carries a nonnegative margin M. The proposed action receives a separate qualified claim-worsening bound Cₐ, covering its direct effect plus qualified action-induced future expansion.
Only after those provider-specific qualifications are complete does the provider-blind rely() function act. It checks exact semantic and trust identity, requires a proven boundary and stable certificate, requires a proven action bound scoped to post-action admissible futures, and applies:
The violated case is strict because consuming the whole violation margin reaches threshold equality and changes the verdict. The arithmetic is simple by design. Establishing what those numbers are entitled to mean is the larger part of the system.
Current truth is not future stability
The recorded mutable-bound control makes the distinction concrete. A ResourceQuota hard limit may be enforced now, but if the evaluated actor can relax that quota, the current number does not justify a positive future-stability certificate for that boundary.
The result is REQUALIFY. Current enforcement answers what is true at the snapshot. Reliance-grade stability asks what remains true across the admissible future.
Matching numbers still may not apply
A counterfactual Inspector case uses M = 1 and Cₐ = 1, so the arithmetic fits. But the relying context rejects the trust profile accepted by the certificate and action bound.
The result is NOT_APPLICABLE, not SUPPORTED. Two artifacts cannot silently choose assumptions on behalf of the machine that consumes them.
SUPPORTED is not permission or reservation
The relying function returns only SUPPORTED, REQUALIFY, or NOT_APPLICABLE. Every output explicitly states that authorization and reservation were not inferred.
The recorded concurrency case shows why. Two one-slot actions can each be semantically within the same one-slot stability margin when evaluated independently. That does not reserve the slot twice. At commit time the authoritative Kubernetes quota admitted one action and rejected the other.
Reliance answers a semantic applicability question. The authoritative system still controls authorization, coordination, admission, and commit success.
The Kubernetes commissioning
The project commissioned this interface against a local Kubernetes scenario rather than stopping at synthetic fixtures. At the reliance point, the claim-relevant rollout creation condition had become stable under an explicitly trust-scoped boundary while broader Deployment completion was still false.
The archived run derived M = 1 POD_SLOT. A server-normalized standalone Pod CREATE was separately qualified at Cₐ = 1 POD_SLOT. The provider-blind consumer returned SUPPORTED, the actual Pod CREATE succeeded, and broader Deployment completion arrived later.
- Quota at reliance
- 4 / 5
- Stability margin
- 1 POD_SLOT
- Qualified action bound
- 1 POD_SLOT
- Relying result
- SUPPORTED
- Final quota
- 5 / 5
- Broader Deployment complete at reliance
- false
- Measured interval to broader closure
- 20.613487 seconds
The result is the separation demonstrated by that trace: machine-consumable evidence supported a claim-specific reliance decision before workflow-wide completion. The 20.613487-second interval is one harness measurement from this scenario, not a production latency distribution or a claim that the profile speeds Kubernetes up by that amount.
Controls that sharpen the result
The recorded and counterfactual cases show why several tempting shortcuts are insufficient.
- Mutable hard bound
- REQUALIFY. Current enforcement is not future stability when an admissible actor can relax the bound.
- Trust-profile mismatch
- NOT_APPLICABLE. Matching arithmetic cannot override a relying party's rejected trust assumptions.
- Replacement reserve
- REQUALIFY. Including one additional adverse replacement path reduces the effective margin from one slot to zero, so the proposed one-slot action no longer fits.
- Concurrent one-slot actions
- Each can be SUPPORTED semantically, while the authoritative quota still admits only one. Proof is not reservation.
Relationship to broader closure and neighboring systems
Broader closure asks whether the workflow has reached its own terminal condition. Reliance Before Closure asks whether a smaller, claim-specific boundary has already become sufficient for a downstream machine. If that boundary cannot be qualified, waiting for broader closure remains a valid fallback. The profile does not force early action.
Runtime verification, relative information completeness, coordination-avoidance results, assume/guarantee reasoning, attestation architectures, safety filters, and action-governance systems already cover important neighboring ideas. Reliance Before Closure does not claim to have invented those foundations.
Its narrower engineering result is an executable handoff between heterogeneous operational evidence, an explicitly qualified unresolved-future boundary, a claim-specific stability result, a separately qualified action-effect bound, and a provider-blind relying party.
Reliance Inspector
Reliance Inspector v0.4.0 exposes the recorded final commissioning case, recorded negative controls, and generated counterfactuals. It shows the decision trace, boundary status, evidence-backed exclusions, explicit trust assumptions, stability margin, action bound, identity diagnostics, timing, and nonclaims.
The hosted surface is intentionally canonical-only. Full evidence ZIP verification and arbitrary semantic-object evaluation remain local capabilities of the archived v0.4.0 release. The hosted app.js, styles, and canonical case data are frozen copies, while deployment-only navigation and scope disclosure remain separate.
Reproducibility
- Recorded evidence
- The frozen commissioning ZIP can be verified offline with Python 3 and no Kubernetes cluster. The verifier rechecks the archive manifest, boundary accounting, trust assumptions, raw Kubernetes objects, margin and action derivations, relying result, final quota state, quota-failure absence, and lead arithmetic.
- Semantic core
- The zero-dependency Python consumer, canonical fixtures, conformance checks, and exhaustive integer oracle can be run independently. A TypeScript implementation is retained as a second implementation.
- Fresh commissioning
- A local kind cluster can rerun the commissioning harness through boundary accounting, margin derivation, server-side action normalization, action-bound derivation, provider-blind reliance, commit, and broader closure.
Result
Reliance Before Closure makes a narrower decision boundary consumable by another machine without pretending the broader workflow is finished. The relying party receives a bounded semantic result only after evidence, assumptions, claim identity, trust identity, stability, and action effect agree.
The recorded Kubernetes commissioning supplies an existence result for that architecture: one trust-scoped operational trace reached SUPPORTED, committed the qualified action, and only later reached broader Deployment closure.
Scope and trust boundary
SUPPORTED is not authorization, a reservation, a transaction, an admission decision, or a guarantee that a concurrent commit will succeed. The minimal reference also does not authenticate certificates or action bounds; verified authenticity is a caller-side precondition.
The Kubernetes result is one scenario-conditioned commissioning trace, not evidence of production prevalence or a universal early-action window. Its positive boundary accepted explicit trust assumptions. Those assumptions remain part of the claim rather than being silently promoted to evidence.
Frozen record and source materials
- Semantic profile
- THRESHOLD_SLACK_V0
- Inspector
- Reliance Inspector v0.4.0
- Inspector archive SHA-256
- 1fdcb8edb34b13cc263eca3b633de243a7c0a1bd4306ceba5259c30ce9aa567d
- Technical Note DOI
- 10.5281/zenodo.22038494
- Inspector software DOI
- 10.5281/zenodo.22037607
- Recorded commissioning
- Kubernetes · trust-scoped · 20.613487 s measured interval in one trace
- Canonical consumer
- Zero-dependency Python
- Independent implementation
- TypeScript