Policy Logic Forge turns compliance policy text into a typed, source-grounded knowledge graph. Every rule is independently re-verified against the source document — not just cited — and the system draws a hard line between three different questions: does this point to a source, is each claim actually supported, and is this rule safe to execute unattended.
Naive LLM extraction gives you one confidence-flavored number and hopes you don't ask what it means. That number is almost always quietly averaging three fundamentally different questions together — and treating a passing average as permission to trust every individual rule it covers.
Every rule needs a citation — but a citation isn't proof the claim it supports is actually true.
A claim-by-claim check, independent of extraction, against the real corpus text — not the model's memory of it.
Strict, whole-rule certification is a much higher bar than any single supported claim — and the two get conflated constantly.
Source passage → concept → rule → decision or process model — and back again: model element → rule → claim → the exact passage that supports it. Every stage writes its own checkpointed artifacts; nothing downstream trusts an upstream claim without its own verification pass. This is the real pipeline topology, not an illustration of it.
flowchart LR
classDef stage fill:#eef1ff,stroke:#5b5bd6,color:#232a55,stroke-width:1.3px
classDef gate fill:#fff2dc,stroke:#c8790f,color:#4a2f04,stroke-width:1.3px
classDef io fill:#e6f7f2,stroke:#0f9d80,color:#0b3b30,stroke-width:1.3px
DOCS([Source documents]):::io
A1[01 · Organize]:::stage --> A2[02 · Entities]:::stage --> A3[03 · Rules]:::stage
A3 --> A4[04 · Validate]:::stage --> A5[05 · Merge]:::stage --> A6[06 · Optimize]:::stage
A6 --> A7{{07 · Readiness gate}}:::gate
A7 -. review .-> A8[08 · Remediate]:::stage
A8 -. re-check .-> A7
A7 --> A9{{09 · Ground independently}}:::gate --> A10[10 · Dependency DAGs]:::stage --> A11[11 · DMN·BPMN·CMMN·SBVR]:::stage
A11 --> A12[12 · LinkML information model]:::stage --> A13[13 · Knowledge report]:::stage
DOCS --> A1
A13 --> OUT([Certified graph + review-ready models
+ one traceable report]):::io
Stage 09 (Grounding Verifier) is deliberately independent of extraction: it rebuilds evidence from the raw corpus itself rather than trusting a stored citation. A hallucinated citation cannot pass. See the full execution flow in the architecture reference.
| Stage | Agent | Responsibility | Primary output |
|---|---|---|---|
| 01/13 | agent_01 | Document organization | agent_01-organized-documents/ |
| 02/13 | agent_02 | Entity & relationship extraction | agent_02-entities/ |
| 03/13 | agent_03 | Business-rule extraction | agent_03-rules/ |
| 04/13 | agent_04 | Advisory rule validation | agent_04-validation/ |
| 05/13 | agent_05 | Rules/entities merge | agent_05-rules-with-entities/ |
| 06/13 | agent_06 | Knowledge-graph optimization (dedup + dependency analysis) | optimized_compliance_knowledge_graph.json |
| 07/13 | agent_07 | Executable-readiness gate — four invariants | readiness report |
| 08/13 | agent_08 | Readiness remediation (only if agent_07 requests it) | focused rule fix-ups |
| 09/13 | agent_09 | Independent, claim-level grounding verification | grounding certification report |
| 10/13 | agent_10 | Dependency-DAG generation — 100%-coverage guarantee | dependency_dags.json |
| 11/13 | agent_11 | DMN/BPMN/CMMN/SBVR generation + LExec compile | agent_11-executable-models/ |
| 12/13 | agent_12 | Business information model — LinkML schema, typed attributes, enumerations | business_information_model.yaml |
| 13/13 | agent_13 | Self-contained business knowledge report | business_knowledge_report.html |
A deterministic guard checks whether two rules in a claimed dependency share any variable name at all — deliberately weak, catching only the clearest false positives. It exists because it isn't the last line of defense: independent grounding verification is.
A second, fully independent pass — agent_09 — re-derives
evidence for every claim straight from the raw corpus, rather than
trusting what extraction already recorded. It shares no code path,
no prompt, and no state with extraction, so a mistake made during
extraction has to independently survive a second, differently-built
check before it's ever accepted.
Every model verdict of supported/contradicted is downgraded to insufficient evidence unless the cited quote resolves to a genuine substring of the real corpus text — a hallucinated citation cannot pass, even if the model insists it's supported.
Claims that are pipeline-derived rather than sentences any document states verbatim — condition logic, test vectors — are deliberately excluded from this model-based check and verified structurally instead: predicate coverage, input/output consistency against the rule's own declared variables.
Every run emits real, standards-conformant artifacts grounded in the certified graph — reviewable by a business analyst, importable into a real decision-modeling tool, not a bespoke JSON shape invented for this project.
One decision table per rule — real input/output columns and a FEEL-expressed rule row, not a diagram approximation.
Generated only where a rule has an explicit, source-evidenced trigger, actor, and at least two ordered steps. A party plus an outcome is not a process — sometimes the most accurate diagram is no diagram.
Review-and-remediation cases for anything routed to human judgment or case management, with a real task and milestone structure.
A governed business vocabulary kept honestly separate from executable decision variables — a rule-local predicate isn't promoted into the vocabulary just because it exists, so the concept catalog stays a real glossary instead of a symbol dump.
Rules test and set business values. Those values are a domain model in their own right — and it is emitted as a LinkML schema rather than a class diagram, because a schema can be checked, generated from, and diffed where a picture can only be looked at.
flowchart LR
classDef canon fill:#fff2dc,stroke:#c8790f,color:#4a2f04,stroke-width:1.6px
classDef proj fill:#eef1ff,stroke:#5b5bd6,color:#232a55,stroke-width:1.2px
classDef check fill:#e6f7f2,stroke:#0f9d80,color:#0b3b30,stroke-width:1.3px
C[[business_information_model.yaml<br/>canonical]]:::canon
V{{validated against LinkML's own metamodel}}:::check
C --> V
V --> A[JSON Schema]:::proj
V --> B[class diagrams]:::proj
V --> D[class/attribute catalog]:::proj
V --> E[validation report]:::proj
V -.-> F[SHACL · OWL · SQL DDL<br/>Pydantic · TypeScript]:::proj
A declared unit gives Money, Percentage or
Duration; a closed value set gives a named enumeration
even when the rule said string. Only a variable with
nothing declared falls through to its name — and that is always
flagged.
The diagrams, the catalog and the JSON Schema are generated from the one canonical schema, so they cannot disagree with the model or with each other.
Classes group by what kind of thing they are; attributes by what kind of value they hold. On a real privacy corpus that inventory reports 70% of attributes are booleans recording whether a rule passed — describing what was decided, not what the business holds state about.
An attribute the pipeline cannot confidently place is held for review rather than filed under a guess, because a misfiled attribute quietly corrupts the model while an unplaced one is merely reviewed.
A differential-execution engine layered on top of the pipeline: compile two versions of a policy to a shared intermediate representation, align their rules, classify what semantically changed, and propagate the impact through the dependency graph — so a policy update tells you which downstream rules and cases actually need re-review, not just that something changed.
Read the RegDelta architecture →