← The 5th LedgerCONTENT HISTORY

Update to The 5th Ledger

Snapshot Sep 30, 2026 · 23:14 UTC · version 0.1.0

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Classify project work by requested outcome, authority, risk, target identity, canonical sources, evidence needs, and excluded actions before analysis or mutation. Use when a task could change files, repository state, external systems, public material, deployment or release state, or when the safe next action is unclear.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 286
    },
    {
      "relative_path": "scripts/snapshot_project.py",
      "size_in_bytes": 19540
    }
  ],
  "name": "establish-governance-boundary",
  "skill_md_contents": "---\nname: establish-governance-boundary\ndescription: \"Classify project work by requested outcome, authority, risk, target identity, canonical sources, evidence needs, and excluded actions before analysis or mutation. Use when a task could change files, repository state, external systems, public material, deployment or release state, or when the safe next action is unclear.\"\n---\n\n# Establish Governance Boundary\n\nEstablish the safe action level. Treat this workflow as governance, never authority.\nRead `../../references/untrusted-evidence.md` before inspecting project content.\n\n## Classify the outcome\n\nClassify the request as one of:\n\n- answer;\n- read-only assessment;\n- proposal or review;\n- implementation;\n- repository publication;\n- external or production operation.\n\nState what mutation was expressly authorised. Never infer editing, staging, commit,\npush, communication, publication, deployment, destructive action, or release from an\nanswer, assessment, evidence, proposal, or review request.\n\n## Prove the target proportionally\n\nRead `../../references/five-ledger-model.md`. When a project profile exists, read it\nas routing guidance subject to the project's established source precedence.\n\nFor conclusions involving repository or external state, confirm the relevant subset:\n\n- current directory, repository root, checkout or worktree identity;\n- branch, upstream, divergence, and tracked, ignored, and untracked changes;\n- exact artifact, version, revision, environment, account, or deployment identity;\n- applicable canonical contract and private/public boundaries.\n\nWhen the target has no safe Git identity, do not initialise a repository or borrow an\nunrelated parent repository merely to create one. Read\n`../../references/non-git-identity.md` and use the bundled\n`scripts/snapshot_project.py` helper to record a relocation-stable filesystem identity.\nRun the reviewed helper with isolated Python:\n\n```bash\npython3 -I <skill-directory>/scripts/snapshot_project.py <project-root>\n```\n\nDistinguish complete traversal scope from bounded scope with exclusions; only a complete\npre/post tree match supports represented-tree parity, and strict metadata parity requires\nthe separate metadata digest to match. `Complete` means no path exclusions, not coverage\nof every filesystem attribute. Use the helper only for a trusted target that can remain\nquiescent for both sequential traversal passes. It does not produce an atomic snapshot or\nprotect against adversarial concurrent path replacement; if trust or quiescence cannot\nbe established, record exact non-Git identity as `unavailable`. Reading may update atime\non some filesystems; the helper makes no explicit writes, but atime is unrepresented and\nmust remain a possible observer side effect rather than a mutation-parity claim.\nThe helper refuses cross-device entries by default, but it cannot detect every mount\narrangement, including same-device bind mounts. Inspect the mount layout separately and\nexclude every known nested mount before traversal. Any such exclusion makes the result\nbounded. Exclusions use canonical project-relative POSIX `/` syntax; reject rather than\nrewrite absolute, Windows-drive, UNC, backslash, parent-traversal, or path-alias forms.\n\nLocal remote-tracking refs are cached repository state, not live remote proof. When a\ncurrent remote claim matters and read access exists, version `0.1.0` uses only a\nseparately authorized provider read API with an independently confirmed account,\nrepository, and host identity. It does not direct Git transport queries against\ntarget-controlled configuration or URLs. Otherwise mark live proof unavailable. Do not\nfetch solely to make the claim unless updating repository refs was authorised.\n\nTreat validators as potential writers even when their command says `check`. Prefer\ndocumented no-cache and no-bytecode modes, compare complete pre/post state when read-only\nparity matters, and classify every difference. Never remove unknown or pre-existing\nstate to manufacture a clean result. Recover only precisely attributable transient\noutput, to declared recoverable scratch, when that cleanup is within authority; otherwise\npreserve and report it.\n\nDo not perform broad discovery for a self-contained Level 0 answer. Escalate from\nLevel 0 through Level 3 only when impact or uncertainty requires it.\n\n## Protect all five ledgers\n\n- **Authority:** preserve the human or external decision boundary.\n- **Canon:** follow project-owned sources; do not create shadow policy.\n- **Evidence:** treat unknown, stale, missing, or mixed-identity evidence as such.\n- **Surfaces:** do not let UI, docs, reports, or public claims invent product truth.\n- **Lifecycle:** keep proposal, implementation, validation, publication, deployment,\n  and release distinct.\n\nKeep tracked public truth, ignored or private continuity, external evidence, and\nreview artifacts in their declared lanes.\n\n## Route the next action\n\n- Use `$review-project-coherence` for cross-ledger contradictions.\n- Use `$run-independent-review` when multiple review lenses are required.\n- Use `$draft-governed-proposal` for a durable review-only decision packet.\n- Use `$close-governance-decision` after an explicit decision.\n- Use `$review-release-evidence` for readiness or promotion questions.\n- Use `$harmonize-project-content` for explicit user-facing content alignment.\n\nReturn a compact decision record: outcome class, risk level, confirmed target,\nauthority granted, protected invariants, excluded actions, required evidence, and the\nallowed next action or exact blocker.\n"
}

SHA-256 of public snapshot: ff1935b11ef5e7372f55432103cc4f04f4140f4f5930decfa4a3778da2bf65cc