"Things" and "Thing Types" in the Context Plane
How I think about the things and the thing types that need to be in the Context Plane to power "AI Agents"
How I think about the things and the thing types that need to be in the Context Plane to power "AI Agents"
“Context” of this post
I often find writing helps me coalesce and refine my thoughts when new patterns start to emerge, but aren’t very clear yet.
So this article is a brain dump / train of thought continuation of the architecture needed to have one Context Plane to rule them all, as part of a proposed “AI Data Stack”.
This article provides an overview of a way to describe both the Object Types and the Object Categories that will hold the metadata I think should be included in the Context Plane as part of a new “AI Data Stack”.
The Context Plane Architecture
I have written some initial thoughts about the architecture of the Context Plane and the things that shoud be stored or federated in it before.
As a quick reminder my current thinking is the architecture diagram for the Context Plane should look something like this:
Object Types stored in the Context Plane
In that previous article I did a bit of a stocktake of all the Patterns and Pattern Templates I see in the Data Domain that hold what I would term as Context.
I have been mulling those over more as we do each McSpikey (experiment) to learn more by doing and to reduce some of the many uncertainties we have identified.
I am currently sitting with this list of Object Types that seem to have value being stored or federated in the Context Plane:
Outcomes
Actions
Business Questions
Business Glossary of terms, aliases and descriptions (use tags for Aliases)
Conceptual Data Model
Logical Data Model
Physical Data Model
Data Dictionary (with schema, fields types, field descriptions etc, also flags)
Facts
Transformation code
Data Quality Rules
Data Contract (Boundary of other Objects))
Measures, and their formulas
Metrics and their formulas
Information Applications (Reports, dashboards, AI Agents etc)
Information Products (Boundary of other Objects)
Data Quality Scores
Notifications
Usage Statistic
Data Sync Statistics
Number of rows in tiles
Principles
Policies
Patterns
Personas
Previous effort of change
Semantic Language is important
I often rail against the lack of clear Semantic definition in the Data Domain, but I am often as loose with my definitions as anybody else.
I had original used the following terms:
Context Object
Context Object Types
But as is the LinkedIn way Gabriel Tanase kindly reviewed my crap semantic definitions and provided a much better version.
The confusion here may be terminological, between "Objects" and "Object Types".
The "Context Objects" you listed are, in my view, "Context Object Types", since you are speaking in general, about classes of stuff.
OTOH, an individual instance would be a "Context Object", obviously of exactly one "Context Object Type". E.g., an individual Action is one Context Object, that belongs to the "Actions" Context Objects Type.
The four things you call "Context Types" are just super-classes / domains / groupings of Context Object Types.
So based on that I have ended up with:
Context Object
A single instance of something in the Context Plane (e.g. the action “Approve Loan”).Context Object Type
The class or category that defines what kind of object it is (e.g. Actions).Context Object Type Category
A higher-level grouping of related object types that share a domain (e.g. Business Context).
Not reinventing the Wheel
Gabriel also pointed me at some excellent documentation from Collibra in that thread, for example:
https://productresources.collibra.com/docs/collibra/latest/Content/Settings/OperatingModel/to_operating-model-settings.htm
Im always keen to reuse Patterns from others, rather than reinventing the wheel so to speak, and so I went down a rabbit hole of the excellent Collibra documentation.
I came away with a feeling of an architecture that is founded on the Pattern of “thing is a thing of a thing”.
Which of course is an infinitely flexible Pattern, but to me has always been an Anti-Pattern and so not a Pattern I want to adopt.
I will need to spend more time looking into bth the Data Catalog and Information Science domains as I am pretty confident that the Patterns I am looking for already exist.
But there is also the value of trying to defining these patterns myself, as I learn by doing (and struggling). Plus when I finally think i have nutted something else and I spot that same pattern articulated in lots of other places then I knwo I am on to something repeatable and valuable.
Context Object Type Categories
Back on task, these are the Context Object Type Categories I have ended up with.
Business Context
Captures the intent, language, and needs that connect data work to business language.Structural Context
Describes the technical metadata that defines how data is stored, shaped, and connected.Operational Context
Provides the live signals and guardrails (trust scores, usage stats, policies, and access rules etc) that keep data reliable and governed in practice.Agent Context
Provides the prompts and guardrails that guide AI agents in applying context.
Yes Structural Context is the same as what is commonly called “Technical Metadata”.
My definition for Operational Context has got examples, which means I do not have a clear semantic defintion for it yet, so I need to keep iterating that one.
Mapping Context Object Types to Categories
I stress tested my categorisation by trying to assign the Context Object Types to one and only one category.
Moving to the AssistedAI pattern and letting my ChatGPT friend expand my bullet point list to become richer text and write a more detailed story, ever so slightly edited by me ….
When people talk about data, they often focus on the raw tables, pipelines, and dashboards. But the real power comes from the Context that surrounds them, the language, the intent, the rules, and the patterns that let both Humans and AI agents understand what data means and how it should be used.
In the Context Plane, we capture that knowledge as a set of Object Types. These are building blocks that represent everything from business questions to transformation code, from policies to personas. Together, they create a shared layer of context that connects business, data, operational and agentic worlds.
To make sense of them, we group these Objects Types into four categories: Business Context, Structural Context, Operational Context, and Agent Context.
Business Context
Object Types in the Business Context category capture the why behind the data: the intent, the questions, and the people who care.
Business Questions – The driving questions that stakeholders ask and want answered.
Actions – What people (or processes) actually do with data once they have it.
Outcomes – The results or changes in the business that happen because of those actions.
Business Glossary – Shared terms, their aliases, and agreed definitions, so everyone speaks the same language.
Conceptual Data Model – The high-level map of business concepts (customers, products, orders) and how they relate.
Logical Data Model – A more detailed structure that shows how those concepts can be represented in data.
Personas – Representations of the different types of people who use or consume data, each with their own needs.
Information Products – The boundary objects that package up context into a consumable unit, such as a unified customer view, a churn model, or a financial performance pack.
Structural Context
Object Types in the Structural Context category describe the what of data: the way it’s stored, shaped, and transformed to become useful.
Physical Data Model – The actual schema and structures in the database.
Data Dictionary – A catalog of fields, data types, and descriptions, along with useful flags.
Facts – Core, measurable events or counts in the data (e.g. sales transactions, logins).
Transformation Code – The SQL, scripts, or pipelines that turn raw data into shaped, ready-to-use structures.
Data Quality Rules – Checks and guardrails that ensure the data stays trustworthy.
Measures – Defined calculations, such as revenue or average handling time.
Metrics – Business-relevant measures with formulas and thresholds (e.g. Net Promoter Score, Churn Rate).
Information Applications – The outputs where information is applied and consumed: reports, dashboards, AI agents, apps.
Operational Context
Object Types in the Operational Context category describe the how well and at what cost dimensions of data. These objects let us monitor and manage the reliability and change effort of the system.
Usage Statistics – Insights into who is using which data, when, and how often.
Data Quality Scores – Aggregated indicators that show how healthy the data is across rules and checks.
Data Sync Statistics – Performance and freshness indicators of data movement.
Number of Rows in Tiles – A quick proxy for data size and growth in a given slice of the platform.
Notifications – Alerts that something requires attention, whether it’s a failed job or a threshold breach.
Principles, Policies, Patterns – The guiding rules and repeatable approaches that shape how data is managed.
Previous Effort of Change – A signal of how much time, cost, and disruption a past change required, helping estimate future impact.
Agent Context
Finally, Object Types in the Agent Context category deals with the prompts and instructions that guide AI agents in using all this context. These Objects define the boundaries and cues for generative systems to behave predictably and helpfully.
Prompts – The structured inputs, templates, and guardrails that tell an AI agent how to use context objects to answer questions, generate insights, or perform actions.
Why it Matters
Each Object Type might seem less than valuable in isolation, but together they form a unified layer of meaning, that can be used by Humans and AI Agents alike to gain understanding.
By capturing both the why (business intent) and the what (structural detail), as well as the how well (operational health) and the how to guide agents (AI context), the Context Plane ensures that every stakeholder—whether a business leader, a data engineer, or an AI agent—works from the same playbook.
That’s how you move from disconnected metadata and data assets to a coherent ecosystem where context is always present, always available, and always shared.
And back to all me again ….
And once again with a map
Visual maps often give a better quick view than plain text, so here you go:
Far from Done Done
Based in my experience to date I will be iterating the Object Types and their categorisation for a while yet, but I think I have the the four Context Object Type Categories pretty stable.
Famous last words?
Wood from the Trees
Still a way to go before I have a coherent set of Patterns that I can Coach / Mentor / Teach somebody else for the “Context Plane”, and the “AI Data Stack” or present as a robust Architecture map.
But as I have already said, writing my half formed ideas helps me think.
An incoherent stream of Context
You can find all the previous articles with my train of thought listed in this thread:
https://agiledata.substack.com/t/context-plane
We are building the Context Plane while flying it, so always looking for early adopters to help us decide the final destination.
If you want a virtual chat grab a slot here:
https://contextplane.ai/contact-us/#bookemdanno