PLATFORM / PRINCIPLES

Four invariants. Every capability inherits them.

The substrate is not configurable. Event sourcing, audit gates, idempotency and reversibility are the contract every module of the platform inherits before it earns the right to be called a capability. This is what makes the platform auditable and the operator in control.

Back to the platform Talk about the substrate

INVARIANTS

The contract is upstream of every capability.

Before a module is allowed to suggest, decide or apply, it must inherit the substrate. This is what separates a platform from a collection of scripts.

Layer output

Event sourcing

Every state change is an event in an append-only log. The current state is a projection of the events. Reconstruction is always possible because the source of truth is the timeline, not the snapshot.

  • Append-only event log
  • Projections derive state
  • Replay reconstructs
Output auditable timeline

Layer output

Audit log

Every applied action writes a row to ads.audit_log (or its domain equivalent). The row carries the reason, the snapshot before, the actor, the rules version. Nothing happens silently.

  • Reason + snapshot_before per row
  • Rules version (git SHA) recorded
  • Reviewable before next action
Output explainable trail

Layer output

Idempotency

Same (rule, natural_key, target_state) never duplicates. Idempotency keys protect from accidental re-runs, network retries, or operator double-click. The platform fails safe under repetition.

  • Idempotency keys on suggestions
  • Deduplication at action layer
  • Re-run cost: zero
Output safe under retries

Layer output

Reversibility

Rollback within 90 days in one command. apply_*.py persists pre-state snapshots so the operator can undo any decision. Reversibility is not a feature added later — it is required before the apply runs.

  • Pre-state snapshot per apply
  • Rollback ≤ 90 days, 1 command
  • Human override always wins
Output reversible operation

SIDE-EFFECT GATE

Real-world actions require explicit operator approval.

The platform can prepare actions, draft them, audit them — but apply that touches the world (Amazon writes, DNS mutations, real sends, public deploys) requires explicit operator approval in chat. The protocol is unmoved by speed or convenience.

web-builder / production route
Canonical route /platform/principles/
Surface state approval contract
Evidence Data, audit_log entries, reasoning. The operator sees what would change before the change runs.

required

Draft The action is prepared in a non-applied form. Dry-run output is visible.

required

Approval The operator approves explicitly in chat — not in a doc, not by silence.

required

Apply Only after approval. Audit_log row is written before the side effect returns.

gated

Readback The applied state is read back and confirmed. Public deploys are verified against production, not local.

required

Decision gate operator owns

The platform never auto-applies side effects without the operator. Speed of the loop never overrides the gate.

NEXT

If your operation needs the substrate, not the scripts, the conversation starts here.

Many tools automate. Few make their automation auditable, reversible and operable by a human in the loop. If that distinction matters for your operation, talk to us.

Talk about the substrate

Bring the friction you can already feel.

We will shape the route: pattern, system review, audit or no-build decision before anything expands.

Talk about the system See how we work