Ask an architecture review board whether a process complies with the enterprise architecture and, most likely, you will get a meeting. Someone will prepare a presentation, someone else will recall the standard, and the conclusion will depend, to a large extent, on who attended. The next day the repository may change and that answer may become outdated without anyone noticing.
It is not a failure of the people. It is the consequence of treating architectural governance as an opinion grounded in static documents. In an executable business architecture, conformance can become something different: a query over the living repository, reproducible, with the same answer for anyone who runs it.
Possible does not mean valid
Every architecture starts from a metamodel. It defines which objects exist — capabilities, services, offerings, processes, data and indicators — and how they may relate.
Cardinalities determine what is structurally possible. For example, a service may be implemented by one or more capabilities, and a process may materialise a service. Yet a model can respect those relationships and still breach the methodology or the organisation’s governance decisions.
That gap is closed by integrity constraints: rules that establish what is methodologically valid. Our methodology consolidates them into fifteen constraints that make up the formal criterion of conformance.
In executive terms, these rules secure five essential conditions:
| Area | What the constraints guarantee |
|---|---|
| The chain holds | No process is left isolated: each process materialises a service or declares who invokes it. No service is left empty: each identifies the capabilities that implement it and the configuration items that support it. And every process that can be requested has a visible, current offering with an operational entry point. |
| The design is coherent | Each approved process has a single objective, stated in a verifiable way. Every path of the future model ends in an expected outcome or a governed exception. Each decision declares the data it uses, the rule it applies and the question it answers. Every captured datum has an explicit purpose. |
| Accountability is explicit | Each process has an owner and a current approval date. Each critical data entity and each indicator has someone accountable. Every executable activity identifies who or what does the work — a person, an algorithm or an agent — and in which environment it runs. |
| Indicators mean something | Every measure declares whether it is a variable or an indicator. When it is an indicator, it carries a target, a threshold and an owner. And no indicator may depend, directly or indirectly, on itself. |
| Change is deliberate | No change to an architecture object is approved without first identifying what depends on it. Capabilities must be properly defined, and all work that produces results must present whoever closes it with the outcomes they can choose. |
These rules are not exotic. An experienced architect has probably met them, or even written them, in handbooks, standards and governance frameworks. The decisive difference is not the rule but what happens after it is defined.
A rule that can be queried is a rule that can be governed
When the constraints are expressed against the metamodel, and not only in a presentation, the platform can evaluate them across the whole repository whenever needed.
Most are resolved by querying the relationships declared between objects. Two require walking a graph: verifying that every path of a process ends in an outcome, and checking that the dependencies between indicators form no cycles. When a rule calls for professional judgement — for example, deciding whether a decision rule is substantive rather than a formality — the system presents the finding to the reviewer responsible for validating it.
In Dexon Architect, this evaluation runs from a screen and does not depend on rebuilding the discussion in a committee. The conformance verifier identifies every finding in the living repository and opens the editor where it must be fixed.
Run at the end of a stage, it works as an exit criterion. Used during a governance committee, it becomes an objective, shared agenda: everyone examines the same findings, on the same version of the architecture.
The fifteen constraints also perform a function equivalent to that of a reference architecture: they embed design decisions taken before each process is modelled and bound which configurations are admissible. The difference is fundamental: these decisions are not only documented; they can be verified directly against the repository.
Why this matters beyond the architecture team
-
For audit, it turns conformance into evidence. If the repository satisfies the fifteen constraints, conformance can be demonstrated through verifiable results rather than resting on a declaration alone. It is the same principle by which maturity is demonstrated rather than declared.
-
For leadership, it preserves the traceability of decisions. The question “which capability does this process contribute to?” can be answered by a query, today and after a reorganisation, as long as the repository is kept current. The traceability chain stops depending on manual reconstruction.
-
For AI agents, it sets the limits of action. Because every activity identifies its executor class, assigning a step to an agent becomes a recorded design decision, with limits, human controls and evidence — not an accidental detail of configuration.
-
For analysts and buyers, it offers a verifiable claim. The methodology is public and also available as a PDF. The constraints are explicitly defined, and a demonstration should let you watch the verifier identify a gap, lead to its correction and then confirm the new state of the model.
Three questions to evaluate an architecture tool
-
Where are its conformance rules defined? In a document people must interpret, or against a metamodel a machine can evaluate?
-
How is a finding handled? As an isolated line in a report, or as a result connected to the object and the editor where the gap is closed?
-
When the repository changes, does the answer change too? If restoring conformance means convening a new review and rebuilding the analysis, conformance was never a property of the architecture — only of the meeting.
A model able to answer these three questions satisfactorily comes close to what analysts describe as a digital twin of an organization: a connected representation of the organisation that also embeds mechanisms to govern its own coherence.
Bring one of your processes. We run the verifier in front of you, review a finding, close the gap and run the validation again. The conversation stops revolving around opinions and starts resting on observable evidence.