The Process Archaeology Interview Framework

The question practitioners ask most often before an agent deployment isn't about model selection or integration architecture — it's about knowledge capture. Specifically: What interview framework surfaces the institutional memory agents will need encoded? That question has no off-the-shelf answer, which is why most agent projects stall not in engineering but in discovery. The discipline that closes this gap is process archaeology — a structured methodology for excavating the tacit, undocumented, and experiential knowledge that lives inside people before it can be moved into machines.

Why Tacit Knowledge Is the Real Deployment Risk

Every organization has two operational realities running simultaneously. The first is the documented one: the SOPs, the wikis, the training manuals, the workflow diagrams. The second is the practiced one: the actual sequence of decisions, workarounds, escalation instincts, and judgment calls that experienced operators execute without ever writing down.

When an agent is deployed against documented knowledge alone, it performs adequately under normal conditions and fails under edge conditions — precisely the conditions where operational risk concentrates. The gap between what is written and what is practiced is not a gap in documentation quality. It is a structural property of how expertise develops in human beings.

Expertise accumulates through repetition and consequence. A billing specialist who has processed ten thousand invoices develops pattern recognition that never surfaces in a job description. A logistics coordinator who has managed a hundred carrier disruptions carries a mental model of exception sequencing that no SOP captures. Deploying an agent into either workflow without first capturing that accumulated judgment is not a knowledge gap — it is an infrastructure gap.

Process archaeology treats knowledge capture as an engineering problem, not a documentation exercise. The goal is not to produce better written procedures. The goal is to produce a structured knowledge substrate that an agent can reason against when the expected path diverges from reality.

The Archaeology Metaphor and Why It Matters

Archaeology is an apt frame because the knowledge being sought is layered, partially preserved, and fragile when exposed carelessly. An archaeologist does not walk onto a site and ask the ground what is buried there. The excavation is methodical, stratigraphy matters, and the tools change as the depth increases.

Process archaeology applies the same logic. The surface layer of organizational knowledge — the documented procedures — is easy to extract and largely incomplete for agent purposes. The middle layer — the informal norms, the preferred sequences, the unwritten escalation protocols — requires structured interviews to access. The deepest layer — the exception memory, the failure library, the "that only happens in March" knowledge — requires deliberate elicitation techniques that most discovery processes never reach.

The interview framework described in this article is designed to move through all three layers systematically. Each layer requires a different interview mode, a different set of questions, and a different way of validating what has been captured. The output is not a document — it is a structured knowledge graph that maps process steps to decision logic to exception patterns to resolution pathways.

Selecting Interview Subjects: Who Carries What

Before a single interview is scheduled, the knowledge mapping exercise begins with a population analysis. Not every person in a process is an equally valuable source of institutional memory. The goal is to identify where knowledge is densest, where it is most at risk of loss, and where it is most practically applicable to agent decision-making.

The four categories of subject that process archaeology consistently targets are the long-tenured operator, the exception specialist, the process bridge, and the recent learner. Long-tenured operators carry the deepest layer of accumulated judgment. Exception specialists — those who spend most of their time on non-standard cases — carry the failure library that agents need most. Process bridges are people whose role sits at the junction of two workflows and who understand the handoff logic that neither team can fully articulate. Recent learners are valuable because their confusion during onboarding exposes the knowledge gaps that veterans no longer perceive.

Each subject category requires a different interview posture. Long-tenured operators respond best to narrative elicitation — asking them to walk through a specific case from memory. Exception specialists respond best to scenario probing — presenting a deviation and asking how they would sequence their response. Process bridges respond best to boundary questioning — asking what information they need from upstream before they can act, and what information they verify before passing downstream. Recent learners respond best to gap-mapping — asking what they wish they had been told that they eventually had to learn through experience.

The interview schedule should not be purely sequential. Some of the most productive sessions involve two subjects from adjacent roles in the same room, because they will surface disagreements about process boundaries that neither would have identified in isolation.

The Four-Phase Interview Architecture

The framework is organized into four phases, each building on the output of the prior phase. Skipping phases is possible but costly — the most common failure mode in knowledge capture is moving to exception elicitation before the baseline process is fully mapped, which produces exception data that cannot be contextualized.

Phase one is process narration. The interviewer asks the subject to walk through their standard workflow from the point at which they receive a trigger to the point at which they hand off or close the task. The interviewer does not interrupt to correct or clarify; they record and annotate. The primary output of phase one is a rough process map that identifies steps, actors, systems touched, and decision points. The secondary output is a list of terms the subject uses that do not appear in documentation.

Phase two is decision decomposition. Each decision point identified in phase one becomes the subject of structured interrogation. For every branch in the process, the interviewer asks three questions: what information the subject uses to make the decision, how confident they need to be before acting, and what they do when the required information is absent or ambiguous. Decision decomposition is where the first layer of tacit knowledge begins to surface, because subjects who have never been asked to articulate their decision logic frequently discover during this phase that their actual behavior differs from what they believe their behavior to be.

Phase three is exception elicitation. This phase begins with the interviewer presenting a set of deviation scenarios derived from the process map and asking the subject to narrate their response. The scenarios are not hypothetical — they are constructed from audit logs, support tickets, incident reports, and other operational residue that documents when the standard process failed. Exception elicitation surfaces the failure library that agents need to handle edge cases without escalating every non-standard event to a human operator.

Phase four is resolution archaeology. For each exception pattern identified in phase three, the interviewer traces the resolution pathway back through time. Who did the subject call? What systems did they check? What prior cases did they reference? Resolution archaeology identifies the informal knowledge networks and institutional reference points that agents must have access to in order to resolve exceptions at the same rate as experienced human operators.

Question Design: The Elicitation Vocabulary

The quality of a process archaeology interview is almost entirely determined by question design. Open-ended questions produce narrative but not precision. Closed questions produce precision but suppress the unexpected. The framework uses a four-register vocabulary that shifts register based on what the current phase requires.

The first register is narration prompting: "Walk me through the last time you handled X from the beginning." This register is used in phase one and is designed to activate episodic memory, which carries more operational detail than semantic memory. When a subject narrates a specific case from memory, they include contextual detail — the time pressure they were under, the system that was slow, the colleague they consulted — that procedural questioning never surfaces.

The second register is contrast probing: "How does that differ from what you do when Y is missing?" Contrast probing is used in phase two to surface the decision branches that a linear process narration omits. Subjects routinely describe their most common path without acknowledging that they take a different path in a significant minority of cases. Contrast probing forces the alternative paths into the open.

The third register is failure prompting: "Tell me about a time this process broke down." Failure prompting is the primary tool of phase three. The goal is not to assign blame or evaluate performance — it is to extract the operational conditions under which the standard process becomes insufficient. Experienced practitioners will often resist failure prompting initially, framing it as an evaluation exercise. The interviewer must establish early that failure cases are the most operationally valuable input the session will produce.

The fourth register is origin questioning: "Where did you learn that?" Origin questioning is used throughout all four phases but is most productive in phase four. When a subject makes a statement that contains embedded institutional knowledge — a threshold, a preference, a sequencing habit — asking where they learned it often surfaces a prior incident, a mentor, or a system limitation that explains the origin of the knowledge and determines how durable it is likely to be.

Mapping the Knowledge Graph

The output of the interview series is not a set of transcripts. Transcripts are inputs. The deliverable is a structured knowledge graph that maps every identified process step to its decision logic, every decision to its information dependencies, and every exception pattern to its resolution pathway.

The knowledge graph has a specific structure that is designed for agent consumption rather than human reading. Each node in the graph represents either a state, a decision, or an action. Edges carry three types of metadata: the condition under which the transition occurs, the information required to evaluate the condition, and the confidence threshold at which a human escalation is triggered rather than an autonomous resolution attempted.

Building the knowledge graph from interview data requires a validation step between interviews and graph construction. The validation step involves returning the rough process map from phase one to the subject for correction before proceeding to phase two. Subjects almost always identify errors in the rough map — omitted steps, incorrect sequencing, missing actors — that would corrupt the downstream decision decomposition if left uncorrected.

The knowledge graph also requires a coverage audit before it is considered deployment-ready. The coverage audit checks whether every branch in the graph has been validated against at least one real case from the exception elicitation phase, and whether every resolution pathway terminates in either an autonomous action or a defined escalation trigger. Branches that terminate ambiguously — the "it depends" cases that subjects describe but cannot specify — are flagged as training-dependent nodes that require human oversight until sufficient case data has accumulated.

Handling Knowledge Conflict and Version Discrepancy

A predictable output of multi-subject process archaeology is the discovery that different operators execute the same process differently. Some of this variation is legitimate — different cases require different approaches, and experienced operators have calibrated their approach to case type. Some of it is drift — the process was defined one way, execution evolved another way, and the documentation was never updated.

Knowledge conflict between subjects is not a problem to be resolved before the knowledge graph is built. It is a data point to be encoded. An agent that has access only to the consensus version of a process will fail when it encounters the case type that the minority approach was developed to handle. The knowledge graph should represent actual operational variation, not idealized procedural uniformity.

Handling knowledge conflict requires the interviewer to surface it explicitly rather than paper over it. When two subjects describe the same decision point differently, the right response is not to identify which subject is "correct" — it is to ask each subject to describe the conditions under which their approach applies. This question frequently reveals that the two approaches are not conflicting but complementary: each is calibrated to a specific case type that the other subject encounters less frequently.

Version discrepancy — where the documented procedure and the practiced procedure diverge — is handled through a separate documentation comparison step that runs parallel to the interview series. Every process step identified in the interviews is checked against the current documented procedure. Divergences are categorized as either deliberate adaptations that should be encoded in the knowledge graph or undocumented workarounds that should be escalated to process owners before encoding.

Validation Loops and Knowledge Confidence Scoring

Process archaeology does not produce certain knowledge. It produces knowledge with varying degrees of reliability, and the knowledge graph must encode that uncertainty explicitly for agent deployment to be safe. A confidence scoring system applied during the validation phase ensures that agents understand when to act autonomously and when to request human confirmation.

Each node in the knowledge graph receives a confidence score derived from four factors: the number of subjects who independently described the same decision logic, the consistency of that logic across the exception scenarios in phase three, the presence or absence of corroborating documentation, and the recency of the most recent case the subject cited as an example. Nodes with high scores on all four factors can be deployed with full autonomy. Nodes with low scores on any factor are deployed with escalation flags that route the case to a human operator until the agent accumulates sufficient resolved cases to recalibrate.

The validation loop runs across the entire knowledge graph rather than node by node. Confidence is not always local — a high-confidence decision node may depend on an information dependency that carries a low confidence score, making the decision itself unreliable despite appearing well-documented. Graph-level confidence audits catch these dependency failures before deployment.

TFSF Ventures FZ LLC integrates a formal knowledge confidence scoring layer into every engagement, treating the validation loop as infrastructure rather than a pre-deployment checklist. This is part of what distinguishes production deployment from a pilot: the scoring layer persists through post-deployment operation and updates as the agent accumulates live case data, which is a capability that consulting-style knowledge transfer projects do not include.

Encoding for Agent Consumption

The knowledge graph that emerges from process archaeology is not yet agent-ready. It is a structured intermediate representation that must be translated into the specific encoding format the agent's reasoning architecture can consume. This translation step is where the operational precision of the interview methodology pays its highest dividend.

An agent that receives vague process documentation will hallucinate decision logic for the gaps. An agent that receives a precisely structured knowledge graph with confidence scores, exception patterns, and escalation triggers will handle exceptions at a measurably different rate. The difference is not in the agent's capability — it is in the quality of the operational substrate the agent reasons against.

Encoding for agent consumption involves three operations applied to the knowledge graph. The first is condition normalization: every decision condition expressed in natural language is converted into a formal condition statement that references specific data fields available in the agent's integration environment. The second is exception indexing: every exception pattern identified in phase three is indexed against the condition set that triggers it, creating a retrieval structure the agent can query when a case deviates from the expected path. The third is escalation calibration: every escalation trigger in the graph is mapped to the specific human role or queue it should route to, ensuring that exceptions that require human judgment reach the right person rather than a generic fallback queue.

Organizations that have invested in a well-executed discovery phase consistently find that the encoding step is faster than they anticipated — not because it is simple, but because the knowledge graph gives the engineering team a precise specification to build against rather than an ambiguous description to interpret.

Sustaining Institutional Memory After Deployment

Process archaeology is not a one-time event. Institutional memory changes as processes evolve, as staff turn over, and as the operational environment shifts. An agent encoded against a knowledge graph that was accurate eighteen months ago will gradually drift from the operational reality it is meant to represent.

Sustaining institutional memory requires a scheduled re-archaeology cadence — a structured periodic review that updates the knowledge graph without rebuilding it from scratch. The re-archaeology cadence should be triggered by three events: significant staff turnover in a process-critical role, a documented change in the upstream system or data environment the process depends on, and any sustained increase in the agent's escalation rate above its deployment baseline.

The re-archaeology interview format is abbreviated relative to the initial engagement. The focus is on delta capture — identifying what has changed in the decision logic, the exception patterns, or the resolution pathways since the last encoding cycle. The coverage audit and confidence scoring steps remain unchanged, because they are the mechanism by which new knowledge is integrated into the existing graph rather than simply appended to it.

TFSF Ventures FZ LLC builds re-archaeology triggers directly into the Pulse AI operational layer, which monitors escalation rate trends and flags when the live case distribution diverges from the exception index by a threshold that suggests knowledge drift rather than random variation. Deployments start in the low tens of thousands for focused builds, scaling by agent count, integration complexity, and operational scope, with the Pulse AI layer priced as a pass-through at cost with no markup — and the client owns every line of code at deployment completion. Information about TFSF Ventures FZ LLC pricing, including what is included in each tier, is available directly through the assessment pathway described at the close of this article.

Organizational Readiness and Interview Logistics

The most technically rigorous interview framework will underperform if the organizational conditions for honest elicitation are not established before the first session begins. Three conditions matter most: subject availability, psychological safety, and sponsorship clarity.

Subject availability is a practical constraint that directly affects knowledge quality. Process archaeology requires extended sessions — typically ninety minutes for phase one, sixty minutes each for phases two and three, and forty-five minutes for phase four — scheduled across a compressed period to prevent knowledge drift between sessions. Organizations that attempt to fit these sessions into the margins of an already overloaded operational schedule consistently produce lower-quality knowledge graphs than organizations that treat the interview series as a dedicated project with protected time.

Psychological safety affects what subjects are willing to say about failure, workarounds, and unofficial practices. The interviewer must establish at the outset that the purpose of the engagement is knowledge capture for agent training, not performance evaluation. Subjects who believe their responses may be used to assess their job performance will sanitize their descriptions of exception handling and avoid disclosing the informal practices that are frequently the most operationally valuable.

Sponsorship clarity determines what happens with the output. When subjects do not know who has commissioned the knowledge capture or what authority the outputs carry, they will hedge their responses against a range of possible uses. Establishing clear sponsorship — who owns the engagement, what the knowledge will be used for, and who has approved the scope — removes that hedge and produces more direct, operationally specific answers.

TFSF Ventures FZ LLC is structured as production infrastructure rather than a consulting engagement — a distinction that directly shapes how organizational readiness is established in practice. Operating under RAKEZ License 47013955, with a 30-day deployment methodology that spans process archaeology, knowledge graph construction, agent encoding, and production handoff across 21 verticals, the engagement model assigns ownership of the completed codebase to the client at deployment completion. That ownership structure changes how sponsorship conversations unfold inside client organizations: because the output is a production asset rather than a deliverable document, senior sponsors engage with the scope differently, and subjects understand that the knowledge being captured will persist in a system the organization controls permanently.

Quality Indicators for a Completed Knowledge Graph

Before an agent is deployed against a knowledge graph produced through process archaeology, the graph should satisfy seven quality indicators that distinguish deployment-ready knowledge from well-organized but insufficient documentation.

The first indicator is path completeness: every identified process trigger has a terminal state, with no open-ended branches that depend on implicit human judgment without a defined escalation pathway. The second is exception density: the knowledge graph contains at least one documented exception pattern for every high-frequency decision node, ensuring that the agent's autonomous resolution capability extends meaningfully beyond the standard path.

The third indicator is information traceability: every condition in every decision node references a specific, named data field that the agent can access through its integration environment. The fourth is conflict encoding: where multiple valid approaches to the same decision exist, both are represented in the graph with the conditions that determine which applies. The fifth is confidence distribution: no more than twenty percent of decision nodes carry a low confidence score, which would indicate that the interview process was too narrow to produce a deployable knowledge substrate.

The sixth indicator is escalation specificity: every escalation trigger routes to a named role or queue rather than a generic fallback. The seventh is provenance tagging: every node in the graph carries a reference to the interview session, subject category, and elicitation phase from which it was derived, creating an audit trail that supports re-archaeology without requiring a full rebuild of the graph from scratch.

An agent deployed against a knowledge graph that satisfies all seven indicators will handle a substantially higher proportion of exception cases without human escalation than one deployed against documentation alone. That operational difference is the direct return on the process archaeology investment — and it is the operational difference that separates a genuine production deployment from an assisted automation pilot.

About TFSF Ventures FZ LLC

TFSF Ventures FZ-LLC (RAKEZ License 47013955) is an AI-native agent deployment firm built on three pillars, all running on its proprietary Pulse engine: autonomous AI agents deployed directly into the systems a business already runs, a patent-pending Agentic Payment Protocol licensed to enterprises and payment networks globally, and a Venture Engine that compresses the full venture lifecycle from idea to investor-ready. Founded by Steven J. Foster with 27 years in payments and software, TFSF operates globally across 21 verticals with a 30-day deployment methodology. Learn more at https://tfsfventures.com

Take the Free Operational Intelligence Assessment

Run the Operational Intelligence Diagnostic — 19 questions benchmarked against HBR and BLS data. Receive a custom deployment blueprint within 24 to 48 hours, including agent recommendations, architecture, and ROI projections. Start at https://tfsfventures.com/assessment

Originally published at https://www.tfsfventures.com/blog/the-process-archaeology-interview-framework

Written by TFSF Ventures Research