CONTRACT REVIEW · AN AGENT ON TALONIC
Most rules flag a value. One stops the contract.
Every contract estate says things that cannot all be true. A term that ends before it begins. A renewal with no notice period. An agreed contribution with no amount. None of these are extraction errors. They are in the documents. Somebody has to decide which ones are worth stopping for. Contract Review is that decision, written down as rules and run on every contract the pipeline reads.
- STAGE
- business rules, after the contract is assembled
- READS
- the assembled contract and the fields your specification declares
- WRITES
- flags, holds and every outcome to the ledger
- WHO DECIDES
- your reviewers, in the queue a hold opens
- STATUS
- running. Flags and holds only
DECIDEContract Review · produces a hold
Rules read every contract before a person does. One of them stops the contract.
RUNNING · FLAGS AND HOLDS
THE AGENT BAND
SCOPE
1
pipeline. The assembled contract data products and the declared fields. No other estate, no outbound call.
RULES
YOURS
written as sentences by the people who own the contracts. Most mark a value. One stops the contract.
ARTIFACT
HOLD
one contract stops and waits for a person. Flagged values travel into the delivered data with their mark on.
REVIEW
1
queue. A held contract arrives with the rule, the sentence its author wrote, the value that failed and the page it came from.
LEDGER
EVERY
outcome is written, including passes. A rule that fired and found nothing is a receipt.
STATUS
RUNNING
on live contract estates. Flags and holds, every outcome in the ledger.
Six cells, six units. Nothing here divides into anything else.
01 / the scope
An agent that can read everything can be blamed for everything.
Contract Review is granted one thing: the assembled contract and the fields your specification declares. Not the document store. Not your contract system. Not the finance system where the amounts live. When it holds a contract, there is exactly one place the disagreement came from.
The unit is the contract, not the file. Six documents can make one agreement. Most of these rules compare two things that are not on the same page and often not in the same document. A rule about a signature date has to see the term dates. Assembly is what makes the rules possible.
- stage
- business rules, after resolution
- subject
- the assembled contract, not the scan
- fields
- the ones your specification declares
- nothing else
- no other pipeline, no other estate
every read is logged · every value carries its source
02 / the rules
Two good sentences beat a manual.
A rule starts as a sentence. Somebody types what they mean, in their own words. Talonic compiles it into a check with a named subject, the fields it reads and the condition that fails. The sentence stays. It is what a reviewer reads when the check fires.
Each rule declares what happens when it fails. Hold, and the record stops. Flag, and the value travels with a mark on it. Record, and the outcome exists only in the ledger. Most of what you find is worth knowing. Almost none of it is worth stopping for. Build the ratio that way.
A sentence is published once it compiles into something checkable. That is the whole trick. The sentence on your specification and the check that runs cannot drift apart.
| what the rule looks for | effect |
|---|---|
| a term that ends before it begins | HOLDS FOR REVIEW |
| a term with no dates on it at all | FLAGS VALUES |
| a signature dated outside any plausible window | FLAGS VALUES |
| two signatures too far apart to be one signing | FLAGS VALUES |
| a termination clause with no notice period in it | FLAGS VALUES |
| a renewal that extends with nobody required to act | FLAGS VALUES |
| an agreed contribution with no amount against it | FLAGS VALUES |
1 holds · 6 flag
A set a contract team started with. Yours will differ. The badges are the platform’s own.
03 / the artifact
A hold is not an error. It is a sentence with a page number.
When a rule holds, what exists afterwards is a record with a name on it: which rule fired, which fields it read, what they said, and which page each value came from. A person who has never seen the contract can open it and see the disagreement in one screen.
A rule returns one of four things. Passed. Failed. Not applicable, which means the contract was out of scope and silence is the right answer. Indeterminate, which means an input was missing. A missing input is not a verdict. Fold it into a pass or a fail and the flag stops meaning anything.
PASSED
the rule looked, the record was in scope, and the condition held
FAILED
the rule looked, the record was in scope, and the condition did not hold
NOT APPLICABLE
the contract was out of the rule’s scope. Silence is the correct answer
INDETERMINATE
an input the rule needed was not there. Never counted as either of the two above
The closed vocabulary a rule returns. Not a distribution.
04 / the review
One rule holds. The rest do not. That ratio is the design.
Make every rule blocking and nobody will use them by Friday. A queue where everything stops gets bypassed, and a bypassed queue is worse than none, because it produces a record that says a person looked.
So one rule holds: the one where the contract’s own dates contradict each other. The others mark the value and let the contract through. The mark prioritises the queue instead of blocking it. An owner can override a hold. The override is written down as an override, with a person on it. It never looks like a pass afterwards.
Design the queue around the assembled contract, not the field. Field by field, every check means opening another system and its sibling documents. That is where review time goes.
05 / the ledger
Rules judge. Something else has to remember.
Every evaluation is written down: the rule, its version, the record, the outcome, the fields it read and the pages behind them. Passes too. That sounds like accounting. It is the whole audit story, and it is what makes a rule change safe, because the run before and the run after compare line for line.
The verdict sits next to the evidence, never on top of it. Nothing a rule decides overwrites what a document said. A reviewer can disagree and still see the same page the machine saw. A system where the verdict replaces the evidence gives you nothing to disagree with.
Nothing downstream re-runs the rules. One judgment per record per version. Every surface shows the same one.
06 / how to start
Start with the sentences you already say.
- Write down what is not allowed to be true. Five to ten sentences from the people who own the contracts. In their words. No query language.
- Send a sample of contracts. Amendments and annexes included, since most rules compare across documents. We read them once and return the data with provenance on every value.
- Pick the one rule that holds. Everything else flags. You can promote a flag to a hold later. You cannot un-teach a team to bypass a queue.
- Read the ledger after the first run. Which rules fired, on what, how often. That is where the next five sentences come from.
next
Send us the contracts you think will embarrass you.
Send a representative sample. We return your data within five business days with coverage, confidence and provenance on every value. Then write us the sentences about what is not allowed to be true in your contracts. We will show you each one running as a check.