Not a roadmap. Each gate is an experiment with a stated success condition and a stated failure interpretation.
A gate is passed only when the observation is external to AgEvidence's own account of it.
Is there enough capital to reach the next gate without a new financing event?
Every subsequent gate is underwritten by optimism about the next round.
Can the core stop changing?
The architecture is not ready for external adoption.
Does the core survive heterogeneity?
The generic evidence substrate may actually be bespoke domain modelling.
Is this portability, or ordinary ETL?
The claimed portability is transformation plumbing with a nicer name.
Can someone use it without trusting AgEvidence?
The neutrality thesis is weak.
Does usefulness become willingness to pay?
Developer interest has not translated into economic demand.
Does the second deployment cost less than the first?
Consulting disguised as software.
Hiring and spending should occur against the next gate, not against the eventual size of the vision.
Integrations are getting easier
Downstream reliance is getting more valuable
Paid work is getting more reusable
That combination is more meaningful than revenue alone. Revenue can rise while every one of the three deteriorates.
| Gate | Question | Status | Failure means |
|---|---|---|---|
| G0 · Capital | Is there enough capital to reach the next gate without a new financing event? | Proposed | Every subsequent gate is underwritten by optimism about the next round. |
| G1 · Canonical protocol freeze | Can the core stop changing? | Demonstrated | The architecture is not ready for external adoption. |
| G2 · Three independent upstream integrations | Does the core survive heterogeneity? | Open | The generic evidence substrate may actually be bespoke domain modelling. |
| G3 · Dual-destination evidence | Is this portability, or ordinary ETL? | Open | The claimed portability is transformation plumbing with a nicer name. |
| G4 · Independent external reliance | Can someone use it without trusting AgEvidence? | Open | The neutrality thesis is weak. |
| G5 · First paid deployment | Does usefulness become willingness to pay? | Open | Developer interest has not translated into economic demand. |
| G6 · Repeat paid deployment without core redesign | Does the second deployment cost less than the first? | Open | Consulting disguised as software. |
The first architecture test is whether the core can become stable enough for external compatibility. Success means a stable primitive set, version policy, fixtures, deterministic verification and no customer-specific semantic fork hidden inside the core. Failure means the company is still discovering the architecture and should not pretend it has an external substrate.
Three materially different upstream systems should be able to emit useful evidence without redesigning the core primitives. This is the first serious test of the generic-substrate claim. If the second or third source requires a new kernel object that exists only for that company, the architecture may be bespoke domain modeling wearing an interoperability label.
The same historical evidence should support two materially different downstream uses without recreating the source history. Different destinations can legitimately reach different sufficiency conclusions. The proof is not that one package magically satisfies everyone; it is that evidence identity, provenance and history survive while distinct profiles interpret it.
An external buyer, verifier, auditor or other recipient should be able to inspect and use an AgEvidence package without treating the hosted application as the sole authority. If independent reconstruction requires proprietary hidden state, the neutrality and portability thesis weakens.
A customer must pay for the commercial layer because evidence has become operationally consequential. The payment should be tied to readiness, method operations, claim evidence, sharing, review or external reliance — not to a custom software project that could have been sold without the evidence architecture.
The second or third paid deployment should reuse the same core and change profiles, configuration, connectors and edge mappings instead of architecture. If revenue continues to require substantial customer-specific engineering, the company may still be useful, but the venture case should be re-underwritten as services-enabled software rather than infrastructure.
The native reading. Claim status, evidence burden, proof gates, falsifiers, contradictions, capital-to-proof, governance, downside, and explicit reasons to stop or narrow the thesis.