A live contract is not adocument with status fields.It is a stateful computationalentity that governs operations.
The Live Contract Model
"State, behavior, and propagation — the three properties that make a contract a governing computational object rather than a reference record. This is the computational model underlying all five Contract Intelligence architectural properties."
Paper 5 develops the full live contract model: what it means for a contract to be stateful, how the typed event schema works, how operational inheritance propagates through the five-level hierarchy, and how continuous state enables contract-grounded AI inference.
The live contract model implements a five-level governance hierarchy: Prime Contract, Task Order, CLIN, Work Package, and Activity. Every level inherits governing rules from the level above it — ensuring every operational event, from strategic resource allocation to an individual timesheet entry, is evaluated against the contract-level rules that govern it.
What This Paper Defines
- Passive — holds information, waits to be read
- No behavioral enforcement
- No propagation — modification is a data entry event
- AI inference on stale, disconnected data
Download the Executive Paper
Complete the form to receive the full research, frameworks, and architectural blueprints.
The Argument
The Five-Level Inheritance Hierarchy
The live contract model implements a five-level governance hierarchy: Prime Contract, Task Order, CLIN, Work Package, and Activity. Every level inherits governing rules from the level above it — ensuring every operational event, from strategic resource allocation to an individual timesheet entry, is evaluated against the contract-level rules that govern it. ""The event schema is the architecture of the live contract. It is not a log of what happened. It is the mechanism by which the contract object maintains consistent state across all operational domains simultaneously."" A labor charge at the Activity level (L5) simultaneously validates against the CLIN ceiling (L3), the period of performance (L2), and cost allowability requirements (L1). All three validations occur structurally as part of charge submission — not in a separate compliance review after the fact. This is what operational inheritance means in a live contract model.
A live contract is a stateful computational entity with a typed event schema, a five-level operational inheritance hierarchy, and a propagation engine that maintains consistent state across all governed operational domains simultaneously. It is the computational foundation of Contract Intelligence.
Key Properties
Foundational architectural specifications defined in this research.
State
Continuously-updated representation of all governed dimensions: funded balance per CLIN, LCAT qualification status, compliance posture, period of performance — all current to the last write event.
Behavior
Active rule enforcement at the point of every relevant operational event. CLIN ceilings rejected at charge submission. LCAT validation at labor assignment. Structural enforcement — not periodic review.
Propagation
Typed events sent to all dependent entities when contract state changes. A modification propagates to CLINs, labor records, billing systems, and scheduling simultaneously — in seconds.
Document with Search
Manages contracts as searchable documents. No live state. No behavioral enforcement. No propagation. Fast text extraction — not operational governance.
Reference Record
Contract terms stored as accounting configurations. No inheritance. No event schema. No propagation engine. Contracts report to the ledger rather than the ledger reporting to contracts.
The Architecture of Choice
Side-by-side comparison of structural assumptions and operational outcomes.
Contract as Document (CLM / ERP)
Passive — holds information, waits to be read
No operational state. CLIN balance requires manual calculation from separate systems. No continuously-updated representation of funded capacity.
No behavioral enforcement
A charge exceeding a CLIN ceiling is not rejected at entry. It is discovered in a report, a reconciliation, or a DCAA audit finding weeks or months later.
No propagation — modification is a data entry event
Each system that references the contract must be manually notified and updated on its own schedule. Risk window between modification and system update.
AI inference on stale, disconnected data
AI cannot reason from live contract state because live contract state does not exist in the data model. Results may be accurate as of last close, operationally irrelevant today.
Contract as Governing Computational Object (CI)
Active — maintains live state across all governed dimensions
CLIN funded balance updated by every charge, immediately. Every operational dimension current to the last write event. No calculation required.
Behavioral enforcement at every write
A charge exceeding a CLIN ceiling is rejected at submission — before it posts. LCAT validation occurs at labor assignment. Compliance enforcement is structural.
Propagation — modification is a typed event
Propagates to all CLIN objects, labor deployment records, billing systems, and scheduling functions simultaneously via a defined event schema.
AI inference on live contract state
Every AI query resolved against current CLIN ceiling, funded balance, LCAT requirements, and policy constraints. Grounded in what is contractually true today.
Strategic Insight
""The event schema is the architecture of the live contract. It is not a log of what happened. It is the mechanism by which the contract object maintains consistent state across all operational domains simultaneously.""
Frequently Asked Questions
How is the live contract model different from workflow automation?
What are the five typed event categories and what do they do?
How does Paper 5 connect to Papers 3 and 6?
What is the relationship between live contract state and AI grounding?
Want to model your own ROI?
Use our interactive calculator to see how a contract-native architecture can transform your margin.