2  Principles of trustworthy assistance

Chapter 1 defines an AI-first workflow as a bounded process in which artifacts, rules, events, benchmarks, and human decision rights govern an agent’s work. This chapter develops the principles that make such a workflow inspectable, repeatable, and reviewable.

Agents are bounded human assistants. Their exact role depends on the example: an agent may draft, calculate, compare, review, or monitor within its assigned boundary. In a code-review workflow, for example, an agent may act as an independent reviewer assistant. It does not make final statistical decisions, approve deliverables, or replace the responsible human role.

2.1 Root principle: Trustworthy assistance

The root principle of an AI-first workflow is trustworthy assistance.

Trustworthy assistance means the agent’s work can be inspected, repeated, challenged, and reviewed. The agent should not rely on hidden memory, unsupported claims, or vague reasoning. It should work from visible artifacts, preserve explicit state, act through defined events and rules, use tools to gather evidence, and escalate judgment to accountable humans.

A workflow is trustworthy when its inputs are visible, its actions are traceable, its findings are evidence-backed, and its limits are clear.

The five principles below translate trustworthy assistance into a practical design pattern.

2.2 Principle 1: Inspectable artifacts

Trust requires the agent and humans to inspect the same source materials.

Artifacts should be readable, structured where possible, versioned, citable, and diffable. Examples include:

• SAP sections that are searchable and citable;
• ADaM metadata that expose dataset names, variable names, labels, types, codelists, and analysis flags;
• TLF outputs with stable table identifiers, titles, footnotes, and source references; and
• findings stored as structured records rather than only narrative comments.

If the agent cannot inspect the work, it cannot reliably assist with the work.

2.3 Principle 2: Explicit state

Trust requires knowing what changed, what was checked, what was decided, and what remains unresolved. The workflow should remember through artifacts, not through chat alone.

State should show:

• which artifact versions are current;
• what changed;
• what was checked;
• which findings were produced;
• what humans decided and why; and
• what remains unresolved.

Clinical study work changes repeatedly. Without explicit state, every agent run becomes a disconnected review. With explicit state, the workflow can distinguish new, repeated, fixed, acknowledged, and unresolved findings.

Workflow state should be visible, reusable, and reviewable.

2.4 Principle 3: Events and rules

Trust requires predictable triggers rather than random or purely chat-driven action. An event indicates that something changed. A rule determines what the workflow should do next.

Event	Rule
SAP section updated	Rerun affected SAP-to-TLF checks
ADaM metadata changed	Rerun checks that use the changed variables
ADaM dataset refreshed	Rerun affected population and value checks
TLF output regenerated	Rerun affected TLF checks
Human requests a recheck	Run the requested review
Another agent changes a deliverable	Verify downstream impact

Without explicit triggers, review coverage depends on someone remembering to ask. Events and rules make the workflow easier to repeat and explain.

Events trigger attention; rules trigger action.

2.5 Principle 4: Tools and evidence

Trust requires findings grounded in the actual study artifacts rather than model memory or guesses. Tools expose real content and perform deterministic operations; the model uses the resulting evidence to interpret the task and prepare findings.

Example tools include:

• parse_sap_requirements();
• inspect_adam_metadata();
• query_adam_population();
• extract_tlf_metadata(); and
• compare_expected_actual().

A finding should state what was checked, what was expected, what was observed, where the evidence came from, and which human role should review it. A statement without traceable evidence is an unsupported opinion, not a finding.

No finding without evidence.

2.6 Principle 5: Human judgment

Trust requires clear accountability. AI-first does not mean AI-only.

An agent may identify discrepancies, assemble evidence, classify likely severity, and recommend follow-up. The accountable human decides whether a finding is valid, whether an artifact should change, and how the decision should be recorded.

The agent should stop or escalate when language is ambiguous, a required artifact is missing, evidence conflicts, a decision requires domain judgment, or the workflow rule does not cover the case.

2.6.1 Designing review so the gate pays for itself

Accountability is a slogan until review is designed as work. Three questions decide whether the human gate functions or merely exists.

Review cost. Checking prepared evidence should cost less than redoing the work or absorbing an escaped defect. That is the economic test of the gate: if reviewers routinely re-derive results from scratch, the workflow has failed its evidence-preparation duty. Fix the workflow, not the reviewers. Principle 4 sets up this economy: a finding that states what was checked, what was expected, what was observed, and where the evidence came from is cheap to verify; an unsupported opinion is expensive because the reviewer must rebuild the missing reasoning.

Sampling. Not every finding needs the same depth of review. Stratify by risk: deep review for high-severity, novel, or low-confidence findings, and spot checks for the rest. Record which finding class received which depth and why, so the split itself is inspectable. This book gives no universal fraction because the appropriate split depends on a workflow’s observed finding mix, severity definitions, and reviewer capacity; a percentage from another setting would be a false benchmark. Each team sets and justifies its own fractions, then records the plan with the benchmark report (templates/benchmark-report.md) and the monitoring report (templates/monitoring-report.md).

Calibration. Review quality decays when reviewers start rubber-stamping. Watch for the signals: an override rate falling toward zero, shrinking variance in review dispositions, or poor agreement when two reviewers check a shared sample. Report the calibration signal even when it looks healthy; silence is not evidence that review still works.

Agents prepare evidence; humans make accountable decisions. Design the review so checking stays cheaper than redoing, sample by risk, and calibrate the reviewers.

2.7 Preview: Change review across SAP, code, and results

A future applied example will use change management across the SAP, analysis code, and results to show how the principles work together. This is a useful preview because a change in one artifact can affect several downstream decisions.

Principle	Requirement for the future example
Inspectable artifacts	Provide versioned SAP requirements, code, metadata, and rendered results
Explicit state	Record changed artifacts and classify findings as new, fixed, acknowledged, or unresolved
Events and rules	Trigger only the checks affected by an accepted change
Tools and evidence	Compare expected and observed behavior and cite the supporting artifacts
Human judgment	Escalate ambiguity and preserve the accountable reviewer’s decision

The full example will define the workflow boundary, inputs, expected outputs, benchmarks, stopping conditions, and lifecycle artifacts. Keeping those details with the example avoids turning this principles chapter into a second workflow specification.

2.8 Putting the principles together

The five principles form a connected system. Inspectable artifacts establish a shared basis for the work. Explicit state provides continuity. Events and rules make action predictable. Tools connect findings to evidence. Human judgment sets the boundary of authority and accountability.

If any one element is missing, the workflow becomes harder to evaluate and trust. Together, the principles provide the foundation for the example-first, AI-first SDLC defined in Chapter 4.