Evidence before
commitment.

In a matter of seconds, a language model can produce text that is detailed, coherent and persuasive. That text looks like solid evidence. But it is not.

What looks like analysis may be an assumption. What reads like a conclusion may be a guess. What is presented as fact may be a reconstruction from memory. When these blend into a fluent passage, a human reader—even a careful one, at times—can lose the ability to distinguish assumptions, guesses and facts.

The more costly and irreversible the decision, the greater the cost of this mistake.

A lantern in the dark

The hardest projects are those whose scope exceeds what one person can know and understand. This has two dimensions.

Breadth: One person, working alongside several agents, takes on the work of a much larger team—a pattern that is becoming increasingly common. No individual can maintain sufficient focus and knowledge across several fields at once.

Depth: A project whose boundaries are initially unknown, where even knowledgeable developers do not yet know what they do not know along the path ahead.

RDEP reduces uncertainty before commitment. That sounds simple. It is not, because the pressure is always in the opposite direction: start now; we will figure it out later.

To do this, RDEP requires the different bases of understanding and decision-making to remain distinct and not be used interchangeably as work proceeds. Evidence remains separate from assumptions. An observation remains separate from its interpretation. A proposal remains separate from a decision. And what we do not know is recorded as unknown, rather than filled in with a plausible sentence.

The practical result is that, at any point in the project, we can ask, “Where did this come from?” and an answer exists.

In RDEP, participants' responsibilities and authority boundaries must be clear. The accountable human defines roles according to the project's needs and assigns them to people or agents. A role may be filled by one agent or ten; the number of agents does not, by itself, increase the validity or independence of the work.

A real project typically involves several advisors working in different areas: one searches for sources, another analyzes dense material, and another provides critique. Alongside them is an agent that executes the work, and another that provides direct advice on the executor's decisions. At the center is an accountable human: the sole point of command and authority among them, and the only one who makes decisions and accepts risk.

Agent agreement and the validity of evidence

Agreement between two AI systems is not independent confirmation.

Two models reaching the same conclusion are not two independent witnesses. The length, detail and confident tone of an output do not turn it into evidence. An agent reviewing another agent's work is still producing AI output, not evidence.

RDEP is not opposed to AI. It was written with AI's continuing presence in mind. That is why this rule is explicit.

As a project expands, more specialties become involved and terminology and abbreviations accumulate, the accountable human may no longer be able to clearly assess the basis of proposals or the consequences of decisions.

RDEP addresses this through a set of connected mechanisms: clarifying the problem and scope, breaking down complex questions, distinguishing evidence from assumptions, preserving the origin of information, examining alternatives and their consequences, recording unknowns, and allowing questions and reconsideration before commitment.

Clear language and explained terminology support this process. The aim is for the human to understand what decision they are making, on what basis, within what limitations and with acceptance of which risks.

Language quality matters alongside these mechanisms. In developing RDEP, selected parts of ASD-STE100 have been examined, including approaches to clear statements, consistent terminology and identifying who is responsible for each action. Some bounded rules arising from this examination have been incorporated into the Engineering Method and the documents it governs.

Because ASD-STE100 was developed for English, extending this approach to multilingual communication requires adapting expression to each language. This direction has been pursued within RDEP, and drafts have been prepared. It does not amount to full adoption of the standard or implementation of a comprehensive language control across all conversations.

The aim is to support informed human understanding: clear language must work alongside traceable evidence, an explanation of the reasoning, explicit unknowns and examination of the consequences of decisions.

It is not document production. Complete documentation, a clean repository and passing automated tests do not establish scientific or engineering maturity. Producing an artifact never, by itself, means passing the stage for which that artifact was created.

It is not a tool. Tools, scripts and agents can enforce policy, but they do not define it. The moment a tool becomes a second source of truth, the very problem RDEP was created to address has returned.

It is not a replacement for the human. Authority to make decisions and accept risk cannot be delegated.

RDEP emerged from encounters with real failures in AI-assisted work: proposals running ahead of evidence, untested assumptions becoming design premises, and decisions whose consequences were not sufficiently clear.

In the project's founding account, limitations in human knowledge and simplistic advice from agents reinforced each other. The result was progress along a path whose basis required further investigation. This raised the central question: how can human–AI collaboration be organized so that a convincing narrative does not take the place of reality?

The response has so far produced a framework that has been developed and put to use. The next direction is a product that provides software support and automates the parts that can be made dependable.

RDEP provides a framework for collaboration between humans and AI agents in research and engineering: the necessary questions, required evidence, assumptions and unknowns must be clear, and each participant's decision-making responsibilities and authority boundaries must be specified.

Facts, observations, measurements, inferences, assumptions, hypotheses, proposals and decisions are not interchangeable. Repeating a statement, presenting it confidently, recording it in a document or obtaining agreement from several agents does not prove it.

The aim is to reduce uncertainties that could change the project's direction before making decisions that are difficult to reverse. Progress means gaining a better understanding and being able to examine its basis. More text, diagrams or code do not, on their own, demonstrate such progress.

RDEP's rules do not depend on a particular model, vendor or application's proprietary memory. When a tool or agent changes, the basis of evidence and decisions must remain accessible, understandable and open to examination by the accountable human, enabling them to direct the project with informed judgment. RDEP's Core covers research and engineering definition through authorized entry into implementation; subsequent execution can be organized through appropriate controls that remain subordinate to the same principles.

Rules and Gates applied through forms and structured dialogue

RDEP now takes the form of written principles, nine (9) review Gates, project forms and collaboration procedures. The forms help keep necessary questions from being lost in conversation and preserve answers, sources and decisions for later reference.

The nine (9) Gates cover the Project Charter, idea definition and assumptions, the state of the art, feasibility, research decomposition, requirements, architecture, readiness to request proposals, and proposal evaluation. Entry into implementation also has separate transition conditions.

The existing forms cover subjects such as:

• Idea and Charter: the problem, operational need, objective, scope and decision authority.
• Assumptions and open questions: what remains unknown, why it matters and the consequences if an assumption is wrong.
• Research and experiments: the question, investigation method, required evidence and resulting findings.
• Feasibility and risk: constraints, dependencies and factors that could make a direction unjustified.
• Requirements and architecture: the origins of requirements, evaluation criteria, alternatives and selection rationale.
• Decisions: the proposal, alternatives, evidence, rationale, status, risks, cost of reversal and conditions for reconsideration.

A form is a place to record and examine the work. Completing it does not, by itself, resolve the problem or pass a Gate.

Roles, provenance and authority boundaries

In the development of RDEP itself, the responsibilities of the accountable human, executing agent and advisory agent have been defined and distinguished. In other projects, responsibilities for research, analysis or review can likewise be assigned to different participants according to need. Increasing the number of agents does not, by itself, guarantee the quality or independence of review.

The question and scope of work are clarified; the executor investigates and prepares outputs within its authority; the advisor's or advisors' opinions are presented with their provenance and limitations; disagreements remain explicit; and the required decision returns to the accountable human. The basis of the decision and the next authorized work are then recorded.

We have specific rules for this interaction:

• Advisors' proposals are not, by themselves, execution instructions or approvals.
• Participation in producing an output must be disclosed when judging that output; an author's review is not an independent review.
• Reproducing a measurement using specified inputs and methods is distinct from substantive judgment.
• Disagreements must be accompanied by reasons; agreement among agents does not create independent evidence.
• Gate passage, risk acceptance and other reserved decisions remain with the accountable human.

In developing RDEP itself, we have used this same framework to define responsibilities and work scope, examine advisors' proposals, record human decisions and preserve the records needed to continue the work.

So far, this approach has enabled us to:

• Record authorization to revise separately from acceptance of the result: permission to revise a text is not treated as acceptance of the revised version or advancement to the next stage.
• Re-examine and correct the attribution of a conclusion: when information from two different sources was conflated, the distinction between the sources and the correction to the conclusion were recorded.
• Keep changes available for reference: the proposal, decision, revised version and earlier record remain available for examination alongside one another.
• Build references for resuming work: decisions, open work and necessary documents are preserved in project records so that resumption does not depend solely on conversational memory.
• Run some recordkeeping and integrity checks: existing tools have been used to check the consistency of files and records; their results are not equated with the validity of the research content.

These are documented uses in the project's own development. We do not yet have a comprehensive evaluation showing how much this approach reduces errors or costs across all projects. Our experience in this work has also shown that having rules does not guarantee flawless adherence to them.

Several external sources have been examined selectively, within a defined scope, during the development of RDEP:

This work has gone beyond simply naming sources. To date, bounded rules have been incorporated into the framework's documents concerning engineering statement quality, requirements-set quality, the distinction between checking conformity to requirements and assessing fitness for intended use, and recording AI-use limits and risks.

This selective use does not amount to full adoption or certification of conformance to these sources.