Skip to content
Merulan

Framework mappings

Framework mappings attach reviewed Product evidence to exact framework elements without making an assurance or install decision.

Framework mappings link a Product release to a named need in Installable Products. Each claim keeps proof and names the exact framework release. A mapping explains the link. It does not install the Product or prove its use works.

Ownership

A framework mapping names the Product key, exact version, and manifest digest. All targets belong to one exact framework release. Each target needs proof from owned content or an exact referenced Product mapping. A pinned adapter checks what the claim means in that framework.

The Product owns its content and references. The framework owns its terms and elements. A matching label or nearby release cannot replace those exact identities.

Lifecycle

Framework mappings have published, superseded, and withdrawn states. A changed claim gets a new revision with retained history. Withdrawal changes the mapping's standing. It does not change the installed Product. Use the exact revision when you compare proof across a release change.

For process framework content, use the validation contract before the publication contract. Publishing a framework does not also map a Product to it. Each needs its own accepted result.

Boundaries

Framework mappings keep each framework's own meaning. An APQC claim records how a Product release corresponds to a process element, with its scope and mode. Proof points to released constructs or exact child coverage. It describes the Product's design, not work a company has run. Installing the Product does not make the company's processes APQC-aligned. A shared process name does not prove that two Products cover the same work.

CUI claims use supported-by to link to an official category or handling obligation. An obligation needs its authority citation. The adapter checks the pinned source digest of the NARA Registry copy it was built from. A CUI mapping is advisory. Current CUI mappings are demonstration correspondence. They are not a compliance or certification verdict. They do not authorize Merulan to store or handle CUI.

A mapping cannot change installed settings or choose a Product reference. Obtain that reference from the Product's release before planning an install.

Failures

Framework mappings fail when targets mix releases or repeat evidence. Referenced evidence cannot name the subject Product itself. The publish path checks the exact Product digest, owned content, and reference graph. APQC proof must agree across its forms. CUI claims cannot assert assurance. A valid shared shape cannot bypass the adapter's checks.

Recovery

Framework mapping recovery starts with the failed target and its proof. Correct the exact coordinate or replace the unsupported claim before publishing. Give a changed claim a new revision. If support for a claim has ended, withdraw it. Retain its history for readers of earlier releases.

Inspect the Product when the problem concerns installed behavior. A mapping repair cannot fix a missing Source or a failed install.