Odin gave an eye at Mímir's well to drink of its wisdom. Mimir does the same work in reverse: it draws requirements out of published standards, lets a human weigh every one, and seals the approved set into a standard bundle — a single, text-only, human-vouched file a Bifrost library can drink from without ever touching the raw source.
A standard bundle is the contract between Mimir (producer) and BifrostBackEnd (consumer) for delivering requirements extracted from published standards into a Bifrost requirements library.
Mimir ingests a publicly available standard, extracts requirement candidates with the assistance of an LLM, and — after human review and approval — seals the approved requirements into a bundle: a single, self-contained, text-only file. A BifrostBackEnd instance (typically a Muninn deployment) imports the bundle into its requirements library.
Text only. Bundles carry no embeddings and no binary payloads. The importing instance re-embeds locally on import — Muninn owns its own embedding model and version.
Stable identity. Every requirement item carries a uid that never changes across bundle revisions. Idempotent import keys on it.
Additive, deprecate-not-delete. Importing a newer revision may add and update items, and marks vanished items deprecated — it never deletes.
Provenance everywhere. Every item records exactly where in the source standard it came from — clause, heading, page.
Human-sealed. A bundle is only produced from reviewed and approved items. Raw LLM output never leaves Mimir.
One bundle = one standard section. Standards are ingested section by section (e.g. one MIL-STD-810H test method per bundle). A full standard is a set of bundles.
<standard-slug>__<section-slug>__v<bundle_version>.bundle.jsonmil-std-810h__501-7__v1.bundle.jsonbundle_format_version (semver) versions this spec;
bundle.version (integer) versions the content of one bundle.
Every bundle opens with the format version, then five metadata blocks
(bundle, standard, section,
generator) and the two content arrays
(requirements, links).
bundle.uid is <standard.ref>/<section.id> — the identity that ties bundle versions together.sealed_by records the human reviewer, not the tool.standard.public_domain states whether verbatim source excerpts may legally ship in the bundle (true for US Government works such as MIL-STDs). When false, source.excerpt fields MUST be omitted or paraphrased.
Each entry in requirements[] is a single sealed requirement.
Its statement is written in Bifrost quality style (shall form),
not a verbatim clause copy — the source text lives in the source block.
| Field | Req. | Rules |
|---|---|---|
uid | yes | <bundle.uid>/<seq> with a zero-padded sequence. Assigned at first sealing; never reused, never renumbered. Items removed in later bundle versions leave gaps. |
layer | yes | Canonical English: Need | Function | Solution | Implementation. |
target | yes | What the constraint applies to: product (the materiel itself — capability, performance, environmental tolerance), verification (test setup, execution, laboratory obligations), or process (program documentation, planning, reporting). Test-method standards (MIL-STD-810 family) yield mostly verification literals plus derived product requirements; product standards (e.g. MIL-STD-461) yield mostly product directly. |
statement | yes | Requirement text in Bifrost quality style ("shall" form). Not a verbatim clause copy — the source lives in source. |
rationale | no | Why this constraint exists, in the standard's terms. |
type | no | Defaults to functional. |
priority | no | Defaults to medium. |
parent_uid | no | Same-layer decomposition inside this bundle (Decompose per canon). Must reference a uid in the same bundle. |
variant_tag | no | Implementation-layer variant identifier when applicable. |
source.clause | yes | Paragraph number in the source document, e.g. 4.5.3. |
source.heading | no | Heading text of that clause. |
source.page | no | Page number within the section as printed (e.g. 501.7-12) or absolute PDF page. |
source.excerpt | no | Verbatim source text; only permitted when standard.public_domain is true. |
parameters | no | The tailorable values a product must fill in when adopting this requirement. Each: name (snake_case), description, source (where in the standard the value is chosen from), example. Enables form-based parameter filling at project adoption on Muninn, without an LLM. Statements reference parameters as bracketed text; the array is the machine-readable side of those brackets. |
tags | no | 3–6 lowercase keywords for search, filtering, and retrieval. Supplements embeddings on Muninn. |
applicability | no | statement — when/to what the requirement applies, in the standard's terms; platforms — the platform/installation classes the standard names (empty = universal). Enables Muninn to pre-filter library matches by product type. |
custom_attrs | no | Pass-through JSON object, imported verbatim. Reserved key: derived: true marks a requirement Mimir inferred from the source (e.g. the materiel requirement implied by a test procedure) rather than one the standard states literally — reviewers and importers must treat these as interpretations, not citations. |
parameters[]
tags[]
applicability
are the v0.3 additions that let Muninn tailor a library requirement to
a specific product downstream — a fill-in form for parameters, keywords for
retrieval, and a scope filter — all without an LLM. All three are optional
and are imported under custom_attrs.
custom_attrs.derived: true. These are interpretations of the
standard, not quotations from it — reviewers and the importer must treat them
accordingly.
Optional. Cross-layer Fulfils relations between items of the
same bundle (orientation per the canonical methodology). Same-layer
decomposition uses parent_uid, not a link. Bind is
out of scope for bundles.
Mimir v1 may emit an empty links array.
Every item becomes a library requirement: is_library = true, project_id = null.
req_id (LIB-{N|F|S|I}-xxx) is assigned by the importing instance. Bundles never ship req_ids — per-instance counters differ.
Keyed on (standard_ref, bundle_uid). Re-import is create / skip / update / deprecate — never delete.
After import, the instance recomputes embeddings locally for created/updated items. Bundles carry none.
Placement. Every item becomes a library requirement: is_library = true, project_id = null.
Provenance columns. origin = "standard", standard_ref = standard.ref, standard_revision = standard.revision. The item uid is stored as custom_attrs.bundle_uid; source.* under custom_attrs.source; target, parameters, tags, and applicability under the same names in custom_attrs (no dedicated columns exist). The adoption/tailor UI reads custom_attrs.parameters to build the fill-in form.
Local IDs. req_id is assigned by the importing instance's ID service (LIB-{N|F|S|I}-xxx). Bundles never ship req_ids — per-instance counters differ across deployments.
Status. Imported items enter the library as active and are read-only there. Adaptation happens via the existing promote-to-company flow, which creates an editable origin = "company" copy.
Idempotency. The import key is (standard_ref, custom_attrs.bundle_uid): unknown key → create; known key, identical content → skip; known key, changed content → update in place (version snapshot); key present locally but absent from a higher-version bundle → set status deprecated. Never delete.
Re-embed. After import, the instance (re)computes embeddings for all created/updated items locally. Bundles carry none.
Links. Imported links are created between the library copies; a link referencing a uid not present locally is an import error.
standard as threshold_source) — tracked in TODO P6, activates when the importer lands.| Version | Date | Status | Description |
|---|---|---|---|
0.3current |
2026-07-06 | Draft | Enrichment for downstream tailoring on Muninn: structured parameters[] (tailorable values a product must fill in), tags[] (search/retrieval keywords), and applicability (scope statement + platform list). All optional, imported under custom_attrs. bundle_format_version 0.3.0. |
0.2 |
2026-07-05 | Draft | Added target classification (product / verification / process) and derived-requirement marking (custom_attrs.derived) — distinguishes constraints on the materiel itself from test-method and process obligations. bundle_format_version 0.2.0. |
0.1 |
2026-07-05 | Draft | Initial specification — bundle structure, requirement item schema, import semantics. Pilot standard: MIL-STD-810H, Method 501.7. |