Everything GlassBox ever says is a view over this layer, and it cannot be retrofitted later, so it is built first. Every fact arrives with both a valid time and a transaction time, is never updated or deleted, and projects deterministically into the knowledge graph. Nothing here involves an LLM.
| event | entity | change | valid time | transaction time | source |
|---|
Three layers go in: connectors, the bitemporal store, and the graph projection. Nothing above them exists yet, and that is deliberate. Truth first, language last.
Gantt, as-of slider, proof explorer arrive in Phase 1. React
phase 1No language layer yet. Phase 0 is entirely deterministic. LM Studio
phase 1Rules need something real to act on first. React Flow
phase 2Rules and CP-SAT scheduling arrive in Phases 1 and 2. OR-Tools
phase 1Retrieval arrives once the graph exists. pgvector
phase 1RDF projection, ~15-class ontology, PROV-O links from every triple back to its event. Oxigraph · SHACL
newAppend-only bitemporal store with as-of query helpers. The foundation. PostgreSQL 16
newWebhooks plus REST backfill, emitting one canonical envelope. Idempotent by checksum. Python · FastAPI
newPhase 0 produces no screens a user would enjoy. It builds the ledger. Every change in your project tools is copied into a permanent, append-only record that nobody, including us, can quietly edit afterwards. Think of it as moving from a whiteboard that gets wiped to a bound accounting book.
It is first because it cannot be added later. Every capability in the later phases is a view over this record, so if it is missing or incomplete, nothing above it can be trusted.
Three services and two stores, with the schema written out so an engineer on the client side can audit the design before a line of it runs. The numbered path is one Jira change becoming a queryable triple.
Follow the numbers. Information leaves your Jira, is normalised into one standard shape regardless of which tool it came from, is written once into a database that only ever adds rows, and is then projected into a map of how everything connects. The database is the truth; the map can be rebuilt from it at any time.
The two coloured columns in the store are the important detail: every record carries both the date something became true and the date you learned it. That single decision is what makes later audit questions answerable.
This phase is intentionally boring engineering. Its value is that everything downstream inherits replayability for free.
One canonical schema every connector emits: source, entity, payload, both timestamps, actor, checksum. Freeze it early; everything hangs off it.
schema v0Append-only Postgres table plus as-of query helpers. No updates, no deletes, ever. Duplicates are harmless because inserts are checksum-idempotent.
PostgreSQL · SQL:2011 patternsWebhook listener for live changes, REST backfill for history, changelog parsing that recovers true valid times from Jira's own history.
~300 lines of PythonDeterministic code, not an LLM, that turns events into RDF triples with PROV-O provenance. Re-runnable, so the graph is a rebuildable view.
Oxigraph · named graphsThese are small, well-understood components: a standard record format, a database that only adds, a connector that reads Jira, and a routine that turns records into a connected map. There is no AI anywhere in this phase, and no novel technology.
That is intentional. The engineering risk in this programme belongs in later phases; here we want boring components that will still be running in five years.
The projection is one-way and deterministic. If the ontology changes later, we drop the graph and rebuild it from the events. That escape hatch is why an early modeling mistake is survivable.
Live change events plus a REST backfill of project history.
Both clocks resolved: valid time from the changelog, transaction time from arrival.
Checksum-deduplicated. Nothing is ever mutated, so history stays intact.
Deterministic mapping into the ontology, each triple carrying PROV-O back-links.
Any past state reconstructed on demand, on either clock.
Someone updates a ticket. Within seconds we receive the change, work out when it truly took effect by reading the tool's own history, stamp when we received it, check we have not seen it before, and store it permanently. Then we update the connected map of the project.
The query at the bottom is the entire value of the phase in one statement: change one date in that query and you see the project as it was, on either clock, at any point in the past.
Completion is not a status report. It is a five-minute demonstration on your own data: pick any date, see the project as your team understood it that morning, then switch clocks and see what was actually true, including things that only surfaced later.
If that demonstration works on your real Jira export, the foundation is sound and the programme can continue. If it does not, nothing later would have been trustworthy anyway.