Wardline 01 03 the problem a wardline solves

3. The problem a Wardline solves¶

There is a structural gap between what automated tooling checks and what high-stakes code requires. The standard assurance stack — linters, type checkers, SAST, DAST, unit tests, conventional peer review — verifies syntactic and conventional correctness: Does the code parse? Does it conform to style rules? Are types consistent? Do tests pass? These checks are necessary but insufficient. They cannot determine whether a .get() default is institutionally appropriate, whether an exception handler preserves the audit trail, or whether data crossing a trust boundary has been validated.

Agent-generated code exploits this gap systematically. Agents produce code that follows established good practice — defensive programming, graceful error handling, sensible defaults — applied without contextual judgement. The patterns are individually correct and collectively dangerous. A .get("security_classification", "OFFICIAL") is syntactically identical to .get("city", "Sydney"). The first silently downgrades a document's security classification; the second provides a location default that may be harmless in many contexts. No tool in the standard assurance stack distinguishes them, because the distinction is semantic: it depends on what the field means in the application's institutional context, not on how the code is structured. Without a wardline, both patterns look identical to tooling. With a wardline, the distinction becomes enforceable — the framework makes it possible to declare which contexts prohibit fallback defaults and which permit them.

What is and is not novel here. The individual pattern rules (WL-001 through WL-006) are expressible as custom rules in existing SAST frameworks — Semgrep, CodeQL, Error Prone, or equivalent. Any team with SAST experience could write these rules. The contribution is not the detection primitives but the governance topology that surrounds them: the severity matrix that varies enforcement by declared semantic context, the exceptionability model that distinguishes project invariants from governable overrides, the taint-state model that tracks data authority across boundaries, the fingerprint baseline that makes governance erosion visible, and the institutional integration that connects enforcement to organisational policy. Well-understood SAST capability, freshly composed into a governance-aware framework — that is the claim.

Why now. The emergence of a semantic boundary layer fits a longer progression in software abstraction: machine operations gave way to source code (compilers), source code gave way to frameworks and modules (reuse), frameworks gave way to infrastructure-as-code (deployment automation). Each step moved human effort into a layer where leverage is greater, enabled by the layer below becoming cheap enough to automate.

Cold-start and adoption dynamics. A wardline has an unavoidable delay between annotation effort and visible risk reduction. Teams invest first in making trust topology explicit; only after enough boundaries are declared do the enforcement layers and governance metrics become materially informative. The framework addresses this with incremental adoption (§7, §15): core classification groups establish the topology first, supplementary groups deepen enforcement later. This delay is real and should be treated as an adoption property of the system, not as evidence that the model has no value.

What constrains success. The primary scaling limits are not rule syntax but knowledge-encoding rate and governance capacity. A deployment can fail even with a sound tier model if tacit institutional knowledge is not converted into manifests and boundary declarations quickly enough, or if exception review and boundary-ratification work outgrow reviewer capacity. Later sections address these limits through visibility mechanisms rather than pretending they disappear: fingerprint baselines surface annotation drift (§10.2), governance metrics surface review pressure (§10.4), and conformance profiles allow staged build-out (§15).

Wardline addresses the semantic-boundary gap; it does not address all 13 ACF (Agent Code Failure) failure modes defined in the parent paper (GCBD). ACF failure mode identifiers are defined in [GCBD]. The following table is informative — it describes intended coverage, not conformance requirements. Conformance is assessed against §15, not against ACF coverage. Coverage entries that reference taint analysis assume a conformant taint-tracking implementation as specified in §6.1–§6.5 and §9.1; implementations that do not implement taint tracking MUST NOT claim coverage of ACF-T1, ACF-E1, or ACF-E2. Coverage entries that reference supplementary annotation groups (Groups 2, 8, 9, 11, 14 — see §7) are conditional on those groups being deployed; deployments using incremental adoption (§7) without these groups have correspondingly reduced ACF coverage.

Wardline coverage of Agent Code Failure (ACF) modes defined in GCBD