# How Decision Traces Turn Your ATS Exhaust into a Talent Context Graph

A practical model for connecting decision-time evidence to the outcomes that follow

> By Naman Puri · Feb 26, 2026
> Canonical: https://www.nodes.inc/blog/how-decision-traces-turn-your-ats-exhaust-into-a-talent-context-graph


---
An applicant tracking system preserves events: applied, screened, interviewed, offered, rejected, hired. It usually cannot answer what evidence the reviewer saw, which policy version applied, why an exception was made, what action a person approved, or what happened after the hire entered another system.

A Talent Context Graph connects those missing parts. Decision Traces supply the edges between a decision and its later outcome. The graph does not replace the ATS, HRIS, CRM, assessment platform, or compensation system. It gives the organization a governed way to ask questions across them while keeping the source records where they already live.

## What ATS exhaust contains

Every recruiting workflow leaves useful exhaust. A requisition carries role, location, compensation range, manager, and approval history. An application carries source, credentials, screening dispositions, interview steps, and timing. An offer carries terms and acceptance. Once a person starts, the HRIS and operating systems hold ramp milestones, production measures, role changes, and other outcomes the business already recognizes.

The problem is the missing chain between those records. A rejection reason may be a short dropdown value. An override may live in a message. The exact evidence available at decision time may be overwritten later. A performance outcome can arrive months after the ATS workflow closes. Each system remains correct within its own job, while the organization loses the relationship between what it knew and what followed.

That relationship matters because a later analysis can otherwise commit hindsight bias. If the system reads today's record to explain a decision made months ago, it may use information the reviewer could not have known. A Decision Trace preserves the decision-time snapshot so the later outcome can be evaluated against the evidence that was actually available.

## What a Decision Trace records

A Decision Trace is a signed, queryable record for one governed action. Its useful fields are concrete:

- The decision identifier and accountable owner.
- The source records and permitted evidence available at that time.
- The model, prompt, policy, and workflow versions used.
- The recommendation, uncertainty, counterevidence, and value of acting or waiting.
- The human review, including approval, edit, delay, or decline.
- The approved action written back to the relevant systems.
- The later measured outcome, when it becomes available.

The human choice remains context. An approval does not prove that the recommendation was correct, and a rejection does not prove that it was wrong. The governed downstream outcome is the evidence used for later evaluation. This distinction prevents historical preference from being promoted into model truth merely because a senior person made the call.

The trace also preserves absence. A missing assessment, stale policy, unresolved identity, or weak comparison cohort should appear as a limitation instead of disappearing behind a score. That makes uncertainty reviewable by the person who has authority to decide.

## How the graph is formed

The trace becomes useful beyond one case when its identifiers connect to the rest of the enterprise record. A practical Talent Context Graph can represent:

- Decisions, such as screening, offer, mobility, or development reviews.
- People and roles, resolved across the ATS, HRIS, and approved operating systems.
- Evidence available at the moment of review.
- Policies and workflow versions that constrained the decision.
- Human reviewers and the input they supplied.
- Approved actions and the systems changed by those actions.
- Outcomes, definitions, periods, and populations used for evaluation.

Edges carry the meaning. A person was considered for a role. Evidence supported or challenged a recommendation. A named reviewer changed the proposal. An approved action altered a system record. A later outcome followed during a defined measurement period. Each edge points back to its source and time.

This structure makes a query auditable. A team can ask which filters excluded people who later reached an approved production milestone, then inspect the affected population, decision-time evidence, counterexamples, and outcome definition. The answer can travel with its limits rather than arriving as an unexplained ranking.

## Start with one outcome and one decision

Building the graph does not require modeling the entire workforce at once. The clean starting point is one repeated decision and one outcome the business already trusts.

First, define the decision boundary: what starts the workflow, which systems may be read, what the system may propose, who approves it, what action may follow, and what later result will be measured. Then resolve identities across the permitted systems and preserve the historical state of each case. Run a read-only Decision Replay before any live workflow is proposed.

The replay should answer whether the history is usable. It may reveal missing outcomes, changing definitions, selection bias, weak comparison groups, or a policy that shifted halfway through the period. A negative result is useful because it stops a production claim from being built on evidence that cannot support it.

If the historical evaluation clears the agreed threshold, the team can define a production scope. A named human still approves, edits, delays, or declines each governed proposal. Later outcomes become evidence for evaluating a calibration candidate. The candidate runs in shadow against the incumbent and requires named-human promotion. Measurement never changes the production model automatically.

## What the carrier record shows

At one Fortune 500 insurance carrier, the connected record covered four years and 10,765 agents. The analysis parsed 8,181 skills and could test 3,597 keywords against post-hire production. After Bonferroni correction, none predicted the production milestone, while 30 were anti-predictive. These are research findings from one carrier and one outcome definition, with methods published in [Decision Traces](https://arxiv.org/abs/2604.19819).

The same history supported a retrospective counterfactual on an industry-experience filter. That filter would have rejected 2,863 producers who later generated $17.7M in annual production. The figure describes value placed at risk under a historical rule. It is not a claim that removing the rule will produce the same value at another company.

This example shows why the graph matters. The ATS held the screening rule and disposition. The downstream systems held production. The Decision Trace structure made the relationship inspectable without treating an individual's later result as proof of what would happen to the next person.

## What the graph can and cannot answer

A well-governed graph can show historical associations, the evidence available for a prior decision, the policies applied, where human reviewers disagreed, which outcomes followed, and how sensitive the result is to a different population or definition. It can surface counterexamples that a summary metric would hide.

It cannot establish a universal profile of success. It cannot turn one employee into a template for another. It cannot erase selection effects in historical hiring data. It cannot claim causality merely because an outcome followed a decision. It cannot decide whether the current case deserves an exception.

Those limits are product requirements. The recommendation should state what is known, what is missing, which evidence cuts the other way, and where the current case differs from the historical comparison. The named reviewer retains authority over the final call.

## The security boundary is part of the graph

Talent context can include candidate records, performance data, compensation, call transcripts, and decision history. The graph therefore belongs inside the customer's controlled environment. Production inference is VPC-resident and single-tenant. Customer records, outcomes, context, and Decision Traces do not move to a hosted foundation-model provider.

The customer owns its weights. A separate release path may move a customer-approved weight artifact after two independent PII checks. Improvements may pool only within the same industry. A returned upgrade is tested on synthetic data, evaluated locally in shadow, and promoted only by a named human. This mechanism keeps production data inside while making every artifact movement explicit and reviewable.

For a fuller treatment of that boundary, see [what a trust boundary means in enterprise AI](/blog/what-is-a-trust-boundary) and the [Nodes architecture](/architecture).

## Questions to ask before building

A technical and talent team can test a proposed graph with a short diligence list:

- Which decision and outcome are in scope?
- Can the system reproduce the evidence available at decision time?
- How are identities, policies, and outcome definitions versioned?
- Where do human input and approved actions enter the trace?
- Which limitations and counterexamples appear with the recommendation?
- What is the shadow-evaluation and promotion protocol?
- Where do production data, weights, and traces live at signing and exit?

If those questions have precise answers, the ATS exhaust can become useful evidence without turning the ATS into a product it was never designed to be. The source systems continue to record transactions. The Talent Context Graph connects the decision, the evidence, the human review, the approved action, and the outcome so the next reviewer can inspect the organization's own history.

Start with the [Decision Trace definition](/glossary/decision-traces), then examine the public [evidence registry](/evidence) for populations, methods, and transfer limits.

## Sources

- [Decision Traces: What Multi-System Data Fusion Reveals About Institutional Knowledge in Enterprise Hiring](https://arxiv.org/abs/2604.19819)

*Naman Puri is the Head of SEO and Answer Engine Optimization at Nodes.*