Process Integrity exit conditions
Candidate exit conditions for the Process Integrity type. See the catalog overview for how to adopt these.
|
Only three of the ids on this page ship in the default library: |
Source grounding and anti-hallucination
"No invented APIs" is not a standalone auditor; it is enforced by delegation. A declarative type-check auditor on each ecosystem surface (tsc --noEmit, mvn compile, and so on) fails on a symbol that does not exist, so the invariant is folded into PROC-AUDITOR-COVERAGE (a covering auditor exists for the surface) and PROC-ADEQUACY-REVIEWED (the auditor is reviewed to catch it). What remains as a distinct source-grounding condition is citing API usage to official documentation.
| Exit condition | What it checks |
|---|---|
|
API usage is cited to official documentation; invented APIs are caught by the delegated type-check auditors under coverage and adequacy. |
|
Each non-trivial framework usage cites the official documentation section it was derived from. |
|
All imports and package references compile against the pinned dependency set with no unresolved symbols. |
|
Configuration keys written by the AI exist in the target framework’s documented configuration schema. |
|
API usage matches the signature and semantics of the exact dependency version in the lockfile, not a different release. |
|
Every documentation URL or reference the AI cites resolves to a live, relevant source. |
|
Factual assertions in generated comments or docs are grounded in a cited source rather than asserted from model priors. |
Provenance and traceability
| Exit condition | What it checks |
|---|---|
|
Each generated artifact records which run, model, and prompt produced it. |
|
Every generated code change maps to a task or spec item that requested it. |
|
Each executed task links back to the specification requirement it fulfills. |
|
Every commit references the spec, plan, or task identifier it implements. |
|
Files or sections authored by the AI are marked as machine-generated in a discoverable way. |
|
No generated artifact exists without a traceable originating task or spec item. |
|
The chain from spec to plan to task to artifact is unbroken for every shipped change. |
Spec adherence and scope control
| Exit condition | What it checks |
|---|---|
|
No feature, endpoint, or behavior is implemented that the specification does not call for. |
|
Every in-scope specification item has a corresponding implementation or an explicit deferral. |
|
No new third-party dependency is added unless the spec or plan authorizes it. |
|
No specified requirement is dropped without an explicit, recorded decision. |
|
No speculative abstraction or configurability is added beyond what the spec requests. |
|
Edits stay within the files or modules the plan scopes, or the deviation is recorded. |
|
Public interfaces are changed only where the spec authorizes it. |
|
Any deviation between delivered scope and specified scope is explicitly declared, not hidden. |
Plan and constitution adherence
| Exit condition | What it checks |
|---|---|
|
Implementation follows the approved plan’s steps and sequencing rather than an ad hoc path. |
|
The build satisfies every applicable constraint stated in the project constitution. |
|
No change violates a prohibition or principle defined in the constitution. |
|
Generated code conforms to the architectural patterns the plan or constitution mandates. |
|
Each change is checked against the constitution before it is accepted. |
|
Any departure from the approved plan is recorded with a rationale. |
|
Generated code matches the project’s mandated style and naming conventions. |
Honest reporting and anti-green-washing
| Exit condition | What it checks |
|---|---|
|
No test result, metric, or check outcome is reported that was not actually produced. |
|
Claimed pass/fail status matches the actual observed state of the build. |
|
No check is made to pass by stubbing, mocking, or hard-coding its expected result. |
|
Failures and errors are reported rather than suppressed or summarized away. |
|
Reported test or requirement coverage is not overstated relative to what is actually exercised. |
|
Items that could not be verified are flagged as unverified rather than reported as passing. |
|
Completion summaries do not claim work as done that is partial, skipped, or deferred. |
|
The build does not silently catch and discard errors to appear successful. |
Auditor coverage and verifiability
Two of these conditions are the locked process-integrity gates: they are always on and cannot be struck. PROC-AUDITOR-COVERAGE requires that every material build surface has a covering auditor (see Coverage gate); PROC-ADEQUACY-REVIEWED requires a fresh adversarial review of every auditor, keyed to the current checks (see Adequacy review).
| Exit condition | What it checks |
|---|---|
|
Every material build surface has a covering auditor, else the gate is red. Locked: always on, cannot be struck. |
|
A fresh adversarial review, keyed to the current checks, covers every auditor and confirms it cannot pass while its invariant is false. Locked: always on, cannot be struck. |
|
No condition is asserted as met without a machine-checkable auditor backing it. |
|
Each auditor executes without error and returns a definite pass or fail verdict. |
|
Evidence supporting each verified condition is retained and retrievable. |
|
Retained evidence actually substantiates the pass/fail verdict recorded for the condition. |
Reproducibility and determinism
| Exit condition | What it checks |
|---|---|
|
Build steps produce the same result when re-run from the same inputs. |
|
All dependencies are pinned to exact versions so the build is reproducible. |
|
Every input required to reproduce the build is committed or otherwise recorded. |
|
Re-running the verification against the same artifacts yields the same verdicts. |
|
The build does not depend on undocumented environment state to succeed. |
|
Any nondeterministic step is seeded or bounded so results are reproducible. |
Human gates and enforcement integrity
| Exit condition | What it checks |
|---|---|
|
Required human sign-off gates are obtained before the gated step proceeds. |
|
Enforcement of exit conditions is not disabled, skipped, or circumvented. |
|
No test is silently skipped, ignored, or marked pending to pass the build. |
|
No lint, type, or security check is disabled to force a passing result. |
|
Destructive operations are not performed without the required explicit approval. |
|
Gated stages run only after their prerequisite gates have passed. |
|
Any warning or check suppression carries a recorded justification. |
Secrets, safety, and model provenance
| Exit condition | What it checks |
|---|---|
|
No credentials or secrets are placed into prompts sent to the model. |
|
No secrets are written into build logs, transcripts, or generated artifacts. |
|
No personal or sensitive data is leaked into prompts beyond what the task authorizes. |
|
The model and version used for the build is recorded for each generation step. |
|
Required agent and prompt guardrails are applied to every generation step. |
|
Generated code does not transmit secrets or sensitive data to unauthorized destinations. |
|
The agent operates within its granted tool and permission scope during the build. |