Active gate vs passive audit

Description

A posture-toward-error pattern with two poles: gate (block invalid inputs at the boundary, preventing them from entering the system) vs. audit (record the signal, surface it on schedule, and let humans or downstream processes respond). The gate is synchronous and forceful — nothing bad passes through. The audit is asynchronous and observational — bad things may pass, but they’re visible and reviewed.

This concept is distinct from asymmetric-gate, which is about cost asymmetry across a boundary (cheap in one direction, expensive in the other). Active-gate-vs-passive-audit is about posture toward error-detection — whether the system acts as enforcer or as witness. A passive audit is still a form of gate in the broad sense (signals are captured), but the intervention is deferred rather than immediate.

The choice between gate and audit is often more interesting than it looks: gates are high-confidence bets (we know what valid looks like well enough to block the rest); audits are lower-confidence (we want to see what comes in before deciding what’s invalid). Systems under active development often start audit-posture and graduate to gate-posture as invariants solidify.

Triggers

User-initiated: User is deciding whether to enforce a constraint at a boundary or to observe and review. Common phrasings: “should we block this?” / “should we just log it?” / “do we need a hard check or can we surface it in monitoring?”

Agent-initiated: Agent detects a pattern where a rule is being applied inconsistently — some instances are blocked, others pass and show up in logs. Candidate inference: “this system has a mixed posture — is the gate/audit split intentional or an oversight?”

Vocabulary cues: “gate,” “block,” “reject,” “validate at ingestion” (gate-side); “log,” “record,” “surface in monitoring,” “audit trail,” “flag for review,” “visibility” (audit-side). Also: “active vs. passive,” “enforce vs. observe,” “synchronous check vs. async review.”

Situation-shape signals: Any error-handling or validation decision with downstream consequences. The concept is most useful when the team is choosing where enforcement happens rather than whether to enforce.

Exclusions

• When there’s no observable error signal — if the system can’t distinguish valid from invalid at the boundary, neither gate nor audit is applicable; the first move is to establish observability.
• When the posture doesn’t matter — low-stakes decisions with trivially cheap correction don’t need this frame. The concept earns its keep when the cost of letting something through is meaningfully different from the cost of blocking it.
• After the system is well-understood — once the domain is fully characterized and schema is stable, the gate/audit question is usually already answered by convention. The concept is most useful when the invariants are still being discovered.

Structure

The gate pole uses asymmetric-gate as its mechanism — block on the expensive path, pass on the cheap path. The audit pole substitutes cadence (when does the audit run?) and surface (where do the audit results appear?) for the blocking mechanism.

Relationships

• asymmetric-gate (specialization relationship) — the gate pole of this concept uses asymmetric-gate as its mechanism. Active-gate-vs-passive-audit is the containing category; asymmetric-gate names the cost structure.
• cadence (composition relationship) — the audit pole requires a cadence: when does the review happen? Daily standup, weekly report, real-time dashboard? Cadence-free audits pile up unreviewed.
• doctrine (composition relationship) — the posture choice (gate vs. audit) is often itself a doctrine: “we gate on schema violations, audit on business-rule violations.”
• trigger-rule-pair (composition relationship) — both gates and audits need triggers: what condition fires the check? A gate without a trigger never executes; an audit without a trigger accumulates nothing.
• gradient (composition relationship) — the gate/audit spectrum is a gradient, not a binary. Rate-limiting, sampling, soft-fails all occupy intermediate positions.

Examples

Aviation safety — preflight checklist vs. flight data recorder

Domain: transportation

Aviation runs both postures toward error at once. The preflight checklist is an active gate: the aircraft does not leave the gate until every item passes, blocking the fault at the boundary. The flight data recorder is a passive audit: it records everything continuously and is read after an incident, surfacing what went wrong once prevention is no longer possible. Same system, opposite stances — pay up front to stop the error, or observe and respond after it — and which one fits depends on how survivable letting the error through would be.

Content moderation

Domain: computer-science

gate: block before publish; audit: publish and flag for human review queue. High-stakes contexts (children’s content) favor gate; lower-stakes or lower-confidence contexts favor audit.

CI/CD checks

Domain: computer-science

gate: fail the build on lint errors; audit: report lint in a dashboard without blocking merge. Teams often choose based on team maturity and signal-to-noise.

Schema validation in APIs

Domain: computer-science

gate: reject malformed requests at ingestion; audit: log malformed requests and alert engineering daily. The gate is appropriate when the schema is stable; the audit is appropriate when the schema is evolving.