B. Trust: Building a Trustworthy Relationship with Claude

Purpose: Researchers who ask "can I trust Claude?" are asking the wrong question. Trust is not a property of the tool — it is a property of the relationship between researcher and tool. That relationship can be designed well or poorly, and the design determines whether trust is warranted. This document names what a trustworthy relationship actually requires, and shows how project infrastructure is the primary vehicle for building it.

The wrong question and the right one

The wrong question: Is Claude reliable?

This question treats trust as a feature of Claude — something that is either present or absent in the tool itself. It leads to one of two bad positions: naive trust ("Claude is good, I'll use it") or blanket skepticism ("Claude hallucinates, I can't trust it"). Both are useless.

The right question: Have I created the conditions under which Claude's output can be trusted for this specific task?

This question puts the researcher in control. Trust is not given or withheld — it is built, through structural choices about how you configure the work. A researcher who has given Claude a precisely scoped task, a well-maintained CLAUDE.md, a clean information structure, and a defined verification point is in a fundamentally different epistemic position than one who has typed a vague question into an empty session.

Same tool. Completely different trust conditions.

What trust actually requires

Hallucination — the failure mode most discussed — is only one dimension of the trust problem, and not the most important one for researchers who work systematically. A more complete picture has three dimensions:

Accuracy: Does the output correctly represent what it claims to represent? This is the hallucination dimension: factual errors, invented citations, misquoted sources.

Scope alignment: Does the output address the task you actually set, or a plausible adjacent task? This is the framing and scope dimension: Claude answered something — but was it your question?

Epistemic transparency: Do you understand enough about how the output was produced to evaluate it? This is the ownership and verification dimension: you can trust output you can interrogate; you cannot meaningfully trust output that is a black box to you.

All three dimensions are necessary. A historically accurate output that addresses the wrong question is not trustworthy. An accurate, well-scoped output that you cannot explain to a reviewer is not safe to rely on. A research workflow that systematically addresses all three is one that produces warranted trust — not faith, not paranoia, but calibrated confidence.

The scope dimension: what you put in shapes what you can trust

The single most powerful lever on trustworthiness is not verification after the fact — it is scope control before and during.

Claude responds to what is in its context. If the context is well-defined, stable, and relevant to the task, the output can be assessed against known conditions. If the context is vague, accumulated, or inflected by prior conversation, the output is shaped by conditions you did not intend and may not be able to reconstruct.

The framing effect: What you include in a prompt does not just inform Claude — it frames what Claude thinks the task is. Including your hypothesis alongside data to be analysed tells Claude to confirm the hypothesis. Including prior interpretations alongside a new source tells Claude to synthesise rather than read freshly. The output reflects not just the question asked but the epistemic environment the question was asked in. (See A.issue.context-scope for the full taxonomy of framing effects.)

The consequence for trust: You can only trust output if you know what conditions produced it. A response generated from a clean, targeted context is auditable: you can trace its reasoning to the inputs you provided. A response generated from a long, accumulated session with many layers of prior context may be correct — but you cannot know which parts of the context shaped which parts of the output.

The practical implication: Trustworthy output requires controlled contexts. New session for each distinct task. Targeted inputs, not everything in the folder. Context that is documented enough to be reconstructable. This is not inefficiency — it is epistemic hygiene.

The verification dimension: checks as architecture, not afterthought

Most guidance on AI verification is offered as a tip: "Remember to check Claude's work." This framing treats verification as a habit — something to remember, something to add on top. It does not work reliably. Habits fail under time pressure, and the plausible surface of Claude's output makes it easy to skim without genuinely verifying.

The more robust approach is to treat verification as architecture — a designed structural feature of the workflow, not an intention.

Verification checkpoints are specific moments, built into the workflow before the session begins, where you stop and check a defined thing before proceeding. Not "I'll review at the end," but: "After extraction of the first five sources, I will review the extraction before running the rest." Not "I'll verify the citations," but: "The citation check is a separate step, with its own prompt, run before anything citing those sources goes into the document."

What makes a checkpoint effective:

• It is defined before the task starts, not decided in the moment (when you are already invested in the output)

• It checks a specific thing that can actually fail — not "does this look right" but "do these person names appear correctly in the source"

• It creates a stopping point — if the check fails, you go back; you do not rationalise forward

Task-type calibration: Not all outputs require the same verification intensity.

The execution/interpretation distinction from A.critical.limitations maps onto trust levels: execution tasks have higher baseline trust because the output can be compared to something deterministic (the source text, the formatting standard). Interpretation tasks have lower baseline trust because there is no ground truth to compare against — only your judgment.

The "critical questioning" step: For any interpretive output, before accepting it, ask Claude to interrogate its own work:

Now argue the opposite of what you just said.
What would a skeptical reviewer identify as the weakest
part of that analysis?
What did you not account for?

This is not about finding a definitive answer — Claude can be wrong in its self-critique too. It is about disrupting the sycophantic completion dynamic: the tendency of Claude to produce plausible, confident-sounding outputs that align with what it thinks you want.

The infrastructure dimension: project setup as trust scaffold

The deepest insight in this document: your project infrastructure is your trust infrastructure.

CLAUDE.md, skills, _history.md, progress files, shared configuration — these are not primarily productivity tools. They are the epistemic architecture that determines what Claude knows when it works, what you know about what Claude does, and whether the conditions that produced an output can be reconstructed later.

Consider two researchers working on the same source corpus:

Researcher A has a bare project folder, no CLAUDE.md, launches Claude fresh each session with a summary of context pasted from memory, accumulates long sessions without breaking them up, and saves outputs to loosely named files.

Researcher B has a well-maintained CLAUDE.md that specifies the corpus, conventions, and constraints; a set of skills encoding the extraction methodology; a _history.md documenting what has been tried and decided; a progress file tracking what has been processed and what remains; and a practice of starting new sessions for distinct tasks.

Both researchers are using the same model, the same tools, the same data. But Researcher B has created conditions in which:

• Claude's starting knowledge of the project is stable and documented

• Methodological decisions are recorded and traceable

• The conditions that produced any output can be reconstructed

• Verification checkpoints are embedded in the workflow through skill prompts

• Returning to the project after a break does not require rebuilding context from memory

Researcher A cannot reliably trust their own outputs because they cannot reliably reconstruct the conditions that produced them. Researcher B can. The difference is not Claude — it is the architecture around Claude.

CLAUDE.md as epistemic contract: A well-maintained CLAUDE.md is not just a convenience. It is a documented statement of what Claude knows about the project and what it is expected to do. When something goes wrong — when an extraction is wrong, when a convention is not followed — you can check CLAUDE.md and know whether Claude had the information to do it correctly. Without CLAUDE.md, you cannot audit the conditions of failure.

Skills as methodological lock-in: When an extraction methodology is encoded in a skill prompt, it is not subject to drift. Every invocation uses the same prompt. When the methodology evolves, the skill file is updated — and the change is tracked in version control. This is the difference between a methodology that is consistently applied and one that varies with the researcher's memory of what they intended.

History files as epistemic continuity: _history.md is not documentation for its own sake. It is the record that allows you to answer, months later: "why did we make this decision?" and "have we already tried this approach?" Without it, you are dependent on memory for your own project's reasoning. With it, you can reconstruct the epistemic chain.

Trust over time: how it builds and how it degrades

Trust in a working relationship with Claude is not static. It accumulates when conditions are maintained well; it degrades when they are not.

How trust builds:

• Through successful verification: you checked, it was right, the scope conditions that produced it are documented

• Through stable infrastructure: the project setup is well-maintained and reflects current reality

• Through explicit feedback: corrections that are incorporated into CLAUDE.md or skills rather than given once and forgotten

• Through calibrated use: tasks matched to appropriate trust levels, with verification appropriate to stakes

How trust degrades:

• Long sessions: Quality degrades as context fills. The Claude at the end of a three-hour session is less precise than the Claude at the beginning. Trust should be lower, not higher, with session length.

• Scope drift: When a session wanders from the original task, the framing context has accumulated layers that were not in the original brief. Outputs are harder to trace to the conditions that produced them.

• Stale infrastructure: A CLAUDE.md that no longer reflects the project's actual state is worse than no CLAUDE.md — it gives Claude false information that corrupts the epistemic baseline.

• Hypothesis confirmation accumulation: In a long session where you have signalled your expected conclusions, each subsequent response is shaped by that framing. Trust in interpretive outputs should decrease as the session continues, because Claude is increasingly writing to your expectations.

The reset habit: Starting a new session is not just a token-management technique — it is a trust-maintenance practice. A fresh session starts from documented, controlled conditions. An accumulated session starts from whatever was said and done before. The epistemically cleanest output comes from a new session with a well-maintained CLAUDE.md.

Trust and the team dimension

In collaborative work, individual trust calibration is not enough. The question becomes: how does a team build shared epistemic conditions that any member can rely on?

This is the function of shared project infrastructure in git: a committed CLAUDE.md, shared skills in .claude/commands/, a shared _history.md. These are not just configuration files — they are the shared epistemic contract of the collaboration. When a new team member joins, they inherit not just the data and code but the documented conditions under which prior work was done.

A team that shares this infrastructure is a team where:

• Any member can reconstruct the conditions of a prior output

• Methodological decisions are accessible to everyone, not stored in one person's memory

• Trust calibration can be shared and developed collectively, not reinvented individually

A team without shared infrastructure is a team where trust conditions vary by person, by session, and by memory — and where no one can fully audit anyone else's AI-assisted work.

The core disposition

The practical disposition that follows from all of this is neither "trust Claude" nor "distrust Claude" — it is design for trustworthiness.

Design the context. Design the verification checkpoints. Design the project infrastructure. Calibrate trust to task type and stakes. Maintain the infrastructure over time. Document what was done and why.

This is not more work than using Claude carelessly. It is the same work, done with awareness of what you are doing. The infrastructure pays dividends over the life of a project; the verification habits prevent errors that would cost more time to correct than to catch; the calibrated trust produces outputs you can stand behind.

The researcher who does this does not need to wonder, at the thesis defence or the peer review, whether Claude got something right that they did not check. They know what they checked and what conditions produced it. That is what trust — in the correct sense — actually means.

Related

• A.critical.limitations — the failure modes (hallucination, sycophancy, vibe research) that trust design must account for; the execution/interpretation distinction

• B.epistemics — the structural mechanisms behind sycophancy and hypothesis confirmation accumulation; why a well-maintained CLAUDE.md can become a confirmation loop engine; cross-model adversarial counter-practices

• A.issue.context-scope — the scope dimension in depth: framing effects, too-much and too-little failure modes

• A.issue.personalisation — the project infrastructure that is the primary vehicle for building trust conditions

• A.markdown.meta-docs — _history, _ownership, progress, _index: the accountability layer of that infrastructure

• A.markdown.token-efficient-docs — how to keep the project files that constitute the epistemic contract lean, accurate, and actually followed

• A.issue.team-claude — shared infrastructure as shared epistemic conditions for teams

• B.ownership — the epistemic transparency dimension: can you explain what Claude did and how?

• A.issue.plan-mode — plan mode as a structured verification checkpoint: the four-phase workflow for high-stakes tasks

• B.experience — the ownership axis: how high-trust workflows feel different from low-trust ones

• A.concept.agents — the supervision spectrum; trust calibration as the basis for deciding how much to delegate

• A.issue.research-wiki — the lint operation as a verification checkpoint for LLM-maintained knowledge bases; trust architecture applied to a compounding research corpus