Home/Solutions/Context Management
Context Management
Every source in one place, modelled as the objects you run on. This is the context layer.
Priori builds and maintains a live model of your operation: the affiliates, users, purchases, chargebacks, and MIDs, with the relationships between them. Analytics, machine learning, and AI agents read this model instead of raw tables. This page explains what the context layer is, how it gets built, and what it changes.
Priori Ontology + Lineage
Why AI cannot read your business
Three things stand between your data and an AI that can use it.
Rows without meaning
A payments table stores MIDs and sub-IDs as strings. The schema does not say what they are, how a chargeback relates to an affiliate, or which campaign a user came from. The person querying carries that knowledge in their head.
Sources that do not hand data over
Affiliate portals, tracker exports, and spreadsheets hold operational truth. None of them were built for integration, so they stay outside the warehouse and outside every analysis.
AI that guesses
Point a language model at raw tables and it invents the joins it cannot see. The answers look right, so you end up checking each one, which takes longer than writing the query yourself.
What the context layer is
The context layer is a knowledge graph of your business. Each node is a real object: an affiliate, a user, a conversation, a subscription, a chargeback, a MID. Each edge is a relationship that holds in reality: this affiliate ran that campaign, the campaign acquired this user, the user's trial rebilled into that subscription, and the subscription charged back.
Domain meaning lives in the model instead of in whoever wrote the query. “Charged back” is a defined relation with a defined direction. A sub-ID is an object with a history. Ask a question through any Priori product and it resolves against these definitions.
The model stays current. Pipelines sync it from your systems on a schedule you control, so the graph describes the business as it is now.
Your systems
Systems of record
Systems of data
Systems of knowledge
Systems of engagement
Priori Lineage
One place, raw first
every source lands with its history kept
Priori Ontology
Objects & relations
What reads it
Business intelligence
Priori Lens
Machine learning
Priori Lab
Agents
Priori Runner
Anomaly detection
Priori Sentry
The objects
An object is anything you would point at when explaining the business to a new hire. For a dating operator running paid traffic, that runs from the network that sent the click to the chargeback that ended a subscription. The catalog below is what a typical graph holds.
Acquisition
Users & engagement
Monetisation
Payments & risk
Operations & knowledge
Three kinds of knowledge get encoded onto these objects.
Relationships are encoded
The chain from acquisition to loss is edges you can query: this affiliate ran that campaign, the campaign acquired a user, the user took the trial, the trial rebilled into a subscription, the subscription charged back on MID-7. One question walks the whole chain.
Domain meaning is encoded
Properties carry your definitions. A sub-ID knows its payout tier and traffic source. A MID knows its processor, its daily cap, and its health. An active user means “messaged in the last seven days” because that is how you defined it, once, for everything that reads the graph.
Decisions are encoded
Choices live on the objects they affect. MID-7 is quarantined, with the date and the processor letter behind it. BIN 4147 gets refund-before-dispute. Geo X traffic routes to offer B. An AI reading the graph reads the policy and the reason, not just the numbers.
This is why an agent here can answer questions a general-purpose AI cannot. Ask “can we push more traffic to MID-7?” and it finds the quarantine, the letter, and the chargeback history that caused it, because all three were encoded when they happened.
What lands in it
The front page shows four groups of systems feeding the layer. Each group carries a different kind of truth, and the model needs all four.
Systems of record hold what happened: the app database, the payment processor, the CRM. This is the ground truth the graph is built on, and where objects like purchases and chargebacks come from.
Systems of data hold the volume: the warehouse, tracker exports, the spreadsheets your team runs on. High-cardinality detail lives here, the thousands of sub-IDs and campaigns where problems hide.
Systems of knowledge hold how your business talks about itself: docs and wikis, repositories, Notion. Without them an AI knows your numbers and none of your definitions. What counts as an active user, how payout tiers work, why MID-7 is quarantined. This is what a knowledge base contributes.
Systems of engagement hold where decisions happen: Slack, email, support tickets. Agents read them for what is being asked and write results back where the team already works.
Leave one group out and the model has a blind spot. Records without knowledge give an AI numbers it cannot interpret. Knowledge without records gives it definitions with nothing to apply them to.
With and without the context layer
The difference shows up the first time you ask a question. Take one from a normal week: which sub-affiliates drove last week's chargebacks.
Without the context layer
“Which sub-affiliates drove last week's chargebacks?”
The model sees tables named cb_events and aff_map, guesses that sub_id joins them, and returns a confident list. Two of the joins are wrong. The number is plausible and unverifiable.
No trace. Checking the answer means rewriting the query yourself.
With the context layer
“Which sub-affiliates drove last week's chargebacks?”
The question resolves against defined objects: Chargeback, related to Purchase, related to Sub-ID. Same answer for anyone who asks, computed from the same definitions.
Every number traces to the objects and source rows behind it.
The failure mode without the layer is not a refusal, it is a wrong answer that looks right. The layer removes the guessing: joins are defined relations, definitions are shared, and the trace is part of the answer.
How it gets built
Priori Lineage lands the sources. Databases and APIs connect directly. Portals that only render HTML get scraped on a schedule. Spreadsheets upload as versioned tables. Everything arrives raw first, so nothing is lost in translation.
Priori Ontology maps the raw tables into objects. Entity resolution joins the same affiliate across your CRM, your tracker, and your payment processor into one record. Field-level lineage records where every value came from, so any number can be traced back to its source rows.
So what?
The layer exists for what runs on it. Each capability gets something it cannot have on raw tables, and the value compounds because they all share the one model.
BI you can trust
Questions in plain language resolve against defined objects, so the joins are relations and the metrics mean one thing. “Which offers held up after refunds, by traffic source” comes back as a chart the same day, with a trace, because Offer, Refund, and Sub-ID are objects rather than columns someone has to interpret.
ML trained on your business
Object histories are ready-made features and encoded outcomes are ready-made labels. A chargeback-risk model reads each purchase's chain, the sub-ID and its payout tier, the BIN's history, the user's message activity, without a feature-engineering project. Scores land back on the objects, where everything else can use them: a risky purchase gets held, a churning user gets a save offer.
Agents that know the operation
An agent on the graph knows what a MID is, which one is quarantined, and why. Ask about pushing traffic to MID-7 and it reads the quarantine, the processor letter, and the chargeback history before it answers. It acts on the objects and writes results back, so the next task starts from what the last one learned.
Watching at full cardinality
The graph is the watch list. Every sub-ID, MID, and campaign gets monitored from the day it appears, thousands of series no dashboard has room for. When a card-testing run starts on one MID, the alert arrives with the object and its history attached, minutes in rather than at month-end.
What changes in practice
- Numbers agree. Every chart, model, and agent uses the same definitions, so month-end stops being a reconciliation exercise.
- AI answers are grounded. A model reasoning over defined objects cannot invent a join. Wrong answers become traceable answers.
- New capabilities start from the graph. A churn model or a new dashboard begins with objects that already exist, not a six-week data project.
- Portals and spreadsheets stop being dead ends. Once a source lands in Lineage, it is part of every analysis that follows.