Computed state
A Startup's state is computed from Events and never set by hand, so a status, a fit or a payback cannot go stale.
State is computed from Events, never set by hand. A computed property names the Events it reads and no Verb can write it, so it cannot go stale.
How it works
A computed property lists the Events it reads. The platform recomputes it when one arrives, and the verifier fails any Verb that takes it as an input or sets it in an effect.
The usual failure is a field someone forgets to update: a stage, a win probability, a runway cell. A computed field has no one to forget it.
Where it runs
| Property | Computed from |
|---|---|
Customer status | Offer.subscribed, Customer.activated, Subscription.unsubscribed, Subscription.renewed and Order.placed; atRisk reads Customer health. |
Lead fit | The Lead fit Policy, graded strong, partial or none. |
Deal statusSince | The Deal's own Events. |
Renewal outcome | The Subscription's Events at the end of its term. |
Play paybackDays | Posted Entries and collected Invoices, walked back through each Customer's Acquisition. |
A Deal's probability defaults from the Portfolio's measured conversion for the same Motion, Deal size and time in stage. It shrinks toward the Startup's own history as that grows.
Sealed readings
A number an investor reads cites a Proof: the Metric, its value, the Policy that computed it and the log root. Verifying the Proof reruns the query against the log root and returns the same value, or the Proof fails.
Example
A Customer subscribes, and Offer.subscribed makes the status trialing; two days later Customer.activated makes it activated. Three silent weeks drop Customer health below its line, the status reads atRisk, and Retention starts a rescue. No Worker ever wrote the field.