Agentic AI Data Foundation: Stage 3 Pipeline Templates

The agentic AI data foundation is the single hardest cap on downstream agent quality — and the stage teams most consistently under-budget. A model can be frontier-class, a vendor can be top-tier, an orchestration framework can be elegant; none of that matters if the corpus the agent retrieves from is stale, ambiguous, duplicated across four systems, or quietly mixes restricted PII into general-access prompts. Stage 3 is where that gets fixed.

What's at stake: every retrieval-grounded agent, every workflow that touches a record of truth, every analytic surface a user actually trusts — all of them inherit the quality ceiling of the data underneath. Skip the audit, the readiness assessment, and the classification policy, and you ship an agent that is confidently wrong in production. Worse, you ship one that is confidently wrong on regulated content, which is the failure mode that ends programs.

This guide covers eight sections: why Stage 3 sets the cap, the 30-point quality audit, the three-level RAG-readiness assessment, the source-of-truth map and ownership matrix, the four-tier classification policy, PII detection and retention, the data-debt prioritisation matrix, and the hand-off contract into Stage 4 vendor selection. Every artifact below is a template — adapt the wording, keep the structure.

Every agent program eventually meets the same wall. The model is capable. The prompt is tuned. The orchestration is clean. And the agent still hallucinates pricing, cites the wrong policy, conflates two customers with similar names, or quotes a product page from three website redesigns ago. None of those failures originate in the model layer. They originate in the data layer, and the model faithfully reflects what was retrieved.

Stage 3 is the only stage in the pipeline where investment compounds across every downstream stage. A vendor decision (Stage 4) affects one vendor. A prototype (Stage 5) affects one workflow. A data-foundation improvement raises the ceiling for every agent built afterward — for years. That asymmetry is why Stage 3 deserves disproportionate budget and why under-budgeting it is the single most common pattern we see in stalled programs.

The honest framing: most organisations entering Stage 3 discover their data is in worse shape than they assumed. The job here is not to be embarrassed by that — it's to measure honestly, fix the highest-blast-radius problems first, and hand a known-quality foundation to Stage 4. Two weeks of disciplined work here saves quarters of remediation later.

The 30-point audit below is the artifact that opens every Stage 3 engagement. Four pillars — freshness, accuracy, consistency, lineage — with seven to eight checks each. Score each check as green, amber, or red on the actual corpus you intend to ground agents on. The output is not a vanity report; it's a triage list for the data-debt matrix in Section 07.

Run the audit on a representative sample, not the whole corpus. Twenty source documents per system, drawn across the date range you intend to retrieve from, surfaces the systemic problems faster than a full scan ever will. The exhaustive scan comes later, after the prioritisation matrix tells you which systems are worth scanning in depth.

The 30-point checklist

# Data Quality Audit · 30 points · Stage 3 template
# Score each: G (green) · A (amber) · R (red)
# Source: ____________________   Owner: ____________________
# Sampled: ____ records   Date: ____________________

## Freshness (8 points)
[ ] F1  Source updated within agreed SLA (daily/weekly/monthly)
[ ] F2  No records older than declared retention window
[ ] F3  "Last modified" timestamp present and reliable
[ ] F4  Stale records (>retention) flagged or archived
[ ] F5  Refresh cadence documented and monitored
[ ] F6  Source-of-truth update propagates within SLA
[ ] F7  No silent failures in upstream sync jobs
[ ] F8  Freshness dashboard visible to data owner

## Accuracy (8 points)
[ ] A1  Field values match source-of-truth on spot check
[ ] A2  No truncated text / mojibake / encoding artefacts
[ ] A3  Numerics in expected ranges (no -1 placeholders, no nulls-as-zero)
[ ] A4  Categoricals match controlled vocabulary
[ ] A5  Dates parse cleanly across locales (no DD/MM vs MM/DD ambiguity)
[ ] A6  Referential integrity intact (no orphan foreign keys)
[ ] A7  Calculated fields recompute correctly from sources
[ ] A8  Hand-labelled accuracy sample ≥ 95% on critical fields

## Consistency (7 points)
[ ] C1  Same entity referenced consistently across systems
[ ] C2  No duplicates within source (canonical-record discipline)
[ ] C3  Naming conventions consistent (column / field / tag)
[ ] C4  Units consistent (currency, distance, mass) and labelled
[ ] C5  Timezones explicit and normalised to UTC at the boundary
[ ] C6  Schema versions tracked and breaking changes flagged
[ ] C7  Cross-system joins succeed on shared keys at ≥ 99%

## Lineage (7 points)
[ ] L1  Every field traced to an upstream source or derivation
[ ] L2  Transformations documented (code, SQL, or written rule)
[ ] L3  Ownership assigned per source (one human, named)
[ ] L4  Access controls documented and enforced
[ ] L5  Retention policy declared and enforced
[ ] L6  Audit log of changes for high-sensitivity fields
[ ] L7  Recovery path documented (backups, point-in-time)

## Scoring rubric
G = production-grade, no remediation needed
A = passable, remediation queued in data-debt matrix
R = blocker, must fix before agent goes live

A few practical notes from running this audit dozens of times. First, expect the freshness pillar to score worst — almost every organisation has at least one source that has silently fallen behind its declared SLA. Second, expect the accuracy pillar to be the most contentious — owners disagree about what "accurate" means until you spot-check against ground truth in front of them. Third, expect lineage to be the most under-documented — the human owner often exists, but the documentation of what they own does not.

RAG readiness measures whether a corpus is ready to be retrieved from — distinct from whether it's clean (quality audit) or governed (classification, PII). The honest version of this assessment lives in three levels. Most teams self-report Level 3 and operate at Level 1. The assessment exists to close that gap.

Run the assessment per-workload, not once-per-organisation. A customer-support knowledge base may sit at L3 while the same company's product-pricing corpus sits at L1; the agent that grounds on both inherits the lower of the two. Score every corpus an agent will actually retrieve from.

The trap level is L2. Teams stand up chunking and embeddings, point an agent at the result, ship to staging, and never close the measurement loop. The agent works — until it quietly stops working, and nobody can tell when, because no baseline ever existed. The discipline of L3 is what separates corpora that survive a model swap from corpora that silently regress every time something upstream changes.

For the mechanics of moving from L2 to L3 — schema, chunking patterns, IVFFlat vs HNSW, recall measurement — see our self-hosted RAG with Postgres pgvector tutorial. Stage 3 readiness is the strategic question; that guide is the implementation answer.

The source-of-truth map names, for every entity an agent will touch, which system is canonical, who owns it, how often it refreshes, and what its downstream copies are. Without it, every team rebuilds the same retrieval pipeline against a different copy of the customer table and pretends they're solving different problems.

The artifact is small — usually a single sheet — and the discipline is the value. The act of writing it down forces the "which system is canonical for customers?" conversation that organisations otherwise avoid for years. Forty-five minutes of controlled discomfort buys a decade of clarity.

The source-of-truth template

# Source-of-Truth Map · Stage 3 template
# One row per entity. Cross-link related entities by ID.
# Owner = one human, named (not a team).

ENTITY              | SoT SYSTEM      | OWNER         | REFRESH    | DOWNSTREAM COPIES                  | NOTES
--------------------|-----------------|---------------|------------|------------------------------------|---------------------------------
Customer            | Salesforce      | J. Patel      | real-time  | Snowflake (15min), HubSpot (1h)    | HS overrides email — fix
Account             | Salesforce      | J. Patel      | real-time  | Snowflake (15min), Stripe (manual) | Stripe out-of-sync ~3% records
Product (catalog)   | Shopify         | M. Okonkwo    | hourly     | Snowflake, marketing site         | Two SKU naming schemes — unify
Pricing             | Stripe Products | F. Romano     | manual     | Sales decks (stale), website      | Decks are 6 months stale
Inventory           | NetSuite        | F. Romano     | nightly    | Shopify (hourly), warehouse WMS    | WMS authoritative for in-flight
Support ticket      | Zendesk         | A. Demir      | real-time  | Snowflake (daily), Slack notif    | Snowflake schema lags 1 release
Knowledge article   | Notion          | A. Demir      | as-edited  | Public docs site (15min CDN)      | No versioning — add ETags
Customer interaction| Gong            | J. Patel      | real-time  | Snowflake (daily)                 | Transcripts only — no metadata
Marketing content   | Sanity          | S. Lindqvist  | as-edited  | Marketing site (build-time)       | Pre-prod previews safe to index
Legal / contracts   | Ironclad        | L. Karimi     | as-signed  | None — silo                       | Restricted, do not index w/o ACL

# Ownership rules
# 1. Every entity has one named owner — escalation is named, not anonymous.
# 2. Owner is accountable for SoT freshness, accuracy, and access policy.
# 3. Downstream copies declare their lag explicitly — no "real-time-ish".
# 4. Agents retrieve from SoT or from a copy with a published staleness budget.

Two things worth knowing once you write this down. First, the number of entities is almost always smaller than expected — most organisations operate on ten to fifteen entities of agent relevance, not the fifty an enterprise architect would draw. Second, the "Downstream copies" column is where the agent-grounding decisions actually live: an agent reading the stale copy will be wrong in exactly the ways the lag predicts. Document the lag, route the agent to the right copy for its latency budget.

Four tiers cover roughly 90% of access-control decisions agents need to make. The simplicity is the point — a five-tier or seven-tier policy looks more sophisticated and ships less. The matrix below is the template; rename the tiers if your security team has existing nomenclature, but keep the count at four.

The classification policy interacts with the agent layer in two places. First, retrieval: an agent operating under a user context must only retrieve from tiers that user can access. Second, generation: the model's output inherits the highest tier of any source it cited. Both are enforced upstream of the model, not inside the prompt.

The default tag matters more than the policy text. A default-public posture (Tier 1 unless raised) ships faster and is harder to govern; a default-internal posture (Tier 2 unless lowered) governs more cleanly and ships slower. Pick consciously based on your sector — consumer brands typically benefit from default-public, regulated sectors from default-internal. Then write the default into the policy explicitly so nobody has to guess.

PII handling is the part of Stage 3 where shortcuts become regulatory exposure. The framing that holds up: detect at ingestion, redact or tokenise before embedding, retain on a documented schedule, audit every access. Each of those four verbs is a discipline; the policy template below names each explicitly.

Detection

Three layers stack. Pattern-based detectors catch the obvious cases — email addresses, phone numbers, national IDs, payment card numbers — using regular expressions tuned per jurisdiction. Named-entity recognition models catch the messier cases — personal names in free text, addresses embedded mid-sentence, indirect identifiers. A human review pass on the highest-tier sources catches the long tail. Run all three on ingestion; never assume the upstream system has done it for you.

Redaction strategies

Three patterns, picked per workload. Hard redaction replaces detected PII with a fixed token ([REDACTED-EMAIL]) before embedding — destroys the ability to recover the original, safest, used when the agent never needs to reach the underlying record. Tokenisation replaces PII with a reversible token that can be resolved server-side under audit — agent retrieves tokens, the surface that renders to the user resolves them under authorisation. Pseudonymisationreplaces with a stable surrogate (consistent within a corpus, meaningless outside) — useful when the agent needs to reason about "the same person" across multiple chunks without ever holding the actual identity.

Retention policy

Retention is per-tier and per-data-type, declared in writing. The template that holds up across sectors: declare a purpose, declare a retention window appropriate to that purpose, declare a deletion mechanism, and audit deletions. "We'll keep it until we're asked to delete it" is not a policy — it's an absence of policy.

# PII Retention Policy · Stage 3 template excerpt

DATA TYPE              | PURPOSE                          | RETENTION | DELETION TRIGGER
-----------------------|----------------------------------|-----------|------------------
Email (customer)       | Authentication, support routing  | 7 years   | Account deletion + 90d
Phone (customer)       | Verification, support callbacks  | 7 years   | Account deletion + 90d
National ID            | KYC / regulatory                 | 7 years   | Statutory schedule
Payment card           | Not retained — tokenised at PSP  | n/a       | Token only — no raw
Support chat transcript| Quality, training, compliance    | 3 years   | Rolling deletion
Marketing event data   | Attribution, optimisation        | 18 months | Rolling deletion
Employee record (HR)   | Employment, statutory            | 7 years post-exit | Statutory schedule
Sales call recording   | Coaching, deal review            | 2 years   | Rolling deletion
Cookie / session ID    | Session continuity               | 30 days   | Rolling expiry

Two operational notes. First, embeddings themselves can encode recoverable PII even after the source text is redacted — embedding inversion is a real attack surface in research literature. Practical mitigation: redact before embedding, never the other way around. Second, agent transcripts are themselves PII the moment a user types their name; the retention policy applies to transcripts the same as it applies to source records.

If your sector is regulated (healthcare, financial services, public sector), our AI transformation engagements stage 3 deliverables include a sector-specific PII handling rubric mapped to your governing framework — GDPR Article 30, POPIA Section 19, HIPAA §164, or sector equivalents.

Every Stage 3 audit produces more findings than the team can remediate in the time budget. The prioritisation matrix sorts by blast radius — how many downstream agents inherit the problem — multiplied by remediation cost. High blast, low cost: fix immediately. High blast, high cost: schedule with sponsorship. Low blast, anything: defer or accept.

The mistake we see most often: prioritising by age. The oldest data-quality issue is rarely the most impactful; it's usually the one that has been around long enough that everyone has built workarounds. Workarounds are not fixes — they're evidence of the blast radius. Sort by impact, not by tenure.

The pattern that holds up across engagements: the top three items on the matrix consume 70% of the remediation budget and resolve 80% of the downstream agent quality problems. The long tail matters — and gets scheduled into the operating model in Stage 10 — but the program lives or dies on the top three. Spend disproportionately there.

The hand-off contract from Stage 3 to Stage 4 is short. Vendor selection becomes meaningfully easier when the buyer can hand the vendor — and the internal eval team — five artifacts: the audit scorecard, the readiness assessment per workload, the source-of-truth map, the classification policy, and the data-debt roadmap with sequencing.

With those in hand, Stage 4 stops being "which vendor sounds best" and becomes "which vendor demonstrably operates on our actual data shape and respects our actual access controls." The RFP template in Stage 4 references these artifacts directly; the evaluation rubric scores against them. Without the Stage 3 output, the RFP is generic and the eval is theatre.

One closing note on sequencing. Resist the urge to fully remediate Stage 3 before opening Stage 4. The top-three blast-radius items should be in flight; the long tail can run in parallel with vendor selection. Waiting for a perfect data foundation is the most common reason agentic programs miss their first production deadline — and it's avoidable. Ship Stage 3 to the "known quality, top items remediating" state, then move.

For the next step, our Stage 4 vendor selection templates pick up exactly where this guide ends — scorecard matrix, RFP template, evaluation rubric, reference-call script, and contract checklist, all referencing the Stage 3 artifacts above.