8. Quality Gates

Automated enforcement points. Implemented as code, not checklists. See SENAR Guide for AI Output Review Checklist.

8.1 QG-0: Context Gate (Task start)

Quality is built at input. QG-0 ensures that a Task has sufficient, well-structured context before work on it begins.

Prevented effect (8.6(a)): modification of engineering artifacts within the Task’s scope, however that modification is produced.

NOTE: The effect is stated without qualifying what produces the modification. A gate defined against AI-directed work alone would leave the same artifact, changed the same way, outside its own declaration whenever the change arrived by another route — and 8.6(a) requires that, for any proposed action, it can be determined whether the gate prevents it. Scope is bounded by the Task: modifications outside the Task’s scope are not this gate’s subject.

Point of admission (8.6(a)): the opening of the Task to modification — the transition at which work within the Task’s scope may begin. The effect is admitted once for the Task. A modification made under that verdict, within the scope the verdict was issued for and by the route the verdict admits, falls within the admission already recorded: it is not a further admission, and calls for no further verdict, record or digest comparison. The route the verdict admits is AI-directed production (4.1); content that reached the artifact by another route is governed by 8.6(j) and is a Gate Bypass however wide the recorded scope was. Where the Task’s scope is changed after the verdict, the verdict stands for a state that no longer holds, and 8.6(c) requires a new verdict before work continues under the changed scope.

QG-0’s verdict is about the Task record it examined — goal, acceptance criteria, requirement link, work type and recorded scope (3.5.1) — and about the content of no engineering artifact. The digest required by 8.6(d) is measured over that record. QG-0 admits the modification of artifacts; it does not examine them.

SHALL criteria: goal defined, acceptance criteria verifiable, requirement or story linked (SHALL), work type assigned, Task Scope recorded (3.5.1) — the artifacts the Task is permitted to modify, recorded before work begins.

SHALL criteria (Team+): acceptance criteria are independently verifiable (each can be tested or measured separately); at least one negative scenario (error case, invalid input, or boundary condition) is included in acceptance criteria.

SHALL criteria (all configurations, security-relevant tasks): security surface declared — tasks touching auth, user input, data storage, payment, or external APIs SHALL identify the threat surface and include at least one security-related acceptance criterion. See SENAR Core (Start Gate, criterion 5) and Section 8.7.

SHOULD: plan, complexity estimate, relevant knowledge identified.

NOTE: Task Scope is a SHALL criterion at every configuration, listed above, and Core requires it as well (Start Gate item 4). Foundation additionally inherits Core’s negative scenario requirement (Start Gate item 3) even though it is listed as a “Team+” SHALL criterion above. At Foundation, QG-0 = Core Start Gate checks + Standard QG-0 structure. The “Team+” criteria (independently verifiable AC, negative scenario) are already practiced at Core level; Foundation formalizes them as gate criteria.

8.2 QG-1: Requirements Gate (Story/Increment level — Team+ configs)

Ensures requirements are defined, approved, decomposed, and of sufficient quality before implementation begins.

Prevented effect (8.6(a)): creation of implementation Tasks from requirements that are not approved, not decomposed to sufficient depth, or not verifiable.

SHALL criteria [Team+]: Business Requirement (BR) exists and is approved; decomposition to Task Requirements (TR) is complete at appropriate depth; all TRs have verifiable acceptance criteria; no orphaned requirements (requirements without implementation Tasks).

Further SHALL criteria, at Team and above, which is where 11.1 places this gate: requirements satisfy the quality properties stated below; non-functional requirements specified where applicable (performance, security, accessibility).

Decomposition Depth

The Context Architect SHALL determine decomposition depth [Team+] based on complexity and regulatory context:

NOTE: For simple features (BR → TR, 2 levels), see SENAR Core.

Requirement Quality Properties

Requirements submitted to QG-1 SHALL be verifiable (each can be tested, measured, or demonstrated) and SHALL satisfy:

a) Consistency — no contradictions with existing requirements at the same or higher level; b) Sufficiency — the set of TRs covers the parent requirement (SR or BR) completely; c) Non-redundancy — no duplicate requirements across Stories; d) Traceability — every TR traces up to a BR; every BR decomposes to at least one TR.

NOTE: These are criteria of QG-1, and 11.1 places QG-1 at Team and above. Below Team there is no level of them to state, and until 1.5 this subsection stated one — SHOULD, scaling to SHALL at Team+ — for configurations that do not operate this gate at all. Removing that level changes no obligation: at Team and Enterprise the notation already made them SHALL, and below Team the gate is absent. Verifiability is the exception, and it is owed everywhere — but not through this subsection. Verifiable acceptance criteria are required by 8.1 at QG-0 at every configuration, and SENAR Core requires the same at its Start Gate.

Requirement Change Management

NOTE: Requirement Change Management applies at Team+ configuration.

When an approved BR or SR changes after implementation has begun:

a) The change SHALL be documented with rationale and the identity of the person who authorized it; b) Impact analysis SHALL identify all downstream requirements and Tasks affected by the change; c) Affected Tasks that are already done SHALL be flagged for re-verification — their QG-2 approval is invalidated; d) The changed requirement SHALL pass QG-1 again before new implementation begins; e) Supervisors of affected Tasks SHALL be notified of the change.

Scaling: at Team, impact analysis SHALL be supported by tooling (requirement parent/child links). At Enterprise, requirement changes SHALL be version-controlled and subject to change review (see Section 11.3, Requirements-as-Code).

8.3 QG-2: Implementation Gate (Task done)

Prevented effect (8.6(a)): closure of the Task and propagation of its result — the point at which the result becomes available to other work as a completed one.

SHALL criteria: CI passes, tests pass, static analysis passes (including type checking where applicable), no new lint violations, acceptance criteria verified by Supervisor, no security vulnerabilities detected by scanning tools, and for any defect found and fixed within the Task the root cause is identified and recorded — the same term SENAR Core uses in its Rule 7 and Done Gate criterion 4.

Where a configuration does not operate QG-3, the AI Output Review Minimum Criteria of 8.4 are performed at this gate whenever 8.7 requires them — at Foundation that is every security-sensitive change, and 8.4 states it from the other side.

SHOULD: coverage meets threshold, no duplication, docs updated, knowledge entry if decision/dead end. Team+: generated tests reviewed against Test Model (TM) — AI-generated tests SHALL exercise the stated acceptance criteria, not just achieve coverage.

NOTE: Foundation inherits from SENAR Core Rule 4 the substance of the Team+ criterion above — that tests verify the requirement and not the implementation — even though review against a Test Model is listed as Team+. The Test Model is a Team+ artifact and its formality scales by configuration (3.22); what does not scale is that a test mirroring the implementation verifies nothing. This is the same reading 8.1 states for the negative scenario criterion, and it is stated for the same reason: a Foundation organization carries the Core rules (11.1), and a criterion here that appears to begin at Team would otherwise read as an obligation removed on the way up.

Evidence and the state it is about

The verdict SHALL be a statement about the Task’s artifacts as they stand at the moment the Task transitions to done (8.6(c)), and SHALL rest on a digest measured over those artifacts (8.6(d)). A verdict earned on one state is not a verdict on a later one: where the artifacts change after the checks ran, either the checks are re-earned against the changed state or the verdict is negative.

What the evidence proves, and what it does not

Bound evidence proves two things, and organizations SHALL NOT present a passing QG-2 as proof of more:

a) that the named set of checks ran against this state; b) that the verdict was not carried over from a different state.

It does not prove the good faith of a party authorized to record approval. A participant holding that authority who intends to mislead can select checks that pass, or record approval of work they did not examine, and the binding will be intact throughout — the evidence will correspond to the state exactly as required, and will still be worthless. The binding is a control against evidence drifting from what it describes: substitution, staleness, replay. It is not an attestation against a purposeful insider.

Where assurance against a purposeful participant is required, it comes from review by a party that does not hold the generating role (Section 10.15, L3) and from separation of authority between profiles (Section 5.2) — not from the binding, and not from adding further checks to this gate.

SHOULD (Team+: SHALL): AI-modified dependency manifests (the project’s declared dependency files — e.g., package.json, requirements.txt, go.mod, Cargo.toml) reviewed for hallucinated packages — packages that do not exist in the official registry or that resolve to unexpected maintainers, typosquatted packages (near-name-matches of legitimate packages), and dependency confusion (internal vs. public namespace collisions).

8.4 QG-3: Verification Gate (Merge — Team+ configs)

Prevented effect (8.6(a)): integration of the change into the shared line of development.

SHALL criteria: acceptance tests pass, security scan clean, no regressions, code reviewed (risk-based — see 8.7).

SHOULD: performance within SLA, accessibility compliance, cross-service integration verified.

AI Output Review Minimum Criteria

At QG-3, the following AI-specific checks SHALL be performed:

a) Generated code does not call non-existent APIs, methods, or CLI flags (hallucination check); b) All imported packages exist in the project’s dependency manifest (dependency validation); c) Generated code follows project architectural patterns and conventions (pattern conformance); d) Generated tests exercise the stated acceptance criteria, not just achieve coverage (test validity); e) No hardcoded credentials, API keys, or secrets in generated code (secrets check).

These criteria replace dependency on the informative AI Output Review Checklist in the SENAR Guide with normative minimum requirements. Where 8.7 requires them for a security-sensitive change at a configuration that does not operate QG-3, they are performed and recorded at the gate that configuration does operate — at Foundation, QG-2 (8.3). The criteria are owed there; the gate is not, and 11.1 is not altered by this.

8.5 QG-4: Acceptance Gate (Release — Team+ configs)

Prevented effect (8.6(a)): release — delivery of the increment to its users.

The qualifier states what Section 11 settles: Section 11.1 gives Foundation two gates, QG-0 and QG-2, and Section 11.2 gives Team and Enterprise all five. It is stated here for the same reason it is stated in 8.4 — a reader of this subsection would otherwise take the criteria below as owed at every configuration.

SHALL criteria: stakeholder acceptance recorded — obtained at a Delivery Review (7.6) or recorded outside one, since 7.6 is SHOULD and the acceptance is not; QG-3 still passing; staging environment (production-equivalent deployment target) verified.

8.6 Gate Properties

Sections 8.1–8.5 state what each gate checks. This section states what a check SHALL be in order to be a Quality Gate.

Criteria alone do not determine where a check acts, what its verdict is a statement about, or what happens when no verdict can be reached. Two implementations can satisfy every criterion in 8.1–8.5 and still prevent different things — or prevent nothing. The criteria say what a particular gate examines; the properties below say what any gate has to be.

A check that satisfies the criteria of a gate in 8.1–8.5 but lacks a property required at the applicable configuration (see Scaling by configuration, below) is not a Quality Gate for the purposes of this standard and SHALL NOT be recorded as one.

Every Quality Gate SHALL have the following properties. Each is named and stated in the sentence that opens it, so the five names with their opening sentences lift out as a checklist of what to look for; the paragraphs that follow bound each property, and several of them carry further requirements of their own — a gate is assessed against the whole item, not against its first sentence alone.

a) Declared prevented effect. The gate SHALL declare the effect it prevents: the specific change to the system, or to the record of work, that does not occur while the gate’s verdict is negative. The declaration SHALL be specific enough that, for any proposed action, it can be determined whether that action is one the gate prevents. “Ensures quality” and “checks the work” are not declared effects, because no proposed action can be tested against them.

The declaration fixes the point of admission: the point at which the gate ceases to prevent the declared effect. Where the effect is a single act, the point of admission is that act, and no further statement is needed. Where the effect is a class of acts that recurs within one unit of work, the declaration SHALL also state at what point that class is opened, because otherwise every act in the class is separately an admission. Properties (c), (d) and (g) attach to the point of admission so fixed. QG-0 is the only gate of this Standard whose declared effect is of the second kind; 8.1 states its point of admission.

b) Preventive placement. The gate SHALL act before the effect declared under (a) — it SHALL be a preventive control and not a detective one. A check that establishes the same condition after the effect has occurred is a detective control. A detective control does not satisfy this property, and its presence does not reduce the requirement on the preventive one; it MAY be operated in addition, and where the preventive control depends on a component that can fail without signalling, operating a detective control as well is a SHOULD.

NOTE: Preventive and detective carry their established meaning in internal control. A preventive control removes the opportunity for the unwanted effect to occur; a detective control establishes, after the fact, that it has occurred. The distinction is one of position relative to the effect, not one of strictness — a detective control may examine more and still prevent nothing.

c) Correspondence of the verdict to state. The verdict SHALL be a statement about the state the gate examined, as that state stands at the point of admission. Where the gate examines the artifacts the declared effect acts on, that is the state of those artifacts; where it examines inputs that exist before the effect, it is the state of the records examined — 8.1 names them for QG-0. A verdict issued for one state SHALL NOT be applied to a different state.

This is a property of the verdict, not of the way the verdict is obtained. It is satisfied where evidence accompanies the proposed action, and equally where the gate derives the verdict itself from the state being admitted. It is not satisfied where the gate accepts evidence it cannot relate to that state — however the evidence was delivered, and however thorough the check that produced it.

d) Binding to a measured digest. The correspondence required by (c) SHALL rest on a digest measured over the artifacts the verdict is about. A recorded identifier of a state — a revision identifier, a version tag, a build number — is a binding only where the party relying on it has itself measured the digest of the named artifacts and compared it with the recorded value; an identifier required to be recorded but never checked against what it names is not a binding, and a gate that presents it as one does not conform. The requirement is on the measurement, not on the presence of the field.

The digest SHALL cover every artifact on which the declared effect would act, and the record SHALL name the set covered and the function used. A digest measured over a proper subset — one file, a manifest, a version stamp — is a binding to that subset and to nothing else; it is compatible with arbitrary change everywhere the effect also reaches, and a gate that presents it as binding the verdict does not conform.

This applies where the verdict is about the state of the artifacts the effect acts on. Where a gate’s verdict is instead about inputs that exist before the effect, and about the content of no artifact the effect will reach, the artifacts the verdict is about are the records the gate examined, and the digest is measured over those. QG-0 is that case, and 8.1 names the record.

The measurement SHALL be of the state the checks were performed on, and the comparison SHALL be made at the point the effect is admitted. A digest computed at admission and compared against a value recorded in the same act establishes that the state equals itself. It is not a binding: nothing about the verdict is fixed by it, and the staleness that (c) exists to exclude passes through such a comparison untouched.

e) Fail-closed. Where the gate cannot reach a verdict — the check does not run, does not complete, or completes without a determinate result — the verdict SHALL be negative and the declared effect SHALL be prevented. Absence of a negative finding SHALL NOT be treated as a positive verdict. This applies to unavailability of the gate itself and to unavailability of anything the gate depends on.

A check whose failure is suppressed, so that a run which produced no result is reported as a determinate one, does not satisfy this property. The requirement is not on the shape of the report but on the fact: where a check a gate relies on did not produce a result, the verdict that follows SHALL be negative, whether or not the pipeline was arranged to always emit a positive one. A gate SHALL identify the checks it depends on; a check named in the gate’s criteria (8.1–8.5) is one it depends on, and a dependency cannot be removed by declaring it advisory while continuing to present its criterion as met.

NOTE: Where a gate is detective — (b) is SHOULD at Foundation and may legitimately be unmet there — this property is not thereby waived, but what it requires is what a detective control can do: the verdict is negative, and no positive verdict is recorded or relied upon. The obligation to prevent falls on gates that are preventively placed; the obligation not to report a verdict the gate did not compute falls on every gate, and is reduced nowhere.

Scaling by configuration

The five properties differ in what they cost to implement, and the obligation level follows that cost and nothing else. Preserving the conformance of any existing implementation is not a basis for setting a level.

NOTE: The normative columns are Foundation, Team and Enterprise — the three configurations this Standard defines (Section 11). The Core column is informative and is retained because the cost argument below is only legible against the smallest scale; 13.3 states how it is to be read, and states it once.

Basis for each level:

• (a), (c), (e) — SHALL at every configuration. These cost policy, not capability. Declaring what a gate prevents, refusing to apply a verdict to a state it was not issued for, and treating an unreached verdict as negative are decisions. They are executable with nothing but the text editor that Core presumes — Section 11.4 lists Tooling as None there — which is why SENAR Core states the same three in its own words, and why an organization that has not made them was not stopped by cost.
• (d) — SHOULD at Core, SHALL from Foundation. Measuring a digest costs one command plus the discipline to record the result alongside the verdict. That is a small capability, but not a free one. Section 11.4 lists Tooling as Recommended from Foundation.
• (b) — SHOULD at Core and Foundation, SHALL from Team. Acting before an effect requires the ability to interpose on it. That is a capability, not a decision. Section 11.4 lists Tooling as Required only from Team.

NOTE: Across the three configurations this Standard defines, only (b) varies: (a), (c), (d) and (e) are SHALL at Foundation, Team and Enterprise alike. An organization conforming at any configuration therefore owes four of the five properties in full from the first day, and the single question the scale poses is whether it can interpose on an effect.

Where a property is SHOULD at the applicable configuration and is not implemented, 13.1(c) applies and the organization SHALL document it with rationale. Where (b) specifically is not implemented, the gate is detective with respect to the effect it declares and SHOULD be recorded as such, so that a later claim at Team or Enterprise begins from a known position rather than an assumed one.

Enforcement

f) Gates SHALL be automated wherever feasible. Criteria requiring human judgment require explicit recorded approval. g) Every gate execution SHALL produce an audit record, including an execution that reached no verdict. The record SHALL contain: the gate; the unit of work it concerns; the verdict, including its absence; the time it was issued; the state it was issued for, by the digest measured under (d), together with the set that digest covers and the function used; and the checks the gate depended on, with the result of each.

The admission of the declared effect SHALL likewise produce a record, naming the verdict relied on and the time. One such record is produced per admission as the gate fixes it under (a) — for QG-0, one per Task (8.1), not one per modification. Without it (b) and (c) cannot be assessed by anyone but the party asserting them: a verdict and an effect that are never recorded in relation to each other establish neither order nor correspondence, and 13.7 asks for exactly that relation.

Records SHALL be retained for a period the organization documents, which SHALL be no shorter than the interval between its conformance reassessments (13.6). Where the organization does not conduct the ceremony 13.6 ties that reassessment to — Foundation omits the Increment Retrospective (11.1) — the interval read here is the interval between its Quality Sweeps (7.4), a ceremony every configuration of this Standard conducts; 13.6 names the same fallback. An assessment can rest on evidence only for as long as the evidence exists. h) The effect declared under (a) SHALL NOT be admitted without a positive verdict, except through a documented Gate Bypass (justification + risk + remediation + senior approval). Admission of the declared effect without a positive verdict and without a recorded Gate Bypass is a bypass, whether or not it was intended as one. i) Organizations SHOULD track Gate Bypass rate.

j) Modification of an artifact within a Task’s scope by a route the gate does not precede — including direct modification by a Supervisor — is admission of the effect declared by QG-0 (8.1) without a positive verdict, and is therefore a Gate Bypass under (h). It SHALL be recorded as one. This obligation rests on (a) and (h) and applies at every configuration of this Standard, Foundation included, where (b) is only SHOULD: a gate that is not preventively placed still declares an effect, and admitting that effect without a verdict is still an admission.

The route is the origin of the content, not the identity of the process that writes the file. Content composed by a person and transcribed by an agent — dictated, pasted into a prompt for verbatim writing, or otherwise supplied for reproduction — arrived by a route the gate does not precede, and (j) applies to it. A gate placed before an agent’s work does not examine text the agent was told to reproduce.

Route is not placement. A gate that is detective with respect to its effect — (b) is only SHOULD at Foundation, and such a gate is legitimate there — still governs the routes by which work reaches its artifacts, and its being detective does not turn every modification into an admission without a verdict. Where QG-0 issued a positive verdict for the Task, and the modification arose from AI-directed work carried out under that Task within the scope that verdict was issued for, the modification falls within the admission that verdict opened. A wide recorded scope widens what the verdict admits by route, not what it admits by origin: content a person composed is not brought inside the admission by the size of the scope. What this clause captures is content that reached an artifact by a route no verdict covered — not work whose gate happens to sit after the effect rather than before it.

Where an Exploration (3.6) yields artifacts that are kept, the Task created under 10.1 does not retroactively bring their production within its gate: the modification occurred before the Task existed, and QG-0 issued no verdict on it. Such artifacts SHALL be recorded under this clause when the Task is created, or reproduced under a Task whose QG-0 preceded them. An Exploration is exempt from needing a Task; it is not a route by which finished work enters the system unexamined.

NOTE: This is a requirement to record, not a prohibition. Modifying an artifact directly stays available, and 4.1 states which case is recognized as substantive at the date of this revision — an environment in which no agent can be run and there is nothing to switch to. That subsection is where the set is settled, and it is dated there. A prohibition that cannot be honored in those cases would produce silent violations in place of records, which is the opposite of what a gate is for. The record is what converts an unremarked practice into a measurable one.

8.7 Risk-Based Review

Security review for high-risk changes: For changes affecting authentication, payment processing, personal data handling, or cryptographic operations, security review SHALL be performed at ALL configuration levels, not only Enterprise. This is a mandatory (SHALL) requirement regardless of team size. Organizations developing security-sensitive systems SHALL apply the AI Output Review Minimum Criteria of 8.4 and the risk-based review of 10.15 to such changes at every configuration, performed at the gate that configuration operates.

NOTE — SETTLED IN THIS REVISION. Until 1.5 this subsection required QG-3 at every configuration for security-sensitive systems, while Section 3, 8.4, 8.9, 8.10 and 11.1 marked QG-3 as Team+. The two statements are reconciled by separating the criteria from the gate. A gate is a control with a declared prevented effect and a point of admission (8.6); its criteria are what it checks there. QG-3 the gate — whose prevented effect is integration into the shared line of development — remains Team+, and the number of gates a Foundation organization operates is unchanged at two (11.1). What is owed at every configuration is the substance: the five criteria of 8.4 and the review of 10.15, performed at the gate that configuration does operate, which at Foundation is QG-2. This follows the form 10.15 already uses, where L3 review is owed for High-risk changes regardless of configuration level without any gate being added to any configuration. The stricter reading the previous revision recommended is therefore now the requirement, and the gate count it would have changed is not changed.

8.8 Gate Pipeline

Exploration ──► (yields work?) ──► Task
Task ──► [QG-0] ──► active ──► [QG-2] ──► done
                                  │
                         (Team+) [QG-3] ──► merged
                                  │
                                [QG-4] ──► released

Story/Increment: (Team+) [QG-1] ──► approved ──► Tasks created

NOTE: This diagram is informative. It shows the order in which gates are reached, not where a gate is required to act. The normative requirement on placement is 8.6(b), read together with the prevented effect each gate declares in 8.1–8.5.

8.9 Summary

NOTE: SENAR Core defines two quality gates and names them the Start Gate and the Done Gate; this Standard calls the same two QG-0 (Context Gate) and QG-2 (Implementation Gate), and the Core document states the same mapping at each of them. Where this Standard cites Core — as 8.1 does — it uses Core’s names, because that is what they are called there. Foundation configuration inherits both gates from Core (Section 11.1).

NOTE: This table says which gates apply. What each of them is required to be — the five properties and the obligation level of each by configuration — is stated once, in 8.6, and is not repeated here. A scale printed twice is a scale that can disagree with itself, and this one had begun to. The Core column of this table is read as 13.3 states, which is where that is stated and the only place it is.

8.10 Security Requirements Cross-Reference

One consolidated view of all security-related requirements across the Standard. Use this table when auditing security coverage or onboarding a new configuration.

NOTE: “All configs” means the requirement applies regardless of team size — including Foundation teams. See 8.7 for the normative statement on security review applicability.