Overview
Science isn’t a subject the system studies. It’s the loop the system runs to get anything done: form a hypothesis about what will work, make it falsifiable, test it, and only then believe the result. “Should work” is not evidence. A tool call that succeeded is.
This shows up most directly in the ISA, where every claim about a project’s state has to carry a falsifier—a concrete way it could be shown false. A claim with no falsifier isn’t a claim, it’s an opinion wearing a claim’s clothes. Applying that discipline to ordinary work—did the deploy work, did the fix work, did the feature work—turns “I think this is done” into “here’s the evidence this is done.”
The scientific method scales down as easily as it scales up. It’s the same loop whether you’re testing a hypothesis about dark matter or testing whether a hook actually fires.
Why This Matters
Without the scientific loop:
- Claims of “done” rest on the model’s confidence, not on verification
- Errors compound silently because nothing was falsifiable in the first place
- Iteration happens on vibes: try something, feel like it worked, move on
- The gap between “should work” and “verified” never closes
With the scientific loop:
- Every claim of done points at the evidence that makes it true
- Failures get caught before they’re reported as successes
- Iteration has a target: the next test that could prove the hypothesis wrong
- Confidence is earned by test results, not asserted by the model
Implementation
In LifeOS, this manifests through:
The ISA’s testable claims and falsifiers - Every ideal-state claim states not just what should be true, but exactly what evidence would prove it false. Closing a claim means running that test, not asserting the claim.
The Algorithm loop - Observe, hypothesize, act, verify. Hill-climbing toward the ideal state is a repeated scientific loop, not a single leap of faith.
Verification gates - Deterministic checks (hooks, integrity scans, deploy gates) stand in for “trust me,” the same way a published result stands in for “trust me, it works.”
The Upgrades queue - Proposed system improvements sit as hypotheses until evidence justifies promoting them, rather than being adopted on the strength of how good the idea sounds.
Examples
Example 1: Claim vs. hypothesis
- Claim with no falsifier: “The deploy is working”
- Falsifiable claim: “The deploy is working if
curlreturns 200 on the production URL and the Interceptor screenshot shows the new copy”
Example 2: Debugging
- Vibes: “That’s probably the bug, let me just fix it”
- Scientific: “If this is the bug, disabling it should stop the failure—test that before touching the fix”
Example 3: Shipping a feature
- Should-work: “I wrote the code, it should work”
- Verified: “I ran the test suite, it passed, and I confirmed the behavior manually against the ISA’s stated criteria”
Related Principles
- Principle #5: Spec / Test / Evals First - Specs are hypotheses; tests are the falsification step
- Principle #3: Deterministic Where Possible - Deterministic gates are how evidence gets collected without relying on the model’s self-report
- Principle #17: Permission to Fail - A hypothesis that fails a test isn’t a wasted cycle, it’s the loop working
