# The moat is the decision history that stays in your VPC

Why enterprise hiring loses decision context, and how a VPC-resident Internal Decision Engine connects it to governed outcomes.

> By Naman Puri · Feb 18, 2026
> Canonical: https://www.nodes.inc/blog/the-moat-is-the-data-that-never-leaves-your-vpc


---
## Highlights

- Systems of record store records. The Internal Decision Engine connects decision context to governed measured outcomes for named-human review.

- Decision traces link hiring judgment to validated performance outcomes.

- At the named carrier, VPC deployment was the verifiable control that enabled their 17-day legal review, and the customer associated this architecture with their ability to use governed outcomes to inform prediction accuracy.

- A Fortune 500 insurance carrier has scored 900,000+ candidates since January 2025; requisition-to-hire time moved from 127 days to 38 days during the deployment.

- Institutional knowledge compounds when captured at decision time, otherwise it disappears.

Every AI vendor will tell you their model is smarter, faster, cheaper.
At the named carrier, their legal review required a verifiable deployment-mode control before proceeding: the system could not send candidate data to external APIs. Their 17-day approval was associated with the architectural choice to keep the model and data inside their VPC, though this does not guarantee approval elsewhere.

The same deployment also produced separate observed and customer-attributed outcomes. Those results do not establish that the architecture caused them.

## The obvious moat everyone chased (and why it failed in hiring)

Most AI companies started with the same story arc:

- Build a better model.
- Wrap it in an API.
- Centralize as much customer data as possible.
- Win with scale.

That playbook works when you’re optimizing product recommendations or email copy. It breaks the moment you touch candidate PII, performance reviews, or any data a regulator might reasonably ask about.

In enterprise hiring, the questions are different:

- Where does candidate data go?
- What external systems see it?
- Can we prove how decisions were made if a regulator, plaintiff, or journalist asks two years from now?

A centralized API is the worst possible answer to those questions. The most “obvious” moat, aggregating everyone’s hiring data in one place, then training a giant model on it, is the one thing legal will never let you do.

So we took the opposite path: no shared model, no central data lake, no magic API in our cloud. Everything runs inside yours.

## What 900,000+ applicants taught us about constraints as moats

When we started, “run all of this inside the customer’s VPC” felt like a handicap.

It meant:

- No managed GPU cluster we could control.
- No centralized labeling team.
- No easy way to debug by “just pulling the logs” from our own environment.
- No shared, cross-customer dataset living anywhere we could touch.

But then a Fortune 500 insurance carrier did something surprising.

They had blocked every AI hiring tool over data privacy and sovereignty concerns. They wouldn’t let vendors send candidate data to external APIs. They wouldn’t let anyone train models on their performance reviews. They wouldn’t accept “trust us” as a governance model.

They approved us in 17 days.

The architecture gave the review team a precise production-data answer: customer records, inputs, outputs, outcomes, and Decision Traces stay inside the customer's cloud.

That decision unlocked everything else:

- We could evaluate customer-specific calibration candidates against governed measured performance outcomes instead of proxy metrics.
- We could ingest ATS data, HRIS data, and CRM/communication traces with full legal sign-off.
- We could validate predictions against actual performance reviews rather than click-through rates or survey scores.

The constraint that looked like a handicap, keeping production data and inference inside their infrastructure, became the reason we were allowed to work with the records that mattered: who they hired, how they performed, and why. A separate release path may move a customer-approved weight artifact after two independent PII checks. Returned upgrades still require synthetic testing, local shadow evaluation, and named-human promotion.

## Small models, big context, zero external calls

From the outside, “AI in your VPC” sounds like a checkbox. In practice, it forces you to make different technical choices.

We chose small, specialized models over huge, general ones.

- Model size: small, specialized models that can run comfortably in a customer’s environment, often on CPU, without requiring a mini, research lab worth of GPUs.
- Deployment: single-tenant, inside the customer’s VPC on AWS, Azure, or GCP, with no outbound calls to external model APIs.
- Training: fine-tuning on the customer’s own ATS + HRIS + communication data, entirely inside their environment.

When we compared how approaches ranked candidates against observed post-hire outcomes, the pattern was clear:

- Prompting frontier models against generic job data got you “smart-sounding” answers and mediocre correlation with actual performance.
- Because it operates as a People Decision Engine inside your VPC, it treats measured outcomes as governed evidence with uncertainty rather than categorical truth or proof of an individual's success. Human decisions provide context, and a named human makes the final call. Calibration or production promotion requires validation. The 10,765-person figure identifies the historical study cohort rather than Nodes throughput. Enterprise talent at one Fortune 500 insurance carrier is the sole current production proof; underwriting, lending, and admissions remain ready for historical validation.

But the smaller models could evaluate that scoped evidence with uncertainty only because we never asked the customer to send their data anywhere. The system presented customer-owned evidence about likely outcomes and risk, and a named human made the final call based on that historically validated context.

The AI lived where the data already was.

## The decision traces everyone else throws away

Traditional systems of record all have the same blind spot.

- ATS: knows who applied, who advanced, who got hired. It doesn’t know why.
- HRIS: knows who got promoted, who underperformed, who left. It doesn’t know what was said in the hiring loop.
- CRM: knows how reps talk to customers. It doesn’t know which of them are top performers a year later.

Everyone sees the outcome. No one captures the reasoning.

In hiring, that missing layer is where the real moat lives.

We call the missing layer “decision traces”, the sequence of signals, judgments, and exceptions that led from “new candidate” to “hired” or “rejected,” and then from “hired” to “top performer” or “miss.”

A few examples:

- The underwriter who didn’t meet the stated years-of-experience requirement but was pushed through by a hiring manager who “just knew”, and turned into a star.
- The sales candidate the panel split on, where one interviewer dug in on objection handling and later turned out to be right.
- The engineer who came from an unconventional background, failed a generic coding screen, but excelled on a bespoke take-home and is now a staff-level anchor.

In most companies, that context is ephemeral. It lives in:

- Slack channels and email threads.
- Verbal debriefs after interviews.
- The gut feelings of your best hiring managers.

The minute the decision is made, the trace dies.

We made a different choice: treat every hiring decision as an eval that should be preserved and abstracted into patterns.

Not “John Smith had X,” but “candidates with pattern X, in context Y, tend to succeed in role Z.”

These decision traces, abstracted into patterns, are the atomic unit of our moat.

- They are generated at decision time instead of reconstructed later.
- They live inside the customer’s VPC rather than in some vendor’s shared sandbox.
- They can be queried, audited, and used to train future models, without exposing raw PII.

You can’t scrape this dataset. You can’t buy it. You can’t approximate it from resumes alone. You have to be present when the decision is made.

That’s where we live.

## Why incumbents and foundation models can’t follow you into the VPC

If the moat is the decision history that stays in your VPC, the obvious next question is: why can’t incumbents or foundation model providers just copy this approach?

On paper, they have everything:

- HRIS vendors sit on decades of employee data.
- ATS vendors own the candidate journey.
- Data platforms aggregate everything downstream.
- Foundation models have the most powerful pattern-machines ever built.

In practice, they’re in the wrong place in the workflow.

- HRIS sees outcomes, not decisions. By the time someone is in the HRIS, all of the messy debates and exceptions that led to their hire are gone.
- ATS sees pipeline, not performance. It watches candidates move from stage to stage but rarely sees the long-term performance data that proves whether those decisions were right.
- Data platforms are downstream archives. They receive data only after systems of record have flattened all the nuance into structured fields.
- External API calls for foundation models often face compliance hurdles because they require sending data outside the enterprise perimeter. At the named carrier, the verifiable deployment-mode control of keeping data in the VPC was required by their legal review to access decision context and measured outcomes.

All of them can approximate behavior from the outside. None of them can assemble the decision context, connect it to governed measured outcomes, and evaluate customer-specific calibration candidates inside your infrastructure under your governance.

We didn’t win access to that position with slogans. We earned it by accepting constraints:

- No central model trained on everyone’s candidates.
- No centralized data lake in our cloud.
- No “trust us, we anonymize” pitch decks.

We show up where it matters, in the VPC, at decision time, and we stay there.

## From hiring intelligence to workforce intelligence

Once you start capturing decision traces and outcomes in one place, something else happens.

You stop “doing AI” for one decision and start building a context graph for every decision.

The same infrastructure that helps you answer “Who should we hire?” starts answering:

- Who is on a fast path to leadership, based on the same patterns we see in your best managers?
- Which internal candidates should we consider for this role, based on demonstrated strengths rather than job titles?
- Where are we taking hiring risks that routinely pay off, and where are we taking risks that consistently backfire?
- What does a successful ramp look like, and how do we evaluate a shorter path?

At the carrier, once the hiring loop was instrumented and the system had a few quarters of outcomes, something changed in ramp:

- New hires received an AI co-pilot grounded in customer-owned evidence from prior work and governed measured outcomes, while people retained the final call.
- Within the VPC, governed outcome evidence securely connects prior applicant context to measured post-hire results to reveal likely outcomes, risk, and uncertainty; any predictive calibration requires rigorous validation, and a named human must always make the final call.

The same traces used for hiring review can connect later ramp outcomes to the evidence and human decisions that preceded them. That creates a record for evaluation; it does not make an individual's ramp predictable.

## The three questions enterprise buyers should ask every AI vendor

If you are buying AI for hiring, or anything else touching regulated, high-stakes workflows, the marketing all starts to sound the same.

Everyone promises:

- Better candidates, faster.
- Reduced bias.
- Better “insights.”

Ignore the slogans. Ask these three questions instead:

1. **Where does my data actually live?**

 - If the answer involves their cloud, their API, or any external model endpoint, assume legal will have concerns.
 - If they can’t run entirely inside your VPC, they can’t safely train on your most sensitive data.
2. **Can this system train on my performance outcomes without sending anything outside my infrastructure?**

 - Ask which measured outcome the system evaluates, which population and period it covers, and where the evaluation runs.
 - The evidence that matters connects human decision context to approved post-hire outcomes, on your infrastructure and under your governance.
3. **Will I have a queryable record of how decisions were made a year from now?**

 - If all you get is a score and a “trust us” explanation, you don’t have a defensible system.
 - You need decision traces for more than satisfying regulators: you need them to understand your own organization’s judgment.

If the answer to any of these is “no,” you’re renting pattern recognition from someone else. You are not building a moat. You are training theirs.

## What this means for AI builders

If you’re an AI founder, this is the part most people don’t want to hear:

Your moat is not a bigger model. It’s not a glossier orchestration diagram. It’s not “agents” as a buzzword.

Your moat is the dataset that:

- No one else can legally touch.
- No one else can structurally observe.
- No one else can easily recreate without standing where you stand in the workflow.

The constraint that protects that decision history is concrete. Customer production records, outcomes, Decision Traces, and context stay inside the approved VPC. No hosted model API sits in the production data path. That constraint is the shape of your moat.

Design for that constraint from day one.

- Choose model sizes and architectures that can live where the data is, instead of where your GPU credits are.
- Build for fine-tuning on real outcomes over prompt-engineering against generic benchmarks.
- Capture the full decision trace as decision context and link it to governed measured outcomes; the human decision itself is not the governed evaluation evidence.

The accelerant is not one more clever prompt. It’s the simple, boring truth:

You either control the decision history that stays in the VPC, or you don’t.

We chose the hard path early: no shared customer production data and no multi-tenant inference.
In exchange, we got something harder to copy than any feature list:

We became the place where your talent decisions are evaluated, remembered, and connected to governed measured outcomes, without moving customer production data into a Nodes-hosted environment. Any later calibration candidate requires shadow validation and named-human promotion, with no automatic improvement assumed.

Related: the wider version of this argument, why the context layer holds its value while models commoditize, is in [Model quality stopped being the bottleneck. The context layer is.](/blog/context-layer-is-the-moat)

## 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.*