The schema rejects bad writes
A test cannot exist without the requirements it verifies. A baseline cannot freeze if an entity is in Draft. The graph enforces invariants the way a compiler enforces types, silently, every write.
Glossary · Engineering-Native
Engineering-native software encodes the domain in the schema itself, typed Requirement entities, computed BOM rollups, cryptographic baselines, MCP-native AI access. This page is the schema-level reference: concrete data-shape contrasts that show exactly where a generic project tool stops and an engineering-native tool starts.
Generic project tools and engineering-native tools both surface a form with fields. The divergence happens one level below, in the data structure the tool was designed around. Four side-by-side examples, in the actual shape an engineer hits at work.
{
"key": "SR-128",
"issuetype": "Story",
"summary": "Battery shall hold charge ≥ 8h at 25°C",
"labels": ["safety", "ISO13485"],
"customfield_10042": "Test method: lab cycle",
"customfield_10043": "Acceptance: ≥ 480 min",
"customfield_10044": "Source: STK-018"
}Requirement {
id: "SR-128"
statement: "Battery shall hold charge ≥ 8h at 25°C"
acceptanceCriteria { threshold: 480 min, condition: 25°C }
verification: { method: "Lab cycle", standard: ISO13485.7.3.6 }
source: ref(Stakeholder "STK-018")
verifiedBy: [ref(Test "TC-501")] // bi-directional
baseline: ref(Baseline "v1.2")
rationale: "Compliance with ISO 13485 §7.3.5"
}// Cell C42 (total mass)
=SUMIFS(D2:D40, B2:B40, "active")
+ VLOOKUP(... // breaks when rows shift
+ manual entries from supplier emailComponent.mass {
computed: rollup(
children: self.children.filter(state="active"),
aggregator: sum,
field: "mass"
)
}
// Mutating a leaf reactively updates every ancestor.
// No re-computation step. The query IS the value.// Best the agent can do without schema:
search("battery requirement coverage")
→ 47 wiki pages, 312 tickets
→ LLM re-reads them, hallucinates relations
→ output uncertain, no audit trail// Typed query, deterministic answer:
agent.exec({
intent: "uncovered safety requirements",
query: Requirement.where(
label="safety",
verifiedBy.size == 0
),
scope: project.id,
permissions: ["read"]
})
→ exact set. Logged. Verifiable.\\fileshare\\baselines\\
v2.1_FINAL_REVIEWED.zip
v2.1_FINAL_REVIEWED_(2).zip
v2.1_FINAL_REVIEWED_jan.zip
// No proof of integrity.
// No relationship to other tools' baselines.
// Reviewer signatures = a "_signed" suffix.Baseline "v2.1" {
hash: sha3-256:7e2c… // Merkle root
contents: [Requirement…, Component…, Test…]
signedBy: [alice.chen, marc.dubois]
parent: Baseline "v2.0"
frozenAt: 2026-05-22T14:32Z
}
// Replay deterministic, tamper-evident, fork-able.A test cannot exist without the requirements it verifies. A baseline cannot freeze if an entity is in Draft. The graph enforces invariants the way a compiler enforces types, silently, every write.
Requirements without a verification link. Components without a supplier. Tests pointing at deleted requirements. All one query, and the schema makes the result trustworthy.
An LLM that has to read 312 generic tickets to guess the coverage gap will hallucinate. An agent that traverses Requirement → verifiedBy → Test → result returns an exact, verifiable answer.
Refactor Requirement.acceptanceCriteria into structured sub-fields and every dependent query, view, and export updates. In a generic-tool world, that refactor breaks 20 dashboards no one will fix.
Author, approver, rationale, timestamp, checksum on every mutation. Exportable as DHF, lifecycle data, CDE delivery, audit trail, all from the same typed history.
New engineers learn the engineering schema, not your team's specific ticket-tool customization tribal knowledge. The schema is the documentation; the documentation can't drift.