Frozen acceptance boundary
The objective, constraints, required behavior, evidence, and failure conditions are fixed before the result is judged.
FalseGreen Job
Production Beta
One consequential change. One frozen definition of done. One independent result.
$2,999 USD
Buy one Job for one bounded consequential engineering scope—not one verifier call or CI run. Define what must be true, then work with Codex or Claude Code against a fixed acceptance target.
FalseGreen is currently in Production Beta. Core verification and acceptance are live, while we continue hardening the hosted execution path against real-world operational edge cases. Beta customers may encounter interruptions; FalseGreen fails closed rather than manufacturing a result.
One Job
Requirements / agreed definition of done
↓ freeze
Coding-agent implementation / repair
↓ verify / reverify
Evidence-backed result + report
What one Job covers
One bounded scope. More than one verification attempt.
When the definition of done freezes, FalseGreen automatically binds the Job to that boundary. Implementation, independent verification, authorized repair, and reverification then stay inside the same Job while the target remains unchanged.
Independent verification
FalseGreen verifies the exact implementation outside the coding agent’s own completion claim.
Explicit result
The Job concludes Accepted, Failed, or Insufficient Evidence—not with a vague confidence score.
Durable report
The result, exact software verified, evidence, limitations, and acceptance history remain available after the coding session.
Repair and reverification
When evidence demonstrates a deficiency, the coding agent can repair it and FalseGreen independently reverifies the same frozen boundary. The target does not move.
The Job boundary
One frozen definition of done stays one Job.
FalseGreen automatically scopes the Job to the frozen definition of done. A failed verification attempt does not automatically cost another Job.
Same Job
Repair what the evidence found.
If FalseGreen demonstrates a deficiency that can be repaired within the frozen scope, repair and reverification continue under the same Job.
Same Job
Change the source, not the target.
The implementation may change during repair. FalseGreen binds each verification attempt to the exact source it verified while keeping the same frozen definition of done.
Current Job ends
Reach a terminal result.
FalseGreen ends the Job when it is accepted or when the bounded repair and evidence policy establishes that the current Job cannot continue.
New Job
Change the acceptance scope.
A material change to the frozen requirements is a different scope. It must not be disguised as repair.
Change the implementation → same Job. Change the frozen definition of done → new Job.
The decision
Three honest outcomes.
FalseGreen reports what the evidence establishes. For ACCEPT, the stopping condition is concrete: the evidence supports the frozen definition of done.
A Job can also conclude Failed or Insufficient Evidence. Buying a Job does not guarantee a favorable result.
ACCEPTED
The frozen requirements were established by the evidence.
FAILED
One or more required criteria were demonstrated to fail.
INSUFFICIENT EVIDENCE
The available evidence could not establish the full boundary.
The report
Every Job leaves a durable record.
The coding session can end. The evidence does not. Every FalseGreen Job produces a durable report showing the frozen definition of done, the exact software that was verified, the evidence FalseGreen observed, any limitations, and the authoritative result.
The report ties the Job to its frozen definition of done and preserves the exact source and evidence from each verification attempt. Accepted, Failed, and Insufficient Evidence keep their distinct meanings; Failed and Insufficient Evidence are both Not Accepted outcomes.
Durable Job report
- boundary
- The exact frozen definition of done
- source
- The exact source, commit, or artifact FalseGreen verified
- evidence
- Verification attempts, retained evidence, and observed outcomes
- limitations
- What the evidence did and did not establish
- result
- Accepted, Failed, or Insufficient Evidence
Verification history
A later acceptance does not erase what failed first.
FalseGreen keeps the verification history of the Job. If an earlier attempt demonstrates a failure, the implementation can be repaired and verified again against the same frozen definition of done. A later Accepted result does not rewrite the earlier attempt—the report keeps both.
Repair and reverification continue inside the same Job only while FalseGreen's bounded Job policy authorizes continuation. This is not an unlimited repair promise.
If a Job reaches a final Not Accepted outcome, that Job remains finished. If later work continues against the same unchanged definition of done under another Job, the earlier result remains linked in the acceptance history rather than disappearing.
Change the implementation: same scope. Change the definition of done: new scope.
See this in the SPARK case study →One FalseGreen Job
Frozen definition of done
↓ verify exact source
Verification attempt 1
NOT ACCEPTED
Demonstrated failure retained
↓ repair implementation
Verification attempt 2
NOT ACCEPTED
Remaining failure retained
↓ repair implementation
Verification attempt 3
ACCEPTED
Current source independently verified
Same Job · same frozen DoD · one Job credit
What it is for
Use a Job where a wrong result has consequences.
Billing and payments logic
Authentication and permissions
Data integrity
Infrastructure changes
Consequential refactors
Agent-generated backend changes
Migration verification
Release-critical behavior
These are examples of the same FalseGreen Job. They are not separate products.
Current language support
Verify across the stack that matters.
Support is scoped to the Job and the environment required to establish its acceptance criteria.
Python
Rust / Anchor
Go
Ruby / Rails
Ada / SPARK
Fortran
Scoped Terraform / AWS
What a Job is not
Bounded acceptance, not universal certification.
CI can supply checks and evidence. FalseGreen independently decides whether the agreed Job is done.
- • Not a replacement for tests, CI, or code review
- • Not a codebase-wide security or compliance audit
- • Not a guarantee that every defect will be found
- • Not a model certification
- • Not a guarantee of a favorable result
- • Not ongoing managed engineering or production operation
After your first Job
Use PR Gate when Jobs should control merge.
Connect PR Gate to the repository once. From then on, any pull request backed by a FalseGreen Job automatically requires an accepted result for its exact head before merge.
Acceptance remains bound to the exact commit or artifact. A changed artifact requires a new acceptance decision.
Learn about PR Gate →Coming next
PR Gate will be free. A Job-backed pull request will require the FalseGreen result tied to its exact head before merge.
See how PR Gate will work →FalseGreen Job
One frozen boundary. One independent decision.
$2,999 for one bounded consequential software Job.
Buy a Job — $2,999