The Auditor Engine
The Auditor is a static verification engine that acts as a gatekeeper for behavioral evidence. It does not evaluate if your code works; it evaluates whether your tests prove anything.
IDENTITY: Gatekeeper, not a fixer. A test may pass PHPUnit/Pest and still fail the audit.
“The Auditor does not decide whether your code is correct. It decides whether your tests prove anything.”
01 — Canonical Definitions
Act
The specific operation under test. The catalyst expected to trigger a system transformation (e.g., $service->run() or a route request).
Observable Effect
A state change existing outside local scope that can be verified independently (DB records, events, files, or responses).
Assertion
A claim made by the test about an observable effect. Must be anchored to the preceding Act.
Audit Observation Signal
The following trace represents a real-time summary of the Auditor's findings. It categorizes the physical evidence extracted from the test suite, identifying unanchored signals and structural violations before they contaminate the knowledge base.
02 — Taxonomy of Rejection
Unanchored Assertion
An assertion validates a value whose origin cannot be proven to originate from the Act, or validates only local return values.
Audit Logic:
If the result is only stored in memory and not mapped to an observable system effect, causality is broken.
Fake Anchor
The assertion's truth can be manufactured without executing the Act, or it targets mock returns instead of application state.
Audit Logic:
Fabricated truth is rejected. This includes self-comparisons, property existence checks, or serializing local objects.
No Observable Effect
The test executes code paths but fails to observe a single real effect outside the local function scope.
Audit Logic:
Execution is not evidence. A test must prove a state change occurred in the database, HTTP layer, or event dispatcher.
Causality Breakdown
Evidence exists, but it cannot be proven that the effect originated from the specific Act in this test.
Audit Logic:
If an alternative source could have produced the effect, or if the effect existed pre-Act, the proof is rejected.
03 — Scope Boundaries
The Auditor MUST NOT:
- ✖ execute application code
- ✖ fix or rewrite tests
- ✖ infer developer intent
- ✖ accept "reasonable" assumptions
Audit capabilities:
- • Hidden database assumptions that reduce test portability
04 — Output Contract
Possible Engine Responses:
The Engine does not provide remediation steps or suggest improvements. It reflects technical truth through absolute rejection.