SemanticSeams · one RDF graph, every diagram a view

Zooming in is a graph traversal

Click a node and the renderer switches with the node's notation. The descent below is the canonical one, and the viewer completes it over a hand-authored model today: see the screenshots.

01
Open the C4 container view: the navigation shell.click client web interface
02
Land on its IFML surface: pages, view components, events, flows.click an event's action
03
Land on the BPMN diagram behind that action, rendered by bpmn-js from the native XML.click a business-rule task or a data object
04
Land on the DMN decision table, or the SHACL shape of the data itself.same graph, different renderer

The seams are the product

There is no BPMN ontology here and no DMN ontology. Native XML stays native and is rendered by the stock viewers. Only the elements that participate in a cross-layer edge get an IRI, and the edges come from one small bridging ontology, built to four rules.

Few and generic beats many and precise

Twenty-five predicates. Each one must earn a cross-layer query or it does not exist.

Reuse inside layers, mint where layers meet

C4, IFML, BPMN, DMN and SHACL keep their own vocabularies. The seam ontology only names the joins.

The method applied to itself

SHACL shapes constrain the seams. CI parses every file, validates the examples, proves the shapes reject bad seams, and checks every predicate is exercised.

Questions no single-notation tool can answer

Because everything is one graph, cross-layer questions are SPARQL. Three ship as canned queries with exact expected rows asserted in CI, and they are buttons on the viewer's inspector, not SPARQL a user sees.

Which UI events can eventually write to this data shape, and through which task?

what-writes-shape.rq · compliance and security review

What breaks, containers, processes and data, if this deployment node goes away?

impact-of-node.rq · impact analysis and drift

Which process tasks may move an entity out of this state?

what-moves-state.rq · lifecycle audit

The first one, as it ships in docs/queries/what-writes-shape.rq: a property path from an IFML event through the seams to whatever writes the shape, including the async hop through a channel.

SELECT DISTINCT ?event ?writer WHERE {
  ?event a ifml:Event .
  ?event ( (seam:triggers/seam:detailedBy/^seam:inModel)
         | seam:decidedBy
         | seam:invokes
         | (seam:publishesTo/^seam:subscribesTo/seam:inModel/^seam:inModel)
         )+ ?writer .
  ?writer seam:writes ?shape .
}

Where it is

Proof of concept, July to October 2026. A read-only viewer completes the descent from architecture to decision table by clicking, and everything below runs under test in CI. A shared visual language for the viewer comes next, then generating the application from the model.

bridging predicates in seam.ttl, with SHACL shapes over them

worked examples: a checkout flow and a chat app, with native BPMN and DMN payloads

canned cross-layer queries, exact rows asserted in CI

acceptance and viewer tests, run on every push

Milestones

Done
The descent
Architecture, then interface, then process, then decision, by clicking. Breadcrumbs record the path, an element with two detail views asks which to open, and DMN decision tables click through.
Done
Trust and questions
A SHACL model-health badge on every view, and canned cross-layer questions on the inspector, answered inline with their exact rows asserted in CI.
In design
One visual language
A single node card with a dot for every seam, containers opened in place on a deterministic layout, and IFML drawn in its own notation. See coming soon and the backlog.
Planned
Generation
htmx pages, a FastAPI route module and a docker-compose file generated from the model, with the BPMN and DMN executed by SpiffWorkflow rather than generated. Proposed in ADR-0007.

The viewer today

The running viewer on the chat-app example, captured in October 2026. Each step follows one seam. Select an image to open it full size.

The chat app's architecture view: a system containing four containers and a production environment with three nodes, under a green Conforms badge — **Architecture**The entry point: the chat app's C4 view, with the model-health badge above it.

The chat interface's IFML model drawn as a node-link graph of the page, its components, events, parameters and flows — **Interface**Clicking the web interface lands on the IFML model it presents.

The message-processing BPMN diagram: persist the user message, route to provider, invoke the LLM, persist the response, signal stream complete — **Process**Clicking Send Message lands on the BPMN process it triggers, drawn by bpmn-js from the native XML.

A chooser for Route to Provider offering two detail views: the DMN decision model and the chat data model — **A choice**The rule task's decision is detailed by two models, so the viewer asks which to open.

The Route to Provider decision table, hit policy First: long user messages go to a long-context provider, everything else to the default provider — **Decision**The DMN decision table behind the rule task, drawn by dmn-js.

The db01 deployment node with its question answered: four impacted results, the message store, chat API, web interface and send-message process — **A question**What breaks if db01 goes away: containers, a process and the data stored there, answered inline from one SPARQL query.

Coming soon

Design mocks drawn over the same chat-app model. None of this is in the viewer yet. The first two are the next viewer work in the backlog; the third is further out.

The chat interface drawn in IFML notation: a landmark page box holding a List, a Details and a Form component, events as circles on their borders, a dashed data flow with its parameter binding, and the Send Message process as an Action hexagon — Design mock · nextIFML in its own notationThe same triples drawn the way IFML tools draw them. Data bindings and form fields come from the SHACL shapes, and the process a button triggers appears as an action you can click into. Design note

The architecture view with the web interface and chat API containers opened in place, showing the IFML model and the BPMN process scaled down inside them — Design mock · nextOpen it in placeContainers open inside the architecture view instead of leaving it: the interface a container presents and the process it executes, scaled down inside the card. Design note

All six layers stacked as planes, with one process task's seams traced as dashed lines to the operation it invokes, the shape it writes and the state it fires — Design mock · laterSee the layers at onceEvery layer on its own plane, with one task's seams traced across them. Design note

Developed against semantic-stack, the Docker stack of triple stores and RDF tooling, and released under Apache-2.0.