Who it is for
Teams trying to move beyond document-centric AI into systems that actually understand where a matter stands.
If your workflows still depend on someone "knowing the context", this is the gap.
Why it matters
Routing, evaluation, and execution gates all depend on context.
In most systems, that context is implicit, fragmented, or out of date.
That creates a predictable failure pattern:
- work is routed based on stale assumptions
- review is triggered too late or not at all
- obligations are missed because they are not visible in the current state
- decisions are made without understanding what has already changed
The issue is not model capability. It is the absence of a reliable system of record for the matter itself.
If the state is wrong, every downstream control becomes unreliable.
The shift to make
Stop treating documents as the source of truth.
Start treating matter state as the system of record.
Documents inform the state. They do not define it.
Once that distinction is clear, routing, evaluation, and monitoring can be tied to something stable and observable.
What “matter state” actually means
A usable matter state is not a full data model of everything.
It is a minimal set of fields that drive decisions.
If a field does not influence routing, review, escalation, or monitoring, it does not belong in the core state.
This keeps the model tight and maintainable.
Practical steps
1. Define a minimal, decision-driven schema
Start with fields that directly affect behaviour:
-
Phase
Intake, review, negotiation, execution, post-completion -
Open tasks
What still needs to be done, with ownership -
Pending decisions
Items waiting for input, approval, or escalation -
Obligations
Active duties with deadlines or conditions -
Risks
Known issues that affect handling or escalation -
Review status
What has been reviewed, by whom, and at what level -
Recent changes
What has shifted since the last decision point
This is enough to support most routing and gating logic.
Anything beyond this should be justified by a clear use case.
2. Assign ownership and update triggers
State fails when it becomes nobody’s responsibility.
For each field:
- assign a clear owner
- define when it must be updated
- define what event triggers that update
Examples:
- phase changes on completion of defined milestones
- obligations update when new clauses are agreed
- risks update when new information is introduced
If updates rely on memory or goodwill, the state will drift.
3. Define freshness rules
State is only useful if it is current.
You need explicit rules:
- when a field is considered stale
- who is notified when it becomes stale
- what happens if it is not updated
For example:
- obligations not reviewed within a defined period trigger an alert
- pending decisions older than a threshold require escalation
- phase must be confirmed before certain outputs can be released
Freshness turns state into an active control, not a passive record.
4. Connect state to decisions
This is where most implementations stop short.
Every key decision should reference state explicitly.
Examples:
-
Routing
High-risk matters route to stricter models or additional review layers -
Execution gates
Outputs tied to binding use require confirmed review status and up-to-date obligations -
Evaluation scenarios
Test cases vary based on matter phase and sensitivity -
Monitoring
Active obligations trigger ongoing checks and alerts
If state does not influence behaviour, it will not be maintained.
5. Maintain a visible change log
Reviewers need to understand not just the current state, but how it got there.
A usable change log:
- records what changed
- shows who made the change
- captures when it happened
- links to the source or trigger
This supports:
- audit
- dispute resolution
- faster re-orientation when matters shift
Without this, teams fall back to re-reading documents to reconstruct context.
Minimum artefacts
You do not need a complex system to start, but you do need clarity:
-
Matter state schema
The defined set of fields and their meaning -
Field ownership map
Who is responsible for each part of the state -
Freshness and alerting policy
When state is considered out of date and what happens next -
State-to-decision map
Which routing, gating, and monitoring rules depend on which fields
If these are not explicit, behaviour will be inconsistent.
Where this usually breaks
Common failure points:
- Too many fields, none of which drive real decisions
- State treated as documentation rather than an active control surface
- Ownership assumed rather than defined
- Updates happen after the fact, not at the point of change
- No link between state and system behaviour, so it becomes optional
This leads to the worst outcome: a state model that exists, but is ignored.
What good looks like
A working matter state model has a few clear characteristics:
- The schema is small and tied directly to decisions
- Ownership is clear and enforced through workflow
- State updates are triggered by events, not manual reminders
- Freshness is visible, with alerts when it degrades
- Routing, evaluation, and gates all reference state fields
- Change history is easy to inspect and trust
At that point, the system starts to behave less like a document tool and more like a live coordination layer.
Adoption pattern
Start small and prove that it holds.
-
Single matter type
Choose a workflow with clear phases and repeatable structure -
Single practice group
Work with a team that can give consistent feedback -
Instrument behaviour for 4 to 6 weeks
Track how often fields are updated, missed, or ignored -
Refine aggressively
Remove fields no one uses
Strengthen fields that drive decisions
Adjust triggers and ownership where gaps appear -
Expand carefully
Only extend once state quality is reliable
Scaling a weak state model just spreads inconsistency faster.
Checklist
- State fields are tied to real routing, review, or monitoring decisions
- Ownership for each field is explicit and enforced
- Update triggers are defined and observable
- Stale state is visible and generates action
- Routing and gates reference state, not assumptions
- Change history supports audit and rapid understanding
Related
Use the Matter State Viewer as a working surface to align legal and product teams on what the minimum viable state actually is.
If the state cannot be agreed, the rest of the system will not hold.