A tracker records labels. A state engine explains what those labels mean, what evidence changed them, what becomes permitted next, and which work is now required.
That distinction is easy to miss because many deals are presented as a straight line: outreach, NDA, CIM, management presentation, bid, diligence, close. The real process branches. Buyers pause and return. Documents have different eligibility rules. Questions block workstreams. Deadlines move. A meeting can create five actions owned by four parties.
Events and states are different
“Buyer requested a management meeting” is an event. “Buyer is in management presentations” is a state claim. The event may support the state, but only after the system resolves the correct buyer, deal, date, participants, prior stage, and source.
Keeping those concepts separate prevents one phrase in one email from silently rewriting the process. Events remain an append-only history. States are revisable conclusions with evidence and an as-of time.
State creates the next work
Once a buyer becomes eligible for a management meeting, the process may create availability collection, internal prep, calendar coordination, document checks, and a client-update line. If the buyer later pauses, those tasks should not continue as though nothing changed.
A state engine connects the change to its consequences. The team sees the exception or decision it owns. Administrative work can be assigned to a person or agent. The workflow does not depend on somebody remembering every downstream step.
Permissions belong inside the state
Deal execution is not merely task completion. It is controlled progression. An executed NDA may change what a buyer can receive. Client approval may be required before a party advances. Counsel may own the final release. Those are state and permission rules, not notes beside a checklist.
Putting the rules in the transaction model lets the system prepare work without overstepping. It can identify an eligible document and stage the action while still requiring the accountable person to approve release.
Receipts close the state transition
The process should not advance because a button was clicked. It should advance when the destination confirms the approved action. A CRM record is read back. A tracker value is checked. A draft remains a draft until a provider records the send. This prevents optimistic status from becoming fictional status.
The result is less interface, not more
A good state engine does not force every banker to stare at a graph. It uses the graph and rules underneath to show a simple answer: what changed, what needs you, what Arvya handled, and what remains unverified.
That is the role of the transaction state engine inside Arvya. It turns the deal from a collection of artifacts into a governed process that can create, route, approve, execute, and verify its own administrative work.
