The SATE-Laravel Mental Model
Rewiring intuition for technical verification.
01. The Problem With “Passing Tests”
In traditional development, a passing test is accepted as a proxy for safety. If the runner returns a green status, the assumption is that the code is correct and the feature is protected.
This assumption is flawed.
Tests frequently pass without proving anything. They execute code paths, move data through memory, and exit without error—yet they never verify that the system reached the intended state. A green build indicates that nothing crashed; it does not indicate that anything was verified.
“A passing test is not evidence. Evidence must be observed.”
02. Act → Observe → Prove
Technical verification requires a complete causal chain. SATE-Laravel audits tests by tracing this progression:
The Act
The intentional operation introduced to the system. This is the catalyst that must trigger a specific behavioral transformation.
The Observation
The measurement of system state after the Act. This must target a permanent or semi-permanent effect that survives the execution context.
The Proof
The logical conclusion that the Observation was caused by the Act. This is the only signal that constitutes behavioral truth.
Observation without an Act is meaningless; it measures state that may have already existed. An Act without observation is invisible; it produces a change that is never verified.
03. What Counts as Evidence
Valid evidence must be external to the local function scope. SATE-Laravel recognizes evidence in these categories:
- /
Persistence: Verified changes to the database or filesystem that reflect the Act's completion.
- /
External Side Effects: Provable interactions with outbound services or the physical world.
- /
Signals: Emitted events or notifications that represent the system’s intent to broadcast its state change.
- /
User-Visible Interface: Final HTTP responses or data objects explicitly returned to the caller as a result of the Act.
Database Portability Awareness
SATE analyzes tests to highlight reliance on database-specific behavior (for example, engine-specific SQL features or transaction semantics).
This helps teams understand which tests are portable across database engines and which assume specific database behavior.
SATE does not execute tests or infer runtime outcomes. It surfaces hidden assumptions so teams can make informed decisions about test scope and infrastructure.
04. What Does NOT Count as Evidence
Code execution artifacts are not behavioral proofs. SATE-Laravel explicitly rejects the following as evidence:
- ✖
Type checks and "instance of" assertions.
- ✖
Assertions that a value is not null.
- ✖
In-memory data transformations that are not persisted or communicated.
- ✖
Inspection of temporary internal variables or local function state.
If an assertion only confirms that data was moved around in memory without crashing, it has provided no proof of behavioral integrity.
05. Why Coverage Is Not Proof
Code coverage measures execution. It reports which lines were touched by the CPU during a test run. It is fundamentally incapable of determining whether those lines achieved their intended outcome.
Executed code is not verified code. A test suite can achieve 100% coverage while containing zero unanchored behavioral proof. Coverage creates an illusion of safety that masks the absence of truth.
“Coverage answers what ran. SATE-Laravel answers what was proven.”
06. Why SATE-Laravel Rejects “Working” Tests
Expect SATE-Laravel to reject tests that have passed in your CI pipeline for years.
Rejection is not an accusation of broken code; it is a technical observation of missing proof. A test is "working" if it doesn't fail, but it is "verified" only if it provides evidence. SATE-Laravel uses refusal as its primary educational tool—forcing you to strengthen the causal chain where it is weakest.
Learning happens through refusal. By rejecting unanchored signals, the system keeps your knowledge base as a repository of truth rather than a collection of coincidences.
07. How to Read a Failure
When the Auditor reports a failure, do not immediately attempt to fix the application logic.
A SATE-Laravel failure is usually a signal of an evidentiary gap. It means the link between your Act and your Observation cannot be proven.
1. Trace the Act. Confirm the system catalyst is intentional and clearly defined.
2. Trace the Observation. Identify the permanent state change that the Act must produce.
3. Verify the Link. Ensure your assertion targets the change itself, not a local proxy or variable.
Verification requires slowing down to trace causality. A failure is the Auditor teaching you where your suite is vulnerable to false safety.