OSCAL integration

mjEdit supports the full OSCAL v1.2.1 standard with specialised editors for every document type.

All 8 OSCAL document types

The OOP principle: components as classes, inventory as instances

mjEdit maps the OSCAL architecture intuitively – inspired by object-oriented programming:

Component = class (blueprint)

"Apache HTTP Server" – type: software, description: web server

Inventory item = instance (concrete asset)

"Apache 2.4.58 on server web-01" – IP: 192.168.1.10, FQDN: web-01.example.com

In the SSP tab an inventory-item dialog is opened, in the “Components” tab the matching software/hardware building blocks are linked via multi-select. mjEdit automatically generates the implemented-components reference with a component-uuid.

Automatic OSCAL document chains

You don’t have to create documents one by one. mjEdit can generate the entire compliance chain automatically:

( Catalog (BSI/NIST) → Profile ) → System Security Plan → Assessment Plan → Assessment Results → POA&M

Each step picks up UUID references automatically, sets metadata (title, version, last-modified) correctly and validates against the OSCAL v1.2.1 schema.

Evidence Workflow with Status Tracking: SSP → AP → AR

Proving that a planned piece of evidence was actually reviewed is the heart of every auditability requirement – and the most error-prone step in practice. mjEdit makes this workflow explicitly visible: three prominent tree nodes connect the System Security Plan, the Assessment Plan and the Assessment Results into a seamless evidence chain.

Three documents – three dedicated tree nodes

When an Assessment Results document is opened, mjEdit automatically loads the linked Assessment Plan via import-ap.href and reconciles the planned evidence items from the AP back-matter against all observation.relevant-evidence[].href anchors in the AR. The result is immediately visible: how many of the X planned items have already been documented?

One-click observation for outstanding evidence

Instead of building an observation manually, a right-click on a ⏳ node in the AR tab is enough:

"📋 Create observation for this evidence"

mjEdit generates a complete, OSCAL v1.2.1-compliant observation – with a UUID, collected timestamp, methods: ["EXAMINE"] and the schema-compliant anchor:

"relevant-evidence": [
  {
    "href": "#<uuid-of-ap-resource>",
    "description": "Evidence from AP planning"
  }
]

Optionally mjEdit sets props[name=evidence-source, value=ap] as a provenance marker.

Why is this so valuable?

• No more gaps: The audit team sees immediately which planned evidence items have not yet been documented – no manual lists or spreadsheets needed.
• Automatic OSCAL compliance: The generated observations follow the NIST OSCAL v1.2.1 schema exactly – relevant-evidence.href as a #uuid anchor is schema-compliant and interoperable across tools.
• Full traceability: The chain SSP (requirement) → AP (plan) → AR (proof) is derivable directly from the file structure – no proprietary database needed.
• Cross-document linking: mjEdit automatically loads the AP when the AR is opened and shows the current review status in real time.

Batch generation for server estates via AI through MCP

With oscal_generate_batch_tailored_chain complete document chains are produced for an entire server estate – e.g. 8 servers – one chain per system:

• 8 servers → 8 subdirectories (named after system_id)
• 6 OSCAL documents each: profile → component definition → SSP → assessment plan → assessment results → POA&M
• = 48 validated documents in a single call

For each server (target) you can specify, among other things: system ID, name, description, platform/OS, server-specific control selection (tailoring), sensitivity level, roles, parties, component definition, assessment actions and inventory_items with hostname, FQDN, IPv4/IPv6 and MAC addresses. Shared fields (shared_roles, shared_parties, shared_sensitivity_level) apply to all systems and can be overridden per target.

Schema validation on three levels

Automatic OSCAL document healing

OSCAL documents today come from many sources: NIST samples, BSI converters, AI pipelines, older generators or manual edits in any JSON editor. The result in practice is schema-violating or outdated structures – e.g. forbidden fields like description on the SSP statement level, missing mandatory fields like import-ap on assessment results, datetime values without a timezone suffix or NIST pre-1.2.1 containers like system-interconnections.

mjEdit solves this with document-type-specific, idempotent healing logic that is invoked automatically on open and on save:

Why does it matter?

• Lossless: content is migrated, not deleted. Text from forbidden fields is moved into semantically appropriate target structures.
• Idempotent: repeated open and save produces identical results.
• Consistent validation: because healing runs both on open and on save (and before any manual validation), the validator sees exactly what will end up in the file.
• Statistics in the log: every save records how many fields were migrated (e.g. statement_descriptions_migrated: 3, legacy_system_interconnections_migrated: 2).
• Round-trip aware: migrated content reappears in the matching dialog on the next open.

Recommendation for “inherited” OSCAL files: an OSCAL document from a foreign tool or a legacy archive does not have to be schema-fixed manually. Open once in mjEdit, save once – done. On the next schema run it is OSCAL v1.2.1 compliant.

Preinstalled compliance frameworks

• BSI IT-Grundschutz++ (2,128 controls)
• NIST SP 800-53 (468 controls)
• BSI criteria catalogue C5 (after Christop Puppe) (work in progress)
• BSI 200-x Compendium 2023 (after Christop Puppe) (work in progress)

Mapping collection — offline AI-powered

The Mapping tab is one of the standout differentiators of mjEdit: controls from two OSCAL documents (source ↔ target) are systematically mapped to each other – e.g. NIST SP 800-53 ↔ BSI IT-Grundschutz, C5 ↔ ISO 27001 or BSI 200-x Compendium 2023 ↔ BSI IT-Grundschutz++.

Why is this so valuable?

A manual mapping between two large control catalogues is one of the most time-consuming and error-prone tasks in compliance work:

• A complete mapping between, say, NIST SP 800-53 (468 controls) and BSI IT-Grundschutz++ (2,128 controls) means worst case almost a million pair comparisons – every comparison requires reading, understanding, judging and documenting.
• Without tooling each mapping project takes several person-weeks to person-months; with mjEdit + AI suggestions the effort drops to a few days – the human only reviews the AI suggestions instead of reinventing the wheel.
• The result is machine-readable (OSCAL JSON), schema-validated, versionable and reusable for years – no more Excel graveyard.

How does the AI work – and what does “offline” mean?

The AI features run entirely locally in mjEdit. An open-source, multilingual sentence-transformer model (paraphrase-multilingual-MiniLM-L12-v2) is used. It is downloaded once on first use and afterwards used offline.

Privacy first: No control text, no catalogue and no mapping suggestion ever leaves the machine. No cloud, no API key, no token cost – making it usable even in highly regulated environments (BSI, public sector, KRITIS).

Auto-suggest with four methods

mjEdit’s mapping editor offers a “Generate suggestions” button. The method can be set per run:

In addition:

• Auto-accept toggle: suggestions above the configurable threshold (default 0.4) are taken over directly – the human only reviews edge cases.
• Cross-language: source in German, target in English? The embedding model handles cross-language semantics natively.
• Bulk operations, schema validation, Markdown export for reviews and reports.

Example mapping hits

Concrete use case: BSI 200-x Compendium 2023 → BSI IT-Grundschutz++

Question: “How can the contents of the existing BSI IT-Grundschutz Compendium 2023 be carried over into the new Grundschutz++? Which contents of which modules should be transferred into which practices of Grundschutz++ – and where do gaps appear?”

mjEdit answers this question in a clearly structured 9-step process:

1. Sharpen the question

Source = BSI 200-x Compendium 2023 (modules), target = BSI IT-Grundschutz++ (practices). Define scope (e.g. only modules ORP.* and OPS.*), protection-needs categories and language alignment.

2. Tailor the source catalogue

The full Compendium 2023 is opened in mjEdit as an OSCAL catalog. The catalog editor is used to mark sections that should not enter the comparison (e.g. obsolete modules).

3. Create source profile → resolve → derive a tailored catalogue

• A source profile is created in the profile editor: include-controls for the relevant modules, add modifications for organisation-specific notes/additions.
• Profile resolution produces a resolved profile (all inheritance, tailoring rules and modifications are evaluated).
• From there a single click exports a tailored source catalogue as a standalone catalog.json – the clean baseline for the mapping.

4. Tailor the target catalogue

Analogously, the Grundschutz++ catalogue (2,128 controls) is opened and filtered to the relevant practice scope (e.g. only practices matching the scope from step 1).

5. Create target profile → resolve → derive a tailored catalogue

Same as step 3, just for the target. The resolved target profile ensures notes, organisation-specific parameters and additions are folded cleanly into the tailored target catalogue.

6. Create mapping file

File → New → OSCAL Mapping Collection. The empty mapping collection receives two resource entries with relative href paths to the two tailored catalogues from steps 3 and 5.

7. Pick source and target catalogue in the mapping tab

Both catalogues are loaded in the mapping tab. mjEdit shows the source controls on the left, the target controls on the right and the mapping table in the middle with columns for method, rationale (matching-rationale), relationship (equivalent, subset-of, superset-of, intersects-with) and statement preview.

8. The automatic mapping

Pick the auto method, set the threshold to e.g. 0.5, press “Generate suggestions”. mjEdit runs the cascade Semantic → Functional → Syntactic for every source control and writes the best match per pair, with score and method, into the table. With auto-accept enabled, hits above threshold flow straight into the mapping collection; everything below lands in the review column.

For e.g. 250 source × 350 target controls, 87,500 pair evaluations are completed in minutes – an effort no team could do manually.

9. Use the result – generate reports and follow-up artefacts

From the finished mapping collection mjEdit can derive at the click of a button:

• Resolved profile (tailoring based on the mapping)
• SSP draft (System Security Plan with carried-over implementations)
• Cross-reference report (Markdown/CSV: which source control covers which target control)
• Gap analysis (which target practices have no source coverage → action needed)
• Component-definition stub (reusable component with mapping references)
• POA&M stub (one entry per gap with proposed remediation)

What value do the different roles get from the mapping?

In short: a multi-month manual Excel exercise becomes a reproducible, AI-assisted, schema-validated workflow of just a few days – with auditable follow-up artefacts for the entire compliance chain.