Capability · Control layer

Three-tier sign-off. Versioned. Reversible. Audit-logged.

Anything that changes a versioned artifact, a spec, a build manifest, a policy, moves through three tiers: author, peer review, sign-off. Every change creates a new version. Revert restores any prior. Linked plans and specs reconcile through a readiness gate before downstream work trusts a document.

3-tier
Sign-off
Versioned
Every change
Revertable
Any prior version
Audit-logged
Every decision
packwolf.app · Approvals
Live screenshot
Approvals screenshot
The approvals queue. Pending three-tier reviews, exception escalations, and the audit trail per decision.
What it actually does

The parts that make this work.

Three tiers, in order.

Author writes. Peer reviewer checks. Final approver signs. The order is enforced, you can't sign-off without a peer review on the same version.

Spec versions are append-only.

Editing a spec creates a new version. Old versions don't disappear. Revert restores any version; comparing versions shows the diff.

Manifest validation.

When a plan changes, the build manifest validates against the linked spec readiness state. Missing approvals show as readiness gaps before downstream work assumes the doc is build-ready.

Exception queue captures escalations.

Edge cases, a tier change that can't follow normal flow, land in the exception queue with explicit operator handling. Nothing slips through.

Approval rules are configurable.

Per-doc-type approval policies. Some docs need three tiers; some need one. Some need specific roles. Operators set the rules; the gate enforces them.

Every decision is in the audit log.

Author, reviewer, approver, timestamps, comments, version IDs. Compliance can reconstruct any decision trail from the log.

How it works

The path through approvals.

  1. 01

    Author makes a change.

    Edit a spec, plan, or policy. The change creates a new version in append-only history. The version starts in author state, not yet visible to downstream consumers as build-ready.

  2. 02

    Peer review opens.

    Reviewer can see the diff vs. the prior version, leave comments, request changes, or approve. Comments thread per section.

  3. 03

    Final approval.

    Once peer review approves, the doc goes to the final-approval tier. Final approver signs off with a comment on the audit record.

  4. 04

    Manifest validates.

    Linked plans and specs validate through the readiness gate. If approvals are incomplete or out of order, downstream work pauses until they're resolved.

  5. 05

    Build-ready propagates.

    Once approved, the version becomes build-ready. Downstream tools can trust the spec; cascading workflows can spawn task-level work against it.

  6. 06

    Revert if needed.

    If the approved version turns out to be wrong, revert restores any prior version as the live state. The reverted-from version stays in history. Nothing is lost.

Common questions

Things engineers actually ask.

Configurable per policy. Some teams require strict separation; some allow it for low-risk doc types. The audit log shows the actual chain regardless.

Related capabilities
CapabilityWorkflowsCapabilityProduct OSCapabilityObservability
Source: docs/specs.md

See it in your workspace.

Closed-beta cohorts are small. Tell us what you'd want this capability to handle for your team.

Request beta access