Most Agentic AI is a large language model wrapped in a to-do list. The model itself is an autoregressive probability distribution: it predicts which word plausibly follows the last one. Nothing inside it represents your project. There is no variable for "is this milestone actually late," no field for "was this invoice paid," no memory of what it did an hour ago. It is fluent. It is not grounded.
Today's agentic PM tools are orchestrated prompt pipelines: impressive in a demo, unaccountable in a deployment. GlassBox inverts the architecture. A bitemporal event store and a knowledge graph hold the truth, a symbolic engine does the reasoning, and the LLM only translates. Every statement carries its derivation, and every report can be replayed as of any date.
The film runs for about seventy seconds and loops. It follows a single blocked ticket, from the project manager who causes it to the director who reads about it: one event travelling through every layer of the system, rather than a montage of features. The badge in the top right corner names the layer as it passes.
Each scene below states what is on screen, and the question it settles.
A Jira board. OILSIM-247 moves into the Blocked column and a comment appears beneath it. Nothing on this screen belongs to GlassBox: it is your board, your workflow and your people, read through the API and never written to.
Does this mean another tool to adopt? No. There is no rollout programme and no retraining, because nobody's working day changes.
The change becomes a nine-field record, appended to a log that is never edited. There are two date columns, one for when the fact became true and one for when the organisation learned of it, and on this row they differ by two days.
How is this different from a database? A conventional system would have overwritten Friday's state with Monday's, leaving no way to show that the gap ever existed.
An as-of control replays the same question against 1 March and against 2 March. The first answers on track, finishing 18 March. The second answers at risk, finishing 1 April.
What is this actually for? Post-mortems, disputes, claims and audits, where the question is never what is true now, but who knew what, and when.
A dependency graph. The blocked ticket turns red and the impact is traced through two named hops to milestone M3, while the same individual is resolved to a single identity across three systems.
Is the model inventing these connections? No. The map is projected from the ledger and can be rebuilt from it at any time.
Four blocks describe an escalation rule in business terms. A dry run then replays that rule against fourteen months of your own history: six firings, five of them real and one a false alarm.
Will we depend on your consultants to change anything? No. The definition of at risk is yours to author, and to test against your own past before switching it on. No competing product can offer that dry run, because none keeps a replayable history to test against.
The rule fires, and the escalation is written straight back into the same append-only log, as row 9183. Conclusions are recorded exactly as inputs are.
Can you explain a decision made two years ago? Yes, and not from memory. The record states which version of which rule fired, on which facts, at which moment.
A typed question, the compiled query shown before it runs, and two panels: what the language model was permitted to do, and what it is never allowed to touch. It selected a question type and extracted two values. It was not given a calculator.
How do we know it is not making things up? It cannot invent a number, because it never computes one. Change the model and every figure on the page stays identical.
A Gantt chart re-plans under real resource limits: the critical path in red, M3 moving from 18 March to 1 April, solved in under a second. This is industrial scheduling, the same class of solver used in plant planning, and it accounts for who is actually available.
Why does this disagree with our current tool? Classical critical path assumes unlimited people. This does not, and where the two differ it is usually the constrained answer that holds.
Three drafted sentences. The second is flagged, struck through and removed because no record supports it. The two that survive carry citations. The deleted sentence is entirely plausible, and every other tool would have shown it to you.
What about hallucination? It cannot be eliminated, only contained. Anyone can demonstrate a good answer; this demonstrates a bad one being caught.
A board-ready status page. Clicking a citation opens the underlying event, with both timestamps, the source system, the person responsible and a hash. One document serves two audiences: the director reads two sentences, the auditor clicks through to the raw fact.
What does compliance cost? Nothing additional. The EU AI Act Article 12 record is a by-product of the architecture rather than a separate programme of work.
The current generation, subagents fanning out over Gmail, Jira, and Drive and then writing conclusions into spreadsheets, makes the LLM the reader, the reasoner, and the source of truth at once. Project management is roughly 70% a symbolic domain (dates, dependencies, capacity, thresholds) and 30% a linguistic one (notes, narratives, risk descriptions). Agent products use a linguistic engine for the symbolic 70%. MIT's finding that failed pilots lack memory and adaptability, not model quality, points at the same root cause.
Most AI project tools work like a very fast assistant who reads everything, forms an opinion, and then throws away the paperwork. The opinion is often good. The problem is that you cannot check it, cannot reproduce it, and cannot show anyone how it was reached. Ask the same question next week and you may get a different answer, with no way to tell which one was right.
That is tolerable for brainstorming. It is not tolerable for the numbers in a steering pack, a claim against a supplier, or a board-level status call. The moment an AI answer needs to be defended, today's tools go quiet.
No statement without a derivation, no derivation without events, no event without a source and two timestamps. Blue layers are symbolic: deterministic and auditable. Amber layers are neural: a local LLM, strictly confined to language.
Gantt with critical path, dashboards, the as-of time slider, and the proof explorer. frappe-gantt · React
Four bounded jobs: NL→query, extraction (human-confirmed), cited narration, canvas copilot. LM Studio / Ollama / vLLM
Drag-and-drop rules that compile to formal logic. Every save is a versioned event. React Flow → IR → rules
Datalog-style rules derive escalations and risks; CP-SAT solves schedules and what-ifs. SPARQL CONSTRUCT · OR-Tools
Hybrid retrieval: SPARQL for structure, entity-linked vectors for prose, community summaries for global questions. pgvector · RRF fusion
RDF under a compact PM ontology, PROV-O provenance on every triple, SHACL validation as continuous data hygiene. Oxigraph · W3C standards
Append-only, bitemporal. The truth everything else is a view of. PostgreSQL · valid-time × transaction-time
Thin, idempotent adapters emitting one canonical event envelope. Jira · GitLab · ADO · CSV · webhooks
Think of it as a filing system with a very good librarian on top. The bottom layers record what happened, in order, and never allow anything to be quietly edited. The middle layers apply your organisation's rules to those records. Only the top layer uses AI, and only to turn the result into a readable sentence.
This ordering is the whole design. Because the AI sits at the end rather than the middle, a mistake by the model produces awkward wording, not a wrong number.
The seven layers above are the concept. This is the deployment: which processes run, what they store, and which protocol carries data between them. Nothing crosses the appliance boundary, and the numbered path is the life of a single fact from a Jira webhook to a cited sentence on screen.
This is the diagram your IT and security teams will ask for. Everything sits on one machine inside your network, behind your firewall. Your existing tools push information in. Nothing is sent out, to us or to anyone else. There is no cloud service, no usage meter, and no external AI provider in the path.
For regulated industries this usually settles the security conversation in one meeting, because the thing they normally worry about, data leaving the building, is architecturally impossible here rather than merely discouraged.
Every fact carries two timestamps: valid time, when it became true in the world, and transaction time, when your system learned it. The gap between the two clocks is exactly the set of facts nobody knew at decision time. That list is the audit-defense feature no agent product can produce, and to our knowledge no published temporal-KG system offers it either: academic work is single-clock.
So the system answers both questions honestly: "show the project as we believed it the day we decided" and "show what was actually true that day, including what we learned later." The diff between them is the post-mortem, computed instead of argued.
Every fact we store carries two dates: when the thing actually happened, and when your organisation found out about it. Ordinary systems keep only the second one, and overwrite it as things change. That is why post-mortems turn into arguments about who knew what.
With both dates recorded, two different questions get honest answers: "what did we believe when we made that call?" and "what was actually true at the time?" The gap between them is the list of things nobody could have known. Computed, not argued.
Connectors are commodities. LLMs are commodities. The genuinely hard part of deployment is capturing how this company runs projects, and that is exactly what the no-code canvas makes tractable. A delivery lead drags this together in minutes; it compiles to formal rules; every save is versioned in the event store. Rules can even be dry-run against project history before publishing, because the bitemporal store makes replay trivial.
Compiles to SPARQL CONSTRUCT + SHACL: a constrained palette that produces sound rules, not a workflow language that produces mush. A local-LLM copilot proposes nodes from a plain sentence; the human wires and approves. In process-mining terms, your compiled rules become a continuous conformance check of the project against its own operating model.
Every organisation runs projects slightly differently. What counts as "at risk", who gets told, and when something must be escalated are judgement calls specific to you. Capturing those rules is normally a consulting exercise that produces a document nobody maintains.
Here, a delivery lead draws the rule on a canvas in a few minutes, tests it against the last six months of real history before switching it on, and the system enforces it from then on. Your operating model stops being folklore and becomes something the system actually applies.
Every answer is a derivation rendered from recorded rule firings, not a paragraph reconstructed from a vanished context window. This is what you hand an auditor, a client in a dispute, or a regulator. It is also, nearly verbatim, the audit log the EU AI Act's Article 12 asks for.
Every statement the system makes can be opened up like a set of accounts. Click a claim and you see the rule that fired, the version of that rule, the facts it used, the original record those facts came from, and both dates. It is the difference between a colleague saying "I think we are late" and handing you the working.
This is also, almost word for word, the record the EU AI Act asks for from high-risk systems. We produce it as a by-product of how the system works, rather than as a compliance project bolted on afterwards.
Everything that determines correctness is OSI-licensed and standards-based (RDF, SPARQL, SHACL, PROV-O are W3C specs, itself an auditability argument). The LLM runtime is pluggable behind one OpenAI-compatible URL.
| Layer | Choice | License |
|---|---|---|
| Events + vectors | PostgreSQL 16 + pgvector | PostgreSQL |
| Triplestore | Oxigraph | MIT / Apache-2.0 |
| Optimization | OR-Tools CP-SAT | Apache-2.0 |
| Backend | Python · FastAPI | MIT |
| Canvas / UI | React + React Flow | MIT |
| Gantt | frappe-gantt | MIT |
| LLM serving | LM Studio → Ollama / vLLM | pluggable |
| Deployment | Docker Compose · air-gap ready | · |
Everything that determines whether an answer is correct is open source and built on published international standards. That is a deliberate commercial decision, not a cost-saving one. It means the system can be inspected by your own engineers, audited by a third party, and kept running by someone other than us.
The AI model is the one genuinely swappable part. Because correctness never depends on it, you can change models, or run a smaller one on cheaper hardware, without affecting a single number the system reports.
The bitemporal core comes first because everything else is a view over it and it cannot be retrofitted. The canvas comes after grounded Q&A, because rules need something real to act on. Each phase has its own architecture page and a demo a client can watch.
Event envelope, bitemporal Postgres, Jira connector, graph projection.
exit: as-of queries answer in SPARQL PHASE 1 · 4–6 WKSCited answers, critical-path Gantt, as-of slider, proof explorer v1.
exit: the May-3 audit demo runs end to end PHASE 2 · 4–6 WKSReact Flow rule editor, compiler, versioning, dry-run against history.
exit: a non-programmer encodes 3 real policies PHASE 3 · 3–4 WKSEntity-linked chunks, hybrid retrieval with RRF, community summaries.
exit: global risk answers survive citation checks PHASE 4More connectors, data-quality panel, RBAC + SSO, air-gap install.
exit: production deployment on client metalThe programme is built so that something demonstrable exists early and each phase stands on its own. Phase 0 and 1 together, roughly two months, produce a system that answers real questions about your real projects and can prove every answer. That is the point at which you can judge whether to continue.
The order is deliberate. The record-keeping foundation cannot be retrofitted later, so it is built first, before anything that looks impressive in a demo. Each phase ends with a specific demonstration, not a status report.