Knowing what your data means is the foundation. Getting people and agents to act on that meaning, and proving that it was allowed, is building on the foundation. Context runs the spectrum of semantics, state, and controls.

By George Anadiotis

When Forrester and Gartner publish competing context layer definitions in the same quarter, the word is mainstream. When Google pays $10 million for a dead airline’s internal business data, the value is mainstream. When W3C and Google publish competing formats for machine-readable wikis, the plumbing is mainstream.

Mainstream doesn’t mean settled, but whichever way you cut it, semantics is a key part of context. The need to define semantics is what led to the resurgence of ontology. Two things are true about it at once now.

Ontology is more necessary than ever; it’s the guardrail, not the prompt. It’s what your data means, and makes a system’s assumptions explicit and machine-processable. The hard part was never calling an API; it’s knowing whether the action is allowed.

Ontology has never been more hyped or cheaper to fake. AI can draft plausible-looking schemas faster than seasoned ontologists. But as the cost of a semantic model heads toward zero, and everyone can generate one – who will separate the wheat from the chaff, and why would anyone converge?

A graph can be the right place to model and govern how things relate, especially an ontology – small, relatively slow-changing, and genuinely graph-shaped. Graphs can help by selecting context at runtime. Definition, validation, and goal-setting remain human.

Four threads run through this issue. Governance moves from prompt to guardrail: ontology deciding not just what things mean, but what agents are allowed to do to them. Trust becomes the real bottleneck, now that generating a plausible ontology costs nothing and validating one still costs everything.

Engineering moves from loop to graph: one agent guessing in circles, versus a mapped system that remembers what happened last week and who’s supposed to own it. Infrastructure and validation are here: graph tooling and use cases are multiplying, the market’s forecast to grow more than tenfold, and the acquisition season is open.

Everyone needs a context layer, but what exactly is it and how do you get one? A reasonable question to ask for something that’s supposed to be a trillion-dollar opportunity. As an emerging market, context layer could not stay undefined for too long.

Forrester proposed a definition for “context layer”, and the knowledge graph community stress tested it. Forrester’s premise: semantics, ontology, semantic layer, knowledge graph, and context layer have become interchangeable buzzwords. Their proposed fix, after months of practitioner interviews:

A context layer is the next evolution of semantic layers and knowledge graphs. It combines the business semantics and governance of the former with the ontological modeling of the latter, then continuously updating with runtime events, decisions, and outcomes to form a living model of the enterprise.

Context for agentic AI. Image: Dan Everett

Dan Everett, Research Director at IDC, defines context as “the situation or conditions that constrain both what information is relevant and how it should be interpreted to support effective decisions and actions”. Everett asks how much context does your knowledge graph actually deliver.

When people claim that knowledge graphs provide their context for agentic AI, Everett argues that this is only partially true. Many claims of “the context layer for Agentic AI” are based on repurposed semantic layers. For the definition to translate into a requirement for agentic AI, you need semantics, state, and controls.

Semantics: concepts, entities, terms, definitions, and relationships. State: states and transitions, activities and sequences, and interactions between systems. Controls: permissions, prohibitions, and obligations that govern what actions can be taken, under what conditions, and what follows from them.

Gartner also emphasizes the crucial distinction between knowledge graphs and context graphs. Knowledge graphs model state, entities, relationships, what exists. Context graphs model motion, decision flows, event traces, how state changes over time. They work together: knowledge graphs supply domain understanding, context graphs supply judgment.

Gartner projects more than 50% of AI agent systems will run on context graphs by 2028. And separately, that context engineering will be embedded in 80% of AI-building tools by that same year, lifting agent accuracy by at least 30%.

Gartner’s analysis flags four capabilities as non-negotiable for getting there: Systematic capture of decision traces across workflows and channels. Context-aware lineage graphs that let structure emerge from execution data, not a fixed schema. AI observability – agents read from the graph, and write back to it as auditable traces. Continuous learning loops that improve agent behavior.

As LLMs commoditize, proprietary context, not the model, becomes the differentiator. Image: Ben Lorica

The strategic stakes are laid out plainly too: as LLMs commoditize, proprietary context, not the model, becomes the differentiator. As Andrea Volpini puts it, you can own the model and still outsource the meaning. Organizations that own their decision logic build agents nobody else can replicate. Case in point: Google recently agreed to pay $10 million for the internal business data of Spirit Airlines, a now defunct business.

Ben Lorica notes most of what companies keep is a record of results, but an agent trying to perform the work may need more than the final result. That does not mean your Slack archive is suddenly a competitive moat. Most workplace exhaust is probably just exhaust. Lorica identifies three useful layers.

At the bottom are messages, meetings, tickets, commits, clicks, and logs. Above that are trajectories, where those fragments are connected into a sequence from goal to decision to action to outcome. That sounds exactly like a context graph, even if it’s not named as such. The most valuable layer is what you can build from those trajectories: good examples, failure cases, evaluations, corrections, and reusable workflows.

Context = Knowledge + Expertise + Norms, Prukalpa argues. The enterprise context layer turns all three into machine-usable context for agents. It has two halves. A core substrate with three tightly integrated parts: AI-ready data and a knowledge graph, semantics and ontology (the shared meaning layer), and skills (reusable, versionable, testable units of procedural knowledge).

Plus five capabilities that run on top: context mining, a development lifecycle for context itself, compounding learning loops, activation and retrieval across many interfaces, and governance and observability.

Florence Benezit notes the data architectures agents access are excellent at storing what’s true right now, but they were not designed to keep how it got that way. The fix she proposes is similar – three layers stacked together: knowledge graphs, ontologies, and context graphs.

The context layer. Image: Pramod Sadalage, Prem Chandrasekaran

When agents become the primary consumers of your data, your data architecture becomes your AI architecture, Pramod Sadalage and Prem Chandrasekaran add. To make data ready for agentic AI, they introduce the AI-ready data stack.

Data contracts and quality to make data trusted. Then traceability and governance to records why an agent acted and bounds what it can reach, making data traceable and governed. The context layer encodes what metrics and entities mean, making data contextual.

The context layer includes a domain model of entities and relationships, a semantic model of metrics compiled to SQL against the analytical store, and a capability model of guarded reads and actions against live systems, with provenance signals across all three. Building on this, agents can query live systems and write back, making data operational.

The difficult part for enterprise agents is rarely calling an API, Yuan Gao notes. The difficult part is deciding whether an action is allowed, executing it without creating an ambiguous side effect, and proving what happened afterward.

We are moving from “can the agent retrieve and explain the right information?” to “can the agent make a governed decision and complete the work reliably?”. Retrieval can surface every document containing the word order. It can’t guarantee the agent picked the right business object.

An ontology makes those distinctions explicit: the objects in the enterprise, their states, their relationships, the authoritative source for each definition, and which concepts can’t be substituted for one another.

A more pragmatic ontology for AI agents, Image: Emmanuel Klinger

But ontology’s role doesn’t stop at definitions. It participates across five stages of an agent’s lifecycle: understanding the enterprise, finding the right data, governing action, planning workflows, and verifying execution.

Emmanuel Klinger argues for a more pragmatic ontology for AI agents, built on six principles: object-relational, human explorable, virtualized, natural language semantics, domain-driven, use-case driven and additive. A bit of controlled imperfection may drive adoption, trading some rigor for usability, speed, and operational fit.

A graph can be the right place to model and govern how things relate, especially an ontology, which is small, slow-changing, and genuinely graph-shaped. But where context lives and what the agent queries at runtime are separate calls, Andrew Lentz notes. Graphs can help by selecting context, not necessarily by making the model traverse it.

The way people work with coding agents keeps getting named one level up, André Lindenberg points out. First prompt engineering: phrase the request well. Then context engineering: control what the model sees. Then loop engineering: stop prompting the agent and build the system that prompts it – cf. Gartner’s learning loops.

Then the next rung got its name. Peter Steinberger, one of loop engineering’s loudest early voices, asked whether we are still talking about loops or have already shifted to graphs. The single loop is the atom of getting better, Carlos E. Perez writes. Choose something to control, set a reference, measure the gap, act to close it, repeat.

It’s simple, cheap, and it works. But the single loop fails in four specific, structural ways: Goodhart’s law, blindness upward, conflict, and measurement decay.

From loop engineering to graph engineering. Image: Carlos E. Perez

The emerging answer is a graph of loops: networks of improvement cycles that watch, feed, constrain, and correct one another. A knowledge graph is about how information connects, while an agent graph is about how work moves through a system, Nhu Hoang adds.

A loop is one agent, cycling through a task, deciding for itself what’s next. A loop can hit a target you’ve already defined (tests passing, a clean build), but it can’t decide what “correct” means. Point it at an ambiguous spec and it burns tokens guessing in circles.

A graph forces that decision up front. You map explicitly which agent owns which domain, how data hands off, what happens when a step fails. Harder to set up, but more predictable at scale. Nick Perry observes that production-minded teams split that into two layers.

A permanent org graph: named agents that own security, data, API contracts, frontend standards, and defend those boundaries continuously. An ephemeral work graph: task nodes spun up for one feature or bug, that split, merge, and dissolve once validated, handing the result back to the permanent owners.

Agents have a memory problem, Dave Bechberger notes: close the session, and everything they learned is gone. A useful long-term memory layer has to satisfy four properties: persistence, relevance retrieval, relational structure, and temporal validity.

Vector stores nail the first two. But relationships and time are second-class citizens in a flat index; there’s no native way to ask “what led to what” or “what did we believe last month.” That’s the gap graphs close.

Every edge should carry two independent clocks: valid time (when a fact was true in the world) and transaction time (when the system learned it). Nothing gets erased. Old edges get marked superseded as new evidence arrives, which makes “what did we believe last quarter” a query instead of a mystery.

Using graphs for long-term memory. Image: Dave Bechberger

Left unmanaged, though, a memory graph rots: duplicate nodes, stale edges, quiet contradictions. Entity resolution, contradiction handling, decay, and compaction are what keep it usable rather than a junk drawer. Worth noting: this isn’t free. Construction cost, schema drift, and cases where a flat vector store is simply enough are real tradeoffs.

William Lyon explores types of agent memory, and Animesh Kumar explores the first wave of agent memory systems – defining what memory is, exploring history and different implementations, and pointing out six cracks. As both Kumar and Bechberger point out, evaluation of long-term memory systems remains unsolved. No clean benchmark exists yet for multi-hop accuracy or temporal correctness.

Agent builders are converging on the same discovery: the simplest way to give an agent durable memory is a markdown LLM wiki. Enterprises are converging on semantic layers, context graphs and ontologies to ground their agents. Tony Seale put these together.

You can combine a markdown wiki with a formal knowledge graph and ontology, Seale argues. It is an extremely powerful pattern, now published as an open standard for the community to evolve. It’s called Vault-LD. The idea is simple: markdown plus YAML-LD frontmatter.

The W3C recently published version 1.0 of the YAML-LD specification. YAML-LD is a set of conventions which specify how to serialize (RDF) Linked Data as YAML based on JSON-LD syntax, semantics, and APIs.

Ontology and agent memory. Image: Tony Seale

JSON-LD is a lightweight, machine-readable format used to store and transport linked data on the web. JSON-LD uses Schema.org vocabularies to explicitly define what web page elements mean (like products, prices, or authors).

JSON-LD owns meaning; it’s the format behind the EU Digital Identity Wallet, Microsoft’s Digital Twins Definition Language, and how AI-ready datasets describe themselves on Hugging Face and Kaggle. JSON Schema owns structure; it’s the validation logic behind most modern API specs, MCP tool definitions, and IoT data models. Juan Cruz Viotti addressed JSON Schema and JSON-LD interoperability.

Google’s Open Knowledge Format (OKF) formalizes the LLM-wiki pattern. OKF v0.2 adds support for trust signals, to answer questions like “what was this made from?” or “Is it still true?”. Neo4j created ki, an open source project to sync a Neo4j graph deterministically from a folder of markdown, and added unofficial support for OKF.

Format aside, AI agents have a semantics problem, not a reasoning problem, Thilo Hermann argues. Autonomous agents need more than a prompt, a model, and a workflow engine to do useful work in an enterprise. They need a data foundation that lets the agent understand what something is, what it means, and how it should be exchanged.

Without that separation, agents quickly become impressive on the surface and unreliable underneath. That is exactly why the distinction between a canonical data model, an ontology, and a knowledge graph is not an academic detail. It is a practical requirement for any serious autonomous agent setup.

Ontology is the guardrail, not the prompt, Anthony Alcaraz chimes in. People keep collapsing three layers into one: Schema is how your data is stored. Columns, types, tables. Ontology is what your data means. Entities, relationships, constraints. A knowledge graph is the ontology instantiated: real entities and edges you can traverse.

John Beverley defines ontology engineering as the discipline concerned with constructing machine-interpretable artifacts designed to systematically disambiguate information, improve information quality, and facilitate information interoperability.

J Bittner explores what does an ontology actually do for a business. In plain English, a formal ontology makes a system’s assumptions (what counts as a customer, an approval, an obligation) explicit and machine-processable. Value shows up once it’s wired into actual work, not as a standalone artifact.

Jessica Talisman claims that while ontologies are hyped, most organizations are not ready to work with ontologies. Before the AI boom, ontology work was typically the job of one overstretched specialist. Now, the pressure runs the other way: flattening ontologies to fit existing pipelines, vector indexes or chunked corpora, which strips out the very dimensionality that makes them useful.

Generative AI can produce a plausible-looking class hierarchy in seconds. Verifying it takes as long as building it right the first time. Talisman’s throughline: description is the deliverable. Not the reasoner, not the graph store, not the axioms – the discipline of writing down what things actually are, in language both people and machines can use.

In terms of acquiring a background in ontological modeling, Jessica Talisman revisited her Ontology Pipeline framework, and published the eponymous book. Year of the Graph subscribers get a 15% discount code for the book!

John Beverley’s World’s Ontology Ecosystem is an intensive five-day introduction to Basic Formal Ontology, ontology engineering, knowledge graphs, semantic interoperability, and ontology-driven applications – recording available here.

Basic Formal Ontology (BFO) is a foundational (or top-level) ontology: a domain-neutral conceptual framework that defines universal, highly abstract terms and relations such as object, event, process, and attribute, serving as a common root for more specialized, domain-specific ontologies.

Antoine Lonjon elaborates on what foundational ontology needs to succeed in the future of architecture and AI: syntax & modularity, spatiotemporal identity, exhaustive relations & classification, logical rigor & computability, granularity across levels of reality, language and culture neutrality, property binding & value spaces, and metaphysical transparency.

Automatic ontolgy creation. Image: Francois Vanderseypen

Still, the race to automate ontology creation is clearly on and it’s moving faster than people realize, Francois Vanderseypen notes. He wonders whether the demand for taxonomists and ontologists might come to a halt, and lists three flavors of automation emerging: LLM-native builders, SQL-native pragmatists, and platform giants.

Kurt Cagle is an ontologist with decades of experience. And he’s come to the conclusion that Chloe, his AI collaborator, is a better ontologist. Not in every dimension, not without guidance, and not without the hard-won experiential context he brings to the collaboration.

But on the axis that matters most for actually building knowledge systems – the rapid identification of patterns, the iterative stabilisation of a schema, the recognition of where cardinality wants to sharpen and where it wants to stay soft – Cagle concedes that Chloe is faster, more consistent, and more willing to revise than he has ever been.

M Bilal Ashfaq breaks down how automated ontology generation works today. Frameworks such as OntoAgent implement a multi-agent pattern, with agents specializing in different phases including scoping, modelling, and validation, and collaborating iteratively until the ontology meets defined quality thresholds.

However, full automation is not yet feasible. LLMs hallucinate. They invent classes, relationships, and axioms that have no grounding in source text or domain reality. Without validation, these fabrications appear in the generated ontology as legitimate content. LLMs can only automate ontology creation with guardrails.

For decades, ontology engineering was constrained by expertise. AI changes this economic equation. Ontology creation is moving from scarcity to abundance. Nicolas Figay asks what happens when the cost of creating semantic models approaches zero? If everyone can generate semantic models, we should not expect convergence.

The great ontology revival. Image: Nicolas Figay

The challenge shifts from creating ontologies to understanding which ontology should be trusted. Perhaps ontology engineers are not disappearing, but their role is evolving. Specialists may spend less time defining classes and properties manually and much more time reviewing, aligning, validating and governing AI-generated semantic artifacts.

Figay notes that the renewed interest in ontologies has revitalized the ecosystem around them. He set out to build a completely transparent, verifiable, and comprehensive cartography of this ecosystem. After filtering for noise, over 500 repositories surfaced.

Four signals stand out: Rust is eating Java’s lunch, with new generation reasoners targeting embedded and edge computing. Reasoning is becoming an AI agent’s tool, turning description logic into a deterministic guardrail against hallucination. Proof assistants are moving in, and ontology matching is back.

The underlying assumption in many of these projects is that the limitations of probabilistic language models can be corrected by introducing a symbolic layer capable of validating generated knowledge against a formally defined conceptual model. This assumes that the ontology itself is both sufficiently expressive and sufficiently complete. Figay warns.

Fanghua (Joshua) Yu argues that teams across an organisation can all say they’re “building an ontology” while solving fundamentally different problems. One is defining that a Smartphone is a subclass of Electronic Product. Another is designing a graph so a recommendation engine can traverse Customer → purchased → Product efficiently.

A third is encoding business rules for free delivery eligibility. A fourth wants an AI agent to know what an Order is, which tools can act on it, and whether it’s actually authorised to issue a refund. One ontology no longer fits every workload. As Ali Khalili puts it, there’s the logician’s ontology, the pragmatist’s ontology, the strategist’s ontology, the agent’s ontology.

Ontology is evolving from a formal model of meaning into an operational component of knowledge graphs, decision systems and AI agents. The progression runs Formal Semantics → Knowledge Graphs → Decisions → AI Agents, or put differently: Meaning → Traversal → Reasoning → Action.

Formal Semantics → Knowledge Graphs → Decisions → AI Agents. Image: Fanghua (Joshua) Yu

Amir Hosseini offers practical advice for ontology engineering on RDF & property graphs; he argues that even though only RDF truly supports ontologies, ontology engineering practices remain relevant across both systems. Meanwhile, Neo4j introduced its Enterprise Knowledge Layer, featuring technical ontology, domain ontology, business process ontology, policy ontology and organization ontology.

Almost no product on the market meets the formal definition of an ontology, as most “ontologies” don’t reason, Colin Goyette argues. Regardless, the useful question for a builder is what to build, in what order, so that agents working against your data are trustworthy at each step. Property graphs have no reasoning engine, and most people don’t notice because they don’t know what it is, Francois Vanderseypen adds.

Building and deploying ontologies in the real world is what the Knowledge Spine series of articles by Bojan Ciric is about. Ciric covers the need and the method for building ontologies, how ontologies survive organizational change and budget reallocation, the agents who use it, the manual for building it, and the moment its founding rule breaks.

Ontology resurgence is largely driven by Neuro-Symbolic AI, RAG (Retrieval-Augmented Generation), and the need for deterministic knowledge grounding to eliminate LLM hallucinations. GraphRAG has found its strongest early traction in industries with large document volumes, dense relational structure, and a high cost of error, Lettria’s GraphRAG Whitepaper highlights.

There is a common thread in these cases: the answer is not in any single document. It is in the relationships between documents. That is the problem GraphRAG was built to solve. GraphRAG earns its complexity from synthesis and multi-hop queries. On simple lookups, it is overhead with no upside.

Researchers from AWS and Cisco compared RAG scenarios on semi-structured knowledge bases, covering regular RAG, GraphRAG, Modular RAG, and Agentic RAG. Retrieval-oriented metrics, the ones commonly used to benchmark these systems, overstate the benefits of advanced retrieval. LinearRAG identifies relation extraction as the weakest link in GraphRAG pipelines, suggesting keeping it only where it makes sense.

The GraphRAG pipeline. Image: Lettria

Research from the UK National Innovation Centre for Data suggests that adding graph-based context helps AI systems better connect information across multiple documents and entities, leading to more complete and reliable answers. Compared with a standard vector-based RAG system, the graph-enhanced approach increased AI truthfulness scores by approximately 80% and more than doubled the number of complex questions answered.

A new study on GraphRAG for multimodal data names something operators already feel: text, images, and structured fields get retrieved in parallel, encoded separately, and assembled with no real cross-modal alignment. The result can look supported and still fail under inspection.

Bin Yu surveyed research from ACL 2026, ACL Findings 2026, and arXiv, and found it all points to the same conclusion: GraphRAG is no longer enough. The future of AI agents isn’t better retrieval – it’s better memory. The four biggest shifts are going from static to self-evolving memory, from similarity to multi-signal reasoning, from storage to cognitive memory, and from unlimited growth to cost-aware memory.

Experts such as Patrick Meyer and Brad Bebee highlight the role of ontology in bootstrapping and guardrailing GraphRAG systems. Irina Adamchic introduced Ontology GraphRAG (O-RAG) to address a challenge when using ontologies for GraphRAG: selecting only the relevant part of a growing Ontology Layer when parsing an unstructured document from a specific domain.

Most GraphRAG implementations are retrieval systems wearing an agentic AI costume. They retrieve well, but they do not reason, Maya Natarajan notes.

The knowledge graph isn’t a replacement for vector retrieval; it’s the layer that gives retrieval structure, gives AI systems governed context, and gives enterprise AI the auditability it needs for consequential decisions. Panos Alexopoulos explores assessing and improving knowledge graph quality in GraphRAG applications.

Knowledge Graphs are becoming a key investment theme in the next wave of intelligent data management, DataM Intelligence’s report shows. The global knowledge graph market was valued at USD 1.34 billion in 2025 and is expected to reach USD 19.16 billion by 2035, growing at a CAGR of 30.8% during the forecast period 2026-2035.

Growth is driven by increasing demand for intelligent data integration and semantic search capabilities across enterprises. Rising adoption of AI, machine learning, and natural language processing is accelerating the use of knowledge graph technologies. The growing need for enhanced data analytics, recommendation systems, and decision intelligence is further supporting market expansion.

Knowledge Graph Market Growth. Image: DataM Intelligence

In related market news, Integral Capital Group has agreed to sell Graphwise, a pioneer in knowledge graph and semantic AI technology, to Oakley Capital. The investment can support Graphwise to become the semantic layer for AI agents, SiliconANGLE notes. Francois Vanderseypen points out that a semantic layer is something hyperscalers lack, and there are available options for acquisition.

Not bad for a discipline that supposedly failed. Knowledge graphs and ontology are having a moment, even when vendors misrepresent them, as Juan Sequeda notes. Knowledge graphs have been “the future of enterprise data” for a very long time, but almost nobody has one – and the organizations that do paid astronomically for them, Michael Kerner opines. He thinks it was never a technology problem – it was a labor problem.

Kerner lists three things that killed knowledge graph projects: you needed a complete ontology before extracting anything, nothing mapped to it, and every single fact on the graph required an act of reasoning. His solution: break down KG construction into iterable, simple actions until every remaining decision is a classification shape that an LLM can help with.

Most knowledge graph projects fail, Kurt Cagle concurs, but the reasons have little to do with the stack. Cagle lists a number of reasons knowledge graph projects fail, including lack of purpose, poor scoping, no long-term plan and feeding relational data straight into a graph. To succeed, he suggests remedies such as starting with use cases, building shape before meaning, and designing for time and change.

Graph use cases, tools and resources

Graphs power investigations with a Human-in-the-Loop approach and open schema tooling. They also power fintech giant Klarna, and can help with drug discovery, countering art forgery, joining the dots between big AI, natural disaster analysis, grid operation optimization, evidence-based global development and auto-remediating databases at Stripe.

All Relations Lead to Rome (ARLtR) is an open source framework that jointly constructs, in a single coherent resource, a knowledge graph, dense embeddings, and fact-grounded question-answer pairs explicitly tied to extracted entities, relations, and supporting text.

OntoKG is an ontology-oriented approach to knowledge graph construction: the schema is designed from the outset for ontology analysis, entity disambiguation, domain customization, and LLM-guided extraction – not merely as a byproduct of graph building.

Joining the dots between big AI. Image: FT

docling-graph transforms unstructured documents into validated, rich and queryable knowledge graphs. knowledge_graph converts any text to a graph of knowledge. Vijayasekhar Deepak compares AI code knowledge graphs – Graphify vs GitNexus vs CodeGraph.

Cognee released V1, building a dynamic memory graph of what agents see. Semantica v0.6.0 was released: open source, graph-native infrastructure for context and accountable AI Systems. The Aerospike Graph Service (AGS) repository has now gone open source. While the SQL/PGQ property graph query feature was reverted from PostgreSQL 19, graph query languages are converging: Gremlin Knows GQL.

The full AI x Graphs Track from AI Engineer World’s Fair is available for viewing, featuring from graph memory and video context to agentic constraints, data models, and knowledge graphs as a control plane. Andy Fitzgerald shared his GraphCon 2026 themes & takeaways; conference replays available here.