Skip to content

Wardline 01 05 authority tier model

5. Authority tier model

The authority tier model is the foundation of any wardline. It defines how an application categorises its data according to the guarantees the system is entitled to assume about each value.

5.1 Four tiers

Tier Classification Meaning Verification basis
Tier 1: Trusted assertion Authoritative internal data Audit records, decision products, fact records. Missingness or corruption is an integrity failure. Institutional (not tool-verifiable)
Tier 2: Semantically validated representation Semantically validated data Has passed through both structural and semantic validation boundaries within the declared validation scope (§14.1.2). Safe to use for its declared semantic purposes without further value-level validation. Machine-verified routing + governance-assured adequacy
Tier 3: Guarded representation Guarded data Has passed through a structural validation boundary. Fields are present, types are correct, the data satisfies its declared structural guarantee. Values may be nonsensical or out of range. Machine-verifiable (schema conformance is decidable)
Tier 4: Raw observation Unvalidated external data From outside the system boundary. May be malformed, malicious, or missing. None (no validation has occurred)
Four-tier authority model with trust classifications and verification basis

The coding posture column is normative in the following sense: the pattern rules (§8) and severity matrix (§8.3) are derived from the posture requirements of each tier. Posture compliance is assessed through the pattern rules and enforcement layers specified in §8 and §9; conformant implementations are not required to enforce posture beyond these mechanisms. Each tier's posture is a consequence of what the preceding validation step has established:

  • Tier 1 is not defensive against malformed data — it is strict (offensive) against invariant violation. Fallback idioms (field access with defaults, attribute access with fallbacks, broad exception handling) are prohibited because they convert integrity failures into undetected corruption.
  • Tier 2 trusts both structure and values. Domain constraints have been verified for every intended use within the declared validation scope, so per-site value-level re-validation is redundant. Code at Tier 2 may use field values directly in calculations, comparisons, and decision logic. Cross-cutting concerns — authorisation checks, freshness verification, concurrency guards, state-transition validation — remain necessary because they are not properties of the data's values. The distinction between redundant value-level re-validation and required cross-cutting validation is code-review guidance, not a scanner enforcement target; the pattern rules in §8 do not include detection of either redundant re-validation or missing cross-cutting checks at Tier 2.
  • Tier 3 trusts structure but not values. Field access is safe (the structural guarantee establishes that the field exists and has the right type), but using a value in a division, a URL fetch, or a security decision without checking domain constraints is unsafe. The .get() with a default is redundant in Tier 3 (the field is guaranteed present) but the value it returns may still be dangerous.
  • Tier 4 trusts nothing. Even accessing a field may crash if the field is absent or the data is malformed.

Once these postures are explicit, the pattern rules in §8 stop looking arbitrary and start looking like consequences.

Adoption order. The tier model is not only a classification scheme; it is also the dependency structure for incremental adoption. Core classification declarations establish the trust topology on which later checks depend. A deployment that has not yet made its Tier 4 intake paths, Tier 2 validation boundaries, and Tier 1 construction points explicit cannot expect supplementary annotations to produce stable, intelligible enforcement results. This is why the framework permits core-first adoption (§7, §15): the topology must exist before richer local contracts can be interpreted consistently.

Failure scope. The wardline prescribes that code at a given tier must fail in certain ways (e.g., halt on integrity violation at Tier 1, reject on shape failure at Tier 4), but not how the failure manifests. The scope of the failure response — process crash, request rejection, circuit-breaker activation — is path-specific and determined by the application's architecture, not by the wardline.

For a worked implementation of this lifecycle — tracing data from Tier 4 through to Tier 1 with concrete annotations and SARIF output — see Part II-A §A.8 (Python) and Part II-B §B.8 (Java).

Coding posture model. The conventional contrast in defensive programming literature is binary: fail-soft (graceful degradation) versus fail-fast (halt-on-anomaly). AI coding agents uniformly apply the former even where the latter is required. This framework extends the binary contrast to four postures — strict (offensive), governance-assured (confident), structure-verified (guarded), untrusted-input (sceptical) (see §2.1 for canonical vs display-label conventions) — each tied to a specific tier. The extension is motivated by the need for finer posture granularity: a binary model maps postures only to the endpoints (strict at Tier 1, untrusted-input at Tier 4). The intermediate postures — governance-assured (Tier 2) and structure-verified (Tier 3) — occupy the space between those endpoints that a two-way contrast does not distinguish.

Bidirectional authority collapse. Uniform defensive patterns produce a compound failure: they simultaneously give unvalidated external data more authority than it has earned (defaults and coercion allow Tier 4 data to cross inward as though validated) while treating authoritative internal data as more negotiable than it is allowed to be (the same patterns handle corruption of Tier 1 records as routine and recoverable rather than exceptional and evidentiary). The collapse is bidirectional because it degrades the authority model from both ends at once — too permissive at the perimeter and too casual at the core. This framework's tier model and pattern rules address both directions: rules WL-001 through WL-004 fire at Tier 1 taint states to prevent the downward collapse (authoritative data treated as negotiable), and the same rules fire at Tier 4 / UNKNOWN / MIXED states (effective states defined in §6.1) to prevent the upward collapse (unvalidated data given unearned authority). The severity matrix (§8) encodes these asymmetric enforcement consequences.

The knowledge requirement at each promotion. Each tier transition requires knowledge proportional to its scope. Shape validation (T4→T3) requires knowledge of the data's structure — its declared structural guarantee. Semantic validation (T3→T2) requires knowledge of the data's usage across the declared validation scope — every intended use of the data and the constraints each imposes. Trusted construction (T2→T1) requires knowledge of the data's institutional meaning — what authority the artefact carries and under what rules it may be produced. Each step is a wider knowledge claim than the last, and each is a correspondingly bigger deal to get wrong.

Verification gradient. The three transitions differ not only in knowledge scope but in verification strength, and the verification at each tier operates in layers of differing character.

T3 verifies both ceremony and substance: schema conformance is decidable, and the enforcement tool can confirm that the structural guarantee is satisfied — the check and the thing being checked are both machine-accessible. T2 verifies ceremony but governance-reviews substance: the enforcement tool machine-verifies the routing — these four checks are exhaustive for T2 ceremony: (1) a checkpoint exists in the declared data flow, (2) taint flow passes through it, (3) a rejection path is present (WL-007), and (4) declared contracts are coherent (§10.2) — but the adequacy of the business logic inside the checkpoint is a governance-reviewed claim, not a machine-verified one (§13, residual risk 10). The machine guarantees the governance gate was hit; governance guarantees the gate is adequate. T1 verifies neither: trusted construction is an act of institutional interpretation that no tool can verify — both ceremony and substance are institutional.

Each step up the tier model widens the knowledge claim and weakens the verification guarantee. Readers should understand that Tier 2's governance-assured (confident) programming posture is backed by a softer guarantee than Tier 3's structure-verified (guarded) programming posture — the confidence rests on governance quality, not machine proof. The T2 guarantee is not purely governance, however: the machine-enforced routing layer is substantial, and language bindings with stronger type systems may partially mechanise T2's governance surface through type-level constraint encoding, narrowing the residual governance claim.

Bindings MAY define declarative constraint manifests for semantic validation boundaries. Where a binding can machine-verify that a validation function tests every constraint declared in its manifest, the residual governance surface at T2 is reduced to manifest adequacy review. The framework does not require this capability — T2's epistemic basis remains governance-assured at the framework level — but bindings that implement it provide a tighter verification envelope. Manifest completeness remains a governance responsibility; the gap narrows but does not close. The presence or absence of constraint manifests does not affect a binding's conformance status (§15). It narrows the residual governance surface but does not change which conformance profile applies.

Semantic validation is always comprehensive within its scope: it establishes that the data satisfies every domain constraint for every intended use within the declared validation scope, not merely those of one particular code path. Data that has been validated for some uses but not all remains at Tier 3 until a validator with knowledge of all intended consumers has cleared it. For many fields, the constraints are universal — a base_url must always be a valid, safe URL; an amount must always be non-negative. The hard cases are rare but important: they are the fields where different consumers impose different constraints, and the semantic validator must satisfy all of them.

The model deliberately permits combined validation boundaries (T4→T2 in one function) because ceremony affects adoption rate. Where structural and semantic checks are simple enough to co-locate without obscuring the distinction between them, combined validation reduces annotation friction while preserving the logical ordering constraint that shape validation precedes semantic validation (§6.2).

Data whose tier classification cannot be determined — typically data crossing the enforcement perimeter from outside, or return values from unannotated code — is assigned the UNKNOWN trust classification. Data combining values from multiple tiers is assigned MIXED. These classifications, along with the four named tiers, produce the eight effective states that the severity matrix (§8.3) uses to grade findings. The effective states and their enforcement consequences are defined in §6.

The enforcement implementation of this model — effective states, taint-state algebra, transition semantics, restoration boundaries, and cross-language taint propagation — is specified in §6.