Ontology How formal semantic models render traditional product specifications obsolete — and what replaces them.
The Accidental Discovery
The observation that prompted this analysis was not theoretical. During the migration of a precision agriculture IoT monitoring platform from a low-code environment to a formally specified architecture, the engineering team began drafting a conventional Product Requirements Document. The platform manages sensor networks, environmental readings, threshold-based alerts, and operator dashboards across distributed agricultural installations.
The team had already completed the domain model using a formal semantic specification language — a declarative system for specifying entities, predicates, invariants, and state transitions as first-class semantic constructs. When they began writing the PRD, they encountered an unexpected pattern: nearly every section they drafted was either already captured in the formal schema with greater precision, or was a prose restatement of what the schema formally specified.
The few sections that contained genuinely new information — stakeholder priorities, experience decisions, deployment phasing — bore little resemblance to a traditional PRD. The team abandoned the PRD and instead produced a document that referenced the schema for all domain and behavioural specification, adding only the experience and authority layers that the formal model did not capture.
This document became the prototype for what we now call the Product Experience Contract.
Why PRDs Exist: The Historical Function
The PRD emerged to solve a specific problem: the gap between human intent and software implementation. Before formal specification languages, there was no machine-readable artefact that captured “what the system should do.” The PRD served as the canonical translation layer.
A typical PRD contains six categories of information:
| Category | Content | Purpose |
|---|---|---|
| Domain model | Entities, attributes, relationships | Define what exists |
| Business rules | Constraints, validations, invariants | Define what must be true |
| State behaviour | Workflows, transitions, lifecycle | Define how things change |
| Acceptance criteria | Testable conditions for completeness | Define when it is done |
| User experience | Personas, journeys, interaction patterns | Define for whom |
| Stakeholder decisions | Priorities, trade-offs, authority | Define who decides |
The first four categories describe what the system does. They are the engineering specification. The last two describe who consumes the system and who governs it. They are the product specification.
The PRD bundles both into a single document because, historically, there was no formal artefact that could carry the engineering specification independently. Natural language was the only available medium for all six categories.
The Implicit Assumption: Humans Are the Only Consumers
There is a deeper structural assumption embedded in the PRD format that is rarely examined: the PRD assumes that the product’s consumers are exclusively human. User personas are human personas. User stories follow the pattern “As a [human role], I want…” Acceptance criteria describe human-observable behaviours.
This assumption was valid for most of software history. It is becoming less so. As AI agents increasingly consume APIs, process structured data, and make decisions based on system outputs, the consumer taxonomy of a product expands beyond humans.
When the Domain Model Is Formal
Consider what happens when the engineering specification is no longer expressed in prose but in a formal semantic language. Schemas define entities with typed fields, predicates that constrain valid states, invariants that bind predicates to entity types, and flows that specify state transitions with preconditions and postconditions. Each of these constructs is compiled and enforced at runtime by a dedicated semantic engine. The schema is not documentation — it is an executable specification that enforces what it specifies.
In the precision agriculture case, the formal schema specified:
- Entities: Sensor, Reading, Alert, Threshold, Installation, Operator
- Predicates: reading validity bounds, alert escalation conditions, threshold consistency constraints
- Invariants: “a Reading must be within the physical range of its Sensor type,” “an Alert in Escalated state must have an assigned Operator”
- Flows: sensor provisioning workflow, alert lifecycle (Triggered → Acknowledged → Resolved), reading ingestion pipeline with validation gates
When the team attempted to write PRD sections for domain model, business rules, state behaviour, and acceptance criteria, they found they were restating — in less precise prose — what the schema already specified formally. The four engineering-specification categories become structurally redundant:
| PRD Category | Formal Model Equivalent | Redundancy |
|---|---|---|
| Domain model | Entity definitions with typed fields | Full — schema is more precise |
| Business rules | Predicates and invariants | Full — schema is enforceable |
| State behaviour | Flows with pre/postconditions | Full — schema is executable |
| Acceptance criteria | Invariant satisfaction (coherence checking) | Substantial — mechanically verifiable |
The Product Experience Contract
The PXC does not attempt to replace the formal schema. It references it. The PXC’s purpose is to capture the information that the formal model cannot express — the experience, authority, and decision layers that are inherently human concerns.
A PXC contains:
- Consumer taxonomy: Who or what consumes this product? Humans and AI agents are enumerated as peer consumer types, each with distinct interaction patterns, data format requirements, and experience expectations.
- Decision model: For each significant product decision, who has authority? What are the constraints on that authority? What trade-offs were considered?
- Experience layer: What should each consumer type experience when interacting with the product? For human consumers: interaction patterns, information hierarchy, response time expectations. For AI agent consumers: API contract guarantees, structured output formats, semantic query capabilities.
- Schema references: Rather than restating domain definitions, the PXC points to specific entities, predicates, and flows. Zero restatement means zero drift.
AI Agents as First-Class Consumers
The most structurally significant departure from the PRD is the PXC’s treatment of AI agents as first-class product consumers — peers alongside human users, not afterthoughts or integration points.
In the precision agriculture platform, the consumer taxonomy included:
| Consumer | Category | Interaction Pattern |
|---|---|---|
| Field operator | Human | Dashboard monitoring, alert acknowledgment |
| Agricultural consultant | Human | Cross-installation analytics, threshold advisory |
| Automated irrigation controller | AI Agent | Real-time reading consumption, threshold-driven actuation |
| Predictive maintenance agent | AI Agent | Historical pattern analysis, anomaly classification |
| Compliance reporting agent | AI Agent | Periodic data aggregation, regulatory format generation |
Three of the five consumers are AI agents. Their experience requirements differ fundamentally from human consumers: they need structured data contracts rather than visual interfaces, semantic query capabilities rather than navigation patterns, and guaranteed response schemas rather than adaptive layouts. A PRD written for human personas would capture none of this.
The Referential Architecture
The PXC achieves specification integrity through a referential architecture: it points to the formal schema rather than restating it.
This eliminates a class of defects that plagues PRD-driven development: specification drift. In conventional practice, the PRD describes the domain model in prose, the implementation encodes it in code, and over time the two diverge. The PRD says “orders have a status field with values Pending, Processing, Shipped, Delivered.” The implementation adds a “Cancelled” status. The PRD is not updated. A new developer reads the PRD and builds a feature that does not account for cancelled orders.
When the PXC references the formal schema, and the schema is the executable specification enforced at runtime, there is no separate document to fall out of sync. There is no drift because there is no restatement.
The Decision Model Pattern
Perhaps the most practically valuable component of the PXC is its structured decision model. Where a PRD embeds decisions implicitly (“the system shall prioritise high-severity alerts”), the PXC makes each decision explicit with its rationale, authority, and constraints.
| Decision | Authority | Rationale |
|---|---|---|
| Alert escalation threshold: 15 minutes | Operations manager | Balances response time against alert fatigue; field testing showed 10 min too aggressive, 30 min too slow |
| Reading retention: 90 days raw, unlimited aggregated | Data governance board | Regulatory requirement for raw retention; storage cost optimisation for aggregation |
| AI agent write access: restricted to derived entities only | System architect | Prevents AI modification of source-of-truth sensor data while enabling computed analytics |
Each decision references the formal construct that implements it. The decision model captures why these values were chosen — information that neither the formal schema nor a conventional PRD systematically preserves.
Implications
For Product Managers
The emergence of the PXC does not eliminate the product management function — it sharpens it. When the engineering specification is handled by the formal model, product managers can focus on the decisions that are genuinely their domain: consumer prioritisation, experience design, trade-off arbitration, and authority definition.
This requires a shift in skill emphasis. Product managers working with formal semantic models need to understand the model well enough to reference it accurately, even if they do not author it. They become consumers of the schema rather than translators of it.
For Engineering Teams
The primary benefit is the elimination of specification ambiguity. When the formal schema is the source of truth for domain model, business rules, and state behaviour, there is no room for interpretation disagreement between what the PRD “meant” and what the code does. The schema is what it means — it compiles, loads, and enforces.
For AI Integration
The PXC’s treatment of AI agents as first-class consumers is not merely a documentation improvement — it is an architectural decision with practical consequences. When AI agent consumers are enumerated with explicit authority boundaries and experience contracts, the system can enforce those boundaries at the semantic level. An agent whose contract specifies read-only access to sensor data cannot be granted write access through an API misconfiguration, because the constraint is enforced at the schema level, not by application-layer access controls alone.
Limitations and Scope
The PXC pattern applies specifically to contexts where a formal semantic model exists. For products without formal domain models — which remains the majority of software in production — the PRD retains its function as the best available specification medium. The PXC is not a universal replacement for the PRD; it is an evolution available to teams that have invested in formal semantic modelling.
The evidence presented here is drawn from a single migration project in a specific domain. While the structural arguments for the PXC pattern are domain-independent, broader empirical validation across industries and team sizes would strengthen the case.
Conclusion
The Product Requirements Document was an appropriate artefact for an era when the only medium for specification was structured prose. In that era, bundling domain models, business rules, state behaviours, acceptance criteria, experience requirements, and stakeholder decisions into a single document was not merely pragmatic — it was the only option.
Formal semantic models change the calculus. When entities, predicates, invariants, and flows are specified in a language that compiles to enforceable semantics, restating that specification in prose introduces redundancy, imprecision, and drift.
The PRD does not disappear. It bifurcates — into a formal model that is more precise than prose could ever be, and an experience contract that captures what formal models cannot.
What remains after the engineering specification is removed from the PRD is the experience and authority layer — a distinct artefact that treats AI agents as first-class consumers alongside human users, and references the formal schema rather than restating it. The deeper implication is architectural: as formal semantic models become more prevalent, the entire specification stack shifts from prose documents that describe intent to formal artefacts that enforce it.