10 records · 7 axes
Add AuthorityEventV1 and OutcomeObservationV1, and evaluate assurance separately from evidence.
Protocol 0.2 / Proposed · not released
A clearer contract for the next decision.
The 0.2 plan adds an assurance axis, authority lifecycle events, criterion-bound outcome observations and versioned evidence admission. These changes are proposed in r3 / sync-4.
Plan updated · r3 / sync-4
Markdown version ↗HelmLoop
A clearer contract for the next decision.
The 0.2 plan adds an assurance axis, authority lifecycle events, criterion-bound outcome observations and versioned evidence admission. These changes are proposed in r3 / sync-4.
Deterministic commitments
A versioned JCS / SHA-256 profile, exact reference binding and an independent JS/Python oracle. Preserve original 0.1 bytes and readers.
Fresh evidence admission
Reassess evidence against the current subject, policy and dependencies. Reused results never carry action authority.
Stop and recovery
Keep physical stop, resource cleanup and effect reconciliation distinct. Unknown delivery requires query and reconciliation before retry.
Independent CLI
Plan an offline helmloop try with a real PASS case and an expected HOLD case, completed within 90 seconds after installation.
Bounded conformance
Two mock adapters cover C0–C4; one exact real binding targets C0–C5. Each claim retains its evidence class and limitations.
HelmLoop
0.2 / 0.2 planned
Ten proposed record types
OutcomeContractV1AuthorityGrantV1ExecutionReceiptV1EvidenceRecordV1AssuranceDecisionV1PromotionDecisionV1ReconciliationRecordV1LearningSignalV1AuthorityEventV1OutcomeObservationV1Seven proposed decision axes
executionevidenceassuranceauthoritypromotionreconciliationobservedOutcomeSix target-specific decisions
Each target declares its required evidence. Admission does not require a future execution receipt; promotion still needs an exact owner decision and its own authority.
| Target | Responsibility |
|---|---|
ADMIT_EXECUTION | Validate current contract, action, grant and admission prerequisites. |
ASSESS_RECONCILIATION | Assess fresh provider query and independently observed state. |
ASSESS_STOP | Assess dispatch fencing, owned resources and cleanup; preserve unknown effects. |
PROMOTE | Assess the owner's exact promotion decision and policy prerequisites. |
ADMIT_RECOVERY | Assess pending-effect reconciliation and fresh attempt, epoch and authority. |
CONFORMANCE | Evaluate only the declared suite and its fixture or real evidence scope. |
Version boundaries matter
0.1 keeps HL-C14N-1, its original readers and six-axis semantics. Planned 0.2 uses helmloop-jcs-sha256-v1 and typed sha256: references. A matching digest checks integrity; it does not grant trust or authority.
HelmLoop
The delivery sequence
All stages are planned. Oracle work can overlap core implementation after canonical/schema freeze; CLI/package work can overlap mock conformance once interfaces are stable.
- S0
Baseline & wire freeze
Proposed · not released
- S1
Pure 0.2 core
Proposed · not released
- S2
Independent oracle
Proposed · not released
- S3
Two mock adapters
Proposed · not released
- S4
CLI & package
Proposed · not released
- S5
One real binding
Proposed · not released
- S6
Documentation & release candidate
Proposed · not released
HelmLoop
Two packages, explicit responsibilities
Neutral core
Planned Apache-2.0 package: schemas, pure evaluator, conformance formats and offline CLI. No scheduler, effect runner or Better Workflows dependency.
Better Workflows binding
Planned AGPL-3.0-only binding: versioned mapping and host-verification integration. Dependency direction is binding → neutral core. These are planned package boundaries, not a claim that distribution review is complete.
The V5 interoperability seam
The r3 sync-4 plan records a bounded Better Workflows typed-digest parser correction. Current profile v3 / mapper v3 accepts typed references; legacy profile v1 / mapper v2 remains a bare-hex reader. Full HelmLoop 0.2 interoperability is still planned.
HelmLoop
What C0–C5 actually establish
Current fixture results do not certify a live runtime, broad portability, production readiness or business value. The research page keeps these open questions visible.
| Level | Responsibility |
|---|---|
C0 | Taxonomy, manifest and documentation parity |
C1 | Source, package and installed byte identity |
C2 | Declared account, host/session and provider/model assurance |
C3 | Filesystem, network, tool and credential restrictions; timeout, cancellation, owned-resource cleanup and independent readback |
C4 | Profile-bound contract, evidence, approval, action and reconciliation E2E, including negative cases |
C5 | Trusted attestation and revocation for the exact live binding |