02 / Security classification
National records.Allied obligations.
The security layer for EMBI’s records and case management. Bring national and allied records into accountable custody, preserving source restrictions alongside the receiving authority’s obligations. Designed for defence cooperation and public administration; live command and control remains in operational systems.
Capability, in practice
The record carries its handling requirements.
01 /
Classification & dual use
Security markings, handling caveats and releasability belong with the record and its case. The existing classification model provides a foundation for the planned source-and-recipient policy binding.
02 /
Clearance-based access
Clearance checks and case-level need-to-know controls are implemented. The target is consistent enforcement across content, search, previews, exports and background processing; compartment and releasability coverage must be verified for each deployment.
03 /
Recognisable markings
Preserve the original classification and show the recipient’s authorised interpretation alongside it. Signed EMBI metadata exports exist. STANAG 4774/4778 conformance is planned assurance work, not a certification claim.
Built on one foundation
Everyday administration. Stronger controls.
EMBI provides the records foundation; EMBISEC adds security handling. The receiving institution needs evidence of origin, an appropriate case, access rules and a defensible lifecycle for each accepted record. Formal SITREPs, LOGREPs, HNS agreements and after-action records are central examples.
Our design targets national confidential and secret records, and allied material including NATO CONFIDENTIAL, within appropriately approved environments. Iceland’s defence classification rules and state data-handling guidance are distinct policy inputs. Other countries need their own approved recipient profiles. No operational classification ceiling or accreditation is claimed.
A bundle, as a cleared officer sees it
Handling is visible before the first record opens.
A fictional HNS closeout case brings together the final handover, resource accounts and supporting reports. Its header makes marking, releasability, file key and retention visible. A record with different handling requirements must be assessed in its own right; the case label does not grant access to everything inside.
Marking schemes
Source markings retained. Recipient policy explicit.
These example markings show why mapping needs an approved policy. A source classification is preserved, with national handling requirements added alongside it. Civil data tiers are not interchangeable with NATO classification levels; mapping alone grants neither release permission nor access.
Sanitised console · fictional HNS exercise data (NG26) · illustrative workflow · markings are illustrative; no automatic equivalence or deployment authorisation is asserted
Planned / EMBISEC Validation & Normalization Engine
A controlled path into the record.
The next development step is approved file and package import: HNS handovers, SITREPs, LOGREPs and after-action records. ADatP-3 parsing will be implemented against selected message profiles. Direct connections to military systems are future integrations requiring agreed interfaces and security boundaries.
Approved source package · original bytes and markings preserved
01 / Validate & normalize
Record receipt and source evidence, check the selected format, extract metadata and propose the receiving institution’s case key. Preserve originals alongside derived representations.
↓ Validated candidate · unresolved checks stay in quarantine
02 / Bind source & recipient policy
Keep the originator’s classification and caveats; add authorised national handling obligations. Bind both to the content and evaluate access before acceptance. This is the planned dual-tag security responsibility.
↓ Authorised acceptance · evidence retained
03 / Register & govern in EMBI
Register the record to its case, protect the declared version, apply retention and holds, and prepare transfer under an approved archive profile. Receipt, registration and archival acceptance are distinct events.
Architecture planned; the complete engine is not operational. Existing foundations include exercise-message parsing, record registration, signed EMBI metadata exports and lifecycle workflows. Normative format conformance, source trust, cryptographic enforcement and deployment approval remain separate delivery gates.
The evidence stays with the record
From source to decision.
The HNS handover illustrates the intended ingestion workflow: preserve the source, assess its binding and trust evidence, and register the accepted package with its case. The complete workflow shown below is planned.
01 / Labelled ingestion
Receive. Verify. Register.
A final HNS handover package is the record of responsibility transferred between parties. The planned engine will check its content, metadata binding and source trust separately, then apply recipient policy. Missing or conflicting evidence goes to quarantine for review.
02 / Supporting data
A decision with a traceable source.
The facility inventory and resource statement support the signed handover. Preserve the exact version, provider and checksum referenced by that record. The illustrated source-to-record relationship is part of the intended workflow; it does not assert an operational connector to an allied system.
Sanitised console · fictional HNS exercise data (NG26) · illustrative workflow
Standards & scope
ISO 15489 informs records practices; ADatP-3 parsing requires selected message profiles. STANAG 4774/4778 are target conformance references. Existing EMBI signatures and parser tests do not establish full interoperability.
Standards references distinguish design targets from implemented checks. They do not imply certification, accreditation or approval for classified operation.
A deliberate boundary
Records and case management.
For accountable public authority.
EMBI preserves official records of decisions and activity. It is not a live command-and-control system. Approved transmission cryptography and cross-domain guards belong to specialist infrastructure; their integration and authorisation are separate from the RMS.
Let’s start with your requirements.
Discuss your records, security and operational environment.
Request a briefing