Capturing how a company actually runs projects is the hard part of every deployment. Phase 2 turns it into a drag-and-drop canvas: a delivery lead wires policy nodes together, and the canvas compiles to formal, versioned, provable rules. No prompts, no code, no consulting engagement.
Drag a node onto the canvas, or click it to drop one in. Drag from a right-hand port to a left-hand port to wire them.
Click a node to edit it. Click a wire to remove it.
Phases 0 and 1 built the truth (events, graph) and grounded answers (queries, Gantt, proofs). Phase 2 adds the layer that makes GlassBox yours: authored judgment. Amber marks what is new in this phase; gray is already running; dashed is still ahead.
Gantt, as-of slider, proof explorer. Phase 2 adds the rule editor screen. React
runningNew job: propose canvas nodes from a plain sentence. Human wires and approves. LM Studio API
newThe whole layer arrives: editor, palette, compiler, versioning, dry-run. React Flow → IR
newCompiled rules execute to fixpoint; every firing is recorded as an event. SPARQL CONSTRUCT · SHACL
newEntity-linked vectors and community summaries arrive in Phase 3. pgvector · RRF
phase 3RDF graph with PROV-O provenance, built in Phase 0. Oxigraph
runningAppend-only bitemporal store. Now also records rule versions and firings. PostgreSQL
runningMore connectors arrive in Phase 4. webhooks + backfill
runningUntil now the system reports facts. Phase 2 lets it apply your judgement. Your definition of "at risk", your escalation ladder, your thresholds and your exceptions get drawn onto a canvas and enforced automatically from then on.
This is normally the part that fails. Companies pay consultants to document how they run projects, the document is out of date within a quarter, and nothing enforces it. Here the rule is the enforcement, and changing it takes minutes rather than a change request.
The canvas never executes. It compiles. Authoring happens in the upper plane, where a human and a copilot are free to be imprecise; execution happens in the lower plane, where only type-checked artifacts are allowed to run. The compiler between them is the reason a no-code surface can stay auditable.
The top half of this diagram is where people work, and people are imprecise. The bottom half is where rules run, and it accepts nothing that has not been formally checked. The compiler in the middle is the only route between them, and it refuses anything ambiguous with a plain-language error.
This is why a no-code tool can still be audit-grade. The friendly canvas is not what executes. What executes is a checked, versioned artefact produced from it.
The canvas is deliberately not a general workflow engine. No loops, no code nodes. A constrained palette that compiles to sound rules beats an expressive one that compiles to mush.
Pan, zoom, minimap, undo, click-to-configure nodes, live validation of dangling wires.
React Flow (MIT)Source, mapping, condition, rule, threshold/KPI, escalation, and report nodes. Calendars understand business days and local holidays.
typed node schemaCanvas JSON to a typed intermediate representation, then to SPARQL CONSTRUCT rules and SHACL shapes. The IR is the contract; engines behind it can change.
canvas → IR → rulesEvery save is a version; every version is an event in the bitemporal store. "Why did this escalate in April but not now?" has a provable answer.
events, like everything elseReplay any draft rule over past project events before publishing. See exactly what it would have flagged, and when. Competitors cannot do this; their systems have no replayable past.
bitemporal replayDescribe a policy in one sentence; the local LLM proposes candidate nodes. The human wires and approves. Neural at authoring time, symbolic at runtime.
local LLM · human-approvedFive of these six components are what you would expect from a decent rules tool. The sixth, testing a draft rule against real history before switching it on, is the one that matters and the one nobody else can offer.
Because we keep a complete, replayable record of the past, you can ask "if this rule had been live since January, what would it have flagged?" and get a precise answer before committing to it. Competitors cannot do this: they have no replayable past to test against.
The studio above shows an escalation policy. The same seven node types express thresholds and reporting rules too. "When budget burn crosses 80% before 60% of the timeline has elapsed, raise a finance risk and add it to the steering pack":
In process-mining terms, a published rule is a continuous conformance check: the project is monitored against your own operating model, not a generic template. Rule governance matches what mature decision-engine buyers expect: versions, approvals, audit trail, and simulation before publish.
The escalation example above and the budget example here use exactly the same building blocks. That consistency is what keeps the tool learnable: a delivery lead who understands one rule understands all of them, and the palette does not grow every time a new requirement appears.
It also has a useful framing for anyone who has bought process-mining software: a published rule is a continuous check of your projects against your own operating model, rather than a generic industry template.
Nothing on the canvas executes directly. It compiles, and only the compiled artifact runs. That is what keeps a no-code surface auditable.
Nodes and wires, validated live in the editor.
The contract. Type-checked conditions, resolved calendars, bound graph terms.
CONSTRUCT rules run to fixpoint over the graph; shapes validate continuously.
Every firing stored as an event: rule ID, version, input facts, derived fact.
The explorer renders firings directly. Same events + same rules = same output.
The canvas is saved as a document, translated into a formally checked intermediate form, and only then turned into something the engine runs. Each time the rule fires, the system writes down which rule version fired, on which facts, and what it concluded.
That recording is what makes the proof screen possible. The explanation you show an auditor is not reconstructed after the fact; it is the actual execution record.
The acceptance test is deliberately uncomfortable for us: one of your project managers, not one of our engineers, encodes three of your real escalation policies with no help beyond the on-screen assistant. If they cannot, the phase is not finished.
We test the handover, not the software. A rules engine only your vendor can operate is a consulting dependency wearing a product badge.