v1
1Layer 1 · Principles · Explainer 02

Automation and audit over gates and approvals.

A gate assumes people will misbehave unless someone blocks them. Audit starts from good faith and relies on the record to keep everyone accountable.

The shift: from prevention to flow.

A gate puts a human in the loop who must approve before work proceeds. It slows the work and fills an inbox with decisions that no one can audit later, and the default posture becomes stop until told otherwise.

Audit inverts that default. Every change and every decision lands in Git history, the record supplies the accountability, and the work keeps moving.

Gates
An approval email in an inbox that nobody can audit later. The default is stop.
Audit
Git history and merged pull requests, with every decision traceable. The default is flow.

The gate becomes policy as code.

The gate becomes an automated, auditable check that runs in CI, and the result lands in the repository's history alongside the change it judged.

.github/workflows/audit.yml
on: [pull_request]
jobs:
  audit:        # validate each changed document
    steps:
      - { uses: actions/checkout@v4, with: { fetch-depth: 0 } }
      - uses: c4g-john/docassert-action@v1
        with: { command: validate, changed-only: 'true' }
  consistency:  # broken traces block the merge
    steps:
      - { uses: actions/checkout@v4 }
      - uses: c4g-john/docassert-action@v1
        with: { command: consistency }

Where gates still belong.

Some contexts legally require a person's signature, and the framework accommodates them. A human approval stays available for the cases that need one, as a documented exception.

When a human signature is required
Model it explicitly with branch protection that requires a named reviewer on the pull request. The approval lands in the merge record with the rest of the history, and one of the gate's signals is now a person's explicit sign-off.