Everything below is generated from ontology.schema.ttl at page load, the same frozen file every engine reads, not a slide redrawn by hand. Three clusters, 14 classes, 17 relations, then the real instances Story A, B, and C actually loaded, snapping onto that schema, and the one append-only table they all live in. Build it schema-first, then pick any story to watch it walk this exact graph.
Read this first · then press play
This is the actual data model behind the whole demo: a graph of 14 classes and 17 relations, with real project records loaded into it. Each of the five demo stories is nothing more than a different walk across this one graph. Below is what each story asks, what it proves, and how to read the shorthand you will see on screen, so the animation itself can stay clean.
The five stories, and the trust failure each one makes impossible
Story · operation
The question it answers
What actually happens on the graph
What it proves
Forensicsattribute_delaycausal model
Why is the Payments milestone late?
Walks from the late milestone m_204 back to the approval a_88 that sat idle nine days, then finds the two people who hold the scarce skill are both already booked on another project. Two real causes, a 21-day slip.
No plausible-sounding explanation that was not actually derived from the raw events.
Capacityrun_schedulerCP-SAT solver
Can we take on Open Banking in Q3?
New task t_201 needs 200 hours of the scarce skill. A constraint solver weighs the four people who hold it against their real cost rates and returns three feasible paths, and rejects a fourth by naming the constraint it breaks.
No hand-waved "yes we can", feasibility is proven or the exact blocker is named.
Time Travelreconstruct_asoftemporal query
Was approving the plan on January 15 reasonable?
Risk r_12 became true on Jan 10 but the system only recorded it on Jan 20. Asked "as of Jan 15", the same query honestly shows no risk. Asked "as of Jan 21", the same code shows the risk. Two clocks, never mixed.
No silent rewriting of history, what was known then stays provable.
Ripplesimulate_scenarioread-only solver
What happens if we reassign Sarah?
Pulling p_14 (Sarah) off her task roughly doubles its solo duration, a further 5.9 week slip, and the contractors have zero real availability on that date. Then the entire what-if rolls back, byte for byte.
No what-if can corrupt the system of record, every scenario is unconditionally rolled back.
Honestystructured refusalintent router
How is team morale on Payments?
The system scans all 14 classes for a concept that fits "morale". None match. There is no Sentiment, Morale, or Feeling class, so it draws the shape that is not there and refuses, naming the exact missing class.
No guessing or quietly substituting a nearby metric, it admits the gap by name.
Reading the graph, colours and codes
Work Breakdown (coral). Projects, tasks, milestones, deliverables, the structure of the work itself.
People and Capacity (indigo). The named individuals, their skills, leave, and overtime.
The key edge, gates (amber). The single link every delay investigation walks first: an approval that gates a milestone.
A real record (teal). An actual project instance loaded onto the schema, e.g. a_88, not just the class it belongs to.
A planted trap (dashed, muted). Data that looks relevant but must never surface as a cause, proving the system follows real relationships, not name matching.
prj_…
a project. prj_core = Core Banking Modernization, prj_aml = AML upgrade.
m_…
a milestone. m_204 = Payments Integration Go-Live.
t_…
a task. t_130 = Sanctions Screening on the AML project.
a skill. sk_int = Payment Gateway Integration, the scarce one.
a_…
an approval gate. a_88 = Vendor Security Gate.
r_…
a risk. r_12 = vendor delivery capacity strained.
cr_…
a cost rate. cr_int_contractor = QAR 260/hr.
valid_time
when a fact became true in the world.
tx_time
when the system actually learned it. The two never mix.
Press Run full simulation for the whole sequence end to end, or select any story below to walk it step by step. Every node and edge in the graph is clickable through to its source record.
click any class or relation to inspect it, independent of playback
STEP 0 /
GLASS BOX
The ontology, end to end
schema, then real data, then all five stories, one continuous walk
SIMULATION · intro
Cluster A, work breakdown
Cluster B, people and capacity
Cluster C, governance, commercial, risk
flagship relation, lit
real instance, lit
distractor, deliberately unwired
01
L2 · live digital twinThe events tableone append-only table, two clocks on every row
Every instance above resolves down to rows here. Nothing is ever overwritten, only appended. valid_time is when a fact became true in the world, tx_time is when the twin actually learned it, and Story C's whole proof lives in the one row where those two clocks disagree.
Select a class or relationGlass Box Ontology v1.0frozen, closed vocabulary
kind
-
comment
Press play, or click any node or edge above.
domain / range
-
source line
-
Glass Box · Architecture Reference · L0 to L6
The stack, top to bottom
Seven layers, one rule: truth flows up from the feeds, language sits on top, and provenance wraps every layer in between. Toggle between a guided tour of each layer's honest v0 tech pick, and a live walk of any of the five stories' actual data, each one a different real path traced through every layer that computes it.
Project Intelligence gives engineering and capital project owners a single, full-stack view of a project's actual state, surfacing schedule risk, cost drift, and delivery signals from raw field data up through natural-language answers, with every claim traceable back to the source event that produced it. Built on an open source, self-hostable stack, so the system runs entirely inside your own infrastructure rather than a vendor's cloud. The interactive reference below is a real architecture walkthrough, not a mockup: every layer, tool, and data path shown is what actually runs in production. The data model itself, the 14 classes, 17 relations, and all five stories walking one graph, is animated at the top of this page: press "Run full simulation" for the whole thing end to end.
STEP 0 /
Select a layer
L0 – L6
Click any band in the stack, or press Play to tour top to bottom.
honest pick
-
why not more
-
-
Story A: live trace
The real tech stack, as a pipeline
Every tool below is open source and self hostable, the sovereignty story from the architecture brief made concrete. This is not the honest v0 shortlist from the layer cards above, it is the fuller real world stack, including the event sourcing and streaming infrastructure a production deployment would actually run. Click any node for what it does and how you would run it. Choose a story above to watch that story's own path physically traverse the pipeline, each of the five stories lights a different, real route through the same tools.
Currently showing: Story A. When two consecutive lit nodes show no connecting line between them, they are parallel, independent sources converging at the next node, not a broken traversal.
click any node to inspect it, independent of playback
open-source tool, idle
lit: the selected story's event just passed through
selected for inspection
Select a toolTech stackclick any node
role
-
protocol
-
why this
-
run it
-
Build order, current status
All five stories, A through E, are fully specified and fully built: the claim, the entities, the engine path, the cross feed reconciliation, the distractor, and the fingerprint, all implemented and running against the live digital twin. Each story was built and stress-tested end to end, twice, with identical output, before engine code for the next story began, in the order A, E, C, B, D. That discipline, prove one path before starting the next, is why every number in this deck traces to a live row rather than a mockup.
Reading the stack: in tour mode, layers light amber top to bottom as a generic explainer. In story mode, choose any of the five stories above, the pulse runs bottom to top for that story's own real path: feeds write into L2, when a feed is involved, L1 validates the shape of every fact, L3 computes the answer using whichever engine that story actually needs, causal model, solver, or temporal query, L4 exposes it as one typed verb, or no verb at all for Story E's refusal, L5 narrates it, L6 renders it, and L0 lights on every single hop, because provenance logs from every layer, not just the top.