GraphNews

6121 bookmarks
Custom sorting
State of Data Products 2026 Q2
State of Data Products 2026 Q2
Calling something "agent observability" can be misleading. In many cases, it's still just execution monitoring. It measures whether the agent completed a task, how long it took, and whether it failed, but it offers little insight into whether the agent actually reasoned correctly within the context of your business. 𝐖𝐡𝐚𝐭 𝐞𝐱𝐞𝐜𝐮𝐭𝐢𝐨𝐧 𝐦𝐨𝐧𝐢𝐭𝐨𝐫𝐢𝐧𝐠 𝐜𝐚𝐭𝐜𝐡𝐞𝐬: 𝐥𝐚𝐭𝐞𝐧𝐜𝐲, 𝐭𝐨𝐤𝐞𝐧 𝐜𝐨𝐮𝐧𝐭, 𝐀𝐏𝐈 𝐬𝐮𝐜𝐜𝐞𝐬𝐬, 𝐫𝐞𝐭𝐫𝐢𝐞𝐬 Useful telemetry, genuinely. None of it checks whether the agent's output was grounded in the right definition of "customer" or the right version of "revenue" for your business. 𝐖𝐡𝐚𝐭 𝐢𝐭 𝐦𝐢𝐬𝐬𝐞𝐬 𝐞𝐧𝐭𝐢𝐫𝐞𝐥𝐲: 𝐰𝐡𝐞𝐭𝐡𝐞𝐫 𝐭𝐡𝐞 𝐫𝐞𝐚𝐬𝐨𝐧𝐢𝐧𝐠 𝐰𝐚𝐬 𝐜𝐨𝐫𝐫𝐞𝐜𝐭 An agent can execute flawlessly against a wrong premise, every single time, and every dashboard you own will show green the whole way through. This is where many AI pilots fail to leap into production. The business never gave the agent a governed definition of its own concepts, so every agent is quietly guessing at meaning it was never handed. At small scale, that's a rounding error. At agentic scale, across thousands of calls a day, that guess compounds into liability. 𝐓𝐡𝐞 𝐝𝐢𝐬𝐭𝐢𝐧𝐜𝐭𝐢𝐨𝐧 𝐭𝐡𝐚𝐭 𝐦𝐚𝐭𝐭𝐞𝐫𝐬 Ontology defines meaning; observability validates that the agent's decisions align with it. But most teams have built neither. They've rather built dashboards for execution and called the problem solved. ➡️ Courts are already converging on this. The emerging principle in AI-related liability cases is "omission is liability"; not having a definition on record is treated the same as having a wrong one. ➡️ The organisations closing the trust gap this quarter aren't running newer models. They fixed ontology and observability underneath the model first, then let the model be whatever model. ➡️ 82% of the transformation value enterprises expect from agentic AI depends on capabilities that don't exist yet, per Gartner. That value sits on infrastructure most companies haven't built. This is the spine of our 𝐐2 𝐒𝐭𝐚𝐭𝐞 𝐨𝐟 𝐃𝐚𝐭𝐚 𝐏𝐫𝐨𝐝𝐮𝐜𝐭𝐬 𝐫𝐞𝐥𝐞𝐚𝐬𝐞. This edition also has a piece on RDF-based semantic layers, and a good one on where semantic models end and semantic layers begin. If you're staring at a pile of pilots wondering why none of them has graduated to production, this one's worth a decent few minutes. 🔖 𝐑𝐞𝐚𝐝 𝐡𝐞𝐫𝐞: https://lnkd.in/dj8GgHTe #Ontology #AIObservability #DataArchitecture
·linkedin.com·
State of Data Products 2026 Q2
From prompt engineering to graph engineering
From prompt engineering to graph engineering
🫠 Over the past few months, so many new "engineering" terms have come up that it’s becoming incredibly hard to keep up. IMHO, I think a lot of people are trying to put new terms around everything, and it’s making the space far more confusing than it needs to be. There also seem to be several different definitions for every term. Prompt engineering and context engineering were at least reasonably well understood. But now we have harness engineering, loop engineering, and graph engineering, and different people seem to mean completely different things by them. ⛳ For instance, a large number of people describe harness engineering as designing the harness around an agent. That includes permissions, tools, memory, context compaction, evaluations, observability, and the broader system that controls how the agent operates. ⛳ Others seem to use harness engineering to mean working with an existing harness so that you can get the most out of coding agents, which starts to overlap heavily with loop engineering. ⛳ Loop engineering itself also has several definitions. Some people describe it as simply setting up automated checks and conditions that allow an agent to keep iterating. Others use it more broadly to describe how humans, agents, evaluators, and feedback systems interact across inner loops and outer loops. ⛳ Then there’s graph engineering, which adds another layer of confusion. It seems to refer to explicitly designing the states, transitions, branches, and control flow through which an agent or workflow operates. At the most basic level, I really hope these definitions are roughly correct, but who knows? Everyone seems to have their own interpretation. The more I read about these terms, the more I wonder whether all of this was already part of designing agentic workflows. 🫠 Why are we introducing entirely new terms for ideas that were already part of building agentic systems? Anyway, whipped up a quick diagram for your reference and happy to have you debate it too, no hard feelings, we're all confused!
·linkedin.com·
From prompt engineering to graph engineering
Graft: Turbocharge Claude Code, Cursor, Codex, Gemini & every coding agent: faster, cheaper, with contextual understanding specific to your codebase.
Graft: Turbocharge Claude Code, Cursor, Codex, Gemini & every coding agent: faster, cheaper, with contextual understanding specific to your codebase.
graph
·github.com·
Graft: Turbocharge Claude Code, Cursor, Codex, Gemini & every coding agent: faster, cheaper, with contextual understanding specific to your codebase.
The Semantic Units Framework, a technology-agnostic representational approach to FAIR and CLEAR knowledge infrastructures - Scientific Data
The Semantic Units Framework, a technology-agnostic representational approach to FAIR and CLEAR knowledge infrastructures - Scientific Data

The Semantic Units Framework by Lars Vogt is a spiritual follow-up to Rosetta Statements, and a far more detailed exploration of the wider idea. To recap, Rosetta Statements were more of a tool for converting simple English language statements (“n-ary” statements, you might recall) into RDF triples. The idea was to encode some basic rules of English syntax into RDF to make knowledge graph construction easier.

The broader Semantic Units Framework, however, is broader in scope, and more abstract. Vogt refers to it as ‘conceptual in nature’ and more of a philosophical approach to knowledge graph creation, rather than a proposal for any specific technology or standard. It can be applied to RDF (and indeed they use an RDF framing within the paper) but it is not specific to RDF. In fact, a lack of universal meaning to the term ‘graph technology’ is cited as one of the many motivations for the paper.

Rather, the paper talks more generally about how natural language can be used to construct FAIR knowledge graphs, and various challenges that may be encountered. There is a particular emphasis on how to expand the notion of knowledge and information beyond that of ‘individual facts’, which is how a single graph entity (or RDF triple) is often constructed. How do we handle statements that may be only mostly or partially true? How do we handle abstract, existential claims, or context?

Vogt proposes a two fold approach: (1) the quantification of ‘semantic units’ as first-class objects, and (2) the introduction of a set of logical resource categories to model difference types of claim. The discussion is lengthy, with an extensive list of examples. It will be interesting to if his suggestions are widely adopted as an increasing number of systems struggle to keep up with the volume of natural language data now available.

h/t G.V()

·nature.com·
The Semantic Units Framework, a technology-agnostic representational approach to FAIR and CLEAR knowledge infrastructures - Scientific Data
Knowledge graphs in drug discovery: How network biology is finding new targets | Drug Discovery News
Knowledge graphs in drug discovery: How network biology is finding new targets | Drug Discovery News

Ever wondered how the biomedical industry uses knowledge graphs? Here’s a general introductory guide from Drug Discovery News.

Did you know that the vast majority of modern pharmaceuticals conceptually do the exact same thing? Nearly all prescribed drugs are just chemicals designed to modulate the behavior of proteins. In many ways, “thing that modulates a protein” is a good approximate definition of the word “drug”.

If that makes biomedical research sound simple however, you’re out of luck. The problem is the sheer size of the parameter space. There are estimated ~20,000 protein-coding genes in the human body, and an even higher number of possible diseases, drugs, phenotypes and pathways. Keeping on top of all the different possible combinations and relationships between them by hand would be impossible, but is fortunately the kind of thing that a graph database can do very well.

As this introduction mentions, though, reality is even more complicated than that. Even “the graph is a simplification of biology.” Just because we give an entry and a name (perhaps even a chemical formula) to a protein, drug or disease, that doesn’t mean that its properties and behaviours can be fully predicted from base principles or existing data. Biomedical research has many strongly supported relationships, but also relationships that are merely suggested, inferred, or perhaps even pure hypothesis. This incompleteness or uncertainty in knowledge also has to be captured.

This article refers to major biomedical knowledge graphs: PrimeKG, Open Targets, Hetionet, STRING, and mentions how neural networks can be used look for patterns in the complicated space of biomedical processes.

h/t weekly edge G.V()

·drugdiscoverynews.com·
Knowledge graphs in drug discovery: How network biology is finding new targets | Drug Discovery News
What Palantir Got Right With Ontologies - Scrydon
What Palantir Got Right With Ontologies - Scrydon
Palantir put the ontology — not the LLM — at the centre of enterprise AI, and that architectural bet is being proven right. But AI itself has now collapsed the cost of building an ontology. You no longer need an army of forward-deployed engineers, and you certainly don't need to hand your most sensitive data to a US vendor to get one.
·scrydon.com·
What Palantir Got Right With Ontologies - Scrydon