Skip to content

Enterprise Architecture Knowledge Pipeline — Closing the Loop Back to the Graph

The architecture knowledge pipeline drawn as a cycle — authored models are converted into a knowledge graph, questions are answered from it with citations, and the findings those answers produce return through authored artifacts and re-conversion rather than through a write from the agent

Two articles on this site describe two halves of the same machine. Bridging Architecture Silos builds the graph: models authored in the notation each audience prefers, lifted into RDF, federated without being flattened. Ontology-Guided Conversational Analysis makes it askable: a question in plain language, resolved through the ontology, answered with the query and dataset attached.

Both run in one direction, and the second one says so outright — currency is "a pipeline property, not a conversational one", and the quality templates exist to make a gap "visible rather than to fix it". That is the right boundary for a read-only instrument. It is also an unfinished sentence, because every useful answer produces something the graph does not yet contain: a gap somebody has to close, an identity somebody has to confirm, a rule worth enforcing from now on, a decision worth recording before the reasoning evaporates.

A pipeline that only runs forward publishes. A pipeline that carries those findings back learns. This article is about the return edge: what a finding is, where each kind of finding legitimately lands, and why the path home goes through authored artifacts rather than through a write to the store.

The forward path, in one line

Models are authored in their native tools, gathered where they are distributed, converted to RDF against the ontologies of a semantic set, merged into one dataset that keeps its per-model graphs, validated against the shapes each metamodel names, and then asked. None of that is restated here — it is documented in full elsewhere, and this article assumes it:

Stage Documented in
Author in the native notation Modelling Languages, Semantic Architecture as Code
Collect, convert, merge Tools — the flow end to end, Converters
Federate without flattening Bridging Architecture Silos
Validate Validation
Ask, and cite the answer Ontology-Guided Conversational Analysis, Agent Skills (APM)

The stages are separate tools with a file format between each pair, which is what lets any one of them be replaced, re-run or skipped. That property is what makes a return edge possible at all: if the chain were one product with an internal state, feeding something back would mean writing into it.

Where the forward path deliberately stops

Three stopping points are enforced rather than merely observed, and all three are load-bearing:

The agent cannot write. Update, insert, delete and load are rejected before any backend is touched, including queries arriving through an analysis plan. A conversation cannot quietly edit the architecture it is describing.

Diagnosis is not repair. The quality templates report what is missing, unowned or unconformant. They change nothing, so a report can be wrong without corrupting anything.

Identity is authored. That a Backstage component and an ArchiMate component denote the same system is a claim about your organization, reviewed by a person, never inferred from a label (DD-11).

Read together, they rule out the obvious design — let the agent fix what it finds — and that is a good outcome. An instrument that both measures and edits cannot be trusted to report honestly on its own edits, and a graph that silently accumulated machine-written facts would lose the one property the whole pipeline exists to protect: that every statement can be traced to whoever asserted it.

So the loop closes through authoring. A finding becomes a proposed change to a file, that change is reviewed like any other, and the graph changes on the next conversion.

The pipeline split by an enforced boundary — on the reading side the agent queries, validates and reports but cannot write, and on the authoring side a human commits a model edit, an identity link, a shape or a decision record, which re-enters the graph only through conversion

The wall is the feature. Everything that enters the graph crosses it as a reviewed artifact, so provenance survives the loop.

Every finding has a return address

The previous article showed that an empty result has four readings and that only one of them is a finding about the architecture. Turned around, that same taxonomy routes the work: three of those four readings are defects in the pipeline or the model, and each has a different home.

What the answer revealed Return address Mechanism
Not modelled — nobody captured it the source model, in the tool that owns it author, then re-convert. Where the gap is itself worth modelling, am:Gap and am:Assessment make it a first-class element
Not converted — the run emitted nothing for it the converter invocation or its type-mapping YAML re-run. A re-conversion replaces the graph in place (DD-15)
Not supported — the dataset has no such term, graph or capability the graph profile, or the arch:Metamodel manifest the model conforms to la-profile verify reports the drift; a person decides whether the profile was wrong or the metamodel needs extending
Not true — the architecture really is like that a decision record, or a shape ad:Decision with ad:justification when it is a judgement; a SHACL shape when it should never recur
Two nodes might be one system {base}graph/reconciliation a reviewed skos:exactMatch, revocable without touching source data

The middle column is the part worth internalising. "There is no owner recorded" and "this notation has no ownership predicate" arrive looking identical in a result set and lead to completely different work — one is a data-entry task, the other a metamodel decision. An answer that separates the asserted from the unknown has already done the triage.

Where the return edge lands, and why there

Each destination is chosen for a property it has, not for convenience.

Source models — because re-conversion is idempotent and reviewable. Run identifiers deliberately do not appear in graph IRIs, so a graph IRI names what the graph holds and a re-conversion replaces it in place. Version control keeps the revision history: git log over the output directory is the lineage, and an unchanged input at an unchanged commit produces a byte-identical graph. A model edit therefore shows up as a reviewable diff of the converted output, not as an untraceable mutation.

{base}graph/reconciliation — because a graph boundary can be revoked. Identity links live in their own dataset-wide graph (DD-29), so an identity decision can be withdrawn without touching any source data, and a query can decline to trust reconciliation at all. Authoring Cross-Language Mappings carries the review checklist, and is explicit that the checklist is the actual control.

Shapes — because a finding that recurs should stop being a finding. A gap found once is a task; a gap found repeatedly is a missing rule. Validation documents how to add an organization-specific profile, and CI runs the profiles on every change to a .ttl file. Two cautions from that page apply directly to a rule written in the heat of a finding: sh:severity does not change the outcome, so narrowing what a shape targets is the only way to stop it firing; and a shape that targets a class with no instances reports clean, which is the failure mode to watch for when a new rule passes immediately.

ad: records — because the reasoning is the part that evaporates. The decision vocabulary makes the argument queryable rather than filed: ad:Issue for the problem, ad:Force and its subclasses (ad:Principle, ad:Policy, ad:Constraint, ad:Requirement) for what pushed on it, ad:Option for what was considered, ad:Decision with ad:justification for what was chosen and why, ad:decisionState (ad:Proposed, ad:Accepted, ad:Rejected, ad:Deprecated, ad:Superseded) for where it stands, and the ad:affectsConcept family — ad:addsConcept, ad:removesConcept, ad:modifiesConcept — for what it does to the model. Because these classes subclass arch:Element, a recorded decision is ordinary model content: it carries arch:inModel, it validates, and the next investigation can find it.

{base}{notation}/{modelId}/graph/derived — because inference must stay subtractable. Anything a rule concludes lands in its own graph (DD-28) so a count, a diff or a validation run can exclude it wholesale, and re-derivation stays idempotent: clear the graph, re-run, no retraction logic against asserted facts.

A finding becomes a fact

Take the unknown from the previous article's evidence bundle: ownership is not recorded for two of the three components. Following it through the loop shows what each stage contributes.

1 — The answer states it as unknown, with a citation. Not as a violation, and not as zero rows. The distinction survives into the bundle: the asserted rows carry a query id, the unknown carries a reason.

2 — Triage decides which return address applies. Ownership is absent because the notation those two components came from has no ownership predicate, not because somebody forgot a field. That makes it a vocabulary question, not data entry. The core ontology has the term — arch:conceptOwner, whose range the core shape ConceptOwnerShape constrains to a Stakeholder — so nothing needs inventing.

3 — Somebody authors the fact where it belongs. Ownership is recorded in the source of record for ownership, in its own format, and reviewed as a normal change. The graph is not edited.

4 — Re-conversion carries it in. The affected graphs are replaced in place, and the diff of the converted output is part of the review.

5 — A shape stops the gap from returning quietly. The core shape governs the range of arch:conceptOwner, not its presence, so requiring an owner is an organizational rule to add — the exact case Semantic Architecture as Code reserves architecture/shapes/project-rules.ttl for, enforced from then on by the same CI that validates everything else.

6 — The original question is asked again, and the answer proves it. Re-running the template produces the same query hash over a different dataset state. That is the part worth pausing on: because the citation records the template, the query hash, the dataset and the profile version, "we fixed it" stops being a claim in a status report and becomes two answers to a provably identical question.

Two clocks

A loop needs a health metric, and "is the model up to date?" is the wrong question, because it has two independent answers. A model can be edited this morning and still be absent from the graph, because nobody re-ran the converter. Those are different clocks, and only the provenance graph distinguishes them.

PREFIX prov: <http://www.w3.org/ns/prov#>
PREFIX xsd:  <http://www.w3.org/2001/XMLSchema#>

SELECT ?graph ?convertedAt WHERE {
    ?graph a prov:Bundle ;
           prov:generatedAtTime ?convertedAt .
    FILTER (?convertedAt < "2026-06-01T00:00:00Z"^^xsd:dateTime)
}
ORDER BY ?convertedAt

Every emitted graph is described as a prov:Bundle in its model's provenance graph, naming the activity that produced it and the input it was derived from, so conversion age is a queryable property of the dataset rather than tribal knowledge. Run start and end times depend on how the converter was invoked and must be OPTIONAL. See Relationship Modelling Guide §12.6 for the query in context and DD-27 for how the provenance layers relate.

Model staleness is an organizational question with a review cadence attached, and Governance & Lifecycle covers it. Conversion staleness is a pipeline defect, and it is the one that makes a correct answer wrong.

What is built, and what is method

This article assembles documented mechanisms into a loop that the tooling does not orchestrate. Being precise about the seam matters more than the tidiness of the diagram.

Built and documented. Converters with a named-graph contract and a provenance graph per run. Idempotent re-conversion whose output diffs cleanly. SHACL profiles with a documented way to add an organization-specific one, run by CI on every change to a .ttl file. Read-only enforcement in the agent skills. Profile drift reporting that never applies its own recommendation. A dataset-wide reconciliation graph whose contents are authored and revocable. The ad: and ap: vocabularies, so decisions and governance processes are model content rather than attachments.

Method, not product. No CI job re-runs a converter — the pipeline validates .ttl changes, and re-conversion is something you invoke or wire up yourself. Nothing in the core ontology records when a fact was last verified; conversion time is available from provenance, but a curation timestamp is not a term. The ad: module has no finding or observation class, so a recorded gap borrows am:Gap or am:Assessment from the notation. And no tool ships to turn a reviewed identity file into the reconciliation graph; the graph is reserved and its contents declared authored, but loading it is your pipeline's job.

Put plainly: the return edge is a practice supported by the design, not a feature you enable. Every step of it is something the artifacts already permit, and none of it happens on its own.

What compounds

The reason to close the loop is that four things improve together, and each improvement makes the next question cheaper to answer:

  • The model gains facts — the gap that was reported once is recorded, and the next answer includes it.
  • The profile gains accuracy — each drift report either corrects the profile or extends the metamodel, so fewer questions get refused for the wrong reason.
  • The shapes gain coverage — a finding promoted to a rule is a class of defect that cannot silently return.
  • The question set gains answers — a question that had no pattern the first time is a candidate for the catalogue, which is how conversational coverage grows without loosening what a refusal means.

An architecture practice that only pushes models forward accumulates artifacts. One that routes what it learns back into the graph accumulates knowledge, which is the distinction the knowledge lifecycle draws at the level of individual knowledge items and this pipeline implements at the level of the dataset.

Where next