17 ms·
Datalog seems like a way to "spell" knowledge graph (KG). The article touches on Datalog statements changing over time. One ingredient I think would be good t
by frumiousirc 19d ago
Datalog seems like a way to "spell" knowledge graph (KG).
The article touches on Datalog statements changing over time. One ingredient I think would be good to add to the system is to make every statement carry "providence" metadata. The providence should be sufficient to enable later confirmation that a statement is still valid or if the statement needs to be reformed without the need to remake the entire graph from scratch.
I would make at least some forms of providence follow a strict schema that is defined for the subject matter that is being captured. For example, statements about a code base should refer to the source files and their version (file modification date, content hash) from which the statements were concluded. When a source file is modified we may then find all statements made from them and reevaluate just those statements.
The next level would be to keep statements even if reevaluation breaks them and add a method to derive a subgraph for a given state of the subject. For example, over many releases of a code base, a lot of statements would not change, some would. Having a graph that spans all conclusions about all releases of a code base and a way to form the subgraph for a specific release would allow the system to efficiently target queries for a particular release.
- GrinningFool 19d ago*provenance
- pixelsort 19d agoThe OP rediscovered that frontier models prefer to reason over logical scaffolding for complex tasks. They excel at technical work with many constraints as they can perfectly maintain the references, flow graph, and evidence states while they works through your conformance gates. Many people here might disagree; but they're holding it wrong. Those folks should ask: 1. Am I using free tier tokens? 2. Am I working on trivial software? 3. Am I expecting models to adapt to my ways of thinking? Anyone affect by any of these three mistakes will maintain an impenetrable filter of perpetual ignorance about model capabilities. Since the OP came with receipts, I'm reproducing an example graph below. From a plan in my active research project: Phase 0 resolve -> vendor -> pin [USER+agent] -> G0 CORPUS-RESOLVED [PASS] Track B B1 Abusalah [WRITTEN] [agent] -> G1B Q-BOUNDARY B2 Guan-Riazanov-Yuan [WRITTEN] (KILL-BOUNDARY risk) B3 Mahmoody-Smith-Wu [WRITTEN] + O-MSW-VERIFIER-COST closed (t = 588, MEASURED) -> G1B PASSED: BOUNDARY-ESTABLISHED Track A 05 Binius [WRITTEN] [agent] -> G1 AUDITS-COMPLETE [PASS] 2026-08-28 07 FRI-Binius 2024/504 [WRITTEN] — vendored by USER; calculated Q-FLOOR point obtained 06 HOBBIT [WRITTEN] — O-QUEUE-M escalated to 179 Phase 2 01 Wesolowski [WRITTEN] — hinge splits; C_overlap = 0, C_tail = 57.50% computed 02 Tight VDFs [WRITTEN] — no omega; O(log T) proof threads; black-box RO base impossible 03 LaBRADOR (light) [WRITTEN] — calculated, not measured; translation remains open 04 LatticeFold+ -- deferred to pre-141 Track C [PASS] C0a contract -> C0b exact simulator -> G0C TRANSLATION-READY C2 Alwen-Serbinenko [TECHNIQUE-ONLY] -> C1 SoW [PASS] ANCESTRY-FOUND -> C4 Seeded PoW [FORM-ONLY] -> G1C [RED] WORK-LEMMA-MISSING [WARN] ANCESTRY-CLASSICAL -> L0 [PASS] SCOPE-FROZEN |- E0 response [PASS] PRESENT `- L1-L2 local [PASS] CARRIER-QUOTIENT -> J0 [PASS] TECHNIQUE-FIT CONFIRMED -> admission decision [PASS] CANONICAL RESULT -> A0 [AMBER] REFERENCE-TESTED -> A1 [PASS] ROOT-LEAF FEASIBILITY LEAD -> semantic equivalence + epoch [USER] C3, C5 -- deferred to pre-141 Phase 2 Q-TAIL / Q-FLOOR synthesis [agent] -> [PASS] G2: TAIL-MECHANISM-FOUND · FLOOR-OPEN Phase 3 reference ledger for 141 [agent] -> CLOSED; awaits fresh USER authorization
- convolvatron 19d agoif you aren't familiar with the literature, then good on you for getting the right insight. provenance and support are staples of the datalog world. the other really handy thing here is that it very straightforward to differentiate datalog rule sets. so if you change a fact, you can run a smaller solution that tells you which consequences are affected by the change. under the assumption that the evaluator is pure, we don't need to keep the support graph as you suggest, we can just generate the deltas from evolution of the differentiated form. detailed provenance can be of real application utility, but if you just care about the accounting, keeping track of the number of supports for each fact is sufficient. another model which is fun is to make the version of the database (monotonic time) an explicit field in your base facts, assuming you can afford to keep the whole history. a deletion then is just a negative-support, and you can ask questions about the state of the world at any time.
- grey-area 19d agoI think you mean provenance, not providence