Wardline 01 10 governance model

10. Governance model¶

A wardline without governance is an honour system. The governance model defines how designated reviewers manage exceptions to wardline declarations, who may authorise them, and what evidence trail they leave.

Governance mechanism summary. The following table maps each governance mechanism to its status under the two governance profiles (§15.3.2). Use this as a quick reference; the subsections below provide full detail.

Governance mechanisms by profile with enforcement type and specification reference

10.1 Exceptionability classes¶

Four classes govern how findings may be overridden:

Exceptionability classes with governance requirements

10.2 Governance mechanisms¶

The following mechanisms apply to the wardline declaration and its exception register, not only to the enforcement tool.

Protected-file review. Designated reviewers MUST approve changes to the wardline manifest, the enforcement baseline, and the verification corpus. Changes to these artefacts without designated reviewer approval are structurally prohibited by the version control system (CODEOWNERS or equivalent).

Temporal separation. The baseline update and the code change cannot be atomically combined by a single actor. If a developer adds a wardline exception and modifies the code that requires it in the same commit, the exception has no independent review.

For deployments at the Assurance governance level (§15.3.2): temporal separation is a MUST requirement. Minimum: separate change, different actor, approved before the dependent code merges. No documented alternatives are permitted.

For deployments at the Lite governance level (§15.3.2): temporal separation is a SHOULD requirement. Teams that cannot sustain full temporal separation MUST document their alternative in the root manifest. The documented alternative MUST include a compensating control — same-actor approval is permitted with mandatory retrospective review within a defined window (recommended: next sprint boundary or 10 business days, whichever is shorter). A Lite deployment that omits temporal separation entirely, without a documented alternative, does not satisfy the Lite governance checklist.

The specific mechanism (separate PR, approval gate, time window) is a binding-level decision.

Branch protection. CI gates — including wardline enforcement — MUST pass before merge to the protected branch. This prevents bypass through direct push and ensures that wardline findings are resolved before code enters the mainline.

Annotation fingerprint baseline. A persistent record of the application's annotation surface — the set of all wardline annotations and their locations. Changes to this surface (annotations added, removed, or modified) are flagged for human review. This includes changes that activate or deactivate SUPPRESS classifications — a trust-classification change that moves a finding from ERROR to SUPPRESS (or vice versa) is a policy change and MUST be visible in the fingerprint diff. This prevents silent erosion of the wardline through gradual annotation removal or classification drift.

For deployments at the Assurance governance level (§15.3.2): the full fingerprint baseline as described in this subsection is a MUST requirement — structured data store, canonical hashing, coverage reporting, and the three-category change detection (added, modified, removed).

For deployments at the Lite governance level (§15.3.2): annotation change tracking is REQUIRED, but the full structured fingerprint baseline is deferred. Lite deployments MUST ensure that annotation changes are visible for human review — this MAY be implemented through VCS diff review of annotation-bearing files, PR-level annotation change summaries, or any mechanism that makes annotation additions, modifications, and removals visible to governance reviewers. The requirement is visibility of annotation changes, not a specific tracking mechanism. Lite deployments that adopt the full fingerprint baseline ahead of graduation satisfy this requirement and simplify the eventual transition to Assurance.

Polyglot fingerprint baselines. In polyglot deployments, fingerprint baselines are per-binding — each binding maintains its own baseline with its own canonical form (see hash canonicalisation above). Cross-binding fingerprint comparison is not a framework requirement. Each binding's baseline tracks its own annotation surface independently; the shared wardline manifest (§14) provides the cross-binding policy alignment, not the fingerprint hashes.

Fingerprint record structure. The fingerprint baseline is a structured data store (see §14 for the interchange format). Each entry records: the annotated function's fully qualified name, its file location, which of the 17 annotation groups are declared on it, the tier context, whether the function is a boundary (and of what type), the artefact class of any changed declarations (policy or enforcement, per §10.3.1), a cryptographic hash of the annotation declarations (not the function body — implementation changes do not trigger governance review), and temporal metadata (first appearance date, last change date).

Hash scope and canonicalisation. The hash scope is the annotation surface only: the set of wardline decorators, tier assignments, and group memberships declared on the function. A change to a function's implementation that does not alter its annotations does not change its fingerprint. The hash MUST be computed over a canonical serialisation of the annotation surface — a deterministic ordering of annotation groups, tier assignments, and boundary declarations — not over the raw source text. Without canonicalisation, equivalent annotations expressed in different syntactic order (e.g., @wardline(tier=1, groups=[1,2]) versus @wardline(groups=[1,2], tier=1)) produce different hashes, generating spurious change-detection events. The canonical form is a binding-level decision — each language has its own annotation syntax — but the requirement for canonicalisation is a framework invariant. In polyglot deployments, fingerprint baselines are per-binding: each binding maintains its own baseline with its own canonical form. Cross-binding fingerprint comparison is not a framework requirement.

Coverage reporting. The baseline MUST also report annotation coverage: the count and ratio of annotated functions to total functions, with specific enumeration of unannotated functions in Tier 1 modules. This directly addresses residual risk 4 (annotation coverage gaps — §13) — unannotated functions in high-authority modules are the highest-risk blind spots, and the baseline makes them visible.

Change detection operates by diff between the current annotation surface and the stored baseline. Three categories of change are flagged:

• Annotation added — a previously unannotated function now has wardline declarations. Low risk; increases coverage.
• Annotation modified — an existing annotation's group membership, tier assignment, or boundary type has changed. Medium risk; this is a classification policy change that may alter which rules apply and at what severity.
• Annotation removed — a previously annotated function no longer has wardline declarations. High risk; the function has left the enforcement surface entirely. Annotation removal in Tier 1 modules MUST be flagged as a priority review item.

Policy and enforcement change presentation. Fingerprint baseline diffs SHOULD distinguish policy artefact changes from enforcement artefact changes (§10.3.1). Changes to tier assignments, boundary declarations, validation-scope consumer lists, restoration boundary provenance claims, and optional-field declarations are policy changes — they alter the trust topology and require security-policy-grade review. Changes to rule severity overrides, precision thresholds, and tool configuration are enforcement changes — they alter detection behaviour and require standard configuration management review. Presenting these as distinct categories in the diff output allows governance reviewers to prioritise policy changes and delegate enforcement changes to standard CM processes.

The baseline is updated after governance review — the reviewed state becomes the new baseline. The specific access mechanism is an implementation detail (§14): the interchange format defines the logical record structure; file manipulation, CLI commands, or MCP tool interfaces are all valid mechanisms for reading and updating the baseline.

Restoration boundary declarations. Declarations that serialised representations may be restored with their original tier are subject to the same governance as trust-escalation declarations. The provenance justification MUST address the four evidence categories defined in §6.3. Restoration boundaries are reviewed as part of the annotation fingerprint baseline.

Manifest coherence checks. Before code-level enforcement runs, the manifest itself SHOULD pass a static coherence analysis that verifies internal consistency and completeness of the annotation surface. For deployments at the Assurance governance level (§15.3.2): manifest coherence is a MUST gate — all coherence conditions MUST pass before code-level findings are considered valid. For deployments at the Lite governance level: manifest coherence is RECOMMENDED. Manifest coherence checks operate on the manifest, overlay, and code-level annotation declarations — they do not analyse application behaviour. Five coherence conditions are checked:

• Tier–topology consistency. Tier assignments in the manifest are compared against declared data-flow topology (boundary declarations, validation-scope consumer lists). A data source declared at Tier 4 that feeds a consumer declared within a Tier 1 validation scope without an intervening validation boundary is a manifest-level contradiction — the policy surface permits a data flow that the enforcement surface would flag.
• Orphaned annotations. Code-level wardline annotations (decorators, type annotations, marker interfaces) that have no corresponding declaration in the manifest or any overlay. An orphaned annotation is enforced but ungoverned — it affects code-level findings without appearing in the governance surface. Orphaned annotations SHOULD be flagged as governance-level findings.
• Undeclared boundaries. Boundary declarations in the manifest or overlay that do not correspond to any code-level annotation. An undeclared boundary is governed but unenforced — the policy surface claims a validation boundary exists where no code-level annotation marks it. Undeclared boundaries SHOULD be flagged as governance-level findings.
• Unmatched contracts. Contract declarations in the manifest or overlay (e.g., validation-scope consumer entries) that do not match any code-level annotation at the declared location. This detects contract declarations that have drifted from the code through refactoring, renaming, or deletion without corresponding manifest updates.
• Stale contract bindings. A contract_bindings entry (§14.1.2) whose declared function path does not resolve to an existing function in the codebase. This is the inverse of unmatched contracts — a contract binding that silently points nowhere after a function deletion or rename, leaving the contract nominally satisfied but with no actual consumer. Detection is a simple existence check (no semantic analysis needed).

Manifest coherence checks run as a CI gate before code-level enforcement. The sequencing is deliberate: coherence failures indicate that the annotation surface is incomplete or contradictory, and code-level findings produced against an incoherent manifest are unreliable. A coherence failure SHOULD block the enforcement run; under the Assurance governance profile, coherence failures MUST block the enforcement run (§15.3.2). Running pattern rules against a manifest with orphaned annotations or undeclared boundaries produces findings whose governance status is ambiguous.

Coherence check findings appear in the SARIF output with ruleId prefixed COHERENCE- (e.g., COHERENCE-ORPHAN, COHERENCE-UNDECLARED) and are subject to standard governance (STANDARD exceptionability — overridable with documented rationale, but not silently suppressible). The specific detection mechanisms are binding-level decisions — language bindings define how annotations are discovered and matched against manifest declarations.

Provenance justification. For high-risk trust-escalation declarations — particularly declarations that data from an external source should be treated as internal (Tier 1) — the governance model requires documented rationale of the actual data source, the trust basis, and the institutional authority for the escalation. "We trust this because we always have" is not a sufficient rationale.

10.2.1 Governance audit logging¶

Governance events — exception grants, baseline changes, manifest modifications, and control-law transitions — MUST produce an auditable trail. This subsection defines the logging requirements.

Events that MUST be logged:

Governance events requiring audit logging

Storage and integrity. Governance events are recorded in two locations: the wardline governance artefacts themselves (exception register, fingerprint baseline) and the SARIF output from each enforcement run. The SARIF output is the primary audit trail — it is produced by the enforcement tool, timestamped, and contains the manifest hash used for the run.

The exception register and fingerprint baseline are VCS-tracked files protected by CODEOWNERS. VCS history provides tamper-evident logging — each change is a commit with author identity, timestamp, and content hash. This is not append-only in the strict sense (VCS permits rewriting history), but branch protection rules that prevent force-push to the protected branch provide practical tamper resistance for most government environments.

For environments requiring stronger tamper evidence (e.g., systems subject to formal audit-logging controls), the wardline CLI SHOULD support exporting governance events to an external append-only log (syslog, SIEM, or dedicated audit database). The export format is SARIF — each governance event is a SARIF result with ruleId: "GOVERNANCE" and the event details in the property bag. This allows governance events to flow into the same audit infrastructure that handles other security events.

Retention. Governance artefacts (exception register, fingerprint baseline, SARIF runs) SHOULD be retained for the duration of the system's accreditation period. In accredited environments this is typically three years from the last formal security accreditation; organisations MAY retain for longer where their retention policy requires it.

10.3 Scope of governance¶

The governance model applies to the wardline declaration, not only to the enforcement tool's findings. A change to the wardline manifest — adding a new trust boundary, reclassifying a data source, modifying an authority tier assignment, or declaring a restoration boundary — is a policy change with potential security implications. It receives the same governance treatment as a change to the application's security controls, because that is what it is.

Agent-authored governance changes. In workflows where AI agents generate code, agents may also generate wardline governance artefacts — adding exception register entries, modifying allowlist configurations, or applying annotations that change the trust topology. These are policy edits, not merely code edits — in one documented incident, an agent resolved a linter conflict by adding a permanent per-file allowlist exception, bypassing the governance model entirely. Agent-authored changes to the wardline manifest, the exception register, the allowlist, or any governance artefact MUST be flagged as agent-originated and require human review as a distinct governance step. The fingerprint baseline flags the change; the governance model MUST additionally distinguish who authored it. An agent that produces a plausible-sounding rationale for a trust-escalation exception is exercising precisely the "competence spoofing" failure mode (ACF-S1) applied to governance rather than code.

The detection mechanism for agent authorship is a binding-level requirement. Language bindings MUST specify at least one of: a metadata field in the exception register recording authorship origin (human vs. agent), integration with VCS-level provenance tracking (e.g., commit-level author metadata distinguishing human and agent contributions), or a convention by which agents mark governance artefacts they generate (e.g., structured commit message tags). The specific mechanism varies by toolchain; the requirement is that agent-originated governance changes are distinguishable from human-originated ones. This is a framework invariant, not a binding convenience — the governance model's integrity depends on distinguishing human from agent authorship of policy artefacts.

The temporal separation requirement (§10.2) provides partial protection — the agent cannot atomically combine the governance change with the code that requires it — but "different actor" in temporal separation MUST mean a different human actor for the governance change when the dependent code change is agent-originated. An agent that generates both the governance exception and the code that requires it in separate commits satisfies temporal separation in form but not in spirit — the two artefacts share the same generative context. The human reviewer must understand that agent-authored rationales warrant the same scepticism as agent-authored code.

Governance of supplementary contract annotations (Groups 5–15). The severity matrix (§8) and its UNCONDITIONAL/STANDARD/RELAXED exceptionability classes govern findings from the nine framework rules — six pattern rules (WL-001 through WL-006) and three structural verification rules (WL-007 through WL-009). These rules apply to code annotated with core classification groups (1–4, 16–17). Findings generated by supplementary contract annotations (Groups 5–15 — operation semantics, failure mode, data sensitivity, determinism, concurrency, access/attribution, lifecycle) are subject to the same governance mechanisms (protected-file review, temporal separation, fingerprint baseline) but their exceptionability is binding-defined. Language bindings SHOULD classify supplementary findings as STANDARD by default, allowing governance override with documented rationale, unless the binding explicitly designates specific supplementary findings as UNCONDITIONAL. This distinction is stated here to prevent ambiguity: the severity matrix governs pattern rules; supplementary groups generate their own findings with their own severity, and the governance model applies to both.

10.3.1 Artefact classification: policy and enforcement¶

Not all wardline artefacts carry the same governance weight. A tier assignment is a policy decision with security implications; a scanner severity threshold is operational configuration. Conflating the two — governing both through the same review process — either over-burdens configuration changes or under-governs policy changes. This subsection introduces an explicit classification that drives governance requirements.

Policy artefacts encode institutional decisions about trust, evidence, and permitted behaviour. Changes to policy artefacts alter what the wardline means — they change the security posture of the application. Policy artefacts include:

• Tier assignments — which data sources are classified at which authority tier (§14.1.1)
• Boundary declarations — where tier transitions occur, including validation-scope consumer lists (§14.1.2)
• Restoration boundary provenance claims — which serialised representations may be restored to which tiers, and on what evidence basis (§6.3, §14.1.2)
• Exception rationale — the documented justification for governance overrides, including the reviewer identity and expiry (§14.1.3)
• Optional-field declarations — which fields on which data sources are optional-by-contract, and what their approved defaults are (§8.2.1, §14.1.2)

Policy artefacts are governed under security policy procedures: changes require ratification by a designated authority, mandatory impact assessment before deployment, and scheduled adequacy review at intervals defined in the manifest metadata (§14.1.1). The governance mechanisms in §10.2 (protected-file review, temporal separation, fingerprint baseline) apply in full to policy artefact changes.

Enforcement artefacts encode how the wardline's policy is operationalised by tooling. Changes to enforcement artefacts alter how the wardline works — they affect detection capability and operational behaviour, but they do not change the trust topology. Enforcement artefacts include:

• Pattern rule severity configuration — per-cell overrides in the root manifest or overlays (§14.1.1, §14.1.2)
• Scanner operational settings — wardline.toml entries: rule severity thresholds, external-call heuristic lists, determinism ban lists
• Precision and recall thresholds — project-defined calibration points (§11)
• Expedited governance ratio threshold — the project's declared tolerance for expedited exceptions (§10.4)
• Tool configuration — scanner flags, CI integration settings, SARIF output options

Enforcement artefacts are governed under configuration management: version control, CI integration, standard code review. They do not require ratification authority, impact assessment, or scheduled adequacy review beyond standard CM practices.

The manifest contains both types. The root wardline.yaml (§14.1.1) carries tier definitions (policy) alongside rule configuration (enforcement). The overlay (§14.1.2) carries boundary declarations (policy) alongside rule overrides (enforcement). The distinction is per-field, not per-file. Enforcement tools SHOULD present policy artefact changes and enforcement artefact changes as distinct categories in the fingerprint baseline diff, so that governance reviewers can prioritise policy changes and configuration managers can handle enforcement changes through standard processes.

Why this matters now. The governance model (§10.2, §10.3) already implicitly distinguishes these categories — tier changes receive heavier governance scrutiny than tool configuration changes in practice. Making the distinction explicit serves three purposes: it gives the governance profile graduation its vocabulary — a "Wardline Lite" profile can require full governance for policy artefacts while relaxing governance for enforcement artefacts; it enables manifest-level threat modelling — governance-layer attack vectors (manifest poisoning, boundary manipulation) target policy artefacts specifically; and it aligns the wardline with established security governance practice — security classification guides are policy artefacts governed differently from the systems that enforce them.

10.3.2 Manifest threat model¶

As annotation coverage grows, coding-level risk falls — annotations constrain generation by making institutional knowledge part of the agent's context window. But the governance risk rises correspondingly: the annotations themselves — who writes them, who approves changes, who decides a data source is Tier 1, who declares a validation scope adequate — become the dominant risk surface. This subsection defines the attack vectors that target the manifest as a policy surface and the integrity controls that address them.

Three governance-layer attack vectors. These are harder to detect than code-level evasion because they operate on policy artefacts rather than code:

1. Manifest poisoning. Corrupting tier assignments so that agents generate code compliant with the wrong policy. A tier assignment that classifies external API data as Tier 1 (INTEGRAL) causes downstream code to treat unvalidated input as authoritative — and the code will be structurally correct against the declared wardline. The poisoning is invisible to enforcement because enforcement faithfully implements the policy it is given. This vector targets the most consequential policy artefact: the tier definition in the root manifest (§14.1.1).

Integrity control: Tier assignment changes (particularly downgrades from a higher to a lower tier, e.g., Tier 1 → Tier 2, or upgrades from a lower to a higher tier, e.g., Tier 4 → Tier 1) MUST require two-person review. Tier changes MUST be tracked as a distinct change category in the fingerprint baseline (§10.2) and presented separately from annotation changes. A tier change on a data source that feeds Tier 1 consumers SHOULD trigger an impact assessment showing the cascade: which boundaries, which pattern rules, and which code paths are affected.

2. Governance fatigue exploitation. Submitting high volumes of annotation change requests that overwhelm review capacity, smuggling consequential changes in noise. This exploits the finite governance capacity (§10.4) by consuming reviewer attention with legitimate-looking changes, then including a boundary widening or tier reclassification in the same review batch. The attack is effective because the governance mechanisms (protected-file review, temporal separation) are per-change — they do not distinguish routine from consequential changes within a review session.

Integrity control: Enforcement tools SHOULD detect and flag anomalous annotation change patterns: volume spikes (more than N annotation changes in a single review window, where N is a project-defined threshold declared in the root manifest), clustered tier changes (multiple tier reassignments in the same commit or PR), and boundary widenings without corresponding code changes (a validation-scope consumer list grows without new consumer functions appearing). These anomaly signals are governance-level findings (distinct from code-level findings) that alert reviewers to potential fatigue exploitation. The expedited governance ratio metric (§10.4) provides a lagging indicator; the anomaly signals defined here provide a leading one.

3. Boundary declaration manipulation. Subtly widening validation-scope declarations so that prohibited data flows become policy-permitted. A validation-scope consumer list that grows to include a function with weaker preconditions effectively lowers the semantic validation standard for all consumers — the validator now satisfies a broader scope, and code that would previously have been flagged becomes compliant. This vector is particularly dangerous because it looks like legitimate architecture evolution (new consumers are common), and the governance review must distinguish genuine scope expansion from scope dilution.

Integrity control: Validation-scope changes (consumers added or removed) MUST require two-person review when the boundary claims Tier 2 semantics. New consumers added to a validation-scope declaration SHOULD be flagged for explicit review with a governance-level finding that identifies the new consumer and asks whether the validator's checks cover the new consumer's preconditions. Consumer removal SHOULD be flagged as a scope contraction that may indicate architectural change. The fingerprint baseline already tracks validation-scope changes as a distinct change category (§10.2); this control adds the two-person review requirement specifically for Tier 2 boundaries.

Anomaly detection requirements. The three attack vectors above share a common detection surface: unusual patterns in policy artefact changes. Enforcement tools SHOULD implement the following anomaly signals as governance-level findings:

Anomaly detection signals for manifest threat model integrity controls

These signals are governance-level findings, not code-level findings. They appear in the SARIF output with ruleId: "GOVERNANCE" and are subject to the governance model's own exception mechanism (STANDARD exceptionability — they can be overridden with documented rationale, but they cannot be silently suppressed).

10.4 Governance capacity¶

Governance capacity is finite. Every finding that requires human review consumes reviewer attention, and reviewer attention is the scarcest resource in any assurance process.

Capacity substitution. The wardline's governance model is designed to shift human review from syntactic pattern detection (which enforcement tooling and LLMs handle well) to semantic classification review (which requires human judgement). The governance burden is not purely additive — pattern-rule enforcement (§8) automates away code-level review that humans previously performed manually, and pre-generation context projection (§9.5) reduces violation volume upstream of enforcement. The net effect is that human attention is redirected from low-leverage syntactic review to high-leverage semantic classification decisions. However, the governance mechanisms in §10.2 (fingerprint baseline, temporal separation, manifest ratification) are net-new activities with no pre-wardline analogue. The substitution holds for code-level review; the governance surface is genuinely additional. The governance burden should be evaluated against the baseline described in §3 — in LLM-heavy development environments, the alternative to wardline governance is not "relaxed human review" but "no effective semantic review at all."

Three mechanisms implicitly regulate governance load:

• Finding rate scales with annotation coverage. Unannotated code produces no findings. As annotation coverage grows, finding volume grows proportionally. This means governance load is controllable through annotation investment — the organisation decides how much of its codebase to bring under wardline enforcement.
• Precision floor as implicit load limiter. The 80% precision floor (§11) ensures that no more than 20% of findings are false positives. A rule that generates excessive governance overhead through false positives is structurally prohibited from reaching blocking status.
• Exception boundary dynamics. Exception boundaries (STANDARD and RELAXED overrides) tend toward a reinforcing loop in which the more frequently an override is granted, the less scrutiny subsequent overrides receive — what began as an exception becomes the default behaviour, and the governance review becomes perfunctory. To counter this dynamic, bindings SHOULD implement age-based exception management (binding requirement): STANDARD exceptions carry a maximum age (recommended: 180 days), after which they are flagged for mandatory re-review. RELAXED exceptions carry a longer maximum age (recommended: 365 days) — the lighter governance burden warrants a longer window, but the absence of any age limit would allow RELAXED overrides to accumulate indefinitely, which is how governance quietly turns into wallpaper. If re-review does not occur within a defined grace period, the exception lapses and the underlying finding reverts to its default severity. The specific age thresholds, grace period, and escalation mechanism are binding-level decisions — the framework requires the capability, not the parameters.

Exception recurrence tracking. The exception register MUST track recurrence: when an exception for the same rule at the same code location is renewed after expiry, the renewal MUST be flagged as a recurrence event. A first renewal is a governance-level WARNING — it may indicate a legitimate deferral. A second or subsequent renewal for the same rule at the same location MUST trigger automatic governance escalation. The enforcement tool's responsibility is detection and signalling: it MUST flag the recurrence event as requiring escalation, and the specific authority hierarchy and routing are organisational decisions declared in the manifest's governance configuration. This prevents temporal gaming where agents regenerate the same violation with a fresh exception and new rationale after each expiry, exploiting the governance model's assumption that each exception is an independent decision. Recurrence tracking operates on the tuple (rule, code location) — a function that has been excepted for WL-001 three times is structurally suspect regardless of whether the rationale differs each time. The enforcement tool SHOULD surface recurrence counts in the fingerprint baseline diff and in the SARIF output as a wardline.exceptionRecurrence property on the relevant finding.

Expedited governance paths. For time-critical exceptions — production incidents, security patches, or other contexts where the standard temporal separation would introduce unacceptable delay — an expedited path MAY be defined at the binding level. The expedited path MUST still require documented rationale and reviewer identity, but MAY compress the temporal separation requirement (e.g., same-PR approval by a designated emergency reviewer). Expedited exceptions MUST be flagged for retrospective review within a defined window.

Expedited governance ratio. Each exception register entry carries a provenance field indicating whether the exception was granted through the standard or expedited governance path (§14). The enforcement tool MUST compute and report the expedited/standard ratio — the proportion of active (non-expired) exceptions granted through the expedited path — in its findings output (§11.1). This ratio is a leading indicator of governance decay (residual risk 6 — §13): a ratio that trends upward signals that "time-critical" has expanded to include routine work. The framework does not mandate a specific threshold — the appropriate ratio depends on operational tempo and organisational risk appetite — but projects SHOULD declare a threshold in their root wardline manifest. When the computed ratio exceeds the declared threshold, the enforcement tool produces a governance-level finding (distinct from code-level findings) that flags the ratio for review. The threshold is a governance parameter, not a precision metric — there is no "correct" value, only a value the organisation has chosen to defend.

For deployments at the Assurance governance level (§15.3.2): the expedited governance ratio MUST be computed and reported. Projects MUST declare a threshold in the root manifest. The automated governance-level finding when the threshold is exceeded is a MUST requirement.

For deployments at the Lite governance level (§15.3.2): the expedited governance ratio is RECOMMENDED. Projects that compute the ratio benefit from the governance decay signal immediately. Projects that do not yet compute the ratio MUST instead document their expedited exception approval process in the root manifest and review that process at each manifest ratification cycle. This provides a weaker but non-zero governance signal — the organisation is at least recording and periodically examining its use of expedited paths, even if the metric is not yet automated.

10.5 Enforcement availability (control law)¶

The enforcement tool is itself a system that can fail. When it is unavailable — CI outage, tool crash, licence expiry, infrastructure failure — the branch protection gate (§10.2) cannot pass. Pure fail-closed blocks delivery indefinitely over tooling problems. Pure fail-open is uncontrolled bypass. Neither is acceptable. The framework adopts a three-state control law model:

Normal law. The enforcement tool runs under full capability: all rules active, manifest current (ratification not overdue), golden corpus maintained, precision and recall above floors. Merge requires enforcement pass. This is the expected operating state.

Alternate law. The enforcement tool runs but in a degraded state. Degradation conditions include: manifest ratification overdue (§14.1.1), golden corpus not updated within a defined window, a rule's precision or recall below the declared floor but not yet returned to development, partial rule coverage (some rules disabled for remediation), or advisory-only mode. The enforcement output reports which capabilities are degraded. Merge MAY proceed with documented acknowledgment of the specific degradation. Not all degradations are equal — bindings SHOULD classify alternate-law degradations into governance bands, with designated reviewer approval required for degradations that affect blocking rules, precision floors, or Tier 1 coverage. A stale corpus is a milder degradation than multiple disabled rules in Tier 1 modules; the governance response should be proportional. Alternate law covers the common real-world cases that are not full outages but are also not full enforcement.

Direct law. The enforcement tool cannot run at all. This is a governance incident, not an expedited exception. Merges MAY proceed only under enforcement-unavailable governance, which is structurally distinct from the expedited exception path (§10.4) — otherwise "tool unavailable" becomes a cheap costume that routine bypass can wear.

Enforcement-unavailable governance requires:

• Authorisation record — who authorised the bypass, why the tool was unavailable, the affected commit range, and the duration window
• Scoped duration — the authorisation covers a specific time window or commit set, not an open-ended bypass. The root wardline manifest SHOULD declare a maximum direct-law duration (recommended: 48 hours). When enforcement has been unavailable beyond the declared threshold, the governance-level finding escalates to indicate that security-sensitive code SHOULD NOT proceed under direct law
• Governance artefact exclusion — direct-law bypass MUST NOT cover changes to wardline policy artefacts: wardline.yaml, overlay files, exception registers, or fingerprint baselines. The minimum technical control is VCS branch protection that restricts modification of governance file paths to designated governance actors independently of CI status. Where the VCS platform does not support path-scoped protection independent of CI, the manifest MUST document the compensating process control, and the retrospective scan (§10.5) MUST verify that governance artefacts were not modified during the direct-law window. If the enforcement tool is down, code MAY proceed under emergency governance, but changes to the guardrails themselves remain blocked unless a stronger manual governance path exists (e.g., designated authority approval outside the normal CI flow). This prevents an outage from being used to rewrite the enforcement policy during the window when the enforcement tool cannot detect the rewrite
• Mandatory retrospective scan — the first successful enforcement run under normal law MUST scan all code merged during the degraded or direct-law window. The retrospective scan covers the full diff between the last normal-law enforcement pass and the current state — not per-commit analysis, because interactions between commits (taint flows that only emerge in the combined state) would be missed. Retrospective findings are tagged with a distinct provenance marker (wardline.retroactiveScan: true in the SARIF result properties) so reviewers can distinguish "this was always there but we couldn't check" from "this was introduced and caught at the normal boundary." Retrospective findings remain open until explicitly reviewed — they do not auto-clear

Control law in SARIF output. The current enforcement state is reported in the SARIF run properties as wardline.controlLaw with values "normal", "alternate", or "direct". Runs under alternate or direct law are flagged as such so they are not treated as equivalent to normal-law runs for assessment purposes. An assessor reviewing SARIF output can see whether the findings were produced under full enforcement or degraded conditions. When the control law is alternate, the wardline.controlLawDegradations property lists the specific degradation conditions.

Retrospective scan verification. The mandatory retrospective scan (above) MUST be independently verifiable — an assessor MUST be able to detect whether the required scan was performed. The verification mechanism:

1. Every SARIF run under alternate or direct law records wardline.controlLaw and the commit range affected (wardline.degradedCommitRange)
2. The first SARIF run that returns to normal law MUST include wardline.retroactiveScan: true at the run level and wardline.retroactiveScanRange declaring the commit range covered
3. If the first normal-law run does NOT include the retrospective scan marker, the wardline CLI produces a governance finding: "Retrospective scan not performed for degraded window [commit range]"
4. The governance finding persists on every subsequent run until either the retrospective scan is performed or the finding is excepted through the standard governance path (STANDARD exceptionability — not RELAXED, because skipping a retrospective scan on code merged without enforcement is a genuine risk acceptance)

This mechanism makes the absence of a required scan detectable. Without it, an assessor reviewing SARIF history would see a direct-law window followed by normal-law runs, with no way to distinguish "retrospective scan was performed and found nothing" from "retrospective scan was never performed."