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 form 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.

Composition

= asymmetric-gate (the enforcement option) + cadence (the audit’s review rhythm) + surface (what signals are exposed to humans).

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.

Encounters

• Schema validation in APIs — 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.
• CI/CD checks — 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.
• Content moderation — 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.
• The engine’s failure-mode gates — label-without-mapping check, flatter-vs-change-next-move check, asymmetry/reversal check are gates, not audits. The design decision was explicit: block the low-quality projection before it surfaces rather than letting it through and reviewing later.
• KCC field validation — age validation at form submission (gate) vs. logging missing fields post-submission (audit). Mixed posture: gate on critical fields, audit on optional enrichment.
• “Passive log vs. active gate” — common formulation in software design discussions; explicitly in James’s corpus ~30 hits.

When it applies / triggers on

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: Engine 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 form is most useful when the team is choosing where enforcement happens rather than whether to enforce.

Composes with

• asymmetric-gate (specialization relationship) — the gate pole of this form 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.

When it doesn’t apply

• 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 form 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 form is most useful when the invariants are still being discovered.

Sources

• Software engineering tradition: input validation (gate) vs. logging/monitoring (audit) as distinct postures.
• “Passive audit” and “active gate” formulations: ~30 hits in James’s full corpus, across API design, content moderation, and agent-instruction contexts.
• Distinct from asymmetric-gate (Talmy’s force-dynamic cost asymmetry framing); this form is about temporal and agency structure of enforcement, not cost structure.

Canonical exemplars from corpus (T2 2026-05-17)

Mined via scripts/mine_new_form_exemplars.py from data/backfilled-insights.jsonl. 48 backfill-only matches at score ≥ 2 — mid-support. Top co-occurrences: doctrine (7), cadence (7), grain (4). Most matches are in KCC gate-audit infrastructure work, so the exemplar set is somewhat domain-biased.

• Gate surface diminishing returns vs audit-driven work (cwd: campconnect, 2026-04-29): “The gate’s surface has diminishing returns relative to other audit-driven work. PR #326’s framing implies it gets removed at public launch, so deep polish on it might be over-investment. But beta-tester eyes are exactly the audience that sees this surface, so under-investment is also wrong.” — explicit gate vs audit tradeoff, with the audience-grain determining the right posture.
• Two browser-driving goldfishes — gate-audit-v2 + data-hygiene (cwd: campconnect, 2026-04-29): “The data-hygiene goldfish doesn’t drive the browser (it’s editing TS/JSX files based on the audit findings) — only the gate-audit-v2 goldfish needs Chrome MCP. So no actual browser-resource contention.” — the audit findings feed an action (data-hygiene fixes), illustrating audit-then-act vs gate-then-block.
• Pollution failure pattern recurring — gate-audit goldfish landing on primary main (cwd: campconnect, 2026-04-29, task-notification): “The gate-audit goldfish’s scaffold landing on primary main is the third instance today. Each smart-tier goldfish has self-corrected by the next dispatch, but the audit signal is real.” — audit posture surfaces a recurring failure pattern that a gate would have blocked.
• Title normalization at different abstraction layers (cwd: campconnect, 2026-04-24): “Title normalization is the generic-llm analog of iClassPro’s field-mapping decision. Same pattern at different abstraction layers: iClassPro has structured source data and drops lane/time into a sectionLabel field; generic-llm has unstructured source data and needs the LLM to recognize that the lane/time inside the title string belongs at the session grain.” — gate posture (drop into a field at ingestion) vs audit posture (let through, normalize downstream).

Trigger pattern (T2): Active-gate-vs-passive-audit surfaces when the user is choosing where to enforce a constraint (boundary vs downstream review) or noticing inconsistent posture (some violations blocked, others surfaced in logs). The 7-each co-occurrences with doctrine and cadence show that the posture choice is often itself a doctrine specifying its audit cadence.