Enter the Customer System

The first technical failure in a deployment often occurs before anyone writes code. It happens when the team enters the customer system with the wrong permission, the wrong witnesses, or the wrong standard of evidence.

A sponsor describes the problem. A dashboard supplies a number. A policy document shows the official path. An experienced operator remembers the exceptions. A production trace reveals behavior no one mentioned. Each may be useful. None is the whole workflow.

Forward deployed engineers work close to customers because distance hides consequential detail. Proximity, however, does not create domain expertise, consent, authority, or unlimited access. It creates an obligation to learn carefully.

The goal of entry is not to “learn everything about the customer.” It is to acquire enough legitimate, representative evidence to make the next bounded decision. That requires a discovery plan, a stakeholder model, an access-purpose map, and an evidence log that can preserve contradiction without turning it into false certainty.

Official service guidance provides durable support for beginning with the user’s whole problem and context rather than a chosen solution, and for using interviews, observation, and existing evidence to learn how real users work. This chapter transfers those principles to FDE engagements without claiming that a government service process is mandatory for every customer. [CLM-009] [CLM-010]

Enter with a question, not a data appetite

Chapter 1 left Orchid Assist with a provisional responsibility charter. The charter did not authorize a solution. It established a bounded hypothesis: Orchid may be able to improve evidence-supported field-service resolution for one equipment family, region, and technician cohort without weakening safety, privacy, reliability, cost, judgment, or ownership.

That hypothesis creates questions:

• Where does a service request begin, and when is it considered resolved?
• Which people make which decisions?
• Which evidence is available when each decision is made?
• What happens when an equipment identifier is missing, duplicated, or wrong?
• When does a technician need qualified approval?
• Which systems contain manuals, inventory, prior service, and telemetry?
• Which path is official, which path is common, and which path succeeds?
• What failure is merely inconvenient, and what failure carries safety, customer, financial, or operational consequence?
• Who owns the decision to change the workflow?

Questions are not decoration before access. They are the basis for access.

Use an access-purpose chain:

discovery question -> minimum credible evidence -> minimum data or access -> handling constraint -> owner and approval -> expiry -> decision enabled

Suppose the team asks for all production tickets. “We need to understand the workflow” is too vague. A better chain is:

Determine how often selected equipment records fail to match the ticket identifier -> customer-run aggregate and a small redacted sample of mismatch classes for the selected family and recent period -> no names, free-text notes, unrelated regions, or attachments -> reviewed in the customer-controlled environment -> approved by the data owner and security/privacy contacts -> access ends after taxonomy validation -> decide whether identifier reconciliation must enter the first vertical slice.

The exact minimization depends on context. The durable rule is that access should be tied to a named purpose, made no broader or longer than necessary, and governed by explicit owners and handling. Current deployment descriptions and security/privacy guidance make least-required access and risk ownership material; the FDE title does not override them. [CLM-011]

This rule improves engineering as well as governance. Large uncontrolled exports create noise, unclear provenance, accidental dependencies, irreproducible analysis, and handling burden. Purpose-bound evidence makes it easier to record what a finding does and does not support.

Stakeholders are not one-dimensional

A stakeholder list often contains names and job titles. That is insufficient for discovery because several different relationships are collapsed into one word.

For each person or group, consider at least six dimensions:

1. Impact. How can the deployment affect this person’s work, rights, risk, performance, or customers?
2. Knowledge. What workflow, exception, system, policy, or history can this person explain or demonstrate?
3. Access. Which people, environments, records, tools, or sites can this person legitimately make available?
4. Responsibility. Which operation, artifact, control, support path, or result is this person expected to maintain?
5. Influence. How can this person accelerate, resist, interpret, or reshape the deployment?
6. Decision authority. Which named choice can this person approve, reject, accept, or escalate?

The dimensions may point in different directions. A sponsor may have high influence and business authority but limited knowledge of field exceptions. A technician may have deep workflow knowledge and high impact but no authority to accept privacy risk. A platform engineer may control access to an API but not own the service operation that depends on it. A support analyst may see failure patterns that leadership dashboards omit.

Separating the dimensions prevents three errors.

First, access is not authority. Someone who can grant a credential may not be permitted to authorize the proposed use.

Second, knowledge is not representativeness. The most experienced operator may have rare expertise and an unusual workflow. Their account is valuable but should not silently describe every user.

Third, influence is not impact. A leader can dominate the project while people with little organizational power absorb most of its consequence.

The stakeholder map is a hypothesis. Mark it as such. Revise it as interviews, observation, records, and operating behavior reveal missing people or misunderstood decisions.

Build an evidence ladder

Discovery produces statements with different strengths. Store the strength with the statement.

This book uses five practical levels:

• Reported. A person, document, or system says something is true.
• Observed. The team witnesses an instance under stated conditions.
• Measured. A defined method produces a value or distribution over a stated population and window.
• Reproduced. The team can trigger or reconstruct the behavior under controlled, documented conditions.
• Production evidence. The behavior is supported by live operating evidence across the bounded context and observation window.

The ladder is not a ranking of human worth. Reported evidence can reveal a safety consequence no event log contains. Production metrics can be misleading when event semantics changed. A reproduced failure may be more useful for engineering than a weak production correlation. The ladder helps the team state what kind of support it has.

An entry in the evidence log should include:

• evidence ID and date;
• exact statement or observation;
• level;
• source and collection method;
• affected user/workflow/system/context;
• sample or time boundary where relevant;
• provenance and handling constraint;
• confidence and reason;
• corroborating or contradictory evidence IDs;
• decision or hypothesis affected;
• owner and next validation step.

Consider these entries:

E-017, reported: Regional service lead states that inventory is “usually current.” No definition of current; applies to Region West; validation pending against update timestamps and technician experience.

E-023, observed: In two supervised Region West cases, technicians opened personal notes before the official manual portal because equipment search returned multiple near-matches. Small convenience sample; affects identifier and trust hypotheses; do not infer prevalence.

E-031, measured: For the customer-run query definition v2 over selected-family tickets in the stated 30-day window, 14 percent lacked the canonical equipment ID. Excludes phone-only requests and corrected tickets; query and data owner recorded.

The precision in the third statement is defensible only because the definition, query version, population, exclusion, and owner are recorded. Without them, “14 percent” is false confidence.

An opinion is evidence of a report

Stakeholders frequently say:

• “Technicians will never use another tool.”
• “The API is reliable.”
• “Security will not allow that.”
• “This exception almost never happens.”
• “The model needs all historical tickets.”

Do not dismiss these statements. Do not promote them to workflow fact either.

An opinion is direct evidence that the person reports, expects, fears, or prefers something. It may also be an informed hypothesis about the workflow. Appropriate testing depends on consequence.

“Technicians will never use it” can prompt observation of current tools, access constraints, prior deployments, evidence needs, and incentive conditions. “The API is reliable” can prompt service objectives, incident history, timeout/error behavior, and a controlled integration test. “Security will not allow that” can prompt the exact control objective, policy owner, affected data/action, alternatives, and formal decision path.

Guidance to start by learning user needs explicitly warns against treating stakeholder opinions as established user needs. The same discipline applies here: preserve the report, record the speaker’s context, and test the inference. [CLM-012]

Contradictions are not a nuisance to smooth over. They often reveal segmentation, incentives, hidden state, or different meanings.

If technicians say equipment search is unreliable while the data team reports 99.5 percent field completeness, both may be correct. The required field may contain a syntactically valid but operationally ambiguous identifier. The data metric may cover records while technicians encounter tickets. One region may differ. A recent migration may have changed behavior. The contradiction directs discovery toward semantics and population, not toward deciding who is “right.”

Choose complementary discovery methods

No single method reveals the whole customer system.

Interviews

Interviews expose language, intent, perceived problems, exceptions, decision reasoning, and organizational history. They are especially useful for asking why a person made a choice and what evidence was unavailable.

Limitations: memory is selective; official process can replace actual process in the retelling; interview conditions affect candor; confident accounts can be unrepresentative.

Good practice:

• ask for a recent concrete case before asking for general frequency;
• ask what happened next, what was checked, who decided, and what failed;
• separate “should” from “did”;
• request artifacts or demonstrations with legitimate handling;
• record exact uncertainty instead of filling it with assumptions.

Contextual observation

Observation exposes tools, switching, waiting, workaround, collaboration, environment, and embodied knowledge that may not appear in procedure documents. It can show where the visible interface is a small part of the actual path.

Limitations: observation can alter behavior; a few cases are not a prevalence estimate; sensitive contexts may prohibit observation; the observer can misunderstand domain actions.

The FDE should narrate interpretations back to the user: “I saw you compare the serial plate with two records before opening the manual. What decision were you making?” The user supplies domain meaning; the engineer does not invent it.

Existing records and artifacts

Policies, runbooks, tickets, logs, schemas, dashboards, incident reports, training material, and support cases reveal stated expectations and historical evidence.

Limitations: artifacts can be stale, selectively retained, generated under changing definitions, or disconnected from actual behavior. A dashboard label is not a metric contract.

Reproduction and technical inspection

Sandbox calls, synthetic fixtures, schema inspection, controlled failure, and code/configuration review reveal executable behavior.

Limitations: non-production environments differ; access can expose sensitive implementation; reproduction demonstrates possibility under conditions, not production frequency.

Quantitative measurement

Defined queries and event analysis can estimate magnitude, variation, cohorts, and trends.

Limitations: collection semantics, missingness, selection, changed definitions, and incentives can invalidate apparent precision.

The discovery plan should combine methods according to the next decision and the cost of being wrong. Interviews and observation may be sufficient to reject an obviously misframed solution. A safety-relevant exception may require domain review, technical reproduction, and stronger production evidence before scope is selected.

End-to-end and front-to-back service guidance reinforces that discovery must include channels, operational processes, technology, and security rather than only the visible interface. [CLM-013]

The Orchid discovery plan

The OA-01 discovery plan turns the charter into executable work.

Decisions discovery must enable

1. Which operational decision and bottleneck should Orchid Assist address?
2. Which equipment family, region, user cohort, and exception set can represent the first safe path?
3. Which data and interfaces are necessary, and what quality/access constraints exist?
4. Which recommendations carry safety, privacy, or material operational consequence?
5. Which owners can define outcome, guardrail, approval, rollout, support, and handoff decisions?

Stakeholder hypotheses

• technicians: affected users, workflow and exception knowledge;
• dispatch/service coordinators: queue, prioritization, escalation, and handoff knowledge;
• service operations leader: outcome and process responsibility;
• equipment/maintenance specialist: qualified domain decisions and safety escalation;
• inventory/ERP owner: stock/order semantics and interface responsibility;
• ticketing/equipment registry owners: identifiers, schemas, access, and change constraints;
• regional leader: data boundary and operating authority;
• security/privacy owners: access, handling, control, and formal exception path;
• support/on-call teams: actual failure demand and ownership feasibility;
• customer engineering/platform teams: deployment, identity, network, observability, and release paths.

This is a hypothesis, not an invitation list. Discovery should deliberately test for overlooked contractors, accessibility needs, low-connectivity sites, night shifts, new technicians, and people affected by the workflow without using the new interface.

Evidence sequence

Begin with existing process/policy/support evidence and a small set of role-diverse interviews. Observe representative cases with permission. Build a provisional workflow and contradiction log. Request minimized quantitative or technical evidence only for decisions the early findings make material. Reproduce a small number of critical interface/data behaviors in a controlled environment. Validate the current-state map and remaining contradictions with users and owners.

The sequence reduces the chance of collecting large datasets before the team knows which semantics matter.

Access-purpose examples

Question	Minimum initial evidence	Avoid initially	Owner/constraint
How are equipment records matched?	supervised walkthrough, schema/field definitions, redacted mismatch examples	full ticket archive and unrelated attachments	registry/data owner; customer environment
Where does inventory fail the decision?	interface docs, error semantics, selected synthetic calls, support categories	production write credential	ERP owner; read-only/sandbox first
Which safety decisions need approval?	policy/process, qualified expert interview, recent de-identified scenarios	model deciding the policy	safety/domain owner
Does connectivity alter use?	site/network constraints, segmented latency/support evidence, supervised observation	device-wide data capture	regional IT and user consent/process

Stop and escalation conditions

Pause or reduce discovery when requested access has no accountable owner; handling requirements are unknown; observation cannot be conducted legitimately; a high-consequence domain decision has no qualified owner; sponsor access excludes materially affected users; or evidence cannot support a representative/safe path.

Stopping here protects the outcome. It prevents urgency from converting ignorance into production exposure.

Trust is built through evidence behavior

Customer trust is sometimes described as charisma, responsiveness, or executive presence. Those qualities can help, but durable technical trust comes from observable behavior:

• say what is known, inferred, and unknown;
• do not overstate domain understanding;
• use the least access required and return or expire it;
• preserve inconvenient contradictions;
• make decisions and changes traceable;
• surface bad news early with consequence and options;
• follow the customer’s formal operating and incident paths;
• show working technical evidence, not only presentations;
• credit user and specialist expertise;
• close loops when someone supplies evidence or raises risk.

Trust is not permission to become informal. A close customer relationship can increase the risk of undocumented exceptions or data sharing. Good FDE practice makes legitimate collaboration easier by clarifying purpose, owner, boundary, and expiry.

Run discovery as a sequence of decisions

Discovery should have a cadence without becoming a factory of meetings. A useful cycle is: prepare, collect, synthesize, challenge, decide, and re-plan.

Prepare

Before an interview, observation, or technical session, write the decision it may affect and the current hypothesis. Review what is already known. Identify sensitive topics, required permission, and the evidence that must not be collected. Select participants because of impact or knowledge, not convenience.

For an Orchid technician observation, the preparation note might say:

Decision affected: whether the first slice must reconcile ticket and equipment identifiers before retrieving manuals. Current hypothesis: technicians routinely resolve ambiguous identifiers using visual equipment evidence and personal knowledge. Observe two selected-family service cases with user and customer approval; record decision steps and system transitions, not customer-identifying content. Do not infer frequency from the sessions.

This note stops the session from becoming open-ended surveillance.

Collect

During collection, preserve the distinction between the participant’s words, the observer’s description, and the observer’s interpretation.

• Participant: “I never trust this field.”
• Observed: technician compared the field with the equipment plate and an older ticket in both observed cases.
• Interpretation: field may be syntactically present but operationally unreliable for identification.
• Next test: review field provenance and a customer-run sample of mismatch classes.

Do not silently edit a statement into your preferred explanation. Ask neutral follow-ups and capture why a decision mattered.

Synthesize

After each small set of sessions, update the stakeholder map, evidence log, contradiction register, workflow hypothesis, and access-purpose map. Synthesis should change an artifact or explicitly state that no decision changed.

Use a short evidence review:

1. What did we learn?
2. What kind of evidence is it?
3. Which prior assumption did it support or contradict?
4. What decision changes now?
5. What consequential unknown remains?
6. What is the least costly legitimate way to resolve it?

Challenge

Ask someone with different impact or knowledge to challenge the current model. Show the evidence and uncertainty, not merely a polished diagram. A support analyst may reveal a failure cluster. A new technician may expose a hidden expertise assumption. A regional owner may invalidate a data path. A security engineer may offer a safer evidence method than the team assumed.

Challenge is not a ceremonial review. Record whether it changes the model, leaves a dispute, or identifies a decision owner.

Decide and re-plan

Discovery earns its cost when it enables a decision: narrow the problem, request specific evidence, add a stakeholder, reject a feature, stop an unsafe path, or proceed to detailed workflow mapping. Record the decision and re-plan only the remaining uncertainty.

This cadence also gives discovery an exit. The team does not need exhaustive domain knowledge. It needs sufficient evidence for the next bounded decision, explicit gaps, and a safe path to strengthen the evidence later.

Conduct sessions without taking the domain

An FDE needs enough domain understanding to build correct technical behavior, but the method must protect against confident imitation.

Ask participants to teach decisions through cases:

• “Tell me about the last time this path failed.”
• “What evidence made you choose that action?”
• “What would cause you to stop or escalate?”
• “Which part is policy, which is judgment, and which is system limitation?”
• “Who would disagree with this description?”
• “What changes for a new technician, another region, or an unusual equipment state?”
• “Can you show the artifact or state you relied on, within the approved access boundary?”

Avoid solution-confirming questions such as “Would an AI summary solve this?” The participant may answer the concept rather than reconstruct the work. Ask first what evidence is sought, how confidence is judged, what errors cost, and where the next decision occurs.

At the end of a session, play back the interpretation:

“I believe the equipment ID in the ticket is treated as a search hint, not a trusted key. When multiple records match, you compare location, serial evidence, and prior service; if ambiguity remains, you escalate before selecting a manual or part. Is that accurate? Which case would break this description?”

The final question invites disconfirmation. It signals that the engineer is building a model, not claiming expertise.

If a participant supplies a safety, legal, privacy, or policy interpretation, record both the content and the authority status. A knowledgeable user can reveal the practical rule while a designated owner remains responsible for approving the rule used by the deployment.

Handle evidence you should not retain

Sometimes sensitive evidence must be inspected without becoming a project asset. A customer expert can run a query and share an aggregate. A production trace can be viewed in the customer environment while only the failure class is recorded. A qualified owner can demonstrate a case using redacted or synthetic inputs. A schema can be reviewed without copying representative records.

The evidence log should say what was observed, by whom, under which conditions, and what conclusion it supports. It should not reproduce sensitive content merely to make the note feel complete.

If the conclusion cannot be audited without retaining prohibited data, do not create a vague assurance. Record the limitation and identify an approved evidence mechanism: customer-retained query, attestation by an accountable owner, reviewed derived statistic, reproducible synthetic case, or controlled test executed by the customer.

Data minimization can reduce future harm, but it can also reduce reproducibility. That is a real tradeoff. Resolve it explicitly with provenance, customer-controlled artifacts, reviewer identity, and a repeatable method rather than by keeping unnecessary copies.

Discovery failure modes

Sponsor-only truth

The team interviews leaders and maps the desired process. Missing users, operators, support, and system owners appear later as “resistance” or “unexpected requirements.”

Repair: map impact and knowledge separately from influence; include representative users and people who handle exceptions.

Data-first certainty

The team receives a large dataset and immediately calculates distributions. Field semantics, missing populations, changed definitions, and workarounds remain unknown.

Repair: start with decision questions and semantic discovery; record query/version/population/exclusions; triangulate with workflow evidence.

Interview theater

The team conducts many interviews but produces no tested workflow model or changed decision.

Repair: connect every discovery activity to a hypothesis, artifact, contradiction, or next decision. Stop interviewing when marginal evidence no longer changes the bounded decision.

Domain performance

The engineer learns terminology and begins making expert judgments. Users stop correcting the confident outsider.

Repair: state interpretations as hypotheses, ask qualified people to explain decisions, and record where formal expertise/authority is required.

Access accumulation

Credentials and exports remain active “in case they are needed.” Ownership and deletion are unclear.

Repair: maintain an access register with purpose, approver, scope, storage, audit, expiration, and revocation evidence. Review it at each phase gate.

Contradiction collapse

The team chooses the most senior or most convenient account and deletes alternatives from the narrative.

Repair: preserve contradiction IDs and design the next observation, measurement, or reproduction to explain the difference.

Treat access as a changing production artifact

Access decisions made during discovery often survive longer than anyone intended. A temporary credential becomes part of a script. A downloaded sample is copied into a test fixture. A broad permission remains because no one recorded who should revoke it. By the time the system approaches production, the team no longer knows which access is necessary.

Prevent this by maintaining an access register from the first day. Each record should contain:

• a stable access ID;
• the question or task it enables;
• the person, service, environment, data category, and operation in scope;
• whether access is read, write, approve, administer, or impersonate;
• the accountable system/data owner and approving authority;
• the user or workload identity receiving access;
• the approved storage, transfer, logging, and retention conditions;
• the issue/change record through which it was granted;
• the grant, review, and expiry dates;
• the evidence produced through the access;
• the condition for reduction or revocation;
• revocation evidence.

The register should distinguish access to observe, reproduce, build, release, operate, and recover. These purposes do not imply the same permission. A discovery analyst who needs to inspect a customer-run aggregate does not necessarily need raw-record access. A deployment service that reads inventory does not need the authority to place an order. A support engineer who can inspect health may not need to view user content. A break-glass identity should not become the normal release path.

Review the register whenever the deployment changes phase. At the end of discovery, remove access that produced its intended evidence. Before the vertical slice, replace personal credentials with bounded workload or development identities where appropriate. Before rollout, test production access, monitoring, and revocation. At handoff, remove hidden FDE dependency.

This practice does more than reduce privilege. It exposes architecture. If an essential workflow decision can be made only through a person’s broad administrator account, the problem is not “remember to be careful.” The dependency, identity flow, and operating owner are incomplete.

Example access records

A-004 might permit a customer data analyst to execute a versioned aggregation over selected-family tickets in the customer environment. The FDE receives the query definition, population/exclusion notes, result table, and owner review, not the raw records. The access remains with the customer analyst and expires from the discovery plan after the metric is reproduced or replaced.

A-009 might permit the FDE’s named development identity to call a sandbox inventory API using synthetic equipment and part identifiers. It allows read operations only, logs calls to the customer sandbox audit trail, and expires at the architecture gate. It cannot prove production latency, capacity, or write semantics.

A-014 might be a proposed production read permission for the Orchid Assist workload identity. It remains pending during discovery because the topology, tenant/region boundary, fields, service owner, and rollout cohort have not yet been approved. Recording it now identifies a future dependency without granting it prematurely.

Make discovery inclusive of edge conditions

“Representative users” is not a synonym for “average users.” A small group can be material because its consequences, environment, or exclusion risk differ.

For Orchid, the discovery plan should ask whether the selected sample covers:

• new and highly experienced technicians;
• low-connectivity and well-connected sites;
• day and after-hours work where support differs;
• common and high-consequence equipment states;
• people who use assistive technology or encounter accessibility barriers;
• contractors or regional teams with different identity and policy paths;
• support and coordination roles that absorb failures without using the interface;
• users who abandoned a previous tool and therefore disappear from activity data.

The team cannot always observe every segment before scope. It can record which segments are represented, which are missing, why the gap matters, and how later verification or rollout will contain it. The mistake is to let convenient access define the population silently.

This also changes facilitation. A group workshop may suppress a junior technician who disagrees with a leader. A translated or asynchronous method may be needed. An observation at a showcase site may miss low-connectivity behavior. An accessibility need may change the permitted artifact or session format. The FDE should work with the customer’s appropriate research, accessibility, privacy, labor, and management owners rather than inventing local policy.

Produce a discovery decision packet

At the end of this chapter, do not hand the team a folder of notes. Produce a compact decision packet that someone who did not attend every session can inspect.

The packet contains:

1. Purpose and decisions. Which next decisions discovery must enable.
2. Stakeholder coverage. Impact, knowledge, access, responsibility, influence, authority, plus missing voices.
3. Evidence index. IDs, levels, provenance, handling, confidence, and affected hypotheses.
4. Contradiction register. Competing accounts, possible explanations, consequence, and next test.
5. Access register. Granted, pending, rejected, expired, and revoked access with purpose and owner.
6. Emerging workflow hypothesis. The current path and exceptions, explicitly not yet the verified OA-02 model.
7. Decision-right gaps. Missing or disputed accountable owners.
8. Discovery limitations. Population, time, environment, data, and method boundaries.
9. Next action. The Chapter 3 workflow-validation work and its stop conditions.

The packet should not turn uncertainty into presentation polish. Use plain language such as “observed twice under supervised conditions; prevalence unknown” and “regional owner not yet identified; production data path blocked.” Precision about weakness is a form of quality.

The stakeholder/evidence framework in this chapter is an original synthesis. It organizes durable discovery and access principles into an FDE artifact; it is not presented as a formal external standard. [CLM-014]

Conduct the discovery exercise

Prepare a two-week discovery plan for fictional Orchid without requesting broad production access. Name the decisions discovery must enable, stakeholder hypotheses, evidence ladder, complementary methods, access purpose/scope/expiry, handling/retention, stop conditions, and daily synthesis/replan cadence.

Inject three conflicts: sponsor says identifiers are reliable while technicians report ambiguity; dashboard shows fast closure while observations show transfers/rework; a useful log contains more sensitive content than the current purpose permits. Preserve the reports separately, choose the next credible test, and route the data-access decision to the named owner.

Pass when the packet distinguishes observed/reported/inferred evidence, records confidence and gaps, includes edge users/conditions, and can proceed without the FDE pretending domain authority or accumulating unnecessary access.

The entry gate

Before Chapter 3 maps the workflow, OA-01 should contain:

• a provisional responsibility charter;
• discovery decisions and questions;
• stakeholder hypotheses across all six dimensions;
• interview, observation, artifact, measurement, and reproduction plan;
• access-purpose records with handling and expiry;
• an evidence log and contradiction convention;
• accountable owners for formal decisions;
• stop/escalation conditions;
• explicit evidence and access gaps.

The gate does not require complete knowledge. It requires a legitimate path to stronger knowledge.

The most important habit is simple: never let proximity masquerade as proof. Enter the customer system with humility, precise questions, minimal access, and records that allow the evidence to disagree with you.

Chapter 3, Map the Workflow That Actually Exists, uses that foundation to model actors, decisions, states, data, tools, handoffs, incentives, queues, and exceptions. It will turn the sponsor’s “AI copilot” request into a verified current-state problem model without erasing what remains uncertain.