CONCEPTUAL: THE PRD AND THE PASSAGE TO FEED

A project basis gives other participants something definite to work from. It expresses what the product is intended to accomplish, the conditions it must preserve, and the questions still to be resolved. The human and the design partner develop this account from their shared understanding of intent. They examine it as a connected description before it becomes the basis on which the project is divided and prepared for execution.

Consider the document editor introduced in Chapter 1. Its owner wants to use agent-proposed changes while retaining control of their own work. The person will continue editing while considering a proposal, and rejecting it must leave those edits alone. Preparing the product requirements document, or PRD, develops those intentions into an account that can guide proposal preparation, review, application, editing history, and verification. It must explain enough of their relationship for someone absent from the conversation to recognise what the project has promised.

HELPS_HUMANS develops the product account with the human, examines the material that supports it, and brings the completed document back for acceptance. A feature may need only a small set of records. A larger product may require wider intake, bounded investigations, and connected sections or normative annexes. At either scale, proposals remain distinguishable from the commitments the human has made.

The authoring method in this chapter has six working steps and two human checkpoints. They organise the preparation and examination of the basis, with the human deciding the product direction and subsequently accepting the document that expresses it.

The subject is a software development undertaking. It can concern a feature, an application, a service, a library, a platform, or several connected systems. Routine maintenance, patches, bug repair, issue execution, and stand-alone database repair or analysis can proceed under their applicable existing basis; they do not require this sequence of product conception. A difficult repair remains a repair. A finding from that work can lead the human to commission a new product capability, with its own purpose and basis, while the original repair obligation remains explicit. A feature request written in a ticket can supply the intent for a genuine development project; its storage format does not determine the nature of the work.

The method draws on the author's DBM practice: examine the role of each source, understand the subject before arranging the document, retain substantive detail in the body, and review the assembled account. Software product formation adds the work of proposing capabilities and developing intention. An engineering manager can recognise the purpose of the accepted design basis while examining the preparation appropriate to software.

PRD development and acceptance belong to Conceptual. The accepted basis then enters FEED, where decomposition develops packages and deliverables and setup prepares their working environment. Dependency mapping and the means of execution follow toward the 30% position. This chapter follows those connections far enough to show what the PRD must make possible.

2.1Prepare a basis document that people can use

The person reading a design basis needs to understand the proposed product without reconstructing it from evidence files. In an engineering DBM, that may require equipment configurations, operating cases, capacities, interfaces, limits, and the conditions still awaiting confirmation. In the editor's PRD, it requires an account of what a proposal is, what the user can do with it, what state those actions preserve, and what happens when the document changes while the proposal is open. Both readers need the substance on which subsequent work will depend.

A short overview can introduce the intention and help the owner recognise the proposed direction. The basis used for decomposition needs enough detail to distinguish the obligations that further work must satisfy. “Users can safely review and undo agent changes” leaves several questions unresolved: whether the proposal touches the live document before acceptance, whether rejection and undo have different meanings, and whether later manual changes survive. A fuller account should answer those questions or identify which remain open and how the project will develop them.

The amount of detail follows the undertaking. A familiar extension can refer to an existing accepted save-and-reopen specification and concentrate on its new interaction with proposal review. An unfamiliar product may need substantial original explanation. A short document can be adequate when the inherited basis is clear and applicable. A long document can still omit the condition that determines whether the design will work. Examine what the next participant would have to assume in order to use it.

Product formation and the existing design basis

PRD work can begin with conversation, current product information, accepted constraints, and observations. The agent can also propose capabilities and compare designs. A proposal needs a purpose, reasons, limits, and a clear request for the human's consideration. Evidence that the capability already exists is unnecessary when its proposed creation is the subject of the work. Claims about present behaviour or demonstrated feasibility require evidence appropriate to those claims.

Some basis documents are instead prepared for issue from an already accepted body of source material. In that arrangement, the document must preserve the upstream decisions. Preparing a readable memorandum does not authorise its writer to change those decisions. A new software PRD can establish a basis from which later project decomposition will proceed; its author therefore has to distinguish inherited commitments from choices being developed with the human.

Knowledge decomposition organises the subject matter available for examination. FEED project decomposition divides the accepted undertaking into the contributions that will produce the intended result. Keeping these purposes clear avoids asking a new project to supply its execution structure before its intended product has been defined.

The software PRD sequence

The method has six working steps. Two of them conclude in grouped human decisions. Source examination, writing, investigation, and correction proceed as needed within the sequence; they do not each require a separate approval.

PRD AUTHORING: WORK AND HUMAN DECISIONS

1. Intake and triage.
2. Develop the product account and confirm direction.
   Checkpoint A: product direction and basis for authoring.
3. Author the PRD and carry its open work.
4. Examine the complete candidate and repair it.
5. Obtain acceptance of the identified product basis.
   Checkpoint B: reviewed PRD and passage to FEED.
6. Preserve the result and hand off without starting FEED.

Figure 2.1. The recommended PRD sequence and its two human checkpoints. The working steps concern authoring within the conceptual phase. Existing direction can satisfy checkpoint A where it covers the proposed basis for writing.

Checkpoint A establishes the position from which the document will be developed. The human considers the proposed outcome, boundary, constraints, material source limitations, and open choices. Their earlier directions may already establish that position. The agent must identify the actual decision and what it covers, rather than repeat the same question because the method has now given it a name.

Checkpoint B concerns the document that writing and review have actually produced. The human can examine its particular requirements, included material, limitations, and open work before accepting it as the basis for FEED. Confirmation of the original intention cannot anticipate every interpretation introduced during drafting. The two decisions therefore concern related but different objects. Neither approves the completed product or authorises work beyond its stated scope.

For a small undertaking, the working record may be little more than a candidate PRD and one supporting file. As the project grows, sources, open questions, and delegated returns may warrant separate registers. Increase the structure where it helps someone locate and examine the work. An unfamiliar author should still be able to tell which document describes the product and which records support that description.

Example — a small feature project. The editor extension can be directed by one human with a continuing design agent and a few bounded execution and review assignments. The human's recorded direction may already cover checkpoint A. A concise PRD can state the one-document boundary, preservation requirements, inherited save and history commitments, and the open stale-proposal question. The four contributions in Figure 1.1 can later be represented in a short dependency table. Several prepared decision subjects may be considered together where their prerequisites are satisfied; each need not have a separate meeting or register. The record must still show what was examined and what the human decided. Separate assignments and records become more useful when several responsible people, unresolved interfaces, concurrent writes, high consequences, or difficult handover make those relationships harder to maintain.

2.2Establish what each source is allowed to support

Begin with the material that gave rise to the undertaking. Recover the owner's directions and corrections, the existing product basis, and the investigations used to examine possibilities. Identify the relevant versions and the question each source helps answer. A previous proposal may explain the history without establishing a present requirement. A test report may describe existing behaviour without making that behaviour acceptable. An accepted direction may define an outcome whose implementation remains unknown.

Intake also establishes which undertaking is being continued. A request may begin a new PRD, resume a draft, or propose a successor to an accepted basis. Inspect the existing target and any predecessor before writing. A new feature in a large application should inherit the relevant accepted commitments without forcing the writer to redefine every part of the application. An unrelated old draft should not become the default merely because it uses a similar filename.

Inspect enough material to support the next decision

The extent of intake follows the product. For the editor feature, the initial conversation, current editing specification, and a bounded inspection of proposal and history behaviour may supply a useful starting set. For a new service, the human may provide interface agreements, data descriptions, examples of caller activity, and operating constraints. A multi-system project may need a source inventory spanning several existing products and organisations.

An inventory identifies where the material came from, which revision was examined, and what it contributes. It is not a declaration that everything listed is correct or current. Read the passages that matter, including the surrounding qualification. Where an image, table, or example supplies the meaning, examine that content rather than relying on a short search result. Retain a source location precise enough for another participant to repeat the examination.

Do not expand intake into a survey of everything the agent can reach. Follow the questions that affect the proposed product and its constraints. If a source points to an interface on which a central promise depends, pursue that reference or identify the missing input. If an old report concerns an unrelated feature, retain it as context only when it has a useful role. The record should distinguish material deliberately set aside from material never examined.

Use the available facilities for reading, searching, extracting, and comparing the relevant material. Where a needed conversion or inspection cannot be performed, report what remains unexamined and which conclusions depend on it. The record should describe the examination actually completed.

Content, evidence, proposals, and navigation

Source treatment should explain the proposed use of each material item. The following table shows a small feature's intake. Larger products can use the same distinctions across a wider set of records.

Keep the source inventory, its proposed uses, and the open questions together with the authoring assignment. The record must distinguish the material actually examined from a similarly named file or a later revision. When several inputs or annexes belong to one candidate, a manifest can identify the set and the role of each item.

An audit report may establish that particular checks were performed against a particular candidate. It cannot supply a missing product requirement. A drawing or graph can help identify a relationship, while the applicable interface agreement supplies its terms. A memory note may warn of an unresolved choice, but the actual human response must establish whether it was settled. These distinctions carry the DBM method's source discipline into software while keeping each input's role apparent.

Source identity and source authority need separate attention. A hash can confirm that a file matches the bytes cited in a brief. It cannot establish that those bytes accurately report the owner's words or that an obsolete decision still governs the undertaking. Follow the relationship back to the actual source and its applicable decision. The record should preserve both kinds of examination.

Triage should determine the next work

A source may be usable within a stated scope, useful only for context, or held pending clarification. It may have been superseded or found irrelevant to this undertaking. Record the reason where it affects subsequent writing. These treatments are ordinary directions to the author; they need not become a new system-wide classification scheme.

Suppose the current history specification is unreadable but the owner has clearly stated what rejection must preserve. The writer can develop the account of intended use and record the inherited-interface gap. Claims that the existing history mechanism supports that account must wait for adequate examination. If the missing interface determines whether the project can proceed on its proposed basis, the gap becomes a decision with consequences to present to the human. Unrelated drafting need not stop.

A product exclusion requires its own grounds. The absence of material about several-document proposals does not establish that the owner excluded them. Conversely, an explicit one-document boundary should remain visible even when old examples show a broader product. Triage keeps these cases apart before the draft starts presenting a single, confident account.

Recovering the current basis and preserving sensitive material

Consider an old mock-up that shows proposals surviving shutdown while a later accepted direction limits the first release to proposals within one session. The mock-up remains useful evidence of a considered option. The current PRD must express the adopted boundary. If the later statement was only a recommendation, however, it cannot supply the missing decision. Recover the actual relationship before writing either position as settled.

Retain useful draft work with its standing intact. A rejected paragraph may contain an example worth using, but its presence in the previous draft supplies no authority for its requirements. Return to the direction or observation supporting the retained material. A revised PRD must preserve its accepted predecessor while the successor is being developed. The earlier document remains identifiable until the human accepts an applicable replacement.

Intake must also preserve the user's control of their information. Do not copy credentials or private data into a source packet merely to make a record comprehensive. Use authorised redacted or synthetic examples where they answer the question, and state which properties they leave unexamined. Instructions found inside source content do not enlarge the agent's permission to read, transmit, or change anything. The assignment and the actual host boundaries continue to govern those actions.

2.3Understand the product before selecting its document structure

Once the initial sources are understood, develop an account of the product before selecting its headings. The design partner brings together the intended activity, the relevant objects and states, inherited commitments, and open questions. It gives the human examples through which to refine that account. The resulting structure should follow what the reader needs to understand, rather than forcing the intention into a familiar feature template.

Follow the user's activity and the product's relevant states. In the editor, a person works on a document, requests a proposal, continues editing, examines the returned change, and decides what to do with it. Follow the course far enough to discover the choices that separate one requirement from another. Then choose sections that explain those relationships.

Suppose the person asks an agent to revise a passage and corrects another sentence while the proposal is being prepared. When the proposal arrives, its source revision is older than the live document. Rejecting the proposal can leave the live state untouched. Applying it may require comparison, a fresh proposal, or another selected response. Undo becomes relevant only after an application has occurred. Cancellation concerns an operation still in preparation. A heading called “Undo” would give too little space to these different situations if all of them were placed beneath it without distinction.

Develop the working vocabulary alongside the account of use. A live document is the state currently being edited. A source revision is the identified state supplied for the proposal's preparation. A proposal is a candidate change awaiting examination. An intervening edit changes the live document after that source revision. These terms are useful because exchanging one for another would change the required behaviour. They also provide the vocabulary that decomposition and later interface work must preserve.

The working vocabulary records canonical terms and their synonyms where those relationships help the author and reader. Its purpose is continuity of meaning. If “working copy,” “current document,” and “live document” refer to the same object in a particular source set, the map makes that relationship available to writers. If two similar terms name different states, preserving the distinction is more important than making every section use fewer words. A writer should not normalise away a difference that matters to the product.

The product account should expose thin areas of the basis. Perhaps the source material explains ordinary application but says little about interruption. Perhaps it describes preserving text while saying nothing about selection or history. The design partner can prepare examples to make those questions tangible. A bounded inspection can establish what the existing application supports. The human then judges whether the new account is adequate for the intended undertaking or requires more conception work.

For an engineering DBM, the corresponding review may find extensive information about equipment and nominal operation but little about an operating case or an interface. Examine the material available and the limitations it leaves. An expected section with little supporting content needs a visible treatment. Inventing a conventional description would hide the gap; omitting the subject could hide the obligation. The document plan must make the position clear. A software PRD needs the corresponding treatment when an expected operating case has little supporting material.

This is also the point to distinguish the product boundary from a gap in the sources. In the editor, “several-document proposals are excluded from this release” records a scope choice. “The required number of documents has not been determined” records an unresolved question. An absence of multi-document material does not establish the exclusion. The human's direction and its recorded interpretation must supply that boundary.

A product without a graphical interface needs the same attention to activity and state. For a service, the account might follow a client submitting a request, receiving an acknowledgement, and obtaining a result. The human must decide what the acknowledgement promises and what should happen if the client repeats the request after an interruption. Those choices can be described before selecting an internal queue or storage mechanism. A library's account similarly concerns the program using it and the people who must interpret its results or failures.

For a coordinated product, follow an activity across systems. Identify what each participant receives, what it is entitled to rely on, and who can act when the result is incomplete. A collection of local capabilities can leave that whole activity unexplained. The PRD's overview should give the later writers and reviewers a common account against which those local details can be considered.

The resulting overview need not settle every design choice. It should identify the intended product, the relationships already understood, and where further work is needed. Those become the basis for planning a document that has enough room to explain the actual subject.

2.4Plan the sections, their sources, and their expected contents

A document plan determines how the product will be explained and which relationships a writer must preserve. For a short feature PRD, the plan may be an outline in the continuing conversation, retained in the authoring record. For a larger product, it may identify a main document, normative annexes, shared terminology, source groups, and bounded authoring assignments. Its extent follows the work needed to produce a coherent account.

Give each substantial section a purpose and enough direction about its expected content. The source references then explain what can support that account and which material constrains it. The author should be able to find the intended result, the basis for writing it, and the open matters that must remain visible. The plan brings the document's organisation, writing instructions, and source relationships together. A short PRD can keep them in one working record.

Designing a section that can carry its subject

For the editor, a section on proposal application may need to explain the action's starting condition, eligibility, treatment of intervening edits, effect on history, and response to failure. Its expected contents should name those matters. A title and a sentence saying “describe proposal application” would leave each writer to determine the necessary extent of the subject.

ILLUSTRATIVE SECTION PLAN: PROPOSAL APPLICATION

Purpose
  Explain when a proposal may alter the live document while
  preserving the user's own work.

Required account
  Compare the source and live revisions; explain application,
  intervening edits, history, failure, and interruption.

Basis
  The preservation direction and one-document boundary;
  the applicable history specification and inspection evidence.

Open choice
  The stale-proposal response remains to be chosen.

Figure 2.2. A section plan relating purpose, required content, sources, and the remaining choice. A small undertaking can retain it in the ordinary authoring record.

Read the mapped sources before deciding that a section can be brief. A history specification may distinguish several operations that the apparent heading conceals. If a section assignment is too broad to address them adequately, divide the writing or reorganise the account. Compression that removes a relevant qualification changes the product meaning even when it makes the document easier to scan.

The writer may propose a state-and-action table because it makes alternatives or obligations easier to compare. Such a table must include the meanings of its states and any limitation on the claimed result. A table of source paths serves a different purpose. Detailed traceability belongs in the supporting record; it should not occupy the place where the reader needs an explanation of the product.

Decide what belongs to the accepted document set

A larger product may need several normative annexes. A main PRD can explain the common purpose and scope while an annex develops a substantial interface or operating case. Identify which annexes supply requirements, which documents are supporting evidence, and which references are included only for context. The human must know the extent of the candidate they are later asked to accept.

Keep each shared commitment in an identifiable home. An annex can elaborate how a requirement applies to its subject and refer to that home. Repeating the requirement independently in several annexes invites conflicting revisions. Conversely, a reference too broad to locate the relevant condition can leave the receiving writer to invent its meaning. State the applicable section or defined interface and retain its revision.

Source mapping remains useful when several writers contribute. The preservation direction may govern the application section. The existing history specification may constrain it. A prototype report may expose a limitation. Their presence in one reading packet does not make them interchangeable. A bounded brief should identify these roles, particularly where the prototype's simplifying assumption differs from the required production behaviour.

A section assignment must supply the intended material. Check the selected passages against the writing question, whether selection is performed by a tool or by the author. An incorrect selection leaves a gap that prose in the brief cannot repair. Simple source references are sufficient where they bound the assignment clearly.

Checkpoint A: confirm the direction that will shape the writing

Bring the human a coherent proposal: the outcome, the product boundary, important constraints, the relevant source position, material choices still open, and the proposed writing and review approach. Explain alternatives where they help the human recognise what they mean. A sketch or an early draft may be the clearest way to do this; preliminary writing is allowed before the checkpoint.

The human's confirmation establishes a basis for authoring. It does not make each proposed sentence a final requirement or freeze the eventual table of contents. A later section may expose an omission that calls for another example or a changed arrangement. Editorial choices within the confirmed direction can proceed. A change to the intended outcome, an adopted constraint, or a reserved decision returns with its consequences for human judgment.

If the conversation already contains a direction that covers the checkpoint, cite the actual words and explain what they establish. Ask only about material matters that remain uncovered or have changed. Keep the interpretation separate from the source direction. The method's two checkpoints are meant to prepare useful decisions; they provide no reason to repeat one the human has already made.

Keeping document structure distinct from project structure

A PRD section serves the reader's explanation. A package and deliverable serve the organisation of project work. One section may draw on several source subjects, and one accepted requirement may affect several eventual deliverables. There is no need to make those structures identical.

The editor's section on preservation can discuss review, rejection, application, and history together so the owner can examine the complete experience. FEED may divide their development into cohesive work domains and bounded deliverables. The later coverage records preserve the relationship between that division and the PRD. Splitting the prose to imitate a task list would make the product harder to understand without necessarily making its execution easier to manage.

2.5Write requirements that preserve the intended distinctions

The writer now has a product direction, a defined section, and its identified source material. Its task is to produce an intelligible technical account from that basis. It must preserve the differences that determine what the product should do, even when the source expresses them through examples or corrections. The human can then examine the proposed interpretation and its consequences before implementation spreads those choices through the product.

For the editor, the initial request to try changes and recover the work develops into several obligations. Review concerns examining a proposal before it alters the live document. Rejection concerns declining that unapplied proposal. Application incorporates a selected change into the live state. Undo concerns a subsequent operation on editing history. Those actions can have different requirements and different checks.

This table develops the teaching example; its entries require the human's examination before becoming product commitments. It shows why a single “undo support” requirement would be insufficient. Each row identifies a different relationship among the action, the relevant state, and the outcome. The open matters are part of the design work still to perform.

A requirement should identify its subject and the conditions in which it applies. Where words such as “unchanged” or “recover” conceal a choice, develop that meaning. Does preservation include the current selection? Does it include undo history? Does rejecting a proposal restore an earlier state, or leave the present state untouched? These questions can lead to materially different results even when the visible document text appears the same.

Keep the reasons with consequential requirements. Preserving manual work allows the person to continue using the editor while considering assistance. This purpose gives a reviewer a basis for questioning a technically convenient design that freezes editing or silently replaces a later revision. It also helps the person directing change understand what may be lost when a requirement is relaxed.

The source of the obligation and evidence of its satisfaction are different relationships. The owner's direction may support the requirement. An accepted technical interpretation gives it a particular meaning. A test can subsequently support a claim about the implemented behaviour. The requirement can therefore be accepted before that product exists, while a test report cannot create a requirement simply by measuring something. Preserve that boundary when developing the local scope of work, its outputs, acceptance criteria, and verification methods.

Keep engineering detail in the body

Keep substantive requirements, limits, relationships, and qualifications in the body or explicitly included normative annexes. This follows the DBM method's treatment of material design content. A table of operating cases or interface conditions has a different purpose from a list of file paths. Moving detailed provenance to supporting records should leave the technical account complete enough for its intended use.

A state-and-action table can make the PRD easier to examine. It helps the reader examine whether rejection preserves the correct state and whether application covers an intervening edit. The detailed source map can remain in supporting records. The required behaviour and its qualifications stay in the body. A statement that a topic is “covered by the source” would force the next participant to recover and interpret the missing account themselves.

The same discipline applies to limits. Do not replace a specific accepted limit with “within suitable limits,” or remove a condition because it makes the paragraph awkward. Equally, do not insert a typical numerical value where the source supplies none. Explain the missing input and which part of the design depends on it. Precision comes from preserving a warranted distinction, not merely from using numbers.

Exclusions must preserve the remaining obligation

Suppose retaining pending proposals across shutdown is outside the initial undertaking. That exclusion concerns the pending proposal. It does not remove the requirement to save content already incorporated into the live document. Writing “persistence is excluded” would blur the boundary and could cause the implementation team to omit required save behaviour.

When preparing a local scope of work, take boundary exclusions further: enumerate the excluded acts and identify who owns them, with the basis for that allocation. That is a means of preserving responsibilities at an interface. The PRD need not invent future deliverable identifiers to do so. It should explain the boundary clearly enough that decomposition can allocate the work and the local contract can name the proper owner.

For example, a proposal-review component may exclude the act of writing the document to storage while relying on the existing save service to perform it. This is an allocation within the product, rather than an exclusion of saving from the product. The basis document should keep those two meanings of “outside scope” apart. Otherwise several locally correct exclusions can leave the project with an obligation nobody owns.

2.6Preserve uncertainty and accepted change while writing clearly

Distinguish several kinds of unfinished business: a missing source, an unresolved intention, an unverified assumption, a later design choice, and a defect in the written account. The distinction determines what contribution can improve the position. A disputed product outcome needs human judgment. A missing interface value may require investigation or an external response. An omission from a section may be repaired from a source already available.

Keep one recoverable account of each material open matter, with references from affected passages. A small PRD can hold those accounts in an open-questions section and use its working record for detailed evidence. A larger PRD may use a linked register. In either case the body must express the relevant qualification where a reader would otherwise mistake the unresolved matter for a commitment.

In the editor, the response to a stale proposal is a design question. A statement that the existing history service can group an entire proposal may be an unverified assumption. A missing source for the promised save behaviour is a gap in the inherited basis. These should not all be rewritten as confident descriptions of how the completed application behaves.

Consider the sentence “The application reconciles the proposal with later manual changes.” It reads like settled design. If reconciliation is only one option under consideration, the sentence has advanced a proposal into a commitment. A faithful account states that the response remains to be selected, identifies the alternatives being considered, and preserves the already accepted prohibition on silent loss. The prose can be direct about what is known and equally direct about what remains open.

Distinguish acceptance of an assumption from confirmation of a fact

The human may authorise an investigation on the assumption that one proposal is active at a time. That gives the investigation a usable boundary. It does not establish that all future users will work that way or that the product has adopted the limit. If the human later selects one active proposal as the release scope, record that decision separately. The same words can describe an experimental simplification, a product limitation, or an observed condition; their standing determines how others may rely on them.

Make the standing of each statement apparent. A cited observation gives the reader a source to examine. An assumption identifies what the work is provisionally relying on. A proposal presents a choice, and an unresolved question identifies work still required. These distinctions can be expressed directly in the prose. Compact labels can help locate them, but the source and interpretation of a statement still require examination.

A design proposal can be worthwhile before its feasibility is fully established. The agent should explain the intended result, the reasons for considering it, and the investigation still needed. Source discipline should prevent fabricated evidence and false attribution. It should also preserve room for the proposals through which the human develops the product. Requiring every proposed capability to appear in a prior source would prevent the very conception work this method is intended to support.

Use supersession at the scope of the actual decision

A later direction can replace one part of the basis while leaving other commitments in place. Identify the part changed, the reason, and the consequences for the current draft. Preserve the previous decision and its original scope so that another participant can understand the development.

The software example is a decision to exclude persistence of unapplied proposals. That decision does not supersede saving of applied content or the recovery requirements of the underlying editor. The current PRD can state the new boundary and, where an older reference would confuse the reader, explain the particular difference. The detailed decision history belongs in the record supporting the current statement.

An updated DBM must preserve the relationship between its current sources and the decisions they supersede. Apply the same care to the PRD's identified directions, specifications, and candidate revisions. Where a source and the current account disagree without an adequate decision, preserve both statements for review. The agent may recommend the treatment it considers best supported. The human act that settles a consequential commitment must come from the person authorised to make it.

Correcting wording after its meaning is settled can proceed within authoring discretion. Changing the promised outcome, a protected limit, or an explicitly adopted design returns to the human. The working record should make those cases distinguishable instead of treating every edit as either a new approval or an inconsequential text change.

2.7Decide what can remain open through the next phase

PRD acceptance establishes a position from which the project can proceed. Its required maturity follows the product and the consequences of further work. The human considers what is already understood, which commitments constrain the remaining choices, and what the next phase can establish from that basis. The document need not anticipate every implementation detail. It does need to make influential unresolved matters visible.

For the editor, preserving intervening manual work can be a fixed outcome while the exact stale-proposal response remains open. The open question affects application, revision comparison, history, and the connected scenarios used for examination. It should have one recoverable description, with links from the places it affects. Repeating an unexplained “TBD” in several sections would give the appearance of recording uncertainty while leaving its common cause obscure.

ILLUSTRATIVE OPEN DESIGN QUESTION

Question
  What should the user be offered when the live document has
  changed since the proposal's source revision?

Commitment shaping the answer
  Application must not silently discard intervening manual work.

Alternatives under consideration
  Require a fresh proposal; offer reviewed reconciliation;
  or develop another response for the human to examine.

Affected work
  Application, revision comparison, history integration,
  and connected verification.

Next contribution
  The design partner compares consequences using an inspection
  of the current revision and history facilities.

Point by which an answer is needed
  Before dependent detailed designs adopt incompatible responses.
  FEED must preserve the question and its affected contributions.

Figure 2.3. An open-question record carrying the constraints, affected work, and intended resolution forward. It identifies the decision still to be made and the work that will prepare it.

This distinction helps determine the next assignment. An investigation of revision comparison can proceed under a bounded question. Decomposition can identify the affected scope. Execution definition toward 30% can bring the shared interface and response into a workable arrangement. Independent detailed implementation would be premature while each contributor must make its own consequential choice about the same behaviour.

Some questions instead prevent an adequate expression of the undertaking. “May the application overwrite the user's later work?” changes the outcome and its consequences. The human must judge that issue where it determines what the project is for. A missing implementation detail and an unresolved value choice can both appear as blank fields; they require different work to resolve them.

A less-developed PRD can still lead to success. Familiarity with the product, limited scope, and concentrated coordination may let the team resolve remaining details as they are needed. As complexity grows, a greater amount of work can become dependent on an unstated interpretation. The difficulty may emerge in the movement from 60% to 90%, when individually developed contributions have to culminate in coherent deliverables. The risk comes from work proceeding on incompatible interpretations; a short PRD does not inevitably produce it.

Follow one such risk through the example. A preview contribution assumes that a stale proposal can be reconciled. The history contribution assumes every application acts on the exact revision originally inspected. The verification contribution tests only fresh proposals. Each can produce a plausible local result. Bringing them together reveals an unresolved product choice that has already shaped three bodies of work. An earlier open-question record, carried through their briefs, would have allowed the manager to organise the common decision before those interpretations spread.

The purpose of additional definition is to reduce such uncertainty where it affects the course of the project. Detail that no later decision uses need not be elaborated solely to make the PRD look mature. The human should be able to see why an open matter can be carried forward, what work will examine it, and which commitments remain binding during that work.

2.8Produce bounded contributions under a common plan

PRD preparation can include inspection, comparison, limited demonstrations, section writing, and review. The four roles provide different responsibilities within that work. HELPS_HUMANS develops the conception and design with the human. HELP_HUMAN maintains the relation to the wider undertaking. WORKING_ITEMS can manage a bounded production effort that needs sustained coordination. TASK performs the particular inspection, section, or review assigned to it. A new kind of document does not require another permanent agent role.

In PRD preparation, HELPS_HUMANS remains the design lead and owns the coherence of the product account. It can prepare the document directly and commission bounded TASK contributions. Where sustained production warrants WORKING_ITEMS, the human or HELP_HUMAN establishes that undertaking and its relationship to the design work. The writing manager owns its integrated return, while the human retains the consequential choices. No new PRD agent is required.

For the PRD, retain close work with the design partner while the intention is still being developed. A manager can coordinate substantial document production once its purpose and section responsibilities are sufficiently clear. That arrangement remains compatible with a small document being written in one continuing conversation. The management question is which contributions need separate attention and who will ensure that they still form one product account.

Investigate a question before adopting its answer

An inspection of the editor's revision and history facilities could establish the available operations, the relevant tests, and the limitations of current behaviour. Give the executor the exact source scope and the decision the return will inform. A read-only brief can prohibit product changes and selection of the stale-proposal response while allowing technical comparison of the alternatives.

On return, examine the contribution against that purpose. A report may accurately identify an operation that groups edits while leaving interruption unexamined. A demonstration may show that a separate preview is possible using a simplified history model. These are useful results when their limits remain attached. They do not yet establish that the production design can satisfy the whole requirement.

Example — selecting the response. In the constructed editor project, the inspection establishes how the application can identify the proposal's source revision and the current live revision. It does not establish a reliable means of automatically reconciling intervening edits. The design partner compares refusal with a fresh proposal against a more extensive reconciliation design. The human chooses the smaller first undertaking: if the revisions differ, leave the live document unchanged and refuse application of that stale proposal; explain the reason and let the user request a fresh proposal. This is a direction for the PRD to express. The complete document still requires review and acceptance. Appendix A follows the choice through implementation and examination.

Exploratory code remains isolated while the PRD is being developed. Production implementation follows PRD acceptance, decomposition, and project setup. A later assignment may adopt part of the prototype, but it must account for the work needed to remove simplifications, satisfy the accepted production basis, and obtain appropriate examination. The existence of code does not discharge those obligations.

Brief the section writer for the actual material

A section brief should identify the intended reader's account, relevant directions and sources, expected contents, working vocabulary, and unresolved questions. State the permitted writes, required return, and what will be checked. Retain the brief as supplied so a later reviewer can examine the contribution against its actual assignment. If a section is too broad for bounded treatment, refine it instead of compressing away its qualifications.

The editor's application section illustrates why the brief matters. A writer supplied only with the heading and an optimistic prototype report could describe automatic reconciliation as the selected design. Supplied with the preservation requirement, the human's fresh-proposal choice, the history constraint, and the prototype's limited purpose, it can prepare an accurate account of the basis and remaining work.

ILLUSTRATIVE SECTION ASSIGNMENT: PROPOSAL APPLICATION

Read the identified PRD, preservation direction, fresh-proposal
choice, history specification, inspection return, and section plan.

Explain application conditions and required outcomes. Preserve
the distinction between applying, rejecting, and undoing. State
that a stale proposal cannot alter the live document and that the user
can continue editing while deciding whether to request a fresh proposal.

Identify the sources used, unresolved history or interruption
questions, and any material the section could not cover.

Figure 2.4. A bounded section assignment after the stale-proposal choice. The actual brief must also identify the permitted writes and the checks required on return.

The return should explain what the section did with its sources, including significant omissions, qualifications, and open matters. A brief assignment can carry this explanation in the return itself. Several substantial sections may warrant separate quality records. A primary source with material relevant content cannot be discharged by a token mention. Where the proposed structure cannot carry it, the writer reports the underdevelopment and recommends a better division or account.

Integrate section work before asking for acceptance

Writers can work in parallel when their assignments and write targets are separate. Their sections can still depend on the same meaning of a term or the same unresolved decision. The manager therefore examines their relationship as well as each return. In the editor, the history section and the application section must use the same adopted meaning of an applied proposal. A consistent vocabulary helps, but the manager must also read the behaviour described under that vocabulary.

A separate assembly assignment can help when a large document has several authors. Its owner must still identify the current section set, incorporated sources, and normative annexes, and check their relationship as a whole. An assembler that finds a missing section returns the gap to its caller. It does not invent the absent content or launch further work beyond its bounded assignment.

Retain the section returns and their sources, assemble the document as a whole, and bring cross-section findings back to the responsible authoring work. A collection of locally satisfactory sections can still leave an incoherent product basis. The next examination addresses that assembled account.

2.9Review the authored document against its basis

The PRD must be examined after the sections have been written and assembled. This is the point at which a reviewer can inspect what the document actually asserts, omits, weakens, or infers. Arrange a separate examination by a competent human or a fresh agent instance that did not author the candidate. This carries forward the DBM method's emphasis on reviewing the authored document against its basis.

The reviewer receives the complete candidate and normative set, relevant original directions and sources, and the open questions. A favourable summary from the author is insufficient. The brief asks it to seek defects, unsupported claims, and failures of fit among the sections. An agent prepares findings through reckoning. The human judges the consequential commitments and the proposed reliance. The required independence concerns preparation and examination; a fresh instance of the same model supplies no model diversity.

What the tools contribute

Read-back, link checks, content identity, requirement references, source comparisons, and searches for unresolved markers can prepare useful evidence. Use tools actually available in the host and examine what their results mean. A count of requirements does not show that the right behaviours were specified. A document with no TBD marker can still hide a choice that nobody made.

Mechanical support is useful when its coverage is understood. A reference check can locate a broken link; a requirement inventory can expose an omitted identifier; a comparison can locate text that changed after review. The reviewer must still assess whether the requirements preserve the intended product.

For the editor, a reviewer can begin by locating the preservation requirements and following them to the original directions. It then examines rejection, application, history, and saving together. Does the body preserve the user's live work? Has the prototype's limited conclusion become a claim of production feasibility? Does an exclusion about pending proposals inadvertently remove saving of applied content? These questions require reading the relevant statements and their relationships.

If a required source is unavailable or the separate review cannot be obtained, retain the candidate and report the examination outstanding. An author can perform useful self-checks without claiming to have supplied an independent review. Do not claim readiness by silently omitting the required examination. Human discussion can continue while the missing review is arranged.

Findings that require different responses

Findings should identify the repair needed. A contradiction calls for different treatment from a missing source, an unresolved choice presented as settled, or a topic mentioned too briefly to guide work. The following categories give these differences concise names. They help direct correction and do not themselves determine severity or require a human decision.

The review return identifies the draft location, relevant text, supporting material, explanation, consequence, and proposed treatment. A legitimate proposed capability is not a defect merely because it is new. A claim that it already works or is feasible needs appropriate grounds. A consequential human disposition remains unfilled until the decision occurs; a typographical repair within authoring discretion is recorded as an agent correction.

A preservation section that says “rejection restores the last saved document” may be incorrect if the accepted requirement is to retain current manual work. A statement that proposal reconciliation is lossless is unsupported if the available evidence covers only unchanged documents. Omitting a pending-proposal exclusion is a missing item. Before the stale-proposal choice, rewriting “response to be selected” as “the proposal is refreshed” would flatten an open decision. Retaining an old several-document capability after its explicit removal is outdated. A section that names interruption without describing its relevant conditions may be incomplete.

ILLUSTRATIVE REVIEW FINDING: APPLICATION AFTER AN EDIT

Draft statement
  “The application reconciles the proposal automatically.”

Governing direction
  When source and live revisions differ, leave the live document
  unchanged and refuse application. Explain why and let the user
  request a fresh proposal.

Finding
  Incorrect: the draft contradicts the selected response.

Correction and backcheck
  State the revision check and refusal. Examine the application,
  history, and user-feedback sections against the same direction.

Figure 2.5. A finding in the constructed editor example after the human has selected a response. Correcting the draft to express that direction requires no new product choice. Changing the direction would require a different decision.

The repair depends on the finding. Missing material may require better use of an already mapped source. A missing source may require further investigation. A source contradiction may require a human ruling. A section too broad to develop adequately may require a changed structure and new assignments. The manager should give the human the issue at the level where it can be resolved, rather than asking for approval of each local editorial action.

Backcheck corrections against the changed candidate and examine their consequences elsewhere. A changed application requirement may affect history and the acceptance scenarios even if only one paragraph was edited. Retain the original finding and its disposition rather than rewriting the review to suggest it was always satisfied. The final assembled set needs an account of the checks that actually cover it. Earlier review remains evidence about its own revision.

2.10Accept an identified document and preserve the work that remains

Bring the human an identifiable candidate with an intelligible account of its state. The body should express the intended product and its limits. Supporting records should show the sources, significant interpretations, review findings, and proposed treatment of remaining matters. The person should be able to examine the proposed reliance without reconstructing the whole authoring run.

This is checkpoint B in the PRD method. The decision concerns the exact PRD and normative set proposed as the basis for FEED. The human judges whether its requirements preserve the intended outcome, whether its boundaries are understood, and whether the remaining questions can be carried forward on the stated terms. Technical examination may require people competent in the affected subjects. The coordinating role identifies those responsibilities rather than implying that one person has personally examined everything.

A small run can present one PRD with its supporting authoring and review record. A larger run may include several normative annexes and linked evidence. State which files supply requirements and which support their examination. Including a source report in the review packet does not necessarily make every statement in that report part of the product commitment.

The human may accept, require revision, accept a clearly identified limited basis with explicit qualifications, or stop the undertaking. An unresolved technical question can remain open where its treatment is understood and acceptable for the next use. An unrecorded decision about what the human actually accepted cannot be replaced by the agent's assumption. If the response is ambiguous about the candidate or scope, resolve that ambiguity before relying on it.

Acceptance of a limited scope must remain distinguishable from acceptance of the whole document. Suppose the owner accepts proposal review and rejection but returns the application annex for revision. The record must identify the accepted portion, its shared constraints, and the work still unresolved. FEED cannot consume the returned annex as accepted merely because it was bound into the same PDF. Equally, a qualification cannot waive a higher-priority obligation or establish that a missing examination actually took place.

Reassess the complete candidate after targeted changes

A targeted section rerun is appropriate when the defect is local and the basis remains valid. The author still assembles the complete current set and assesses its relationship. Reusing an unaffected section preserves good work. Review evidence must identify the candidate to which it applies and which relationships require renewed examination.

In the editor, the fresh-proposal choice and the correction in Figure 2.5 affect the application account and may also affect history, user feedback, the relevant scenarios, and the account of open work. The manager identifies those consequences, arranges the affected writing and checks, and presents the combined candidate. The earlier review remains evidence about its own revision. Coverage of the new one must be established by the current examination.

Preserve the distinction between preparation, review, and acceptance when the document is saved or integrated. A merged PRD may still await the human's acceptance. Whether the project uses a version-control system or ordinary files, apply its review and backcheck requirements to the actual candidate.

Bind the human decision to the material examined

Before the decision, retain the reader-facing candidate, its normative annexes, and a manifest identifying their roles and content. Preserve the source and review material presented alongside them. Use an immutable copy or a version reference that preserves the identified content. The purpose is to make the accepted set recoverable after further editing occurs.

Record the human's response against the preserved candidate. Keep the decision record separate from the content it identifies, so that recording acceptance leaves that content unchanged. Later edits produce a changed candidate whose examination and acceptance must be considered in their own right.

CONSTRUCTED PRD ACCEPTANCE AND HANDOFF

Candidate
  The one-document review PRD, corrected after Figure 2.5 and
  re-examined with its application and history requirements.
  The record identifies the preserved candidate and review evidence.

Human decision
  Accept this basis for decomposition and setup. A stale proposal
  cannot be applied; the live document is preserved and the user
  can request a fresh proposal.

Remaining work
  Develop the history and interruption details under the accepted
  preservation requirement. Resolve shared design questions before
  dependent implementation adopts them. During production, verify
  the connected apply, reject, undo, save, and reopen behaviour.

Figure 2.6. Acceptance of the corrected basis in the constructed example. The decision record identifies the examined content and leaves later design and product verification explicit. It does not report a real acceptance or a completed product.

An agent can retain or transcribe an evidenced human response through the host's available mechanism. It cannot originate the binding human act. Preserve the words, their attribution, the candidate, and the purpose of reliance. A later reader needs these relationships to distinguish an accepted limitation from an author's interpretation or a reviewer's recommendation.

Deliver the basis to its intended working location

Where the assignment authorises issue of the accepted PRD, place it at the identified working location or provide an exact reference to the accepted set. Verify the copy against the retained candidate. Do not add or remove requirements while preparing a more convenient reader-facing version.

Inspect the target again before writing. If another participant has changed it during review, preserve both contributions and resolve the conflict. If the target cannot be written, retain the accepted candidate with its authoring record and report issue to the working location as outstanding. Prepared bytes are not evidence of a completed write to another location.

The handoff identifies the accepted scope and revision, applicable decisions, open work, review coverage, and the next proposed undertaking. Existing human direction may already authorise continuation into FEED. Where it does not, the completed PRD supplies no independent permission to start it. PRD preparation concludes with a reliable basis and handoff. Decomposition and setup are subsequent undertakings under the human's applicable direction.

2.11Carry the accepted basis into FEED

FEED turns the accepted product basis into a division of work and a prepared environment for carrying it out. Its participants need the exact PRD and included annexes, the decisions that govern them, and the open questions whose answers still affect execution. Transfer that set without converting a provisional interpretation into an accepted requirement.

The first work is to express the scope as obligations that can be allocated while preserving their conditions. A broad preservation requirement, for example, may contain distinct obligations for inspection, rejection, application, and history. Their separate allocation must retain the common purpose and the relationships that make the complete behaviour useful. The resulting division is examined against the product basis in both directions: every included obligation needs a contribution, and every proposed contribution needs a reason to belong.

Examine the proposed division

The human examines three prepared results during decomposition: the interpreted basis, the proposed structure, and the independently audited final package. PRD acceptance establishes the source for that work. The first decomposition checkpoint examines the interpretation produced from it. The later checkpoints examine the division and the assembled result. Each decision concerns work that has become available for judgment. Separate subjects need not require separate meetings where the required material is ready, but a decision cannot cover a later result that has not yet been prepared. Chapter 3 develops the three checkpoints and their records.

Package boundaries follow the kind of work. The engineering variant uses discipline-exclusive design Packages and Deliverables defined by artifact kind. The software variant uses cohesive work domains and Deliverables with bounded production and verification contexts. A software contribution can include code, tests, configuration, and documentation. Applying the engineering artifact-kind rule indiscriminately would divide those supporting outputs without necessarily improving responsibility for their combined result.

Size each Deliverable so that its full obligation and required context can be understood. Investigation, implementation, review, and repair can occur through several bounded assignments while the Deliverable retains its identity. A broad responsibility that depends on many unrelated decisions may need a different division. The Context Envelope described in §3.3 makes that examination explicit.

Prepare the work and its examination together

Setup gives each accepted contribution an identifiable working location, its context and sources, and a local production contract. Inspect existing work before creating or repairing records. Preserve completed preparation and make any unfinished part explicit. Local working notes can retain caveats and references to earlier work, while the governing basis and current state remain in their designated records.

The Scope of Work develops the obligation far enough to guide production and examination. Its outputs serve the allocated scope and objectives. Its acceptance criteria describe the required conditions, and its verification methods state how those conditions will be examined. Tests produce evidence through those methods. The requirement remains the reason for the test and the basis for interpreting its result.

Keep maintained claims at the level of commitments, depended-on relationships, and conditions supported by named verification. Incidental mechanisms belong in code, tests, and developer documentation. A specifically adopted mechanism remains binding. This distinction lets the contract continue to guide work through implementation changes; §§3.6–3.7 develop its form and evaluation relationships.

The accepted PRD must preserve the distinctions from which these local obligations can be written. It need not anticipate their identifiers or file layout. Once decomposition and setup are complete, the development loop establishes dependencies and the means of execution toward 30%. The first project DAG is constructed before passage through that gate.

2.12Maintain the relationship between the basis and later work

The PRD continues to govern interpretation after FEED begins. A decomposition finding may expose an omitted obligation. A local contract may show that the proposed verification cannot examine the requirement adequately. Implementation may reveal that an inherited interface does not support the intended behaviour. The project must carry those findings back to the appropriate decision while preserving the parts of the basis that still apply.

Suppose the history inspection finds that the existing application cannot group proposal edits in the way the PRD assumed. The human may retain the intended outcome and accept the additional work needed to provide it, select another behaviour, narrow the undertaking, or commission further investigation. The agent's role is to prepare the finding, its grounds, the alternatives, and their consequences. Changing the requirement to fit the convenient operation without that decision would conceal what the project had failed to establish.

Develop a successor PRD against the accepted predecessor, identify the affected commitments, and repeat the examination and acceptance needed for the changed basis. Before project decomposition is accepted, no decomposition amendment is implied. Once decomposition exists, a change to its accepted scope must also pass through the project's change procedure. The method used here brings three prepared subjects to the human: the proposed change and impact, the exact amendment and propagation plan, and an independently audited resulting state. It records downstream obligations instead of treating finished edits as complete propagation.

Later detail can also resolve an open question without contradicting the PRD. The fresh-proposal choice in §2.8 preserved the prohibition on silent loss while settling what the user would be offered. Record how such a decision answers the question and which dependent work may now proceed. If a decision changes the prohibited outcome, identify the superseded commitment and examine the consequences. The distinction keeps refinement and amendment understandable without making all design detail a new project scope change.

The product basis and a derived publication retain different responsibilities here. An initial accepted PRD supplies the basis for the new project. A DBM derived from an upstream accepted design basis cannot amend that basis merely through new wording. If that upstream basis changes, the publication needs the affected regeneration and review. The project using the published document must identify which revision it has adopted and assess changes to its own basis.

The continuing record preserves these relationships. A successor needs the accepted document and its applicable decisions, the current work and evidence, and the unresolved matters with their owners and consequences. The PRD handoff records the transfer into FEED. Subsequent development normally continues from the selected local graph and actual project state; a separate session handoff is useful when it adds facts needed for recovery. Chapter 4 develops this practice. Keep the recurrent procedure distinct from the current steering and the work it selects.

A useful basis document allows the next participant to continue the project and to recognise when continuation requires another judgment. It carries enough technical substance to guide work, enough provenance to examine that substance, and enough account of purpose to make its constraints intelligible. The work of preparing it is complete for its present use when the human has examined and accepted that position, with the remaining obligations explicit. FEED then develops it into the structure through which those obligations will be carried forward.