For IT & platform leaders
Your business runs on dark joins.
The relationship isn't in the data. It's in the work. Your systems record what happened. They don't record how any of it connects — because the connections were declared in calls, email, Slack and docs, where no schema was waiting to catch them. We call those dark joins — and no integration project has ever found one.
TL;DR — a dark join is a relationship that is real, load-bearing and actionable in your business, and exists in no schema anywhere in your estate. It was never entered, so it can't be integrated, resolved or piped. Noded reads the action layer — the calls, email, chat, docs and tickets where people actually declare those relationships — and assembles them into a live Context Graph per account from pointers, not copies. One governed MCP layer. No new store of record.
CIO · VP Platform · Enterprise Architecture · Head of Data · Head of Applications
The problem, precisely
Try writing the query your exec team keeps asking for.
Which renewals are blocked by unresolved support issues? Everyone in the business knows the answer. Nobody can query it.
SELECT o.name, o.close_date, c.case_number, c.status FROM opportunities o JOIN calls ON o.account_id = calls.account_id -- fine JOIN cases c ON ??? -- there is no key WHERE o.close_date < CURRENT_DATE + 90
There has never been a key. Not because someone forgot to model it, and not because an integration is misconfigured — but because the fact that this case blocks this renewal was never data. It was said on a Tuesday call, restated in an email, repeated in a Slack thread and written into a shared agenda doc. Four declarations of the same relationship, all of which entered your estate as unindexed strings inside text blobs, hanging off records that couldn't represent them.
A relationship that was never recorded cannot be derived from the records. It isn't in the data — it's in the work.
Why it never got entered
Your people document their work constantly. Just not where you built for it.
A form, with no field for it.
There is no picklist for blocks, no field for same root cause as, and nowhere to put champion went quiet because of this. The schema is a filter, and it filters out precisely the relationships nobody anticipated when the object was designed.
Priority: High
Related to: —
So the relationship is mangled into a free-text note, or far more often, not entered at all. This is not an adoption problem you can train your way out of.
A message, with no resistance.
Nobody experiences Slack as data entry. No required fields, no validation rules, no admin asking why a picklist is blank. So when someone needs to convey a dependency, they simply say it — accurately, with identifiers, and without friction.
— it's why procurement went quiet"
That sentence is a complete, precise, load-bearing relationship between four records. It cost nothing to produce and no system captured it.
The systems built to capture structure are the ones least able to capture the structure that matters.
The inversion
Everyone is running the association backwards.
Three assumptions sit under every integration, MDM and knowledge-graph project you have funded. Each of them points the wrong way.
The call isn't about the account. It's about six things the recorder couldn't represent.
Take the human artifact and attach it to the record. The recorder logs the call to the account. The email plugin attaches the thread to the contact. Each is a one-way association into the single object the tool happened to know about — and every other relationship in that conversation is discarded at ingest.
Read the records out of the work. A call that references a case, a competitor, a contract clause and a roadmap commitment creates edges to all four. The work tells you which records belong together — not the other way around.
You cannot derive an edge from data that never contained it.
Enterprise search, ontology platforms and MDM all derive relationships from the data — from schemas, identifiers, metadata, document similarity, co-occurrence. However good they are, that approach can only ever surface relationships that something already recorded.
Derive them from the action layer — the forwards, mentions, escalations, replies and edits where humans declare relationships as a by-product of coordinating. That recovers the edges that were never written down, which is precisely the set that matters.
It's a log of the work, not a map of it.
The system of record is the map of the business, and when a relationship is missing the diagnosis is always the same: the data isn't clean enough yet, so fund another phase. Eighteen months later the join key still doesn't exist.
The database is an artifact — a record of what someone remembered to enter. The structure of the business lives in the action layer. That isn't the messy exhaust of the real system; it's where the relationships are declared.
Scope
The action layer is bigger than the meeting.
This is not a transcription problem. Calls are simply the most vivid example. The action layer is the entire human surface of your business — the tools people use to do the work, as distinct from the systems they are required to log the work into.
People are more precise than they get credit for.
“Blocked by NOD-231.” “Duplicate of the ticket Sarah raised.” “Same root cause as the Contoso deployment.” “Per section 4 of the MSA.” That is how coordination works, and every one of them is an edge with an identifier attached.
The signals come with it.
Who forwarded what to whom tells you who owns a problem. What keeps getting re-referenced tells you what is live. What five people were suddenly added to a thread about tells you what just got serious. None of it is in a table.
Nothing new to ask of your people.
A meeting agenda doc listing seven ticket numbers, two roadmap items and the contract is a dense little graph, hand-built by someone who understood the account — sitting in a folder, relating to nothing. Multiply by every account, every quarter, for as long as you've existed.
Why this is suddenly urgent
Your agent program isn't stalled on the model. It's stalled on missing edges.
Ask an agent “what's the risk on the Contoso renewal?” and it does exactly what it was built to do: retrieves the account record, retrieves some documents mentioning Contoso, and produces a fluent summary of the fields you already had.
It will not tell you the renewal is blocked by a six-week-old case, because nothing in its context says those two things are related. RAG retrieves documents. It does not know which records a document is about.
Every new integration adds nodes and zero edges.
You can integrate forever and the graph stays sparse. No context window, prompt strategy or model upgrade supplies the missing relationships, because they were discarded at ingest — long before any model was involved.
Fix it once, and every agent inherits the fix.
This is a data-layer problem sitting underneath an agent problem — one of the few places left in an enterprise stack where a single piece of work pays off across every downstream initiative you haven't scoped yet.
The mechanism
Ingestion chaining™, and why it isn't a model guessing at your data.
Three signals do the work. The design matters, because the objections to it are legitimate and the answers have to be mechanical rather than reassuring.
PageRank, for enterprise work.
Every touch is an edge — a forward, a mention, a status change, a reply, even a read. Records the work keeps reaching for climb in rank and earn their way into the graph. Importance is a property of the link structure, so nobody has to flag anything.
Importance decays unless renewed.
A record nobody has touched for a business cycle falls out of the active chain. This is what stops the graph becoming another lake. Most knowledge systems fail here: they accumulate, never forget, and within a year the signal is buried under everything that used to be true.
“Blocked by” in. “Duplicate of” out.
A classifier over the surrounding language, not the identifier alone — applied the same whether it was spoken on a call or typed in a thread. “Blocked by NOD-231” chains the record in; “closing as duplicate of NOD-231” keeps it out. Same identifier, opposite relationship.
Naive extraction — regex for anything shaped like a ticket ID — produces a graph so noisy it is worse than nothing, because a wrong edge in a customer graph costs more than a missing one. We tune heavily toward precision, and every edge carries provenance back to the sentence that created it. That's the right thing to interrogate any vendor on, including us.
Where it sits
You have probably funded three of these already.
| MDM / entity resolution | Enterprise search | Ontology platform | Noded | |
|---|---|---|---|---|
| Where relationships come from | Schemas & identifiers | Document similarity | A modelled ontology | The action layer |
| Finds relationships never recorded | No | No | Only if modelled first | Yes — that's the point |
| Moves or copies your data | Yes — golden records | Yes — a full index | Yes | No — pointers only |
| New store of record to govern | Yes | Yes | Yes | None |
| Answers “what's live on this account” | No | No | Partially | Yes, per account |
| Time to first value | 12–18 months | Weeks | Multi-quarter | Hours to days |
If a tool works from the storage layer, it structurally cannot find your dark joins.
Don't take it on assertion
Measure your own dark join rate. It takes an afternoon.
Run this against your own estate before you talk to us or anyone else. It costs nothing and it settles the argument either way.
Pick one important account. Pull thirty artifacts.
A deliberate mix — call transcripts, email threads, Slack conversations, shared docs. Include the non-call surfaces. That's where most people are surprised.
Count the outbound references.
How many contain an explicit reference to something outside the record they're filed against — a ticket number, a Jira key, a contract clause, another document, a different customer, a named competitor, a roadmap commitment, a person outside the account team?
Now check whether any of them exist as a link.
For each reference, find the relationship as an actual edge in a system you own. Not a mention in a text field — a link something could traverse.
Step 03 usually returns close to zero.
That ratio is your dark join rate — the honest measure of how much of your operating reality your systems can represent. Email and doc comments typically score worst, because no vendor has ever built even the naive one-way integration for them. It's a more useful number to take into a budget conversation than another data-quality score, because it measures the thing your executives are complaining about when they say the CRM is useless.
The part your security review asks about
Reading the action layer without becoming a new liability.
Your records stay home.
The graph holds pointers, not copies. Records stay in the systems that own them, under those systems' permissions. Disconnect tomorrow and everything is exactly where it always was. Never trained on — not our models, not anyone's. SOC 2 audited.
Governance is subtractive.
You decide what's exposed, per source, per field — and what isn't exposed doesn't exist as far as any agent is concerned. Access stays permission-aware against source systems, so the graph never becomes a lateral disclosure path between teams.
Nothing changes until you say so.
Default read-only. Every write-back is opt-in, attributed and reviewable. And consolidating agent access behind one governed MCP layer usually replaces a growing sprawl of individually-credentialed point integrations — which is the larger governance problem.
Honest answers
What IT leaders actually ask us.
Isn't this just ETL with a new name?
No — nothing moves. ETL copies records from a source into a destination. Ingestion chaining observes how work touches records and precipitates a graph of pointers, rank and relationships. The output isn't a table of your data — it's the edge set your data never had.
How do I know it isn't inventing relationships?
Ask this hard. The intent classifier separates “blocked by” from “duplicate of”; every edge carries provenance back to the sentence that created it; and the system is tuned for precision over recall. If a vendor can't show you the sentence behind an edge, be sceptical of the edge.
We already have Glean / Microsoft Graph / an ontology.
Good products, and this is the cleanest way to see the difference. They derive relationships from the data — schemas, metadata, similarity. Deriving them from the action layer is a different operation with a different output: the edges nobody ever recorded. Noded vs Glean →
Does this add pipeline or governance burden?
It should reduce it. No pipelines to babysit, no new store of record to certify, no DAGs to debug. Association happens automatically at ingest, and exposure is subtractive. The usual net effect is fewer credentialed integrations to review, not more.
Could we just build this ourselves?
Yes, and the design is in the white paper. It's connectors across the full action layer, interaction rank over a live edge stream, a decay model tuned to your business cycle, an intent classifier with a labelled eval set, permission-aware resolution, and a cached serving layer. That's a platform team and several quarters.
Where does Noded fit less well?
Noded shines when work flows through connectable tools — recorders, email, Slack, docs, tickets, CRM. If your customer interactions never touch those systems, you'll get less from it. And if your estate is genuinely complex, expect a scoped project rather than a switch-on — that is what forward deployed exists for.
The full argument
The white paper, if you'd rather forward something.
The relationship isn't in the data. It's in the work.
Everything on this page, argued properly and laid out to be read away from a browser — the version that survives being forwarded to the person who wasn't in the meeting.
- The query you cannot write, and why the key never existed
- Why MDM, ETL and knowledge graphs structurally can't find dark joins
- The full ingestion chaining design — rank, decay, intent filter — with its failure modes
- The build-it-yourself spec, in enough detail to actually cost it
- The objections, answered mechanically rather than reassuringly
On its way.
Your download should have started. If it didn't, grab it here — and check your inbox for a copy.
Download the PDF ↓Next step
Run the diagnostic first. Then talk to us.
The relationship isn't in the data. It's in the work. Measure your own dark join rate — one account, thirty artifacts, an afternoon — and bring the number to a working session with our team. We'll walk your architecture, show you what ingestion chaining finds on an estate like yours, and answer the security and governance questions before anything is connected.
45 minutes, technical, no deck. Complex estate? We'll run the project with you →