What to Expect
Factual alignment between the product behavior and user expectations.
01. What Happens When You Run SATE
When you run SATE against your codebase, the system performs a deterministic analysis of your test suite and application behavior. The output of this process is not fixed; it depends entirely on the technical clarity of your application's behavioral surface.
- /
SATE may generate executable tests.
- /
SATE may produce versioned audit artifacts.
- /
SATE may refuse to generate tests for specific behaviors.
Refusal is an expected and valid outcome.
02. You Will See Refusals
SATE will refuse to generate or execute tests when behavior cannot be proven without guessing. This refusal is intentional and programmatic.
A refusal does not mean the system is broken, nor does it necessarily mean your application behavior is incorrect. It indicates that the evidentiary chain required for absolute verification is incomplete or ambiguous.
“SATE prefers refusal over speculation.”
03. You Will Receive Artifacts, Not Just Tests
When behavior cannot be safely verified with executable code, SATE produces audit artifacts. These are versioned records that document what was discovered and the specific technical reasons why execution was refused.
Artifacts are a standard part of the SATE output cycle. They provide the provenance required for manual review and architectural decision-making.
Artifacts are not errors. They are evidence.
04. You May Encounter Contradictions
SATE may identify situations where different tests within your suite assert different, incompatible outcomes for the same behavioral surface.
These contradictions are often the result of tests written by different contributors at different times. Both tests may pass in isolation within a standard runner, yet they represent a split in authoritative truth.
When this happens, SATE will not choose which test is correct.
These findings do not automatically fail CI unless explicitly enforced by your team.
05. Human Decisions Are Required
SATE is an evidence system, not a decision-making engine. It does not decide which business behavior is "correct" and it will not automatically resolve contradictory proofs.
The role of the system is to surface behavioral evidence so that humans can decide the final intent of the application.
“SATE provides evidence, not decisions.”
06. Results May Change as Code Changes
Even small changes in your application source code can significantly affect SATE’s findings. A minor adjustment to a return type or a state transition may change a surface's classification, trigger a new refusal, or invalidate an existing artifact.
This variability is an intended byproduct of technical precision. It reflects the engine's sensitivity to behavioral shifts, not system instability.
07. What SATE Does Not Guarantee
SATE does not guarantee:
- ✖
Software correctness.
- ✖
Absence of bugs.
- ✖
Complete test coverage.
- ✖
That all behaviors can or should be tested.
- ✖
That generated tests represent business intent.
08. Generated Tests Are Proposals, Not Authority
When SATE generates executable tests, those tests are produced as candidates. Generation does not imply correctness, business intent, or final authority.
All generated candidates are immediately subjected to the same audit rules as human-written tests. They may be accepted, rejected, deferred, or materialized as audit artifacts.
SATE will refuse to introduce generated tests that contradict existing behavioral truth, even if those tests would pass in isolation.
Generation is proposal, not decision.
09. Serialization and Structural Boundaries
SATE evaluates behavioral truth at a defined serialization boundary.
Only scalar outcomes (booleans, numbers, strings, null) are serialized and asserted as authoritative truth. Complex structures such as arrays, objects, models, and response bodies are intentionally excluded.
When behavior depends on non-scalar structures, SATE will refuse execution and produce an audit artifact instead of guessing.
These boundaries are intentional and exist to preserve determinism, comparability, and audit integrity.
10. Concurrency and Runtime Behavior
SATE does not simulate concurrency, race conditions, timing behavior, or runtime scheduling.
The system audits logical and behavioral consistency, not runtime interleavings or thread safety.
Absence of concurrency analysis is an intentional boundary required to maintain deterministic and reproducible audits.
Final responsibility for correctness, behavior, and acceptance remains with humans.