All notable changes to the OpenDEA Metamodel are documented here. Format follows
Keep a Changelog; versioning follows
docs/versioning.md.
CR-MM-ECF-03 implementation: ECF domain enum migration to the v2.5.0 canonical Domain set (carried by technehub-labs/dea-metaframework v2.5.0; CR-ECF-008 + ADR-ECF-003). One of seven Domains renamed: Domain 6 OperationsAndEnablement → EnablementAndOperations (kebab-case operations-enablement → enablement-operations; lowerCamelCase operationsEnablement → enablementAndOperations; Python identifier operations_enablement → enablement_and_operations), driven by the Domain/Stage Orthogonality Stress Test. The metamodel profile preserves the kebab-case restatement per CR-MM-ECF-01 §3.1 and updates the kebab-case value to the new canonical form. Backward-compat aliases preserved in dea-metaframework:tools/ecf_coordinates.py:DOMAIN_ALIASES for at least 2 release cycles. The metamodel's catalog ID abbreviation oe is unchanged (stable; not re-keyed).
Files touched: 14 files + 1 new CR carrier + 1 CHANGELOG section. See change-requests/CR-MM-ECF-03.md for the full mapping table and validation evidence.
Unchanged: Domain number (6), matrix position (row 6), semantic anchor (Execution), axiomatic grounding ("persists" + "exchanging value"), domain scope, lifecycle applicability, seven-Domain partition, seven lifecycle Stages, Stage 5 name (Operate), and the ECF = Domain × Stage = 49 coordinates construction.
CR-MM-ECF-02 implementation: ECF domain enum migration to the v2.4.0
canonical Domain set (carried by technehub-labs/dea-metaframework v2.4.0;
CR-ECF-007 + ADR-ECF-002). One of seven Domains renamed: Domain 3
PeopleAndOrganization -> AgencyAndOrganization (kebab-case
people-organization -> agency-organization), driven by the Substrate
Independence Stress Test. The metamodel profile preserves the kebab-case
restatement per CR-MM-ECF-01 §3.1 and updates the kebab-case value to the
v2.4.0 set. The other six Domains are unchanged. No content redistribution
required (CR-ECF-007 §6.3).
Files: 3 entity schemas, 1 sqlite schema + regenerated db, 1 pydantic Literal, 1 typescript type alias, 1 detector map, 1 validator mapping table, 1 controlled vocabulary, 5 docs files, 2 CR records.
CR-MM-ECF-01 implementation: ECF domain enum migration to the v2.3.0
canonical Domain set (carried by technehub-labs/dea-metaframework v2.3.0;
CR-ECF-006 + ADR-ECF-001). Five of seven Domains renamed; one Domain
replaced (Supply & Resources -> Strategy & Direction). The metamodel
profile preserves the kebab-case restatement per CR-MM-ECF-01 §3.1
but updates the kebab-case values to the v2.3.0 set.
This is a non-canonical-version migration; the metamodel's own semver (v3.0.0-alpha) is unchanged. It is the first consumer of the post-gate downstream reconciliation programme (CR-MM-ECF-01).
-
Kebab-case Domain restatement (CR-MM-ECF-01 §3.1, v2.3.0):
# Before (v2.2.0) After (v2.3.0) 1 governance-existencegovernance-existence(unchanged)2 supply-resourcesstrategy-direction3 agency-organizationagency-organization(unchanged)4 customer-demandparty-relationship5 product-offeringproduct-value6 operations-deliveryenablement-operations7 finance-valuefinance-accounting -
schemas/entities/business-object.json:ecf_domainenum updated to the v2.3.0 kebab-case set. -
schemas/entities/organizational-unit.json:ecf_domainenum updated to the v2.3.0 kebab-case set. -
schemas/entities/process.json:process_audienceenum updated to the v2.3.0 kebab-case set. -
scripts/validate_ecf_kebab_restatement.py:DOMAIN_KEBAB_TO_PASCALmapping table updated; the broken-schema self-test fixture updated to use the new v2.3.0 values. -
sqlite/schema.sql: the threeprocess_audience,ecf_domainCHECK constraints (onprocesses,business_objects,organizational_units) updated to the v2.3.0 kebab-case set. -
sqlite/dea-metamodel.db: regenerated from the updatedschema.sql(clean rebuild via the Pythonsqlite3module; the schema-only dry-run in CI was already validating the source of truth). -
pydantic/process.py:process_audience: Literal[...]updated to the v2.3.0 kebab-case set. -
metamodel/vocabularies/classifications.yaml: the three controlled-vocabulary enums (BusinessObject.ecf_domain,OrganizationalUnit.ecf_domain,Process.process_audience) updated to the v2.3.0 kebab-case set. -
scripts/detect_drift.py:DOMAIN_IDPascalCase-to-lowerCamelCase mapping updated to the v2.3.0 set. -
typescript/src/interfaces.ts: both theEcfDomaintype alias and theProcessAudiencetype alias updated to the v2.3.0 kebab-case set. -
change-requests/CR-MM-ECF-01.md: the proposal's domain mapping table (§3.1) and the references throughout updated to the v2.3.0 set. CR status flips to Merged with this PR. -
docs/concepts/terminology-alignment.md,docs/ecf-profile.md,docs/glossary.md,docs/process-type-taxonomy.md: every reference to the old Domain names and identifiers updated; the audience-table inprocess-type-taxonomy.mdrewritten to the v2.3.0 mapping (including the v1->v2 migration table).
scripts/validate_ecf_kebab_restatement.py: PASS (every kebab-case value inbusiness-object.jsonandorganizational-unit.jsonresolves 1:1 to the v2.3.0 canonical PascalCase enum).scripts/validate_ecf_kebab_restatement.py --self-test: PASS (built-in broken-schema self-test detects the v2.3.0 rogue-domain and missing-Domains cases).tests/conformance/: 133/133 pass (E005 classification-vocabularies test confirmsProcess.process_audienceenum inprocess.jsonmatches the controlled vocabulary inclassifications.yaml).tests/runtime/: 290/290 pass (no regression in the runtime ontology scenario/provenance/interop tests).scripts/detect_drift.py: correctly surfaces downstream drift indea-catalog-processesanddea-catalog-business-capabilities(old v2.2.0 identifiers detected in their entity YAMLs); these are the per-repo migration PRs that follow this one.
The same kebab-case rename propagates to:
dea-catalog-processes(43+ files; carrier: CR-BP-ECF-01)dea-catalog-business-capabilities(51+ files; carrier: CR-BC-ECF-01)dea-catalog-stakeholders,dea-catalog-actors,dea-catalog-digital-business-service-factory(per-repo migration)
Until those land, the detect_drift.py output is expected to surface their old identifiers.
Introduces the OpenDEA Process kernel + specializations discipline, mirroring the established Capability kernel + specialization template (CR-016, ADR-015). No canonical version bump.
dea:Process(abstract Core anchor): structural activity organization; aligned 1:1 with WSFwsf:Process(WSF Foundational Semantic Synthesis §6; Tier-3 derived construct).dea:specializesregistry extension:dea:Processis now accepted as a source and target type for the specialization relationship (mirrors thedea:Capabilityprecedent).- Federation mapping (
mappings/wsf/mapping.yaml):dea:Process ↔ wsf:Process(EXACT; LOSSLESS);dea:BusinessProcess ↔ odea:BusinessProcess(EXACT; LOSSLESS). - Glossary entry (
docs/glossary.md): the Process kernel with the WSF discipline citation, the specialization template, and the Activity / Workflow distinction.
dea:BusinessProcessreclassified from a flat kernel to the first Core specialization ofdea:Process:legacy_idscleared ([dea:entity-process, Process]migrates todea:Process.legacy_ids; per WSF authority the legacy belongs to the kernel, not the Business specialization).definitionextended with the WSF/ADR-015 specialization lineage ("Specializesdea:Process(CR-MM-PROC-01; ADR-015 precedent; WSF ADR-WSF-04)").
- All other
dea:BusinessProcessfields (layer,dimension,building_block,class_alias,catalog_repo,artifacts,membership) are unchanged.
schemas/entities/process.json(the BusinessProcess instance schema) is unchanged. The schema title"Process"is misleading post-this-CR and will be updated to"Business Process"in the catalog-side CR (CR-BP-SPEC-BP-01).- All existing references to
dea:BusinessProcessin any catalog or downstream artifact are preserved; the kernel introduction is additive. - The CR-016
dea:Capability/dea:BusinessCapabilitytemplate is the precedent; this CR applies it to Process.
- Required by:
CR-BP-SPEC-BP-01(catalog-side re-anchoring ofdea-catalog-processes; the catalog's metamodel pointer will declare bothdea:Processanddea:BusinessProcess). - Triggers:
CR-AR-FMWK-01(root-model sync ondea-architecture-framework; required for the catalog'svalidate-allocationworkflow).
Closes matrix findings F1/F2/F3 for dea-metamodel. No canonical version bump
(conformance-evidence + governance sweep; no schema data migration).
scripts/validate_ecf_kebab_restatement.py(stdlib only; CR-MM-ECF-01 §3). Proves every kebab-case value in theecf_domain/ecf_stageenums ofschemas/entities/business-object.jsonandschemas/entities/organizational-unit.jsonresolves 1:1 to the canonical PascalCase enum indea-metaframework. Ships a built-in broken-schema self-test.docs/ecf-profile.md(CR-MM-ECF-01 §6). Authority chain, F1 normative mapping table, F2 by-design absence rationale, F3 terminology pointer, conformance evidence links..github/workflows/ci.ymlstep: "Validate ECF kebab-case restatement (CR-MM-ECF-01)" runs after JSON schema validation on every push/PR.
conformance/matrix.yamlbumped to0.2.0;compiled_at: 2026-09-03.dea-metamodelstatus:conformant-with-extension→conformant.conformance/CONFORMANCE-REPORT-v0.1.mdregenerated viascripts/build_conformance_report.py. Overall verdict: PASS.change-requests/README.md: status row added for CR-MM-ECF-01.- F1 closed: kebab-case restatement validated by the new validator.
- F2 closed: by-design absence governed in
docs/ecf-profile.md§4. - F3 closed: terminology pointer preserved; canonical home cited.
schemas/entities/business-object.jsonandschemas/entities/organizational-unit.json: kebab-case enums retained (no consumer migration required).schemas/entities/capability.jsonandschemas/entities/process.json: no ECF fields added (F2 by-design).vocabulary/terminology-registry.yaml: pointer preserved per CR-CM-000A §14.metamodel.yaml,metamodel/dea-metamodel.yaml, schemas, viewer, pydantic, sqlite projection: no data-shape changes.
Implements ADR-015: capability kinds are specializations of an abstract root, not classifier entities, ECF coordinates, or compound typing.
dea:Capability: new abstract Core entity, aligned 1:1 withwsf:Capability(ADR-WSF-07). The only Core addition; concrete anchor count unchanged (CR-8 freeze holds).dea:SystemCapability,dea:InfrastructureCapability(technology profile) anddea:AIAugmentedCapability(ai profile): kind specializations per ADR-WSF-04 (parent meaning plus additional constraint).Capability.capability_layer: governed enumeration (strategic | operational | support) inschemas/entities/capability.json, registered inmetamodel/vocabularies/classifications.yaml(E005).mappings/wsf/mapping.yaml: WSF federation mapping with explicit confidence/lossiness:dea:Capability↔wsf:Capability(EXACT),dea:BusinessCapability↔odea:BusinessCapability(EXACT), kind specializations (HIGH/PARTIAL; kind flattens to context on the WSF side).
dea:BusinessCapabilitynow declaresSpecializes dea:Capability; the generic legacy aliasCapabilitymigrates to the root;dea:entity-capabilityremains.dea:specializessource/target type lists extended inmetamodel/dea-metamodel.yaml(registry regenerated in sync).
Capability.capability_type(business/technical/hybrid) deprecated in the schema: kind is now the entity type. Values preserved for backwards compatibility; catalog migration guidance deferred to a catalog-side CR.
metamodel/registry/entities.yaml,metamodel/registry/relationships.yaml,pydantic/,specification/,metamodel-puml/metamodel-v2.puml.
Closes the artifact-pointer gap left when PR #159 (schema hygiene) shipped
without updating metamodel/dea-metamodel.yaml. Three findings (U1, U2, U3)
were addressed in PR #159; this follow-up wires the metamodel yaml to the
specialization schema so the artifact block resolves correctly.
metamodel/dea-metamodel.yaml:dea:BusinessCapability.artifacts.json_schemanow resolves toschemas/entities/business-capability.json(wasschemas/entities/capability.json).metamodel/dea-metamodel.yaml:dea:BusinessCapability.artifacts.pydantic_modelnow resolves topydantic/business_capability.py(waspydantic/capability.py).sqlite_table(capabilities) andts_interface(typescript/src/interfaces.ts) unchanged; the existing table mapping and TypeScript surface continue to apply.
- No new schema or pydantic files in this PR; they shipped with PR #159.
- No consumer change;
dea-catalog-business-capabilitiesalready conforms via CR-DEA-BC-03 (catalog-side narrowing + the new specialization schema). change-requests/README.mdCR-MM-02 row updated to reflect implementation status (PR #159 schema hygiene + artifact-pointers follow-up).
Sixth and final Phase slice of CR-AM-11. The legacy v1-alpha maturity
catalog (Assessment-Models/dea-catalog-maturity-models) is recorded as
status: legacy in the assessment-registry; the migration plan shape is
documented; the fold-v2-in vs freeze-as-legacy decision itself is deferred
to CR-AM-01 Release 1 per CR-AM-11 §26 closing-action record. Specification
and metamodel remain 1.0.0.
assessment-models/governance/legacy-migration-plan.md— the migration plan shape. Covers scope, both Plan A (fold v2 in) and Plan B (freeze as legacy), what's already in place (Phases 0–5 footprint), and the Release-1 decision checklist.assessment-models/maturity/maturity-bands-v2.yaml— gainsid: dea:maturity-bands-v2andversion: "1.0.0"so future baseline registrations can reference it as amodelReference(this also unblocks a future CR-AM-09 §17 baseline test that wants to look it up by id rather than by file path).assessment-models/contracts/contract-suite.yaml— newlegacy_handlingblock recording thatstatus: legacy,status: deprecated, andstatus: supersededregistry records are exempt from the six §16 contract families by design. Consumers must checkstatusand route to the canonical replacement per the migration plan.
Assessment-Models/dea-catalog-maturity-modelsPR #3 — addsMIGRATION.mdpointing at the canonical plan; status remains legacy; catalog stays read-only at the Phase 1 commit pin.Assessment-Models/assessment-registryPR #2 — the legacy catalog record'snotesnow references the canonical migration plan.
contract-suite.yaml(Phase 2 slice 1 logic):OK — contract suite 1.0.0: 6 families, 34 schemas claimed (complete), all paths resolve, legacy_handling presentassessment-registryvalidator:OK — 2 registration record(s) validmaturity-bands-v2.yamlparses with id+version
Fifth Phase slice of CR-AM-11. The four composite dimensions referenced by the Digital Transformation composite model (CR-AM-11 §31 first-model candidate, merged PR #1) are now published as canonical registry entries for other consumers to import. Specification and metamodel remain 1.0.0.
Four new dimension-package entries in
assessment-models/maturity/components/registry.yaml:
dea:component-digital-culturev1.0.0 — leadership sponsorship, shared DT vocabulary, safe-to-fail experimentationdea:component-technology-adoptionv1.0.0 — reference architecture, automation coveragedea:component-operations-modernizationv1.0.0 — service-reliability, incident-response (the DT model adds two composite-specific dimensions consumer-scoped via kind=extend)dea:component-services-deliveryv1.0.0 — delivery-cadence baseline (the DT model overrides this with platform-engineering consumer-scoped via kind=override)
Each component lands as its own YAML in
assessment-models/maturity/component-examples/, following the existing
dimension-package shape (id + version + kind + published_by + content:
id:version pointers to the model's dimension artefacts).
The DT model's extend (operations-modernization) and override
(services-delivery) kinds remain consumer-scoped — they do not
modify the canonical registry entries. Other consumers importing the
canonical entries get the baseline unchanged.
- Registry YAML: 5 components, unique (id, version) pairs, all paths resolve, all parse
test_maturity_composition: 19/19 green
Third Phase slice of CR-AM-11. The OpenDEA Enterprise Architecture reference assessment instance — the first ecosystem participant and the canonical consumer of the published contract suite. Specification and metamodel remain 1.0.0.
assessment-models/maturity/scale-examples/opendea-enterprise-architecture.yaml— 5-level model-owned scale (L-0 Absent → L-1 Aware → L-2 Defined → L-3 Managed → L-4 Self-Optimising) with linear topology, exponential progression, per-leveleffort_multiplier(1.0x / 1.5x / 2.5x / 4.0x / 6.0x) documented at the model level, and digital-native naming (no CMMI-era vocabulary).assessment-models/maturity/evaluation-examples/opendea-enterprise-architecture.yaml— weighted 0–100 native-domain evaluation model with 6 criteria (framework-documentation, modelling-coverage, governance-cadence, tooling-integration, drift-and-conformance, ecosystem-contribution); each criterion carries per-level expectations covering L-0…L-4.assessment-models/maturity/baseline-examples/opendea-enterprise-architecture.yaml— Benchmark 2026 baseline; sha256-locked content_hash reproduces the snapshot block (levels + progression + ordering + conformance). References the canonical v2 band instance (dea:maturity-bands-v2 v1.0.0) and the matching evaluation_model.assessment-models/governance/reference-instance-opendea-ea.md— documentation: architecture, conformance declaration per the six §16 contract families, and Phase 3 exit criterion (a real instance demonstrating the maturity architecture).
test_maturity_scale.py::WorkedScaleValidationTest::test_opendea_ea_reference_instance_validatestest_maturity_evaluation.py::WorkedEvaluationValidationTest::test_opendea_ea_reference_evaluation_validatestest_maturity_baseline.py::OpenDEAEaReferenceBaselineTest(5 new tests)
All maturity suites green locally (69/69).
Second Phase 2 slice of CR-AM-11. Decision (Option C, user-directed): the CR-AM-11 §5 repository layout is the logical contract architecture, carried by the manifest and a map document — zero files move. Specification and metamodel remain 1.0.0.
assessment-models/contracts/logical-layout.md— the logical → physical map for the §5 layout, with the decision rationale (21 schemas referencecommon.schema.jsonvia sibling-relative$refs; physical relocation cost is all-rewrite, no behavioural gain) and the rule that physical extraction, if ever revisited, is a new CR.logical_layoutblock incontracts/contract-suite.yaml— the machine-readable form of the map; every physical path asserted to exist by CI.
validate-contract-suitejob extended: fails iflogical_layoutis missing or any mapped physical path does not resolve (negative-tested locally).
First Phase 2 slice of CR-AM-11 (Federated Assessment Model Ecosystem). Specification and metamodel remain 1.0.0; additive publication manifest + CI guard + governance doc, no canonical version bump.
assessment-models/contracts/contract-suite.yaml— the machine-readable publication of the six CR-AM-11 §16 contract families (assessment / maturity-model / maturity-scale / scoring / conformance / benchmark), each mapped to its landed artifacts per the Annex A inventory. All 34 schemas claimed by exactly one family.assessment-models/governance/contract-publication.md— the consumption contract: §15 handshake shape, immutable-pin rules, §17 compatibility declarations, versioning note, and the extraction boundary (physical relocation of contract artifacts lands as separate Phase 2 PRs; the manifest is the anti-drift guard for the extraction itself).
validate-contract-suitejob inci-assessment-models.yml: suite identity/version, exactly the six §16 families (attributed guard), every artifact path resolves, every schema Draft 2020-12, and complete schemas/ coverage (an unmapped schema fails CI).
assessment-models/README.mddirectory tree referenced a non-existent in-subtree.github/workflows/ci.yml; now points at the real repo-rootci-assessment-models.yml. Tree also gains thecontracts/entry.
Architectural proposal landing (docs-only; no schema, runtime, or vocabulary changes). Specification and metamodel remain 1.0.0.
change-requests/CR-AM-11.md— Federated Assessment Model Ecosystem: revives the Assessment-Models organization as the ecosystem authority (assessment-registry + assessment-ci + maturity-components + independently-versioned model/tool repositories) consuming versioned OpenDEA contracts from dea-metamodel, which remains the canonical engineering authority. Establishes the three-level CI model (local / contract-conformance / ecosystem), immutable version references, the contract inventory (Annex A), the contract-extraction & sub-tree-reduction pre-step (Phase 2), the initial legacy classification of the six existing org repositories (Phase 0), and the phased implementation sequence (Phases 0–6). Umbrella: CR-AM-01; depends on CR-AM-09/10; supersedes the retired dual-authority attempt (CR-014).
First implementation phase of CR-AM-10 (Maturity Component Composition & Reuse). Specification and metamodel remain 1.0.0; additive schemas + vocabularies + registry + worked examples, no canonical version bump.
assessment-models/schemas/maturity-component.schema.json— the versioned, independently-governed reuse package (CR-AM-10 §3): requiredid, version, metamodel_version, name, kind, published_by, status, content; content entries are id:version pointers into the publishing model's own artefacts (never inline content); CR-MM-01.1 governance fields (owner/steward/effective/review dates).assessment-models/schemas/component-reference.schema.json— the consumer-side typed reference (CR-AM-10 §4): mandatorykind(import/extend/override), id:version-pinned component, conditional payloads (import carries none; extend requires additions; override requires replaces + rationale). A kindless reference is refused — no silent inheritance.assessment-models/vocabulary/component-kinds.yaml+reference-kinds.yaml— controlled vocabularies (4 component kinds, 3 reference kinds).assessment-models/maturity/components/registry.yaml— the component registry; (id, version) uniqueness + registration-before- consumption guards.assessment-models/maturity/component-examples/— worked examples: Operations publishesoperations-service-dimensions.yaml(dimension-package); Digital Transformation consumes it viadt-imports-operations-dimensions.yaml(import) anddt-overrides-incident-response.yaml(override with rationale).
assessment-models/tests/conformance/test_maturity_composition.py— 19 tests: schema integrity, vocabulary/schema enum drift guards, worked-example validation, and boundary guards (kindless refused, import-with-payload refused, override-without-rationale refused, versionless component pin refused, registry uniqueness, registration coverage).- CI job
validate-maturity-componentsinci-assessment-models.yml— example validation + registry guards + vocabulary alignment, executed on every PR.
Proposal-only landing for CR-AM-10 (child of the CR-AM-01 umbrella). Specification and metamodel remain 1.0.0; no runtime, schema, or example changes — docs only.
change-requests/CR-AM-10.md— Maturity Component Composition & Reuse: versioned MaturityComponent packages (dimension / criterion / level-expectation / evidence-requirement), explicit reference kinds (import/extend/override— no silent inheritance), acyclic ChildModelReference composition resolving only through the composite's own CR-AM-09 scale, explicit collision reconciliation, and composite baselines that lock the resolved reference set. Driving use case: the Digital Transformation composite maturity model. Four-phase implementation roadmap; Phase 1 fixed as component identity + reference model.change-requests/README.md— CR-AM-10 row (status: Proposed).
change-requests/README.md— CR-AM-08 and CR-AM-09 rows updated from "Proposed" to "Implemented (all four phases; additive, no canonical version bump)"; both closed on main via PRs #135–#138 and #139–#142.
Final implementation phase of CR-AM-09. Specification and metamodel remain 1.0.0; additive schema + worked baseline + migration map + governance sections, no canonical version bump. After this PR lands, CR-AM-09 is closed: maturity scales are model-owned, versioned, benchmark-locked, and the existing v1/v2-beta content is mapped into the scale structure.
assessment-models/schemas/maturity-scale-baseline.schema.json— the immutable, benchmark-locked snapshot of the effective scale contract (CR-AM-09 §8): requiredid, version, status, scale, locked_at, content_hash, snapshot; the snapshot carries the full level definitions, the progression contract, and id+version references to the band set, resolution rule, and evaluation model.content_hashis sha256 over the canonical JSON of the snapshot — the reproducibility anchor; any mutation invalidates it.- Worked baseline
maturity/baseline-examples/proactive-operations-benchmark-2027.yaml— locks the Phase 1 alternate-naming scale + Phase 3 band set + resolution rule + Phase 2 evaluation model for "Benchmark 2027"; hash-verified. - Migration map
maturity/migration/v2-beta-to-scale-map.yaml— maps every CR-MM-01 v2-beta band exactly once into the scale structure with verbatim definitions (summary → definition), preserves the v1 legacy aliases from the existing v2-to-v1 name map, and carries the v2-beta effort multipliers (1.0 → 6.0) forward as the formalised superlinear-effort insight (linear topology, exponential function). Evolutionary, never re-authored (CR-AM-09 §11 constraint 6). - Governance —
assessment-models/governance/maturity-scales.mdgains §6a (baselines are immutable; the Benchmark Assessment Contract; historical reproducibility mandatory) and §6b (evolutionary migration discipline). - 19 conformance tests
(
assessment-models/tests/conformance/test_maturity_baseline.py) — schema integrity + lock/hash refusal; spec test 7 (content hash recomputes over the snapshot; mutation invalidates; snapshot levels and progression match the locked scale; band/resolution/evaluation references resolve to landed artifacts); spec test 8 (every v2-beta band maps exactly once; target definitions verbatim-equal to v2-beta summaries; legacy v1 names agree with the existing alias map; target ordinals strictly ascending; source ranges preserved; target scale declares linear/exponential); boundary guards (frozen CR-AM-06/07 surfaces untouched; no TRANSFORM keys). - CI — new
validate-maturity-baseline-against-schemajob;validate-yamlglob extended tomaturity/baseline-examples/andmaturity/migration/.
Third implementation phase of CR-AM-09. Specification and metamodel remain 1.0.0; additive schemas + vocabulary + worked examples, no canonical version bump.
assessment-models/schemas/progress-scoring-band.schema.json— the first-class scale component (CR-AM-09 §7): a band set document bound to a MaturityScale, each band resolving to a level id. Three families:numeric(min/max/inclusivity over the native domain),non-numeric(indicator/operator/value condition triples),multi-dimensional(dimension requirements + mandatory criteria + evidence requirements). Bands may gate onmandatory_criteria— the score alone is never sufficient.assessment-models/schemas/level-resolution-rule.schema.json— the seam between native scores and level attribution (CR-AM-09 §7): requiredid, version, scale, strategy, consumes, logic; optionalevaluation_modelandband_setreferences. Highest-conformant-level resolution is expressible — a level is attributed only when all lower-level prerequisites AND its own conditions hold.vocabulary/level-resolution-strategies.yaml— 5 strategies: highest-conformant-level / band-mapping / threshold-based / expert-review / custom. Schema enum ≡ vocabulary, asserted.- Worked examples under
maturity/resolution-examples/—proactive-operations-bands.yaml(numeric bands over the native 0–10 domain, contiguous with unambiguous boundary ownership, L3/L4 gated on the mandatoryevent-detectioncriterion + L4 evidence requirements — spec test 5: the score never implies the level) andproactive-operations-resolution.yaml(highest-conformant-level walk; consumes exactly the evaluation model's declared level_resolution_inputs). - 21 conformance tests
(
assessment-models/tests/conformance/test_progress_resolution.py) — schema integrity, three-family enum, strategy vocabulary parity, mandatory-field refusal, spec test 5 (high bands gate on mandatory criteria; L4 gates on evidence; mandatory criterion ids resolve in the Phase 2 evaluation model; rule consumes exactly the declared inputs; the highest-conformant walk is stated), band↔scale consistency (every band level resolves within the scale; every scale level has a band; numeric bands contiguous over the native domain with unambiguous boundary ownership), and boundary guards (no Phase 4 baseline vocabulary, no TRANSFORM keys, frozen CR-AM-06/07 surfaces untouched). - CI — new
validate-maturity-resolution-against-schemajob;validate-yamlglob extended tomaturity/resolution-examples/.
Second implementation phase of CR-AM-09. Specification and metamodel remain 1.0.0; additive schema + vocabularies + worked example, no canonical version bump.
assessment-models/schemas/maturity-evaluation-model.schema.json— the model-owned evaluation contract (CR-AM-09 §6): requiredid, version, name, scale, scoring, criteria; thescalereference binds the evaluation to its Phase 1 MaturityScale;scoringdeclares the native mechanism + domain (never normalized — a 0–10 native model stays 0–10 end to end);criteriacarry CriterionLevelExpectation (per-level behavior expectations, CR-AM-09 §4 — maturity is behavior, not merely a score), mandatory-gate flags, and evidence requirements;level_resolution_inputsdeclares what the Phase 3 LevelResolutionRule consumes.- Two controlled vocabularies —
scoring-mechanisms.yaml(9: weighted / threshold / criterion-satisfaction / mandatory-criterion / expert-assessment / evidence-based-classification / multi-factor / hybrid / custom) andscoring-domain-kinds.yaml(10: numeric-0-100, numeric-0-5, numeric-0-10, percentage, weighted-index, categorical, boolean-conformance, multi-dimensional-vector, rubric, custom). Schema enums ≡ vocabulary YAMLs, asserted both directions. - Worked example
assessment-models/maturity/evaluation-examples/proactive-operations-evaluation.yaml— a native 0–10 threshold-mechanism evaluation feeding the Phase 1 alternate-naming scale, with three criteria (one mandatory gate) and progressive level expectations per criterion (spec test 4: native 0–10 validates without normalization). - 22 conformance tests
(
assessment-models/tests/conformance/test_maturity_evaluation.py) — schema integrity + mandatory-field refusal (incl. normalization vocabulary structurally refused), mechanism/domain vocabulary parity (all 10 native domains present), spec test 4 (native 0–10 validates; domain bounds asserted), spec test 6 deepened (evaluation schema carries no topology/function fields — progression lives on the scale), criterion-level expectations resolve within the referenced scale (cross-artifact consistency), expectations demonstrate progression (≥ 3 levels per criterion), no-assumed-equal-unit-distance guard, and boundary guards (no Phase 3 resolution vocabulary, no TRANSFORM keys, frozen CR-AM-06/07 surfaces untouched). - CI — new
validate-maturity-evaluation-against-schemajob;validate-yamlglob extended tomaturity/evaluation-examples/.
First implementation phase of CR-AM-09 (proposal merged as PR #133). Specification and metamodel remain 1.0.0; additive schema + vocabularies + worked scale examples, no canonical version bump.
assessment-models/schemas/maturity-level.schema.json— the model-owned level shape (CR-AM-09 §8–§11): requiredid, ordinal, name, definition; optionalshort_description, characteristics, expected_practices, expected_capabilities, expected_behaviours, evidence_expectations, conformance_description. Identifier is structural; name and definition carry the model's semantics.assessment-models/schemas/maturity-scale.schema.json— the governed scale shape (CR-AM-09 §3–§7): requiredid, version, name, levels, ordering, progression;levelsrequires ≥ 2 entries; the scale declares its progression contract (topology + function as independent axes — the maturity-v2 effort-coefficient insight formalised at the schema level);conformancedeclares the per-result outcome vocabulary (5 statuses) and thehighest_conformant_level_resolutionflag (CR-AM-09 §26).- Three controlled vocabularies —
progression-topologies.yaml(linear / branching / gated / state-based / custom),progression-functions.yaml(linear / exponential / logarithmic / stepwise / threshold / custom),conformance-statuses.yaml(conformant / partially-conformant / non-conformant / indeterminate / not-assessable). Schema enums ≡ vocabulary YAMLs, asserted both directions. - Three worked scale examples under
assessment-models/maturity/scale-examples/— 5-level autonomous-operations (canonical naming, linear topology with exponential function — Test 1 + Test 6 of CR-AM-09 §35), 6-level linear-exponential (Test 2 — proves the metamodel supports 6+ levels), and a 5-level alternate-naming proactive-operations scale that breaks the autonomous-operations naming pattern (Test 3 — proves no canonical level naming is imposed). The conformance suite asserts the latter introduces distinguishing terminology and never reproduces the autonomous-operations naming pattern entirely. assessment-models/governance/maturity-scales.md— Phase 1 governance doc: identity rule (model, scale, level), topology ≠ function independence, levels carry explicit semantics, scoring bands/resolution/baseline locking deferred to Phases 3/4 (schema carries no pre-emption vocabulary), explicit conformance outcomes, Phase 1 acceptance checklist, boundaries vs CR-014/CR-MM-01, CR-AM-04/05A/06/07, CR-AM-10.- 22 conformance tests
(
assessment-models/tests/conformance/test_maturity_scale.py) — schema integrity + ≥ 2 levels enforcement + ordinals unique and ascending, level schema validation, three-way vocabulary parity (schema ↔ YAML), topology/function independence, spec tests 1/2/3/6 from CR-AM-09 §35, identity rule (L0 in scale A ≠ L0 in scale B even at the same ordinal),highest_conformant_level_resolutionexpressible, conformance-status vocabulary complete, and boundary guards (scale schema carries no scoring-band or resolution-rule vocabulary — Phase 3 additive discipline). - CI — new
validate-maturity-scale-against-schemajob;validate-yamlglob extended tomaturity/scale-examples/.
Final implementation phase of CR-AM-08. Specification and metamodel remain 1.0.0; additive schema + worked example + governance doc, no canonical version bump. After this PR lands, CR-AM-08 is closed: the interpretation layer is complete from AssessmentResult through ImprovementObjective, with the seam to the value-CR explicitly governed.
assessment-models/vocabulary/improvement-objective-priorities.yaml— 4 priorities:deferred,scheduled,active,monitoring.assessment-models/schemas/improvement-objective.schema.json— the governed seam from assessment interpretation to the value-CR (CR-AM-08 §9). Requiredid, version, status, target_state, evidence, priority, lineage;target_stateaccepts numeric scores (e.g.75 percent) or maturity-level identifiers (e.g.L4);evidencecites AssessmentInsights and AssessmentGaps by id + version;additionalProperties: falsethroughout — TRANSFORM-side keys (project,initiative,investment,roadmap,business_case,budget,kpi_target,value_realisation,program) are structurally refused.assessment-models/objectives/examples/automation-coverage-above-median.yaml— the worked objective that closes the Phase 1/2/3 chain: the benchmark-gap insight and assessment gap motivate a target of 75% automation coverage at priorityactive, with no initiative, project, program, investment, roadmap, or value figure attached — those belong to the value-CR, not the assessment metamodel.assessment-models/governance/insights.md— Phase 4 governance doc: three types never conflated (AssessmentInsight / AssessmentGap / ImprovementObjective), evidence as the only authority, confidence ≠ significance as independent axes, generation methods with AI never the authority, gap reference semantics explicit, objective = intent (action = value-CR), and a CR-AM-08 acceptance checklist.
- 17 conformance tests
(
assessment-models/tests/conformance/test_improvement_objective.py) — schema integrity + worked example + mandatory-field refusal; priority vocabulary parity; worked-chain closure (every cited AssessmentInsight + AssessmentGap resolves to a landed Phase 1/2/3 artifact);lineagemirrorsevidence; target state within natural magnitude (above cohort median, at/below cohort Q3); seam guards (TRANSFORM-side keys structurally refused even at the evidence-citation level; CR-AM-06/07 frozen surfaces untouched). - CI — new
validate-improvement-objective-against-schemajob;validate-yamlglob extended toobjectives/examples/.
Third implementation phase of CR-AM-08. Specification and metamodel remain 1.0.0; additive schema + vocabularies + examples, no canonical version bump.
assessment-models/vocabulary/gap-types.yaml— five explicit reference semantics: target-gap, benchmark-gap, trend-gap, threshold-gap, coverage-gap. Same numbers, different meanings: a gap number without a reference type is not canonical (CR-AM-08 §7).assessment-models/schemas/assessment-gap.schema.json— the governed gap shape: requiredid, version, status, type, subject, current, reference, difference, lineage;reference.kindenum drives the never-conflate rule;reference.sourcemandatory for benchmark-gap and trend-gap (citation discipline);differencecarries absolute (= current − reference) + optional relative_percent- direction (above/below/at).
additionalProperties: false— TRANSFORM vocabulary structurally refused.
- direction (above/below/at).
- Three worked examples under
assessment-models/gaps/examples/— one per primary family:benchmark-gap-automation-coverage.yaml(cites the CR-AM-07 comparison and the Phase 1/2 worked insight),target-gap-automation-maturity.yaml(current L3 vs declared L4 on the same capability),trend-gap-automation-maturity.yaml(L2 → L3, sources both states in lineage). - 18 conformance tests
(
assessment-models/tests/conformance/test_assessment_gap.py) — schema integrity, three-example landing check, every example validates, mandatory-field refusal, never-conflate guard (every example'sreference.kindpermitted for its declared type), source required for benchmark/trend gaps, difference arithmetic + direction consistency (current − reference = absolute; direction matches sign), cross-artifact lineage consistency (benchmark-gap cites landed comparison + insight; trend-gap sources include the previous-state result), and boundary guards (no TRANSFORM vocabulary; frozen CR-AM-06/07 surfaces untouched). - CI — new
validate-assessment-gap-against-schemajob;validate-yamlglob extended togaps/examples/.
Second implementation phase of CR-AM-08. Specification and metamodel remain 1.0.0; additive schema + runtime module, no canonical version bump.
assessment-models/schemas/insight-rule.schema.json— the governed mechanism that turns evidence into insight (CR-AM-08 §6):condition(evidence channel + metric + operator + threshold),result(insight type + significance + interpretation template with{value}/{threshold}/{peer_position}/{median}/{n}placeholders), and theconfidencecontract (level +minimum_population+ limitations). Phase 2 evidence channel:benchmark_comparisons(metrics percentile / rank / score).assessment-models/insights/rules/benchmark-below-median.yaml— the canonical worked rule; closes the Phase 1 worked insight'slineage.insight_rulereference (id + version + result type asserted by conformance).runtime/insights/—rules.py(structural validation with governed constant sets ≡ vocabulary YAMLs ≡ schema enums; invalid rules refused with every violation listed) andderive.py(derive_insightapplies a rule to a BenchmarkComparison for a subject member). Derivation contract: reproducible (same comparison + rule version + subject → same insight), evidence fidelity (cites exactly the comparison derived from — never invents or widens evidence), confidence enforcement (population below the rule'sminimum_population→ downgrade tolow+small-cohort-size), no match → no insight (never a fabricated negative statement), and ghost subjects (no standing) refused.- 20 conformance tests
(
assessment-models/tests/conformance/test_insight_rule.py) — schema integrity, worked-rule validation (schema + runtime), three-way vocabulary parity (YAML ↔ schema enum ↔ runtime constants), derivation through the real CR-AM-07 composer (schema-valid insight output, reproducibility, evidence fidelity, lineage rule identity, template substitution, confidence downgrade/hold, ghost-subject refusal, subject measure from the comparison axis), Phase-1 reference closure, and boundary guards (no TRANSFORM vocabulary; frozen CR-AM-06/07 surfaces untouched). - CI — new
validate-insight-rule-against-schemajob;validate-yamlglob extended toinsights/rules/.
First implementation phase of CR-AM-08 (proposal merged as PR #132). Specification and metamodel remain 1.0.0; additive schema + vocabularies + example, no canonical version bump.
assessment-models/schemas/assessment-insight.schema.json— governed, evidence-bound interpretation shape (CR-AM-08 §3): requiredid, version, status, type, subject, evidence, interpretation, confidence, generation, lineage. Evidence is mandatory and must cite ≥1 source artifact (results / views / comparisons); confidence (low/medium/high + optional coverage % + explicit limitations) is independent of significance; generation method is declared; lineage carries every cited artifact + the InsightRule reference when rule-generated + timestamp.additionalProperties: falsethroughout — TRANSFORM vocabulary (project/initiative/investment/recommendation/…) is structurally refused (CR-AM-08 §9).- Vocabularies —
insight-types.yaml(11 types; no domain-specific types),significance-levels.yaml(5 levels, independent axis),insight-generation-methods.yaml(rule / analyst / algorithm / ai-assisted — AI never the authority). - Worked example —
assessment-models/insights/examples/telecom-sa-2026-automation-coverage-gap.yaml— a benchmark-gap insight over the CR-AM-07 worked comparison (as-authored CR-AM-08 §27 scenario shape: 58% vs cohort median 72%). - 19 conformance tests
(
assessment-models/tests/conformance/test_assessment_insight.py) — schema integrity, worked-example validation, evidence/lineage/ interpretation mandatory-refusal cases, vocabulary↔enum parity both directions (×3 vocabularies), boundary guards (no TRANSFORM vocabulary in the schema; CR-AM-06/07 frozen surfaces untouched; comparison schema gains no insight terms), confidence≠significance axis independence, and cross-artifact consistency (example cites the landed comparison; lineage mirrors evidence; rule-generated insights carry rule id + version). - CI — new
validate-insight-against-schemajob;validate-yamlglob extended toinsights/examples/.
assessment-models/README.mdtree annotation repaired for CR-AM-07 landings (percentile-methods / ranking-rules / comparison-exclusion-reasons vocab rows, comparison-examples tree entry) and extended for CR-AM-08 Phase 1; schema-file total corrected to 23.
Proposal-only PR. Specification and metamodel remain 1.0.0; no schema, runtime, or example changes.
change-requests/CR-AM-09.md— the spec for model-owned maturity scales. The metamodel standardizes HOW maturity scales are represented; each maturity model defines WHAT maturity means:MaturityScale(2..* levels; identifiers structural, semantics explicit;levelCountderived),MaturityLevel(id + ordinal + name- definition; characteristics and criterion-level expectations),
ProgressionModel(topology ≠ function — linear/exponential/ logarithmic/stepwise/threshold/custom over linear/branching/gated/ state-based/custom), native model-owned evaluation and scoring (no universal 0–100),ProgressScoringBand(numeric, non-numeric, and multi-dimensional families),LevelResolutionRule(a score never implies a level without the model's resolution logic; highest-conformant-level expressible), explicitLevelConformance, and immutable benchmark-lockedMaturityScaleBaselinewith mandatory historical reproducibility. Supersedes the earlier composable-maturity CR-AM-09 concept; boundaries vs CR-014/CR-MM-01 (content migration), CR-AM-04/05A/06/07, and CR-AM-10 (reuse — future). Four-phase plan; Phase 1 fixed as scale + level-semantics vocabulary and schema only.
- definition; characteristics and criterion-level expectations),
change-requests/README.md— CR-AM-09 row (status: Proposed).README.md— rationale-table row for CR-AM-09.
Proposal-only PR. Specification and metamodel remain 1.0.0; no schema, runtime, or example changes.
change-requests/CR-AM-08.md— the spec for the interpretation layer above the completed evidence chain (AssessmentResult → AssessmentView / BenchmarkEligibility → BenchmarkCohort → BenchmarkComparison). Canonical concepts:AssessmentInsight(evidence mandatory; confidence independent of significance; versioned lineage; declared generation method — rule / analyst / algorithm / ai-assisted, with AI never the authority),InsightRule(governed, reproducible derivation — never hard-coded interpretation),AssessmentGap(five explicit reference types — target / benchmark / trend / threshold / coverage — never conflated), andImprovementObjectiveas the semantic hand-off (actions, projects, investments, roadmaps, and value realization deliberately excluded — TRANSFORM stays outside the assessment metamodel). Reconciles with the CR-AM-07 comparison-policy hand-off contract and picks up the deferred-scope items designated there (gap analysis, comparison confidence, metric direction). Boundaries table vs CR-AM-04/05/06/07, CR-012, and the future value-traceability CR (deliberately de-numbered: CR-AM-09 is Maturity Scale, Progression & Conformance Architecture). Four-phase plan; Phase 1 fixed as vocabulary + schema only.change-requests/README.md— CR-AM-08 row (status: Proposed).README.md— rationale-table row for CR-AM-08.
Follow-up slice of CR-CM-001 (terminology registry migration to
technehub-labs/dea-concepts-model). Specification and metamodel remain
1.0.0; no canonical version bump.
vocabulary/terminology-registry.yaml— the interim canonical registry (CR-CM-000 / CR-CM-000A §14) is replaced by a governed pointer to the canonical home (technehub-labs/dea-concepts-model · governance/terminology-registry.yaml, v1.1.0,homed_by: CR-CM-001). All content blocks (terms, verbs, prohibitions, Concept Areas, artifacts, rules, planned-repository mandate) now live solely in the canonical home — two diverging copies are exactly the failure the migration exists to prevent.tests/conformance/test_015_terminology_registry.py— rewritten from registry-content conformance to pointer integrity: canonical home declaration, non-canonical local status, full provenance (introduced/extended/homed), version parity, and a drift guard that fails if any content block reappears locally. Landed-spec guards (CR-CM-000/000A verbatim) and the bare-domain:forward guard are unchanged. Registry content conformance is owned by the canonical home, whosetools/validate.pyexercises the vocabulary against every concept file (proven 11/11 violation classes at foundation).docs/concepts/terminology-alignment.md,README.md,change-requests/README.md— registry references updated to the canonical home + local pointer.
Final implementation phase of CR-AM-07. Specification and metamodel remain 1.0.0; additive surfacing + governance, no canonical version bump.
runtime/comparison/report.py—render_text/render_jsonsurface aBenchmarkComparisondocument as a human-readable report or canonical JSON. The report is a view over the derived artifact (CR-AM-07 §3): it renders exactly the schema-declared fields, in deterministic order (standings sorted by rank, JSON with sorted keys), and carries no CR-AM-08 vocabulary — insight, narrative, trend, and recommendation remain parked. CLI:python -m runtime.comparison.report <comparison.yaml> [--format text|json].assessment-models/governance/comparison-policy.md— the comparison policy: eight policy rules (derived-never-truth, eligibility-only-door, minimum-sample gate, missing-data-N/A, declared methods, ties share standing, one cohort one snapshot, additive schema evolution), the Phase 4 surfacing contract, and the CR-AM-08 hand-off (what the insight layer consumes, may rely on, owns, and is never handed).- 13 conformance tests
(
assessment-models/tests/conformance/test_comparison_report.py) — header/cohort identity, distribution block, rank-ordered standings, tie semantics (shared rank 15, competition skip of 16), derivation hashes, determinism, JSON round-trip, schema-declared keys only, CR-AM-08 vocabulary guard, and CLI behaviour. - CI — new
validate-cr-am-07-phase-4job runs the report conformance suite.
change-requests/CR-AM-07.mdstatus → Implemented (all four phases).change-requests/README.mdCR-AM-07 row → Implemented.
Documentation-only follow-up to CR-AM-07. Specification and metamodel remain 1.0.0; no schema, runtime, or example changes.
assessment-models/governance/comparison-policy.md— new "Deferred scope from the as-authored proposal (decision record)" section: preserves the eight statistical-semantics decisions from the original CR-AM-07 proposal that the four landed phases consciously narrowed (percentile ≠ absolute attainment, measurement-scale constraints, score-vs-maturity separation, metric direction, gap analysis, comparison confidence, multi-cohort participation, versioned benchmark metrics), with rationale and where each deferred item lands (CR-AM-08, extension phase, or a future metric-registry CR).assessment-models/README.mdgovernance-tree annotation updated to point at the decision record.
Third implementation phase of CR-AM-07. Specification and metamodel remain 1.0.0; additive runtime module, no canonical version bump.
runtime/comparison/standings.py—StandingsEnginecomputes per-member percentile, rank, and peer position (4/27) over admitted members. Governed enumsPercentileMethod(inclusive / exclusive) andRankingRule(competition / dense), values ≡ the Phase 1 vocabularies. Ties share percentile and rank; competition ranking skips after a tie, dense does not. Admission guard, minimum-sample enforcement, and exclusion semantics are inherited from the Phase 2 distribution engine.runtime/comparison/compose.py—compose_comparisonis the only path that assembles a complete, schema-validBenchmarkComparisondocument: distribution and standings derived together from the same member input over the same cohort snapshot, with membership hash and reproducibility hash (CR-AM-07 §10, §13).- 17 conformance tests
(
assessment-models/tests/conformance/test_comparison_standings.py) — worked-example regression (all 27 standings + hashes reproduced exactly), tie semantics under both ranking rules, both percentile methods, boundary guards, and composed-document schema validation.
Second implementation phase of CR-AM-07. Specification and metamodel remain 1.0.0; additive runtime module, no canonical version bump.
runtime/comparison/engine.py—DistributionEngine.computederives cohort statistics (n, min/q1/median/q3/max, mean, sample standard deviation, IQR) over admitted members on the comparison axis. Exclusive median-of-halves quartiles; sha256 reproducibility hash over the canonically sorted score multiset. Emits distribution + exclusions only — percentile/rank/peer position remain Phase 3 (CR-AM-07 §11).- Enforced by construction (CR-AM-07 §10): non-admitted members
raise
ComparisonError(eligibility is the only door); distributions below the cohortminimum_sample_sizeare refused, never silently emitted; members with missing/non-numeric scores are excluded with explicit machine-actionable reasons — never imputed (missing data is N/A, not zero). vocabulary/comparison-exclusion-reasons.yaml— governed reasons (score-missing-on-comparison-axis,score-not-numeric).- 18 conformance tests
(
assessment-models/tests/conformance/test_comparison_distribution.py), including the regression pin that the engine reproduces the Phase 1 worked example's distribution and reproducibility hash exactly.
First implementation phase of CR-AM-07. Specification and metamodel remain 1.0.0; sub-tree additive, no canonical version bump. Phase 1 ships the comparison contract only — no distribution engine (Phase 2) or percentile/ranking engine (Phase 3).
assessment-models/schemas/benchmark-comparison.schema.json— a BenchmarkComparison binds a cohort snapshot (membership hash), the comparability key inherited verbatim from CR-AM-06, a single declared comparison axis, distribution statistics (n, quartiles, mean, spread), per-member standings (score, percentile, rank, peer position4/27), and full derivation metadata (percentile method, ranking rule, minimum-sample enforcement, excluded members with explicit reasons, reproducibility hash). The schema carries no eligibility or membership rules — CR-AM-06's surface is consumed, never redefined (CR-AM-07 §8).vocabulary/percentile-methods.yaml—inclusive/exclusive, with formulas; tied members always share a percentile.vocabulary/ranking-rules.yaml—competition(1,2,2,4) /dense(1,2,2,3); ties share the best rank.benchmark/comparison-examples/telecom-service-assurance-2026-comparison.yaml— the CR-AM-06 §10 worked shape made canonical over the §6 worked cohort: 27 members, org-a at score 82 → percentile 88.5 → peer position 4/27 (percentile under the declaredinclusivemethod; §10's "87" was an illustrative shape), with an exercised tie at score 70.- 16 conformance tests
(
assessment-models/tests/conformance/test_benchmark_comparison.py) — schema/example validity, vocabulary ↔ enum parity, tie and ranking-rule semantics, minimum-sample enforcement, comparability-key inheritance, and the CR-AM-06/CR-AM-08 boundary guards. - CI:
ci-assessment-models.ymlgains avalidate-comparison-against-schemajob; the YAML-parse glob now coversbenchmark/comparison-examples/.
Spec-only proposal for the CR-AM series successor to CR-AM-06. Specification and metamodel remain 1.0.0; no runtime, schema, or example changes.
change-requests/CR-AM-07.md— definesBenchmarkComparisonas a reproducible derivation over an admitted BenchmarkCohort: cohort distribution, percentile semantics, peer ranking & peer position, and the CR-AM-08 insight hand-off. Consumes CR-AM-06 eligibility without redefining it (§8 boundaries). Four-phase implementation plan (§11): vocabulary & schema → distribution engine → percentile & ranking → integration & governance.
Extension to CR-CM-000, landed before the Concepts Model repository exists (CR-CM-001). Specification and metamodel remain 1.0.0.
change-requests/CR-CM-000A.md— the extension, landed verbatim (md55d2283edffd9ee2a7ccda015589017c2).vocabulary/terminology-registry.yamlextended with: the §7 canonical vocabulary (11 terms across MetaFramework / Concepts Model / Metamodel / Catalog layers, each with namespace/status/owner); the §9 conceptual relationship verbs (has-ecf-context,uses-domain,uses-stage,belongs-to,includes,maps-to— withmaps-toexplicitly distinct from inheritance); the §10 prohibited semantics (baredomain:attribute, Concept-Area-as-Domain, Profile-as-Domain, implicit metamodel typing); the §11 nine initial Concept Areas; and the mandateddea-concepts-modelrepository layout (concept-areas/, neverdomains/; registry's long-term homegovernance/terminology-registry.yaml).docs/concepts/terminology-alignment.md— new §7 covering the extension.- 10 new conformance tests in
tests/conformance/test_015_terminology_registry.pycovering every supplement section. - Companion document lands in
dea-metaframework:docs/terminology/concepts-model-alignment.md(CR-CM-000A §16).
First CR of the Concepts Model (CM) series. Specification and metamodel remain 1.0.0; this CR is terminology governance only — no schema, runtime, or version changes.
vocabulary/terminology-registry.yaml— the authoritative terminology registry, introduced before the first canonical Concepts Model (CR-CM-000 AC-7). Bounds the five artifacts (Enterprise Concept Framework, OpenDEA Concepts Model, OpenDEA Foundational Metamodel, Catalogs, Profiles), reserves Domain/Stage for the ECF (every use must be ECF Domain/ECF Stage or namespace-qualified), and introduces the Concepts Model vocabulary: Concept Area (many-to-many membership), Concept Profile, Concept Classification, and ECF Context (zero-or-more; association, not identity — Concept Area ≠ ECF Domain, no automatic 1:1 mapping).docs/concepts/terminology-alignment.md— KB note capturing the CR's decisions, the five artifact boundaries, and the non-identity principle.tests/conformance/test_015_terminology_registry.py— 9 conformance tests covering registry integrity, reserved-term ownership, Concepts Model term constraints (AC-1…AC-7), and a forward guard against baredomain:fields in future Concepts Model artifacts.change-requests/CR-CM-000.md— the CR, landed verbatim (md52ec1e5c4539835f9b971ae7042280450).
Eighth and final phase of CR-11. Specification and metamodel remain
1.0.0; this phase realises the public conformance surface
(CR-11AM), conformance test suite (CR-11AN), and golden
interoperability datasets (CR-11AO). The OpenDEA CLI gains an
opendea-conformance entry point that emits a typed report.
ConformanceClassextended with the six CR-11AM interoperability classes:Exchange,Identity,Mapping,Runtime(CR-11AM's "Runtime" side — encoded internally asMAPPING_RUNTIMEto avoid clashing with the runtime's own usage of the word),Federation,Agentic. Adding a class is a contract change; the seven CR-9 classes remain unchanged.ConformanceReport.render_text+render_jsonproduce typed reports — the public CR-11AN contract includesconformanceVersion,runtimeVersion,specVersion, stable alphabeticalclassesCovered, and per-suite declarations.runtime.conformance.runnerships a default interop-roundtrip suite (Exchange / Identity / Mapping / Provenance / Federation) and anopendea-conformanceCLI bound to it viapython -m runtime.conformance.runnerwith--format {text,json}+--runtime-version+--spec-version--include-golden.
models/golden/basic-enterprise.yaml— the smallest conformance-valid OpenDEA graph (7 nodes / 5 edges across organisational, capability, application, service, actor, stakeholder- data dimensions). Validates against the canonical registry at load.
golden_graph_assertions(basic-enterprise)regression baseline added;test_model_loader.py+test_014_specification_rules.pygolden-suite count update from 7 → 8.- 13 new runtime tests (384 total in
tests/runtime/).
Seventh phase of CR-11. Specification and metamodel remain 1.0.0; this phase realises the bounded federation shape from CR-11AH/AI/AJ + the CR-11AK boundary rule ("Do not implement a universal federation engine"). Federation delivers entity-locality labelling, a structured reference shape, and a query-dispatch facade that can answer with local + remote sources under three explicit strategies — never silently.
EntityLocality(re-export) — the five canonical states (LOCAL / FEDERATED / IMPORTED / DERIVED / VIRTUAL) CR-11AI mandates.FederatedReference— system + adapter + external identifier + schema version; rejects incomplete references at construction.FederatedQuery— typed dispatch request with declared sources, authority policy name, and one of three strategies.AuthorityContext— the slice of the resolved AuthorityPolicy affecting one query; recorded on every result, never invented.FederationView.dispatch+FederationView.resolve_reference— the single entry point for bounded federation dispatch.SourceResolver+InGraphResolverpluggable resolvers; the in-graph resolver matches by entity id foropendeaand by (system, external_identifier) for remote systems.RemoteSource+QueryAdapter+DirectQueryAdapter— the adapter shape: declare sources, run the chosen adapter, never invent identifiers the remote system did not return.ResolutionStrategy— IN_GRAPH_FIRST / SOURCE_PRIORITY / MERGED, declared by the caller; the dispatcher never re-orders silently (CR-11AK boundary).- 13 new runtime tests (370 total in
tests/runtime/).
Sixth phase of CR-11. Specification and metamodel remain 1.0.0; this phase wraps the CR-9H/I canonical event envelope with a schema-first JSON contract (CR-11AF) and an end-to-end external-event → knowledge-update pipeline (CR-11AG).
EVENT_JSON_SCHEMA+event_json_schema()+validate_envelope(): Draft-07 contract for the canonical envelope.additionalPropertiesisfalse, the event-type taxonomy matches the CR-9H enum, and the optionalprovenancebag mirrors the CR-11S/T/U Exchange envelope so consumers can audit and reconcile events with no extra translation step.EventPublicationService.publishis the only path that turns a runtime mutation into a canonical event. The service validates every payload at the boundary and refuses to publish invalid envelopes.EventPipeline.ingestruns the full CR-11AG flow:External Event → Adapter → OpenDEA Event → Knowledge Update → Rules → Assessment → Agent/Decision, with pluggable hooks for rules, assessment and agent stages plus a knowledge-update applier for the four entity-/relationship-mutating event types.PassthroughAdaptervalidates an envelope as-is; subclasses can lift any external wire format into the canonical shape.derive_updates(event)maps ENTITY_CREATED / ENTITY_CHANGED / ENTITY_DELETED / RELATIONSHIP_CHANGED toKnowledgeUpdatehints; the other event types pass through so downstream stages can react.- 14 new runtime tests (357 total in
tests/runtime/).
Fifth phase of CR-11. Specification and metamodel remain 1.0.0; Phase 5 lands canonical mappings from OpenDEA into the four most relevant EA-domain standards — ArchiMate, BPMN, DMN, DMM — in that order. Mappings are informative bridges: OpenDEA never adopts the external metamodel (CR-11W); standards-specific concepts without an OpenDEA counterpart are recorded as Extensions in the standard's own namespace (CR-11AR), never absorbed into the core.
mappings/archimate/mapping.yaml— CR-11X extends the CR-8 §45 matrix with explicit relationship classes, confidence/lossiness on every entry, and the document rule that composite/approximate alignments are marked, never smoothed over.mappings/bpmn/mapping.yaml(new) — CR-11Y: Process / Task / Sub-Process / Event / Gateway mapping to OpenDEA's BusinessProcess/Workflow/Task/TemporalEvent/DecisionCriterion shapes.mappings/dmn/mapping.yaml(new) — CR-11Z: the DMN profile shape (Decision → Decision → Decision Evidence → Decision Outcome) plus FEEL preservation (rule-expression kind:dmn-feel).mappings/dmm/mapping.yaml(new) — Phase 5 DMM band correspondence: DMM Level 1–5 ↔ OpenDEA maturity v2 Emergent/Structured/Systematic/Adaptive/Self-Optimising.MappingRegistry+load_reference_mappingslifts the YAML files into an :class:InteropRegistrywith governed mappings, confidence + lossiness, and an Extension fallback for unmapped concepts. 8 new runtime tests (343 total intests/runtime/).
Closes two alignment gaps surfaced by the post-CR-MM-01 / CR-AM-01 compliance audit on 2026-08-21:
scored-by-v2-bandsregistered inassessment-models/vocabulary/relationship-types.yaml(CR-MM-01 introduced this relationship type but did not register it; CI did not catch it).- CR-AM-01 §42 governance fields added to 5 v2-beta maturity models and the 2 Phase A registry
artefacts:
steward,effective_date: 2026-08-21(or2026-08-20for Phase A),review_date: 2027-02-21(or2027-02-20).
assessment-models/vocabulary/relationship-types.yaml: new entryscored-by-v2-bands(source_kinds: maturity-model, target_kinds: maturity-bands).assessment-models/maturity/v2-beta/{ea-capability,modernization,technology,operations,services-delivery}.yaml: each gainssteward,effective_date,review_date.assessment-models/maturity/maturity-bands-v2.yamlandv2-to-v1-legacy-name-map.yaml: each gainsowner,steward,effective_date,review_date..github/workflows/ci-assessment-models.yml: new CI jobvalidate-relationship-vocabularyasserts everyrelationship_typevalue inmaturity/*,maturity/v2-beta/*,maturity/examples/*,examples/*is registered in the controlled vocabulary.
- None. This is metadata-only. All v2-beta maturity model content (characteristics, exit criteria, evidence) is unchanged from CR-MM-01. All v1 → v2 scoring logic is unchanged. Phase C consumer tooling remains parked for CR-MM-02.
See CR-MM-01.1.
Fourth phase of CR-11. Specification and metamodel remain 1.0.0; this phase extends the CR-9.2 / CR-11 Phase 1–3 internal provenance graph with the external source chain so every canonical fact remains traceable back to where it came from, and exposes a PROV-shaped projection so the chain is interoperable with established provenance vocabularies.
ExternalProvenanceService.record_external_sourceregisters an Evidence + Source pair atomically with its ExternalIdentifier correlation in the InteropRegistry (CR-11O).ExternalProvenanceService.integration_chainwalks OpenDEA Entity → Assertion → Evidence → Mapping → Adapter → ExternalIdentifier → External System (CR-11BD).prov_projectionexposes any Assertion as PROV-style Entity / Activity / Agent / Source (CR-11AE).- 5 new runtime tests (335 total in
tests/runtime/).
A new assessment-models/maturity/v2-beta/ directory lands five YAML files
— one per canonical maturity domain — that mirror the v1-alpha originals
in Assessment-Models/dea-catalog-maturity-models (archived) but use v2
level ids, names, score ranges, and legacy_name aliases, plus a new
per-level effort_multiplier.
ea-capability.yaml— domain: enterprise-architecturemodernization.yaml— domain: modernizationtechnology.yaml— domain: technologyoperations.yaml— domain: operationsservices-delivery.yaml— domain: services-delivery- Each carries
status: beta,score_scheme: dea-maturity-v2,band_reference: ../maturity-bands-v2.yaml,legacy_model: ../v2-to-v1-legacy-name-map.yaml. - Content fidelity: every level's
summary,characteristics,exit_criteria,evidenceis preserved byte-identically from v1-alpha.
- New job
validate-v2-beta-modelsin.github/workflows/ci-assessment-models.ymlasserts:- exact 5-file count and complete coverage of the five domains
- every level's
id/name/score_range/effort_multipliermatches the canonicalmaturity-bands-v2.yaml - every level's
legacy_nameround-trips throughv2-to-v1-legacy-name-map.yaml - every level has non-empty
summary,characteristics,exit_criteria,evidence
validate-yamlglob extended to includeassessment-models/maturity/v2-beta/*.yaml.
Specification and metamodel remain 1.0.0 — no canonical VERSION bump. See CR-MM-01.
Documentation-only reciprocal cross-link between
metamodel/profiles/assessment/profile.yaml and assessment-models/.
Closes the integration story left open by CR-014 §3 (explicitly out of scope
for CR-014 itself).
metamodel/profiles/assessment/profile.yamlgains across_references:block pointing atassessment-models/(kind: internal-sub-tree, relation: integrates_with, canonical_url anchor).assessment-models/README.mdgains a### Upstream profilesubsection pointing back at the profile and stating the layering convention.
Specification and metamodel remain 1.0.0 — no canonical version bump. See CR-015.
Third phase of CR-11. Specification and metamodel remain 1.0.0; the canonical exchange envelope is now validated against an explicit JSON Schema and round-trips through import/export with ExternalIdentifier links.
EXCHANGE_JSON_SCHEMA+exchange_json_schema()for the canonical Exchange envelope.ExchangeService.export_graphproduces an Exchange from any GraphStore.ExchangeService.import_exchangematerialises entities, edges and external-identifier links from an Exchange.ExchangeService.validateruns schema + semantic checks.- 6 new runtime tests (205 total in
tests/runtime/).
Final phase of CR-10. Specification and metamodel remain 1.0.0; the runtime supports observation, operational state, and drift detection against the architecture baseline. The full "digital twin" claim remains deferred until synchronization and behavioral semantics exist (CR-013).
DigitalTwin.observe(subject, observed_state, at)records an observation as both an in-memory event and a graphObservationnode traced from the subject.current_state(subject)returns the latestOperationalState.state_diff(subject)compares architecture lifecycle against observed state, returning explicit drift signals.- 6 new runtime tests (199 total in
tests/runtime/).
Sixth phase of CR-10. Specification and metamodel remain 1.0.0; agentic scenario generation produces candidates that close a maturity gap, with humans retained in the approval loop.
ScenarioProposer.propose_scenarios_for_gap(gap_id)returns aScenarioProposalReportwith candidate scenarios, impact summaries and a recommendation that is never approved by default (CR-9CR).- Candidates are evaluated against the CR-10 Phase 5 simulation adapter.
- 5 new runtime tests (193 total in
tests/runtime/).
Fifth phase of CR-10. Specification and metamodel remain 1.0.0;
the runtime is the semantic coordination layer; domain simulators live behind
SimulationAdapter.
SimulationAdapterABC withprepare / execute / retrieve_results / map_results / validatelifecycle.ScenarioImpactAdapterreference implementation that runs the CR-10 Phase 2 impact engine locally.SimulationRegistrydispatches by capability.SimulationRequest/PreparedRequest/ExecutedRun/SimulationResult/MappedResultvalue objects preserve engine contract, model version, parameters and assumptions.- 6 new runtime tests (188 total in
tests/runtime/).
Fourth phase of CR-10. Specification and metamodel remain 1.0.0; maturity projection is the gap-to-initiative transition layer.
MaturityProjector.project(gap_id)returns aMaturityProjectionwith current/target/projected maturity and proposed initiative ids.- Projects the maturity gap forward using the available ChangeInitiative candidates in the graph.
- 6 new runtime tests (182 total in
tests/runtime/).
Final tenth milestone of CR-9. Specification and metamodel remain 1.0.0; the Explorer exposes the runtime through the seven-module API surface.
- enum with the seven modes (explore / assess / trace / compare / query / simulate / govern).
- wrap the underlying runtime services.
- exposes conclusion → evidence → source provenance.
- 8 new runtime tests (176 total in ).
Eighth milestone of CR-9. Specification and metamodel remain 1.0.0; the agent runtime is the governance surface for discovery, authority, policy, audit and tool registry.
AgentRuntime.request_authorizationreturns ALLOW / DENY / ESCALATE driven byPolicynodes carryingaction,effectand optionalactor_role.audit_logrecords every decision with agent, action, target, effect, policy reference and timestamp.ToolRegistrymaintains aprovides -> capabilitymapping and supports agent → tool binding.- 7 new runtime tests (168 total in
tests/runtime/).
Seventh milestone of CR-9. Specification and metamodel remain 1.0.0; the decision & impact engine is an executable governance layer over runtime decisions, gaps and outcome proposals.
DecisionImpactEngine.evaluate_decisionagainst the live graph: targeted outcomes, addressed gaps, dependency paths.dependency_pathsBFS through active edges (statusdeprecated/retiredexcluded) returning explicit node + edge sequences.propose_initiativeswritesOutcomenodes into the graph with explicitresults-inauthorship from the decision; duplicate ids are skipped.- DecisionError for unknown / non-Decision nodes.
- 5 new runtime tests (161 total in
tests/runtime/).
Sixth milestone of CR-9. Specification and metamodel remain 1.0.0; assessment is the executability layer for the CR-5 assessment profile.
AssessmentService.execute_assessmentwalks the assessment graph, aggregates measures, applies the scoring strategy and maturity mapping, and persists anAssessmentResultwith full provenance.- AssessmentGap recorded automatically when current maturity is below
target_maturity. - Golden DMM executable fixture:
models/dmm/executable.yaml. - 5 new runtime tests (156 total in
tests/runtime/).
Fifth milestone of CR-9 (Runtime, Knowledge Graph & Interoperability). Specification and metamodel remain 1.0.0; integration is additive runtime machinery over the CR-9.1 graph and the CR-11 interop foundation.
IntegrationService.run_full_import/run_incremental_importmaterialise ExternalSystem payloads as OpenDEA entities with source metadata and ExternalIdentifier links.- Source metadata on every imported entity:
sourceSystem,sourceTag,sourceRecordare recorded on the node's properties and thesourceenvelope. - Conflict preservation: when an incremental import disagrees with an
existing entity's
lifecycle_stateorclassification, the disagreement is recorded as aKnowledgeConflictrather than silently overwritten. - 5 new runtime tests (146 total in
tests/runtime/).
Second half of CR-9.10 (Conformance & Interoperability Release). Specification and metamodel remain 1.0.0.
- Interop scenarios (CR-9CM): three end-to-end scenarios — external-id correlation, reasoning materialization, full scenario impact pipeline — spanning the CR-9.2 provenance, CR-9.3 reasoning, CR-10 scenario, and CR-11 interop layers.
- Performance suite (CR-9CJ/CK): synthetic 1K / 10K enterprise models exercising load + query + traversal against the reference in-memory store with explicit engineering-target budgets.
- Conformance class coverage: the interop suite covers API, Validation, Provenance; the performance suite covers Query.
- 6 new runtime tests (146 total in
tests/runtime/).
First half of CR-9.10 (Conformance & Interoperability Release). Specification and metamodel remain 1.0.0; conformance is the audit surface for the runtime programme.
- Runtime conformance classes (CR-9CL): the seven classes — Core, Profile,
API, Query, Validation, Provenance, Security — are declared explicitly
(
ConformanceClassenum) and cannot be silently extended. - Excluded endpoints audit:
EXCLUDED_ENDPOINTSdocuments which runtime surfaces the public suite deliberately does not exercise, includingstore.inferand any future autonomous-mutation endpoints. - Golden graphs (CR-9CN):
GOLDEN_GRAPHSreuses the existing canonical fixtures (models/golden/{enterprise,dmm}.yaml,models/scenarios/customer-service-baseline.yaml) and asserts expected node/edge counts and loadability. - Conformance runner:
run_conformance(suites)produces aConformanceReportwith the aggregated set of conformance classes covered by the suite catalog. - 5 new runtime tests (140 total in
tests/runtime/).
Fourth milestone of CR-9 (Runtime, Knowledge Graph & Interoperability). Specification and metamodel remain 1.0.0; the temporal/event runtime is additive on the CR-9.1 graph and the CR-9.2 provenance layer.
- Bitemporal truth (CR-9G):
as_of(valid_at, recorded_at=None)answers "what was true at valid_at, as we knew it at recorded_at" using the edgerecorded_atproperty alongsidevalid_from/valid_to. - Current-time filter (CR-9F):
what_is_true_now(store, entity_id)returns only neighbours whose edges are currently valid and non-retired / non-planned. - Event envelope (CR-9H):
Eventcarries id, type, subject, occurredAt, observedAt, source, version, payload and the canonical EventType taxonomy. - Event log (CR-9I):
EventLogis append-only and exposesfilter(subject, type). - Snapshots and drift (CR-9BI/BD/BE):
snapshot_graph(store, id, label)freezes any GraphStore;diff_snapshots(before, after)reports added/removed/modified entities and edges. - 8 new runtime tests (135 total in
tests/runtime/).
Third phase of CR-10 (Scenario, Simulation, Digital Twin & Strategic Decision Intelligence). Specification and metamodel remain 1.0.0; decision intelligence is additive runtime machinery over Phases 1–2.
- Metrics as semantic objects (CR-10J): id, definition, unit, calculation, source, baseline and target.
- Explicit criteria and weights (CR-10M):
Criterionrequires a visible non-zero weight; no weights are hidden in algorithms. - Decomposable scoring (CR-10N): every
ScenarioScoreexposes criterion value, normalized weight and weighted contribution. - Comparison and ranking (CR-10F/L): deterministic scenario ordering by weighted score with stable tie-breaking.
- Recommendation ≠ decision (CR-10AI):
Recommendation.approved_decisionis always false; approval remains governed decision machinery. - Explainable recommendation (CR-10AL): rationale, criteria, weights, evidence and assumptions are returned with the recommendation.
- 6 new runtime tests (127 total in
tests/runtime/).
Third milestone of CR-9 (Runtime, Knowledge Graph & Interoperability). Specification and metamodel remain 1.0.0; reasoning is additive runtime machinery over the CR-9.1 graph and CR-9.2 provenance layer.
- Governed rule registry (CR-9S): rules carry id, name, version,
enabled/disabled state, profile scope, severity, declared
applies_toscope and executable condition. Duplicate or out-of-scope derivations are rejected. - Levelled inference (CR-9R): Deterministic, Ontological, Graph,
Probabilistic and Generative levels are explicit and recorded on every
Inference; levels are never blended. - Evaluation ≠ materialization (CR-9CQ):
ReasoningEngine.infer()derives candidate conclusions without mutating the graph.materialize()is an explicit second step that records the result as a PROPOSED assertion via the CR-9.2 provenance layer — never as approved fact. - Explainability (CR-9T): every inference records rule, level, supporting
inputs, explanation steps and confidence;
explain()returns the structured Why chain. - 7 new runtime tests (121 total in
tests/runtime/).
Second phase of CR-11 (Interoperability, Federation & Ecosystem Conformance). Specification and metamodel remain 1.0.0; identity reconciliation is additive runtime machinery over the Phase-1 interoperability foundation.
- EntityResolution with the full reconciliation-state vocabulary
(CR-11K/L):
UNMATCHED,CANDIDATE,MATCHED,MERGED,CONFLICTING,REJECTED. Thresholded exact/candidate matching; below the auto-match threshold results are reviewable candidates, never silent merges. - KnowledgeConflict (CR-11L): first-class preservation of source disagreement. Every competing value remains in the conflict; resolution records the chosen value plus the policy, actor and timestamp.
- AuthorityPolicy (CR-11M/N): property-specific source authority across
(source, property)pairs. Five tie-breakers:highest,newest,most-confident,human,no-write. Undeclared authority is rejected (CR-11R). - No silent merge:
approve_resolutionrequires an explicit actor and the chosen entity must be a candidate;MERGEDwithout approval is rejected. - External ids never adopted: approved resolutions add an
ExternalIdentifierlink; the canonical entity id is unchanged. - 13 new runtime tests (114 total in
tests/runtime/).
Second phase of CR-10 (Scenario, Simulation, Digital Twin & Strategic Decision Intelligence). Specification and metamodel remain 1.0.0; impact analysis is additive runtime machinery over the Phase-1 scenario foundation.
- Impact graph (CR-10G): dependency propagation from explicit scenario changes, with direct (depth 1) vs indirect (depth > 1) impact and exact relationship paths.
- Impact categories (CR-10G): strategic, business, capability, process, customer, data, application, technology, security, risk, agent, governance, financial, operational.
- Explicit impact valence (CR-10H): Positive / Negative / Neutral / Mixed / Unknown. Affected never automatically means negative; valence changes only through caller-supplied rules.
- Change analysis: every CR-10C delta operation reports added / removed / modified entities plus propagated impacts.
- Architecture delta: canonical graph-snapshot diff for added, removed and modified entities and relationships.
- Golden impact report for the CR-10AS customer-platform replacement scenario.
- 5 new runtime tests (101 total in
tests/runtime/).
Second milestone of CR-9 (Runtime, Knowledge Graph & Interoperability). Specification and metamodel remain 1.0.0; the provenance graph is additive runtime machinery over the frozen semantic contract.
- First-class runtime assertions (CR-9O): claims carry subject, payload,
asserted_by, confidence, validity window and status (proposed,verified,approved,rejected,superseded,disputed). Assertions are encoded as canonicalKnowledgeAssetnodes withprovenance_kind=assertion, preserving the frozen Core. - Evidence graph (CR-9P): Evidence and EvidenceSource are graph citizens;
lineage uses canonical
traces-to, while loaded models expressingEvidence -supports→ AssessmentResultjoin the same explainability path. - Provenance chain / Why? (CR-9T/BC):
ProvenanceService.why(subject)returns Conclusion → Assertions → Evidence → Sources with stable structured output — the runtime seed for CR-9BZ "Why?" navigation. - Explicit authority transitions (CR-9CQ): assertions cannot be created
approved; status changes are actor-stamped, reason-carrying transitions with
history. Derived assertions retain
derived_fromandderivation_rule. - 9 new runtime tests (96 total in
tests/runtime/).
First phase of CR-11 (Interoperability, Federation & Ecosystem Conformance). Specification and metamodel remain 1.0.0. Governing principle (CR-11 §2): OpenDEA is the semantic contract; adapters absorb external complexity.
- Four distinct concepts, never conflated (CR-11A):
ExternalSystem(Source),IntegrationAdapter(semantic mechanism — distinct from the transport connector, CR-11D),SemanticMapping(correspondence),Exchange(the transfer). SemanticMappingwith the full mapping vocabulary (CR-11F: EQUIVALENT…NO_CORRESPONDENCE), explicit confidence (CR-11G), declared lossiness (CR-11AQ), testable transformations (CR-11H), and governance — owner/version/status/effective/deprecation dates; SUPERSEDED requires a replacement reference (CR-11AT/AU).ExternalIdentifier(CR-11I): external record ids are correlated, never adopted as canonical identity.InteropRegistry.resolve()is exact match only — reconciliation/confidence lands in Phase 2.Extension(CR-11AR): unmappable external concepts are preserved in non-opendeanamespaces — never discarded, never absorbed into Core (ADR-013, CR-11 §66).Exchangeenvelope (CR-11S/V) with schema/profile/mapping version declarations;InteropRegistry.export()produces the canonical JSON exchange from any GraphStore — semantics, not storage layout (CR-11U).- Integration error taxonomy (CR-11AW) and import-mode / sync-direction / locality vocabularies (CR-11P/Q/AI).
- Credential safety:
ExternalSystem.authenticationis a credential-store reference; inline secrets are rejected (CR-11AY). - 16 new runtime tests (87 total in
tests/runtime/).
docs/interoperability/— overview, architecture, identity, mappings, federation, events, security, exchange-format, provenance, archimate, bpmn, dmn, conformance (13 documents).docs/adr/ADR-013-core-non-accumulation.md— the CR-11 §66 correction: the Core does not accumulate; adapters absorb external complexity.change-requests/CR-011.md— the CR as authored.
First phase of CR-10 (Scenario, Simulation, Digital Twin & Strategic Decision Intelligence) plus the CR-1→CR-10 documentation consolidation CR-10 calls for (§A–§P). Specification and metamodel remain 1.0.0.
- Scenario as a first-class semantic object (CR-10A): id, owner, purpose, baseline reference, assumptions, changes, constraints, affected entities (derived), expected outcomes, lifecycle status, version, provenance.
- Baseline immutability + simulated-state isolation (CR-10B): baselines are
frozen snapshots;
ScenarioEngine.simulate()applies the delta to a fresh graph — production/current state is never mutated. - Explicit delta vocabulary (CR-10C): ADD, REMOVE, REPLACE, MODIFY, RECLASSIFY, CONNECT, DISCONNECT, ENABLE, DISABLE, MOVE, SCALE — structural (Level 0, CR-10K) semantics with registry validation.
- Explicit assumptions, constraints, outcomes (CR-10D/E/I) with uncertainty classes (CR-10O: Known/Estimated/Assumed/Predicted/ Simulated/Unknown) — forecasts are never deterministic facts.
- Scenario lifecycle enforcement (CR-10A), frozen evaluated versions + explicit versioning (CR-10AG), reproducibility hash (CR-10AF).
- Golden scenario
models/scenarios/customer-platform-replacement.yaml+ baseline model — the CR-10AS canonical example, exercised end-to-end intests/runtime/test_golden_scenario.py. - 22 new runtime tests (71 total in
tests/runtime/).
docs/opendea-conceptual-architecture.md— the authoritative CR-1→CR-10 narrative: what OpenDEA is (semantic contract, not an EA tool), the layer model (§B), reference-implementation-vs-specification (§N), core-vs-profiles (§I), normative-vs-informative (§J), the semantic stack (§P), roadmap (§O).docs/concepts/— four-state model (§C), truth model (§D), semantic lifecycle (§E), digital-twin positioning (§H + CR-10AA/AB), scenario.docs/opendea-and-dmm.md(§F + terrain semantics CR-10AN–AQ) anddocs/opendea-and-agents.md(§G).docs/adr/— ADR-001…ADR-012 recording settled architectural decisions (§K).docs/glossary.md(§L) anddocs/conformance-model.md(§M).docs/README.md— documentation index with the normative/informative convention.change-requests/CR-010.md— the CR as authored; roadmap rows CR-011…CR-013 added per CR-10 §O.
First milestone of CR-9 (Runtime, Knowledge Graph & Interoperability). Additive tooling only — the specification and metamodel remain 1.0.0 (the CR-8 semantic contract stays authoritative; the runtime provides interchangeable implementations, CR-9 §101).
runtime/— reference OpenDEA runtime (CR-9BV: demonstrates the semantics; not the only valid implementation):runtime/graph/base.py— canonical graph model (CR-9E: first-class edges with provenance/temporal/status/properties) +GraphStore, the vendor-independent graph interface (CR-9D).infer()raisesInferenceUnavailable— no silent inference (CR-9CQ).runtime/graph/memory.py—InMemoryGraphStorereference implementation: defensive reads, referential integrity, copy-on-write transactions with rollback (CR-9BP), temporal traversal (at=— "what is true now?", CR-9F; planned edges never read as current, CR-6 §22).runtime/model/loader.py— canonical model loader: CR-8 reference validator (levels 0–3) runs before any mutation; loads are atomic; envelope provenance/source/temporal fields preserved verbatim (CR-9K, CR-9 DoD).runtime/api/service.py—RuntimeService: entity/relationship CRUD with registry-backed write validation (types, abstract types, endpoint compatibility via the TTL type hierarchy). No agent write path — no autonomous mutation by default (CR-9CR).
tests/runtime/— 49-test runtime suite (CR-9CO): vendor-independent GraphStore contract (CR-9CL seed — conform future Neo4j/Neptune/RDF stores by subclassing), golden/negative loader contract, CRUD semantics, provenance/temporal retention, transaction rollback, no-silent-inference.docs/runtime-architecture.md— CR-9 KB note: closed-loop intent, layered runtime, model-vs-state-vs-assertion-vs-evidence-vs-inference, integration/ reasoning/agentic principles, trust & freshness commitments, milestone plan and DoD tracking.change-requests/CR-009.md— the CR as authored; stale CR-009/CR-010 placeholder rows inchange-requests/README.mdcorrected (drift fix).
OpenDEA 1.0. Consolidation of CR-1…CR-7 into a formal, machine-validatable, profile-driven semantic specification (CR-8 §63 phases 8.1–8.10).
specification/— the formal specification corpus: 22-sectionOpenDEA-Semantic-Architecture-Specification.md(§52),core-freeze.yaml(§3-§4, 18 anchors frozen + §3 candidate evaluation + anti-inflation rule),naming-conventions.md(§6-§7 incl. reconciled divergences),type-system.md(§8-§9/§14-§15),relationship-semantics.md(§10-§14),profile-mechanism.md(§16-§17/§53-§55),conformance-spec.md(levels 0–5, invariants, error taxonomy, open/closed world, assertion provenance),serialization-versioning.md(§18-§22).- Generated artifacts (
.github/scripts/generate_specification.py): semantic inventory- reconciliation (§63 8.1/8.2), canonical vocabulary (§5), concept/relationship catalogues (§49) — documentation is a generated artifact, never a parallel truth (§50).
- Reference validator
tools/opendea_validate.py(§35): levels 0–3 + governance checks, registry-driven, DEA-E/W error taxonomy (§29), structured report (§28),--normalizecanonicalizer (§36). - Model envelope schema
schemas/model-envelope.json(§23-§24) with context, assertion provenance (§40-§41) and source-of-record linkage (§42-§43). - Golden + negative model suites
models/(§30-§33): 7 golden (incl. all six §31 scenarios) MUST pass; 8 negative MUST fail for the expected rule — the specification as a testable contract. - Visualization profile
visualization/profile/(§47-§48): the viewer consumes presentation hints; dependency direction is specification → … → viewer, never reversed (§67). - ArchiMate mapping
mappings/archimate/(§45) with documented divergences; DMN evaluation (§46); RDF/OWL adopted as derived serialization. - test_014 — 13 specification conformance tests (suite now 125).
- Version 1.0.0 across all artifacts. Relationship
constrained-bysources widened to Orchestrator/Controller (found by the reference validator during golden-model validation — the tool working as intended).
- SHACL-style graph validation (§26) and JSON-LD context (§21) — roadmap.
- DMN/BPMN profiles (§46) — extension candidates.
- Reference API (§62) — semantic contract defined; runtime services are CR-9 scope.
- Governance profile
metamodel/profiles/governance/— 14 entities: Intent, Objective, Policy, PolicyRule, PolicyEvaluation, PolicyDecision, DecisionOption, DecisionCriterion, DecisionRecord, Authority, Delegation, GovernanceBody, GovernanceRule, Action. - Agentic profile
metamodel/profiles/agentic/— 18 entities: Agent (specializes Actor), AgentProfile, AgentSkill, Tool, ToolPermission, Orchestrator, Controller, Orchestration, Workflow, Task, AutonomyPolicy, AutonomyLevel, HumanOversight, Approval, Escalation, AgenticSystem, AgentOpportunity, Memory. - 24 relationships: motivates, seeks, constrained-by, authorizes, performed-by, informed-by, delegates, grants, authorized-by, approves, establishes, consults, mitigates, escalates-to, evaluates, has-skill, invokes, coordinates, enforces, permits, prohibits, requires-approval, has-oversight, accesses.
- G001–G016 conformance (test_013) — suite now 112 tests.
- Core schema extensions: Decision + rationale/confidence/uncertainty/assumptions/authority_ref (§11/§17); Constraint + strength hard/soft/preference/guideline (§10); Action reversibility (§41).
- Endpoint extensions: agents make Decisions (§65), GovernanceBody governs/establishes, owns covers Agents (G007), composes covers AgenticSystem (§58) and Decision options, accountable-for covers Decision/Action (G016), specializes wires Agent/Orchestrator/ Controller under Actor (§27/§46).
- The causal loop is now complete: Intent → Objective → Policy → Decision → Action → Change → State → Outcome → Evidence → Assessment → new Decision (§2/§45/§68).
- 32 governance/agentic entities await upstream OpenDEAM allocation before entering the viewer graph.
- RACI profile (§37), AI Agent Maturity assessment profile (§54), agent readiness scoring (§55) → follow-up profiles reusing CR-5 machinery.
- LLM/prompt/RAG/vendor-framework specifics → technology profiles, deliberately out of scope (§66).
- Lifecycle profile
metamodel/profiles/lifecycle/— 18 entities: TemporalInterval (the five clocks: transaction/valid/observation/planned/effective — §5), TemporalEvent + TemporalState abstracts, LifecycleState/Event/Transition (§7/§28), Transition (§14), ArchitectureState + Baseline/Current/Target/Transition/Scenario specializations (§9–§13), Scenario + ScenarioAssumption (§25), ArchitectureSnapshot (§30), ArchitectureDelta (§32), Version (§19). - 14 temporal relationships: valid-during, contains, from-state, to-state, caused-by, introduces, removes, modifies, in-state, records, captures, may-become, version-of, precedes. New CR-2 category L — temporal.
- temporal-dimension — fifth cross-cutting overlay dimension for lifecycle entities (mirrors the measurement-dimension precedent).
- Temporal pattern on the entity base schema (§4) + temporal relationship instances (§21/§22): valid_from/valid_to/status/recorded_at on relationship-instance.json.
- Temporal integrity rules T001–T010 automated (test_012) — suite now 88 tests.
- Endpoint extensions: Change → replaces/introduces/removes/modifies elements and realizes TargetState (§15); Change depends-on/enables Change (§34); supersedes widened to applications/services/technology (§20); type hierarchy wired via specializes.
- Change formalized with per-type lifecycles (§7): proposed→approved→in-progress→completed/ cancelled; planned vs actual mandatory (§16); history never overwritten (§17).
- 18 lifecycle entities await upstream OpenDEAM allocation before entering the viewer graph.
- Timeline/state-selector/delta visualization → dea-web-viewer (CR-6 §42 Phase 9).
- Instance-level temporal validation (T001 ordering, T005 contradictions, T008 cycles) → validation services; metamodel-level guarantees automated here.
- Assessment profile
metamodel/profiles/assessment/— 28 entities: Assessment, Framework, Dimension, Criterion, Indicator, Observation, Measure, Score, Scale, Unit, Result, Subject, Scope, Target, Gap, MaturityModel/Level/Scale/Rule, Aggregation/Scoring/ MaturityMappingRule, Evidence/Source/Artifact, Benchmark/Population/Reference. - 13 assessment relationships + supports/produces endpoint extensions (§17/§10).
- DMM profile
metamodel/profiles/dmm/— DMMv5 as AssessmentFramework instance: 6 dimensions, maturity shell, scoring container, §23 dimension→DEA mappings; independently versioned (§33/A012). - A001–A013 conformance (test_011);
generate_registry.py(registry regen scripted).
- A008 enforced: removed
Capability.maturity_levelclassification — the §2 anti-pattern found live in the vocabulary. Maturity now exists only via AssessmentResult + framework-owned MaturityLevel.
- 28 assessment entities await upstream OpenDEAM allocation; DMMv5 substantive content import; viewer assessment overlay (§39 Phase 9).
- Core ontology
metamodel/core/— 18 anchors: 8 existing (Entity, Actor, OrganizationalUnit, BusinessCapability, Resource ×3 kinds) + 5 new abstracts (ArchitectureElement, Behavior, Service, Information, Organization) + 5 new concretes (Decision, Outcome, Requirement, Constraint, Change — each with schema, SQLite table, pydantic model, TTL class). - 10 profiles under
metamodel/profiles/(business, ecosystem, digital, data, technology, ai, governance, assessment, dmm placeholder, ecf viewpoint) with explicitdepends_ondeclarations; no circular dependencies (O004). - Core relationship grammar (25 types) + 5 new registry relationships:
makes,results-in,targets,affects,contributes-to. - Membership classification: every entity carries
membership: core|profile; viewer graph entities carry it too (viewer can render Core/Profile independently). - Ontology conformance O001–O009 automated — suite now 59 tests.
- Semantic backbone wired per CR-4 §20 (14 relationships gained core-anchor endpoints).
- CR-2 parked
targetslabel RESOLVED →dea:affects(crosswalk updated).
- 10 new core anchors are not yet allocated in the upstream root model (dea-architecture-framework) — root model v0.6.0 candidate; viewer graph picks them up on the next sync.
- DMM profile content (CR-5), Agent ontology (CR-7), viewer Core/Profile rendering (dea-web-viewer PR).
- 70 relationship-state properties removed from 25 entity schemas — the 37
CR-2F-deprecated properties plus 32 ID-reference arrays (
processes,metrics,owned_*,parties,mitigates,technology_stack, …) andCapability.maturity_level. Every removal has a disposition (target relationship or explicit re-assertion requirement) inmetamodel/migration/entity-normalization.yaml. - SQLite projection:
ownercolumns (6),parent_ou(+index),parent_concept,capabilities.maturity_leveldropped.
lifecycle_statuson every entity schema, driven by the new centralized vocabularymetamodel/vocabularies/lifecycle.yaml(CR-3R).external_references {system, identifier}on every entity schema + SQLiteentity_external_referencestable (CR-3P) — external IDs never replace OpenDEA identity.metamodel/vocabularies/classifications.yaml— 55 controlled classification vocabularies, CI-synced against schema enums (E005).- Entity conformance rules E001–E010 as automated tests (suite now 48 tests).
metamodel/migration/entity-normalization.yaml(CR-3U/3V): 54 entity actions, 58 property dispositions, migration metadata 0.7.0 → 0.8.0 (reversible).
Technology.lifecycle_statusrenamed toadoption_status(adoption posture is a classification, not the universal entity lifecycle).- Relationship endpoints extended (normative, MINOR): supports+Actor source, realizes+BusinessObject, represents+EcosystemActor, composes+Actor, owns+BusinessProcess, informs+Entity targets.
- Abstract entity categories (CR-3L) → CR-4 consolidation.
- Agent as specialized entity (CR-3D) → CR-7.
- Assessment/maturity model (CR-3B target) → CR-5.
- Canonical relationship ontology: 49 normative relationships (48 stored + 1 virtual
inverse view) with full §3 structure — category (A–K taxonomy), canonical direction,
typed source/target endpoints, cardinality at both ends, inverse declarations,
transitive/symmetric flags, temporality, provenance requirement, lifecycle
(
proposed | active | deprecated | retired). - Relationship crosswalk
metamodel/migration/relationship-crosswalk.yaml— all 59 viewer labels + 10 legacy instance-enum values explicitly dispositioned; nothing silently reinterpreted. - Instance metadata (§6/§21/§22):
relationship-instance.jsonv2 supportseffective_from/to,status,confidence,asserted_by,rationale,evidence, structuredprovenanceincl.agent_id+verification_statusfor AI-asserted relationships, andmapping.kindfor narrowedmaps-to. - Viewer graph-side migration (2I): every edge carries canonical
rel_ids;relationship_definitionsembedded for viewer definition display; generator hard-fails on unmapped labels (R012). - Conformance rules R001–R012 as automated tests (suite now 37 tests).
maps-tonarrowed to crosswalk/classification/traceability/equivalence semantics (§9).- Overloaded relationships decomposed (§17):
governance→governs/mandates/controls/owns/ responsible-for;implementsdisambiguated fromrealizes/operationalizes/supports;influences→informs; split labels (produces / consumes,publishes / subscribes) decomposed. - SQLite
relationshipstable rebuilt from the registry: 48-type CHECK constraint, metadata columns; pre-0.7.0 columns retained but deprecated. - TTL ObjectProperties regenerated from the canonical registry (48).
- Legacy viewer rel_types (7) demoted to rendering styles; categories are the semantics.
- 35 duplicated relationship-state properties across 20 entity schemas (CR-2F) — physical removal in CR-003.
- Instance types
influenced-by,decomposes(superseded — see crosswalk); instance fieldsweight,bidirectional.
- Normative metamodel source
metamodel/dea-metamodel.yaml— the single authoritative semantic definition (CR-1.1). - Metamodel manifest
metamodel/manifest.yaml(CR-1.2). - Entity and relationship registries under
metamodel/registry/with stable semantic IDs for all 54 entities and 17 relationships (CR-1.4, CR-1.5). - Governance docs:
docs/architecture.md,docs/semantics.md,docs/versioning.md(CR-1.7, CR-1.12). - Change-control mechanism
change-requests/with CR-001 as the first record (CR-1.8). - Conformance suite
tests/conformance/(tests 001–006, CR-1.9). - CI enforcement of version consistency, referential integrity, duplicate IDs, and generated-artifact freshness (CR-1.11).
- Unified version baseline: all artifacts converge on 0.6.0 (previously metamodel.yaml 0.3.0, VERSION 0.4.0, entity-graph 0.5.0, sqlite 0.1.0-alpha).
- README restructured: explicit Normative / Derived / Informative separation.
metamodel.yaml(legacy root index) deprecated in favour of the normative source; retained for consumer compatibility until the catalog migration phase.
- Semantic expansion freeze in effect until CR-003 closes (CR-1.6).
- Component versions separated: metamodel / JSON Schema / SQLite projection / viewer (CR-1.3).
- ADR-0005: entity_role / completeness_contract; Resource abstract same-layer root. Synced from OpenDEAM root model v0.5.0 (53 entities, 2 dimension entities, 70 edges).
- ADR-0004 renames: Principle→Tenet, Standard→Guardrail, Reference Model→Blueprint.
- Root-model pin v0.3.0; entity-graph generation from OpenDEAM root.
- Initial scaffold: schemas, SQLite projection, TTL ontology, viewer graph.