The God Who Paid For The Binding
A guarantee that costs nothing to give is not a guarantee. Týr is the engine that makes verification claims expensive in the only way that matters — they must be backed by a recorded obligation and a recorded proof, against a specific realisation, or they do not count. In Bifrost, a requirement does not become Verified because someone asserted it. It becomes Verified because the evidence exists and the system can compute that it does.
A Line Drawn Once, And Held
Bifrost is a constraint model. The discipline that makes it useful is knowing what is a constraint and what is an activity. Verification obligations are constraints; closure is a fact about a constraint. Running the test campaign is neither — and Týr does not attempt it.
Obligations and Closure
Verification cases — the method and acceptance criteria that any realisation must demonstrate. Verification executions — the result, date, executor, and evidence pointers recording that a case was proven against a specific realisation. These are native citizens of a constraint model.
Execution Management
Test campaigns, run scheduling, procedures, lab resources, results ingestion. Your test management tools already do this work well, and Týr does not duplicate them. Evidence lives outside Bifrost; Týr holds pointers — attachments and document references — never managed test artifacts.
Týr is part of Bifrost, not a separate product — it surfaces in the workbench as the Verification working mode, against the same requirements you already hold.
Two Records, One Mechanism
Everything in Týr is built from two record types. The separation between them is the whole design: an obligation is durable and reusable, a proof is specific and perishable.
The Obligation
What must be demonstrated. A case declares exactly one method and its acceptance criteria, and connects to the requirements it proves through the Verifies relationship. Cases are governed content — reviewed, versioned, and library-eligible, like requirements themselves.
The Closure
That it was demonstrated. An execution records a result against a specific realisation — carrying date, executor, anchor node, and evidence pointers. One execution closes the case's obligation for every requirement that case verifies, for that realisation.
The General Rule
A case states what a realisation of its target requirements must demonstrate. A Solution case is proven against each fulfilling Implementation, per variant — this is product verification, and it is the dominant flow. An Implementation case is proven against the built article itself — conformity verification. One mechanism, every case-bearing layer.
The upper layers carry no cases. Needs are validated, not verified — validation asks whether the right system was built, which is a stakeholder judgement rather than a demonstrable claim. Verification begins where a claim becomes demonstrable.
Verifies
Bifrost has always been built on a deliberately small set of relationships. Verification did not get a workaround — it got a relationship, ratified into the canon alongside Fulfils, Decompose, and Bind.
ᛏ Verifies — Obligation
Connects a verification case (source) to a Solution or Implementation requirement it verifies (target). The case states what any realisation of the target must demonstrate — method and acceptance criteria.
The Source Is Never A Requirement
Unlike the other three relationships, a Verifies link never originates at a requirement. Its source is always a verification case. This is what keeps the obligation a first-class object rather than an attribute buried on a requirement row.
Many-To-Many By Design
One case may verify several requirements — a single thermal test or EMC campaign routinely closes multiple constraints at once. Forcing a duplicate case per requirement would fragment the evidence trail. One requirement may equally carry several cases, one per method.
Needs And Functions Are Never Targets
The Need and Function layers are never the target of a Verifies link — Needs are validated, not verified. The rule is enforced by the system, so verification obligations cannot drift onto layers that cannot carry them.
It Attaches From Outside
With the NFSI layers drawn as columns, Fulfils runs horizontally across them and Decompose runs vertically within one. Verifies attaches from outside the columns entirely — a case pointing at the requirements it proves.
IADT — One Method Per Case
Týr uses the four classical verification methods. A case declares exactly one. Where a requirement needs two methods, it carries two cases — because closure is per case, and blending methods inside one obligation makes closure unreadable.
| Method | Definition |
|---|---|
| Inspection | Examination of the item itself — visual check, drawing conformity, workmanship. |
| Analysis | Verification by calculation, simulation, or read-across without operating the item. |
| Demonstration | Operating the item to show functionality, without instrumented measurement. |
| Test | Operating the item under controlled, instrumented conditions against quantitative criteria. |
Execution Status
| Status | Meaning |
|---|---|
| Pending | The obligation exists; the proof does not yet. |
| Passed | Demonstrated against the acceptance criteria. Closes the obligation. |
| Failed | Attempted and not met. The obligation stays open. |
| Waived | Closed by decision rather than by proof. Requires a recorded rationale. |
| Not applicable | The obligation never existed for this variant. Declared once, with a reason — never defaulted. |
⚠ Waiver Is Not Non-Applicability
A waiver closes an obligation that applies. Non-applicability records that the obligation never existed for that variant. Confusing the two corrupts the coverage numbers in opposite directions — a waiver hides an accepted risk inside a clean percentage, while a false non-applicability quietly shrinks the denominator. Týr keeps them as distinct, separately reasoned decisions.
Anchor Node — Owned-At ≠ Verified-At
Every execution records the architecture node where the evidence was actually produced. It defaults to the fulfilling element's own node, but may sit higher: some criteria are only demonstrable at integration level — EMC on the assembled unit, not on the board. Flexibility lives here, in where the proof happened. What was proven — which case, against which fulfiller — is never ambiguous.
Verified For A Variant, Or Not Verified
Closure is computed, never stored as an absolute fact. Coverage is held per requirement and derived over Verifies links — which means it cannot drift out of step with the evidence, because it is not a separate record that someone has to remember to update.
A Solution requirement is never simply "verified". It is verified-for-a-variant. A new variant starts with empty execution columns against the existing cases: the obligations carry over, the proof does not. This is the honest regression model — the alternative, inheriting a parent's proof, is how organisations end up shipping an unverified variant with a green dashboard.
| Case | Method | Gen 1 | Gen 2 | OEM |
|---|---|---|---|---|
| VC-001 · Fording depth | Test | PASS | PENDING | N/A |
| VC-002 · Seal integrity | Test | PASS | PASS | PASS |
| VC-003 · Weld conformity | Inspection | PASS | PASS | WAIVED |
| VC-004 · Thermal margin | Analysis | FAIL | PENDING | PENDING |
The cases × variants matrix is the Requirements Verification Traceability Matrix — generated from the link graph rather than maintained by hand. Non-applicable pairs drop out of the denominator entirely; waived pairs close with their rationale attached.
Roll-Up Across Layers
Coverage propagates up Fulfils links as a derived view: a Function's verification position is the roll-up of its Solutions', and a Need's is the roll-up of its Functions'. The upper layers hold no cases of their own, but they inherit a computed position — so "how much of this stakeholder need is actually proven?" is answerable without anyone maintaining a parallel spreadsheet. Contractual requirements get first-class treatment: their closure status per variant is the customer-facing acceptance position.
Verified Becomes Earned
The project requirement lifecycle ends Draft → Proposed → Approved → Verified → Retired. In most requirements tools, that final state is an assertion — someone sets it, and the system takes their word. In Bifrost it is a gate.
⚠ The Verified Gate
A requirement may enter Verified only when all its applicable verification cases have passed-or-waived executions for the variant or variants in scope. The transition records which executions satisfied it. A requirement with no statable acceptance criteria cannot be verified at all — which makes verifiability at approval time a natural writing-quality check, alongside the six AI quality rules.
Case Lifecycles
Cases follow the same two-track pattern as requirements — one status field, scoped by library membership.
Project cases
There is no Verified state for a case: a case is the instrument of verification, not a subject of it. Approval is the gate that makes a case count toward coverage denominators as an obligation of record.
Library cases
As with requirements, there is no Retired in the library, promotion lands in Proposed, and deprecated cases remain permanently with their traces preserved.
ᛚ Cases In The Library
Verification cases follow their requirements into the library — a standard-prescribed obligation is exactly the kind of knowledge the library exists to hold. A shared case is instantiated once per project on first adoption, with its Verifies links to other targets re-established as those requirements are adopted in turn. Executions never enter the library. Evidence belongs to a project and a variant; the obligation is the reusable part.
How Týr Was Drawn
Obligations and closure, never execution
What must be proven and whether it was. How the work gets scheduled and run belongs to the tools that already do it well.
Verify the claim, not the node
A case proves a fulfilment claim about a requirement. The architecture node records where the evidence happened, not what was demonstrated.
Closure is computed
Never stored as an absolute fact. Coverage is derived from the link graph, so it cannot silently disagree with the evidence underneath it.
Per-variant honesty
A new variant inherits the obligations and none of the proof. Empty columns are the correct starting state, however uncomfortable the dashboard looks.
Evidence is a pointer
Týr references the report; it does not become the document management system. The trail must survive outside Bifrost.
One mechanism, every case-bearing layer
Solution and Implementation verification are the same machinery pointed at different targets — not two subsystems with two vocabularies.
Where Týr Goes Next
Verification touches every other part of the suite. These connections are on the way.
Standards Bring Their Obligations
A published standard usually specifies both what must hold and how it must be shown. As standards enter your library, their prescribed verification obligations will come with them — so an imported requirement arrives already knowing what would prove it.
Proposed Cases Alongside Requirements
Verification cases proposed at the same time as the requirements they prove, under the same human review gate as every other proposal — so the obligation is written while the intent is still fresh.
Risk Informs Method
Where the failure analysis says a consequence is severe, the verification method should not be a visual check. Closer coupling between Fenrir's risk picture and the method a case declares.