Skip to content

Execution Ledger template

The Execution Ledger is the level-1 operational companion of an Objective: one ledger per objective, maintained OUTSIDE the versioned contract layer (Work Ledger plane), referenced from it. It records HOW execution is actually going, while the Git Objective records WHAT/WHY/DONE.

Single-writer rule

The Lead (wetopi-lead) is the ONLY writer. Workers deliver evidence via their cards and PRs; the reviewer records verdicts via the review channel; the Lead transcribes the state into the ledger. Nobody else edits it — the ledger's integrity depends on one hand.

Ledger location and lifecycle

  • Lives in the operator's Work-Ledger plane (level 1), NOT in the docs repo — Git holds contracts, never live state (DocOps §1).
  • Created by the Lead at objective acquisition; archived with the objective's completion (keep it as part of the audit trail).
  • Its objective header must reference the objective's commit/PR SHA in the docs repo — that cross-reference is what keeps L1 and L2 honest.

Template

# Execution Ledger — <OBJ-<DOMAIN>-<NNN>>

objective: OBJ-<DOMAIN>-<NNN>
objective_ref: wetopi-platform/docs PR #<n> @ <merge-or-head SHA>
created: <date>       last_updated: <date>
writer: wetopi-lead (single writer — see PROC header rule)
backup_locator: <backup path/mechanism + schedule + last restore drill date>

## Status
<one line: current phase of the objective's state machine>

## Next action
<one line: the single next step + owner lane>

## Cards
| card_id | lane | phase | state | commit / PR | notes |
|---|---|---|---|---|---|
| t_xxxxxxxx | wetopi-build | P1 | done | docs#<n> @ <SHA> | <one line> |

## Evidence log
| date | card / PR | evidence | gate result |
|---|---|---|---|
| <date> | t_xxxxxxxx | <command outputs, validator exits, verification table rows> | pass |

## Reviews
| date | reviewer | scope | verdict | follow-ups |
|---|---|---|---|---|
| <date> | wetopi-approver | PR #<n> | APPROVE / REQUEST_CHANGES / REJECT | <required changes> |

## Blockers
| date | blocker | kind | state |
|---|---|---|---|
| <date> | <what and why> | needs_input / capability / dependency | open / resolved |

## Deviations from the objective
| date | deviation | reason | approved-by |
|---|---|---|---|
| <date> | <what diverged from the contract> | <why> | <who accepted it> |

## Backup / restore
<restore procedure reference + last drill result — LOCATOR ONLY, no secrets>

Content rules

  • No live config, no secrets: never paste .env values, auth.json, tokens, connection URLs, credential hashes, pool output or live snapshots. Reference the credential identity/path (Infisical path, profile name), never the value.
  • Evidence, not conclusions: the evidence log carries verifiable artifacts (command exit codes, PR URLs, validator outputs, log excerpts) — judgments live in Reviews, facts in Evidence.
  • Fail-closed discipline: an unresolved blocker or a missing verdict is recorded as such — never silently downgraded to "done".
  • Card IDs are references: the ledger names Kanban card IDs to anchor evidence; it never duplicates the board's card bodies.
  • Deviation honesty: any divergence from the objective contract gets a Deviations row with an approver; unapproved deviations are blockers.