Builder capability
Generate software and evidence.
Coding agents implement the change. Tests, CI, scanners, formal tools, and human reviews remain part of the engineering system and produce evidence.
FalseGreen for Enterprise
The acceptance control plane for coding-agent work.
Separate builder capability from final acceptance authority.
Agents can generate, test, review, and modify software. FalseGreen keeps human intent, verification evidence, acceptance authority, and enforcement distinct from the system doing the work.
Acceptance architecture
Human requirement
↓
Frozen acceptance boundary
↓
Agent implementation
↓
Engineering evidence
↓
Independent acceptance
↓
Enforcement
Authority separation
The builder does not grade its own outcome.
Tests, CI, human review, static analysis, security scanners, formal tools, and AI reviewers can all produce evidence. FalseGreen decides whether the total available evidence establishes the frozen definition of done for the bounded Job. The builder cannot declare itself done, and the validator cannot invent the definition of done; human-defined requirements remain authoritative.
Acceptance authority
Decide whether the bounded outcome is done.
FalseGreen independently determines whether the available evidence establishes the frozen definition of done for the applicable Job.
Frozen boundary
Human-readable intent remains authoritative.
FalseGreen binds verification to the agreed definition of done before the implementation is judged. The builder can repair the software when evidence finds a deficiency, but it cannot weaken the target to make the work pass.
Exact-source authority
An ACCEPT belongs to the source that earned it.
A changed revision does not inherit old authority. This keeps acceptance inspectable across CI, distributed teams, and changing pull-request heads.
Bounded authority
Arbitrary capability does not imply arbitrary authority.
Consequential engineering may require powerful tools. FalseGreen keeps their use scoped to the applicable task, workspace and source identity, permissions, and acceptance boundary.
Read Trust & Security →Fail closed
Ambiguity does not become acceptance.
Where FalseGreen authority is required, a changed source, ambiguous identity, invalid authority, or service failure must not silently become green.
FalseGreen PR Gate is coming soon. It will enforce existing exact-source acceptance for Job-backed pull requests; it will not perform verification or manufacture ACCEPT.
See PR Gate →Durable evidence
Acceptance remains inspectable.
A FalseGreen report records the bounded claim and the limitations of what was established—not a floating green badge or universal correctness claim.
- 01Frozen criteria
- 02Exact source identity
- 03Verification outcome
- 04Supporting evidence
- 05Explicit limitations
Governance
One acceptance authority for coding-agent work.
The same frozen definition of done, source-bound verdict, and durable evidence apply whether the coding agent changed billing code, authentication, or data handling. The builder does not get the final say—FalseGreen does.
See Trust & SecurityTrust & Security
Reduce what you have to trust.
Inspect how FalseGreen separates human intent, builder capability, evidence, source identity, and acceptance authority.
Read Trust & Security →Proof
Move from architecture claims to evidence.
Review the current empirical and case-study evidence behind independent acceptance and actionable repair.
Read the proof →Higher-volume verification
Establish an independent acceptance boundary.
Discuss regular FalseGreen Job volume, invoicing, and enterprise terms without changing the public self-serve Job model.
Discuss higher-volume verification