# Protocol 0.2 roadmap — r3 / sync-4 | HelmLoop

> HelmLoop makes authority, evidence, promotion and observed outcomes explicit across AI agent workflows. Explore the executable 0.1 candidate and the proposed 0.2 protocol.

Source: https://helmloop.dev/roadmap.html

Protocol 0.1 includes eight record schemas, a deterministic six-axis reducer, a CLI and two fixture observation adapters. These are local implementation artifacts, not a public package release or live-runtime certification.

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: helmloop-v02-plan-20260915-r3 / sync-4; 2026-09-16; PROPOSED

## 10 records · 7 axes

Add AuthorityEventV1 and OutcomeObservationV1, and evaluate assurance separately from evidence.

## 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.

## The delivery sequence

- 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

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.

## 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.

## What C0–C5 actually establish

- C0: Taxonomy, manifest and documentation parity
- C1: Source, package and installed byte identity
- C2: Declared account, host/session and provider/model assurance
- C3: Runtime restrictions, cancellation and owned-resource cleanup
- C4: Contract, authority, action and reconciliation end to end
- C5: Trusted attestation and revocation for the exact live binding

## Ten proposed record types

- OutcomeContractV1
- AuthorityGrantV1
- ExecutionReceiptV1
- EvidenceRecordV1
- AssuranceDecisionV1
- PromotionDecisionV1
- ReconciliationRecordV1
- LearningSignalV1
- AuthorityEventV1
- OutcomeObservationV1

## Seven proposed decision axes

- execution
- evidence
- assurance
- authority
- promotion
- reconciliation
- observedOutcome

## Six 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.

- 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.

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

## Read the evidence at its actual scope

Current fixture results do not certify a live runtime, broad portability, production readiness or business value. The research page keeps these open questions visible.