Some teams start at the specification.
A three-engineer team does not care which layer a requirement lives on. They care that there is a specification — sent by a customer, or written by themselves — that every line needs an answer and a proof, and that all of this competes with the actual design work.
Bifrost Lite is the same Bifrost, configured for that team. Stakeholder Needs and Functions are not on the screen: a prime's lines arrive with that work already done, and a small team writing its own specification simply starts at the Solution layer. Your project begins at the lines and ends at the compliance matrix. Everything the full platform does between those two points — traceability, verification obligations, evidence, signed exchange, the assistant — is there; everything you would never touch is not on screen.
The page walks the loop from both seats. A prime issuing a specification writes the lines and the verification method it requires on each; a subcontractor answering one states a position on each line and proves it. Both sit at the same table, and a small team on either side runs the same edition.
Issue. Answer. Verify. Return.
The lines, and the method the customer requires
Issuing? Author the lines, mark them contractual, and set the verification method you require on each. Receiving? From a prime on Bifrost, a signed exchange package; from a prime on paper, their spreadsheet — an ID, a statement and a verification method column. Either way every line lands as a read-only contractual requirement: the customer's words and the customer's method, locked, at the top of the project.
A position and a case, on the row
State your position on each line — comply, partial or non-comply, with a note where it is not plain compliance — and put a verification case on it. A line is answered by those two, never by an approval somebody clicked. Your derived requirements explain how, in your values, on the lines that need translating into a design; a salt-fog test or a mass limit needs none.
One case per line, the customer's method first
Verify by… on a line: the required method is pre-selected, the acceptance criterion is written against the line's own value; choosing another method is allowed and reported, never refused. Approved as you save when your role allows. When the customer re-issues a line, the case on it reads to re-confirm — the proof stays exactly as recorded, the line stops counting as verified until you confirm the case or run it again.
The matrix, in the customer's format
A prime on Bifrost gets the signed return package: your positions, your requirements and the evidence against their lines. A prime on paper gets the workbook, or the response document — every line with the customer's text, your stated position, the case, the result, and a change-request register — printed to PDF.
One table. The whole week on it.
The compliance table is where a Lite team lives. Every contractual line is a row — received or your own; every row carries the position you stated, the method the customer requires, which case proves the line and where the proof stands. The verbs sit on the row. The strip above it names the first line that still needs something.
| Line | Requirement | Ack | Position | Derived requirements | Verification case | Result |
|---|---|---|---|---|---|---|
| SPK-S-001⇄ ACME-SPK-001 | The speaker module shall deliver 10 W RMS continuous output at 1 kHz with less than 1 % THD.ᛏ customer requires Test | APPROVED | COMPLY | SPK-I-001The driver shall be a 2-inch full-range unit rated 15 W RMS, class-D amplified at 5 V. | SPK-VC-001TestAPPROVED10 W RMS sustained for 10 min at 1 kHz into the rated load, THD below 1 %, at 25 °C. | PASSED ✓1 evidence |
| SPK-S-002⇄ ACME-SPK-002 | The speaker module shall weigh no more than 180 g including the enclosure and the grille.ᛏ customer requires Inspection | APPROVED | PARTIAL178 g bare; 184 g with the grille the customer added.no change request beside it | SPK-I-002The enclosure shall be moulded PC-ABS with a wall thickness of 1.8 mm. | SPK-VC-002InspectionAPPROVEDMass on a calibrated scale, enclosure fitted, below 180 g.Needs re-review — the line's wording changed since the case was confirmed.Still valid | PASSEDto re-confirm |
| SPK-S-003⇄ ACME-SPK-003 | The speaker module shall operate from a 5 V supply drawing no more than 2 A.ᛏ customer requires Test | DRAFT | not stated | none+ derived✦ Write | no caseᛏ Verify by… | — |
| SPK-S-004⇄ ACME-SPK-004 | The speaker module shall reproduce 80 Hz to 18 kHz within ±6 dB.ᛏ customer requires Test | DRAFT | not stated | none+ derived✦ Write | no caseᛏ Verify by… | — |
| SPK-S-005⇄ ACME-ENV-1 §4.2 | The module shall operate from 0 to 45 °C ambient without derating. | DRAFT | not stated | none+ derived✦ Write | no caseᛏ Verify by… | — |
Standards you must meet
“Comply with …” imposed by the customer enters the project the way the lines did: each clause of the standard becomes a contractual requirement carrying the standard reference, one row of the same table. A standard you choose yourself comes in as your own requirements, still carrying the reference, and stays off the table your customer reads. No stakeholder Need, no constraint Function; Lite does not ask you to build that chain.
One product, one flag.
Lite is not a fork and not a cut-down model. It is a configuration of the same instance the full edition runs, with the surfaces a small team never uses taken off the screen. The exchange format is byte-identical, so a Lite instance and a full one exchange packages without conversion — and the same instance becomes the full edition with a configuration change, no migration, the day the team wants the upper layers.
Lite is defined by what it lacks, never by who buys it. Which side of the contract a project is on — answering a customer's lines, or issuing the specification with a small team — is read from the project's data, in either edition, and the screen follows that: a team that issues the specification sees its own requirements first, a team that answers one sees the compliance table first.
Everything the week needs
- Solution and Implementation requirements, traceability, history, baselines
- Týr: verification cases, executions, evidence, the computed coverage
- Signed, encrypted exchange packages — receive and return
- The compliance table — positions, the customer's required method, the case and its proof, a pass recorded on the row — with the workbook and the response document; Excel, Word, ReqIF exports
- The assistant verbs: Tidy, Write for this, Check coverage, Draft verification case
- Standards clauses adopted as requirements from a bundle we deliver
The upper half of the model
- The Need and Function layers as authoring surfaces
- Norn derivation — Needs into Functions into Solution requirements
- The standards imposition chain (standard → Need → constraint Function)
- The model lenses that need Functions to mean anything
Still served by the API, still there the day you switch to the full edition.
The same discipline, read from the data
Lite is not a second methodology. A project with no stakeholder Needs and a set of contractual lines at the top is, in the Bifrost methodology, a delivery project — and the method says exactly what changes there, and nothing else:
The received lines are the top
They are obligations, not orphans. The coverage question is not “which Function fulfils this Need” but “which of ours answers this line”.
Sourced, not parented
Your requirement needs a source: the line above it, a standard clause, a design decision, or the contractual flag. One with none of these is the orphan the strip names — that is the discipline Lite keeps.
One case per line
Every received line carries a verification case by default, taking the method the customer required. Approval still makes it count; a passed or waived result still closes it. Nothing about verification is relaxed.
Answered by a position and a case
A line is answered when the supplier has stated a position on it and a case is on it. Acknowledging a line into scope is a different act, and the tool never prints one as the other. Derived requirements explain how; they are never the gate.
A re-issued line goes stale
When the customer's wording moves, the cases on that line read to re-confirm: their proof stays as recorded, and the line does not close until an engineer confirms the case or records a new run. The one place a stale link changes a computed result — and it demotes nothing.
Not about which side of the contract
A small prime authoring its own specification at the Solution layer gets the same edition and the same table. Lite is about the size of the team and where its work starts, not about being a subcontractor.
The posture and its six rules are written into the Bifrost methodology (v0.14, Delivery Projects) and the Týr engine definition; the contractual scope of the edition is in the Product Description (v0.11) that governs every claim on this page.
Send us your specification.
The one you received or the one you wrote. We will stand up a Lite instance, land the lines in it and walk the first three with you. No discovery-call theatre.
info@odinsinsight.com Running the whole model? See the platform and Týr.