Skip to main content
Jira progress: loading…

ZAMG-IM

ZAMG–ZAR Integration Model

1. Purpose​

This model defines how ZAMG operates inside the ZAR framework rather than beside it.

The goal is to ensure that:

  • ZAR remains the canonical registry backbone
  • ZAMG acts as a compiler/generator over ZAR-native identities and metadata
  • ZCP consumes approved contracts rather than owning registry truth
  • ZSSR validates and routes execution using ZAR-backed approved manifest data
  • deterministic and AI-assisted generation both remain governed and auditable

2. Core architectural principle​

ZAR is the system of record. ZAMG is the manifest compiler. ZCP is the execution protocol. ZSSR is the routing and validation gate.

This means:

  • CMI remains canonical in zar.cmi_registry
  • CSI remains canonical in zar.signal_csi_binding
  • engines, micro-engines, components, modules, tables, and proposal artifacts remain ZAR-native
  • generated manifests are compiled views and operational contracts built from ZAR-backed data

ZAMG should not create a parallel identity universe.

3. Main responsibility split​

3.1. ZAR responsibilities​

ZAR owns:

  • canonical artifact identity
  • canonical signal identity
  • module/component topology
  • engine and micro-engine registration
  • proposal staging structures
  • status/lifecycle metadata
  • table- and binding-level governance metadata
  • compiled canonical manifest storage
  • approval evidence, review queue, and projection logs

3.2. ZAMG responsibilities​

ZAMG owns:

  • artifact candidate intake
  • artifact detection and classification
  • interaction-point detection
  • operation extraction
  • deterministic resolution
  • registry-backed enrichment
  • controlled AI suggestions where ambiguity exists
  • manifest compilation
  • confidence scoring
  • review gating
  • canonical promotion into manifest storage

3.3. ZCP responsibilities​

ZCP owns:

  • command envelope and semantic execution calls
  • opcode-based operation invocation
  • runtime use of approved CMI/CSI-backed contracts

ZCP does not own:

  • CMI registry
  • CSI registry
  • ruleset registry truth

3.4. ZSSR responsibilities​

ZSSR owns:

  • route validation
  • ruleset application
  • execution gating
  • fallback enforcement
  • policy-aware routing decisions

4. ZAR-native data backbone for ZAMG​

The current ZAR model already provides the backbone needed by ZAMG.

4.1. Canonical artifact identity​

Primary source:

  • zar.cmi_registry

Relevant fields:

  • cmi
  • module_code
  • component_id
  • cmi_kind
  • artifact_name
  • version_major
  • version_minor
  • version_patch
  • version_text
  • zar_code
  • semantic_role
  • runtime_class
  • artifact_location
  • implementation_ref
  • owner_team
  • source_doc_id
  • source_file
  • md_document_link
  • status
  • lifecycle_status

4.2. Canonical signal identity​

Primary source:

  • zar.signal_csi_binding

Relevant fields:

  • signal_id
  • csi_module
  • csi_component
  • csi_kind
  • csi_name
  • csi_version_maj
  • csi_version_min
  • csi
  • status

4.3. Supporting ZAR structures that should feed ZAMG​

Already present or implied by the current ZAR database:

  • component_registry
  • documented_component_registry
  • module_registry
  • module_alias_registry
  • engine_registry
  • micro_engine_registry
  • signal_registry
  • signal_engine_binding
  • signal_component_binding
  • component_module_map
  • proposal/result tables for CMI, CSI, signal, table, codex results

These structures should be treated as deterministic and heuristic sources for ZAMG resolution.

5. Canonical manifest layer inside ZAR​

The compiled contract layer now lives in:

  • zar.artifact_manifest_registry

Supporting workflow tables:

  • zar.artifact_manifest_approval_evidence
  • zar.artifact_manifest_review_queue
  • zar.artifact_manifest_projection_log

This is the operational layer where ZAMG outputs are promoted into governed artifacts consumable by:

  • ZCP
  • ZSSR
  • docs generators
  • OpenAPI/SDK projections
  • analytics and governance tools

6. ZAMG operating modes inside ZAR​

ZAMG should support three practical modes.

6.1. Compile-from-approved mode​

Used when CMI and CSI are already canonical and stable.

Behavior:

  • resolve existing CMI
  • resolve CSI via signal bindings
  • apply deterministic defaults
  • compile manifest
  • auto-approve if low-risk and policy allows

6.2. Proposal-assisted mode​

Used when one or more identities or mappings are not fully canonical yet.

Behavior:

  • resolve what is known from canonical tables
  • create or enrich proposal-stage candidates
  • mark critical unresolved or review-required fields
  • compile review-required candidate manifest

6.3. Refresh/reprojection mode​

Used when the underlying artifact identity remains stable but contract projections need regeneration.

Behavior:

  • load existing approved canonical manifest
  • re-run generation against latest deterministic rules and metadata
  • compare semantic delta
  • auto-approve or send for review based on change class

7. Data flow model​

7.1. Upstream sources into ZAMG​

ZAMG should ingest from:

  • docs/frontmatter
  • code metadata and routes
  • documented component records
  • engine and micro-engine registry data
  • signal bindings
  • module/component maps
  • proposal/result tables
  • manually confirmed overrides
  • template registries and opcode registries

7.2. ZAMG compilation path​

  1. identify artifact candidate
  2. attempt CMI resolution in zar.cmi_registry
  3. attempt component/module resolution using registry and mapping tables
  4. detect operations and interaction points
  5. resolve opcode and artifact-type defaults
  6. resolve signal scope through signal_registry + signal_csi_binding
  7. attach routing/policy defaults
  8. compile candidate manifest
  9. validate and assign review class
  10. write candidate to zar.artifact_manifest_registry
  11. route to review queue or canonical approval
  12. log projection events after promotion

8. CMI integration inside ZAMG​

CMI resolution should be registry-first.

8.1. Primary match path​

Try exact or near-exact resolution using:

  • module_code
  • component_id
  • cmi_kind
  • artifact_name
  • version_text

against:

  • zar.cmi_registry

8.2. Candidate generation path​

If no exact match exists:

  • generate deterministic CMI candidate using naming rules and mapped module/component metadata
  • compare against uniqueness constraints
  • record proposal candidate where needed
  • mark review-required or proposal-required state

8.3. CMI status filtering​

For production candidate promotion:

  • prefer status = active
  • prefer lifecycle_status = active

Draft, deprecated, or retired artifacts should not be silently promoted into production canonical manifests.

9. CSI integration inside ZAMG​

CSI resolution should be signal-first, then binding-first.

  1. identify signal_id
  2. join to zar.signal_csi_binding
  3. prefer status priority such as:
  • stable
  • experimental
  • draft
  • legacy
  • deprecated
  • retired
  1. validate component/module/kind alignment where available
  2. if ambiguous, mark review-required
  3. if missing, create proposal pathway

9.2. Production policy​

For production manifests:

  • prefer stable
  • allow experimental only with explicit approval if policy permits

Do not auto-approve:

  • draft
  • deprecated
  • retired

for production CSI dependencies.

10. Manifest as compiled operational contract​

The manifest should be treated as a compiled contract view, not the root identity store.

That means:

Root truth remains in ZAR tables

  • cmi_registry
  • signal_csi_binding
  • engine/component/module registries
  • proposal and result tables

Compiled truth lives in manifest storage

  • resolved operations
  • opcode bindings
  • exposure metadata
  • routing defaults
  • policy defaults
  • resolution provenance
  • review state
  • projection state

This distinction is crucial.

11. Approval and workflow integration​

The review/approval system should operate fully inside ZAR-backed tables.

Candidate lifecycle

  • ZAMG writes candidate row into artifact_manifest_registry
  • if review is needed, queue row created in artifact_manifest_review_queue
  • decisions recorded in artifact_manifest_approval_evidence
  • approved canonical state written back to artifact_manifest_registry
  • downstream projection actions recorded in artifact_manifest_projection_log

This gives us:

  • traceability
  • queryability
  • replayability
  • governance evidence
  • Ask ZARA-friendly semantics

12. Projection model​

After approval, the manifest may be projected to:

  • ZCP binding/config layers
  • ZSSR route validation/config layers
  • docs/MDX projections
  • OpenAPI projections
  • SDK generation
  • analytics or governance dashboards

Every projection event should be logged in:

  • zar.artifact_manifest_projection_log

This ensures approval and publication remain decoupled.

13. Deterministic-first rule in the ZAR context​

Aa we know the real tables, the deterministic-first principle becomes:

  1. resolve from canonical ZAR tables
  2. resolve from mapping tables and templates
  3. resolve from approved proposal-derived patterns
  4. use AI only for ambiguity
  5. require review for critical AI-assisted fields

Principle 1

ZAMG should query ZAR as the canonical registry layer, not mirror it.

Principle 2

CMI and CSI should be referenced, not recreated, in canonical manifests.

Principle 3

Proposal/result tables should be reused as staging infrastructure wherever possible.

Principle 4

Manifest storage should be the compiled contract layer above canonical registries, not a replacement for them.

Principle 5

Only approved canonical manifests may feed production ZCP and ZSSR projections.

15. Immediate implementation recommendations​

Based on the current schema, we:

Now

  • use artifact_manifest_registry as compiled manifest store
  • add the active-review unique index
  • begin logging all approval evidence and downstream projection events in the three companion tables

Next

  • define exact deterministic joins for:
    • CMI resolution
    • CSI resolution
    • engine/micro-engine to component mapping
    • documented component to artifact mapping

Then

  • formalize the ZAMG–CSI/CMI integration spec
  • formalize the comprehensive opcode registry

16. Final summary​

The refined model is now:

ZAR = canonical registry backbone ZAMG = manifest compiler inside ZAR artifact_manifest_registry = compiled operational contract layer ZCP = runtime command protocol using approved contracts ZSSR = governed routing and validation gate



GitHub RepoRequest for Change (RFC)