Skip to content

Architecture model to repository governance

Trigger

A project/domain architecture needs to become a governed enterprise repository model and published view set.

Intended outcome

Canonical model facts, cross-project dependencies, Open Exchange interchange and published views are consistent, reviewable and traceable to named owners.

Workflow steps and gates

Step Accountable role Activity Handover Gate
1 Solution Architect finalises project model facts, decisions and project ownership boundaries project architecture model and source artefacts Elements/relationships have stable identities and evidence basis
2 Architecture Repository and Modelling Lead maps model facts into the canonical repository/metamodel and repository conventions canonical project model No model fact is silently reinterpreted to fit a tool
3 Architecture Repository Engineer imports/updates the canonical repository, preserving IDs, lifecycle and provenance repository revision plus interchange artefacts Repository structural validation passes
4 Model Consistency Reviewer checks references, orphans, cross-project ownership, lifecycle conflicts and view drift consistency findings/gate No blocking integrity error remains
5 Enterprise Architect resolves enterprise/domain overlap, shared elements and portfolio dependencies accepted enterprise model/repository decisions Cross-project dependencies and reusable/reference elements have owners
6 Technical Design Authority Member applies architecture governance to material conformance/exception decisions approved/rejected repository release Exceptions and residual risks have named authority and expiry/review

Running this workflow: operator and implementer boundary

In Claude Code or Codex CLI, use the prompt in the next section (or adapt it to your programme): it is a provider conversation request, not a shell program named after this workflow. You supply the source materials, actual owners, gate acceptance and any authorisation for changing real systems. The provider agent interprets the registered workflow stages and role contracts, calls supported tools if allowed, and returns explicit evidence and blockers. Stage completion in the diagram or metadata is not proof of a successful external tool call, an approved exception or a released system.

For consequential decisions explicitly start /layered (Claude) or $workflow-layered (Codex); this version does not force every direct/natural-language workflow invocation into Fabric. Human L0 authority remains separate, with Codex requiring the actual human to run any protected authority command in a trusted terminal. See the interaction model, layered engagement and human authority.

How to use this workflow

A practical prompt pattern is:

Apply the architecture-model-to-repository-governance workflow to this situation. For each step, identify the current state, accountable role, required evidence, hand-over artefact, gate status and unresolved blocker. Do not skip a gate merely because the implementation is technically complete.

Operational interpretation

The workflow is most useful when the team keeps each hand-over explicit. The system can help generate or review the artefacts, but the accountable role and approval decision remain organisational responsibilities.