FEED AND DEVELOPMENT TO THE 30% GATE

An accepted product basis states the result to be developed and the conditions it must satisfy. FEED gives that commitment a division into Packages and Deliverables, assigns responsibilities, and establishes the local scopes of work. The work toward 30% then defines the means of execution and resolves the relationships that govern its order. Construction of the initial project DAG completes this phase. The graph, its supporting records, and the proposed continuation are brought to the human at the 30% gate.

This progression establishes an organisation through which many contributions can serve one purpose. Each participant receives a defined result to produce, the material needed to understand it, and a basis for examining its completion. The project manager can then direct effort, follow consequences across boundaries, and bring the contributions together. The quality of this arrangement depends on the division of responsibility and on the relationships preserved between the parts.

The organisation develops in two directions. Decomposition works from the intended whole toward its contributions. Dependency analysis reads across those contributions to establish what each requires from the others. A proposed division may look satisfactory until this second examination exposes a shared decision, a missing interface, or a circular prerequisite. The team resolves these matters while the means of execution are still being formed.

In traditional engineering, the DBM supplies the accepted basis from which this work proceeds. In the software course used here, the corresponding input is the accepted PRD. The Packages and Deliverables belong to the project organisation; the product's components and interfaces belong to its design. Their boundaries may coincide where that gives a useful division of work. Their relationship must remain explicit where they differ. A software component can require several project contributions, and a single Deliverable can produce code, tests, and supporting documentation.

This chapter follows the accepted basis through division of scope, local production definition, dependency examination, and construction of the DAG. Human judgment governs the consequential choices about scope and organisation. The method gives those choices a definite sequence and a record through which later participants can understand their grounds.

3.1Establish the scope to be divided

Start with an identified, accepted basis. Read the PRD or DBM, its included annexes, applicable decisions, and the treatment of open questions. Establish the extent of the present undertaking and the existing work that it must preserve. For an addition to a product, the relevant inherited basis may include accepted interfaces, operational limits, and specifications outside the new feature's immediate scope.

Record the source revisions used. When several documents describe the same matter, establish which governs and how the others contribute. A newer document may supplement an earlier one, replace a particular provision, or remain a proposal. The source record must preserve that relationship. Unresolved conflicts are carried into the review of the basis with their locations and consequences.

WORKING_ITEMS coordinates decomposition and setup. It prepares the proposals and checks, assigns bounded contributions to TASK where useful, and assembles the result for the human. HELP_HUMAN maintains alignment across the undertaking. Questions that alter the intended product return to HELPS_HUMANS through the human or HELP_HUMAN. The four roles retain these responsibilities as the work moves from definition into execution.

Normalise the scope

The decomposition method expresses the source as identifiable Scope Items. A Scope Item is a statement that can receive a definite scope disposition and allocation while retaining the conditions that give it meaning. The resulting set is the structured scope of work, or SSOW. This is the project-level account used for decomposition. Each Deliverable will later receive its own local scope of work, which serves as its production contract.

Division of a source statement requires attention to its subject, action, conditions, and required result. Separate obligations when they can be allocated or disposed of independently. Retain a condition with the obligation it qualifies. Preserve the source reference through any division so that a reviewer can recover the complete original account.

For example, a requirement to reject an unapplied proposal while preserving intervening manual edits concerns the live document at the time of rejection. Both the timing and the manual edits qualify the preservation requirement. A separate obligation concerning undo after application can receive another Scope Item. The common source and objective retain the relationship between them.

Each Scope Item receives a stable identifier, its statement, a source reference, and one of three scope dispositions: included, excluded, or unresolved. Exclusions remain in the account because they explain the undertaking's boundary. An unresolved disposition remains visible until the appropriate decision is made.

An included requirement can leave design choices open. The project may commit to preserving information while leaving the storage method to detailed development. Record the requirement as included and locate the open design question separately. This preserves the outcome that already governs the work while allowing its means to develop. Where the uncertainty concerns whether the outcome is required at all, the Scope Item itself needs a scope decision.

The vocabulary map records the terms used in this interpretation. Establish a preferred term where several expressions mean the same thing. Retain separate terms where the source distinguishes different objects or conditions. In software, “saved,” “applied,” and “accepted” can describe different acts with different consequences. Consistent terminology lets later participants follow those distinctions through requirements, local contracts, and evidence.

Relate scope to objectives

Objectives express the success conditions that give the work its direction. The accepted product basis supplies their purpose; decomposition makes their relationship to the Scope Items and proposed contributions explicit. Keep the objective small enough to discuss and sufficiently definite to guide assessment. An objective about preserving a user's work should identify the intended preservation and use, so that the proposed contributions can be examined against it.

Some relationships may remain uncertain. Record unmapped objectives as open issues, stating what is missing and which further work or decision can establish the relationship. This gives the human a usable account of the limitation and prevents an unsupported mapping from becoming part of later briefs.

Before the first checkpoint, the manager checks the draft SSOW, vocabulary, objectives, source references, and classifications together. It prepares the conflicts and proposed interpretations that require judgment. At checkpoint 1, the human confirms or corrects this interpreted basis. Preserve the decision with the material it concerns. A small combined review, described in §3.4, can include a provisional structural proposal; its final form must agree with the basis the human accepts.

3.2Choose the Package boundaries

A Package is a defined partition of project scope. Its description states the category of work it contains and the boundaries that distinguish it from adjoining Packages. This method uses a flat decomposition: Packages contain Deliverables directly. A short hierarchy makes the accountable home of each contribution easy to find and keeps the enduring structure distinct from the finer division of current assignments.

A useful Package brings related work into a common domain of responsibility. Its participants should be able to understand the included scope from a reasonably coherent body of context. Its boundaries should make the exchange with other domains identifiable. This arrangement reduces the amount of unrelated material that must accompany each assignment and gives coordination a definite subject.

The software method calls these Work Domain Packages. They persist through design, implementation, checking, and repair. Their names and descriptions therefore identify the work domain throughout the project. A domain such as editing state, access control, or data exchange can remain intelligible as its production matures. Stage labels are maintained in the project coordination record.

Examine a proposed boundary

Read the proposed Package against the actual scope. Determine which decisions its work must share, what information it produces for others, and what it needs in return. A boundary is useful when it gives a participant a coherent responsibility and makes the remaining exchanges manageable. Assess the cost of those exchanges as part of the division.

Related code locations can provide evidence about the existing design. They do not supply the complete project organisation. A feature may cross a user interface, an application service, and a persistence mechanism. The decomposition must establish who carries the behaviour through those parts and who examines their combined result. Where separate Packages own the parts, the common interface and integration responsibility require explicit treatment.

Excessively broad Packages make local context harder to select. Excessively narrow ones multiply exchanges and fragment responsibility. Compare alternatives by following representative obligations across their proposed boundaries. Explain where a choice concentrates a shared decision, where it separates independent work, and what coordination remains. The human then judges the proposal with its consequences visible.

Allocate each Scope Item once

Every SSOW Scope Item has exactly one Package home. The Scope Ledger preserves this allocation for included, excluded, and unresolved items. This single home establishes responsibility for accounting for the whole obligation. Several Deliverables may contribute to an included obligation, including supporting contributions from another Package. The Package allocation identifies where the obligation belongs; Deliverable mappings and dependency records identify the relationships through which it is fulfilled.

When a Scope Item appears to require two Package homes, examine the statement. It may contain independently allocatable obligations that should be split with their source links retained. It may instead describe one outcome whose fulfilment requires several contributors. In that case, retain a single scope allocation and define the supporting relationships. An unresolved boundary is presented for the human's decision at the second checkpoint.

Exclusions deserve the same care. A Package can exclude an act because another Package or an established external service performs it. The project still needs the act when it forms part of the accepted product scope. Name the receiving responsibility and preserve the relevant interface. Section 3.7 develops this requirement at the level of the local scope of work.

An organisation with an established nested work breakdown need not discard it to use this arrangement. Map its existing branches to a set of accountable Packages and identify the Deliverables within each. Retain any higher levels needed for reporting or contractual control. The adaptation is sound when each Scope Item still has one accountable home, supporting contributions remain explicit, and a participant can recover the governing scope without mistaking a reporting level for a separate obligation.

Apply the appropriate domain rule

The engineering arrangement used here assigns discipline-exclusive design Packages. A Package containing design work corresponds to one discipline. Within it, design Deliverables are defined by knowledge-artifact kind: a drawing set, calculation package, specification set, or model package. Repeated outputs of the same kind are Artifacts within that Deliverable.

Thus a piping drawing set can contain several sheets while a piping calculation package carries the calculations supporting that design. A structural contribution retains its own discipline responsibility and exchanges the required geometry, loads, or other inputs through an identified interface. This organisation keeps both discipline responsibility and the kind of product being prepared apparent.

The software arrangement groups cohesive work domains and sizes Deliverables around bounded production and verification contexts. One software Deliverable can include implementation, tests, and documentation needed to establish its result. Use the selected arrangement consistently. A project combining engineering and software needs an explicit arrangement for its respective scopes and interfaces, including the rules that govern each decomposition.

3.3Define the Deliverables

A Deliverable is the smallest production unit in the durable decomposition. It belongs to one Package and carries a defined contribution to the accepted scope. Its register entry identifies its description, type, responsible party, anticipated Artifacts, Scope Item links, and objective links. A software Deliverable also carries a Context Envelope. These fields establish the result for which work will be organised and assessed.

An Artifact is a tangible output of that contribution. Software Artifacts include code, tests, configuration, scripts, schemas, and documentation. Their locations follow the product's technical arrangement. The Deliverable record identifies them and relates them to the committed result. In the engineering arrangement, repeated instances of an artifact kind belong within the corresponding kind-level Deliverable.

Define the output in terms that will remain useful as the work proceeds. A title is followed by an account of the result, its limits, and the basis on which it can be assessed. Anticipated Artifacts show what will make that result tangible. Where a detail is unknown, identify the missing definition and the work expected to resolve it. Avoid selecting technologies or filenames solely to complete the register.

Size the complete responsibility

In software decomposition, each Deliverable must be executable by a bounded Type 2 contribution. Its full responsibility must be understandable within a bounded body of context, with a coherent means of verification. Consider the applicable requirements, interfaces, existing implementation, tests, and source material together when judging its size.

A Deliverable can pass through several assignments and sessions. Investigation, implementation, checking, and repair may each require separate work. The current undertaking's work graph records those assignments and their present state. The Deliverable retains the identity and result against which the combined contribution will eventually be assessed.

This distinction is useful only when the Deliverable itself has a sound boundary. Repeatedly subdividing execution cannot compensate for a production unit whose result requires an indefinite collection of unrelated decisions. Examine whether a broad unit should become several Deliverables, whether a common interface should be established separately, or whether the Package division needs revision. Give the proposed remedy a technical reason.

A shared-interface definition is one possible Deliverable. It can establish the information and behaviour that several later contributions will use. Its own result must be assessable: the definitions, obligations, and permitted variations must be coherent enough for their intended consumers. Subsequent implementations then provide evidence of conformity to that interface.

Use the Context Envelope

The Context Envelope records the expected breadth of information, coupling, and verification needed for a software Deliverable. The following rubric uses four classes.

File counts provide only a rough planning aid. Coupling and verification determine their significance. A change to a few files can require extensive understanding of shared state. A larger set of repetitive files can remain a bounded undertaking when their governing contract and checks are clear. Record the actual reason for an L or XL classification. Review the classifications and their reasons together when examining the proposed decomposition.

For an exception, describe the retained scope, why the proposed boundary remains preferable, and how context, coordination, and examination will be handled. Carry the exception into the final audit. The human's acceptance establishes the chosen treatment and its consequences; actual execution must still use a suitable model, sufficient context, and available host capabilities.

Assign responsibility

The responsible party belongs to the project organisation. Agent instances belong to particular assignments. A Deliverable may receive contributions from several TASK instances, and one WORKING_ITEMS manager may coordinate several related Deliverables. The responsible human and the technical authority for acceptance remain identifiable through the project arrangement.

Use a manager where the undertaking requires sustained coordination of implementation, feedback, integration, and repair. A smaller contribution with an independently assessable return can be dispatched directly through the permitted role relationships. Model selection and reasoning effort follow the needs of that assignment. They do not alter the role's authority.

A responsibility can remain unassigned while the party is being established. Retain that condition with the decision or appointment needed to resolve it. Before dependent work requires the contribution, establish who will supply it, who will examine it, and where the result will return. This gives the project a practical route from an accepted structural proposal to an executable assignment.

3.4Check coverage and accept the decomposition

The Scope Ledger connects the interpreted basis to its allocated work. It records each Scope Item, its disposition and source, its Package, the contributing Deliverables, objective links, and open issues. Decision references retain the grounds for consequential boundary choices. The ledger is the principal means of examining whether the decomposition accounts for the accepted scope.

Read it in both directions. From a requirement, follow the contributions expected to satisfy it. From a Deliverable, follow the scope and objective that justify its inclusion. Then read the definitions at both ends of each link. The proposed work must preserve the meaning and extent of the obligation it claims to cover.

Three questions arise in this examination. Allocation asks where the obligation belongs. Adequacy asks whether the defined contributions can fulfil it. Satisfaction asks whether the produced work has done so. FEED establishes the first two as a basis for production. Later evidence supports the third.

A ledger can contain a valid link to a Deliverable whose description omits a required condition. A requirement to preserve live state, for example, may be mapped to work described only as closing a review panel. The missing preservation belongs in the definition and its examination. Locating the defect at this stage lets the team repair the work's intended scope before implementation distributes the omission across several contributions.

Use counts to direct examination

The coverage summary gives the number of Scope Items, Packages, Deliverables, and objectives, together with unassigned items, missing Deliverable mappings, unmapped objectives, Context Envelope classes, and open issues. Its revision and date identify the account being examined. Under this method, every Scope Item must have a Package allocation before the decomposition is accepted.

Read each count according to its definition. An excluded item retains a Package home for traceability while requiring no production mapping. An included item with no defined contribution needs further treatment. A high number of Large Deliverables directs attention to their boundaries and coordination needs. The underlying records supply the reasons on which a decision can be based.

The second checkpoint brings the structure and its examination together. WORKING_ITEMS presents the proposed Packages and Deliverables, coverage findings, interfaces, responsibilities, the context-sizing review, and exceptions. The engineering arrangement includes its discipline and artifact-kind checks. The human confirms or revises the division and the treatment of its remaining questions.

Preserve the accepted working package

The decomposition is maintained as a concise main document with authoritative companion registers where their size or use warrants separate files. The main document explains the scope, structure, decisions, and open matters. Its companion inventory identifies the working home of the Scope Ledger, coverage summary, and other separated records. An assembled reading copy is produced from this controlled set.

Retain the exact package accepted at each checkpoint together with the human decision and its scope. Later preparation must be able to recover that package even while the working documents continue to change. Identify the accepted predecessor, outstanding work, and any derived record requiring regeneration. Complete this record before directing other participants to the new accepted basis.

Figure 3.1 shows the three subjects of decision and the preparation needed for each.

DECOMPOSITION DECISIONS

1  Basis
   Prepare: sources, SSOW, vocabulary, objectives, findings.
   Human decision: confirm the interpreted basis.

2  Structure
   Prepare: Packages, Deliverables, coverage, exceptions.
   Human decision: confirm the division and its treatment.

3  Final package
   Prepare: assembled documents and an independent audit.
   Human decision: accept the audited decomposition.

Retain the material and decision for each subject.
Each later decision uses the preceding accepted basis.

Figure 3.1. Three subjects of decomposition review. They may be considered together when the work is small enough for their grounds and consequences to be examined in one sitting.

For a small, reversible undertaking, the basis, structure, and final package may be presented together. The human can decide all three subjects in one sitting after the required preparation and independent examination. A large or uncertain undertaking benefits from separate checkpoints: agreement on the basis prevents extensive structural work on a disputed interpretation, and agreement on the structure limits costly reworking of the assembled package. The distinction concerns what must be decided; it does not prescribe three interruptions for every project.

A content hash is an identifier calculated from a file's contents. It supports a comparison of the bytes used for review and subsequent work. The decision record supplies the human act, its scope, and its purpose. Together they preserve the relation between a decision and the material it concerns.

Audit the assembled result

Before checkpoint 3, an instance that did not author the candidate examines the assembled package against the source basis and structural definitions, including any decisions already accepted at earlier checkpoints. The audit follows changed classifications into the ledger, boundary choices into Package and Deliverable descriptions, and sizing exceptions into the final account. It also checks the inventory, identifiers, coverage, and remaining issues. When the decisions are combined, any material correction made during that review requires examination before final acceptance.

Correct supported mechanical defects within the accepted decisions. Present substantive conflicts with their source records and consequences. Changes made after review require examination of the corrected material and its affected relationships. At checkpoint 3, the human accepts the audited decomposition for downstream use or returns the affected work for repair.

The final accepted snapshot gives setup a recoverable basis. Stable identifiers retain the history through later renames and amendments. Changes to accepted scope, parentage, or mappings require a controlled amendment, including propagation to dependent records. Section 4.7 describes that work. Regenerate assembled copies from their amended working sources.

3.5Prepare the workspace

Project setup makes the accepted division available to the people and agents who will work on it. Each contribution needs a working location, its governing material, and a dependable account of what is already prepared. WORKING_ITEMS first inspects the workspace and the accepted decomposition. A new project, a partly prepared workspace, and an accepted amendment require different preparation.

Select the preparation still needed and assign it within explicit read and write boundaries. Record who performs it and which method is used. An eligible manager can carry out bounded preparation or delegate it to TASK.

Establish coordination

Decide what the project will maintain about production order. Sequencing may be coordinated externally, a selected set of critical dependencies may be recorded locally, or the project may undertake a full dependency account. The software course taught here develops that full account into the first DAG at 30%. The chosen coverage determines what the workspace can report.

A partial dependency account can identify the blockers it records, but cannot establish readiness against relationships it has never represented. External coordination likewise needs its own basis for directing work. Record the chosen coverage, the dependency locations, and the meaning of the input maturity required.

Establish working locations

Keep the working account of each Deliverable together: identity and scope, applicable sources, current state, and dependency information. These records let an arriving participant establish what the contribution is and what can be done with it. Product source and tests can remain in their appropriate technical locations, reached through references from the Deliverable.

Figure 3.2 shows one arrangement for keeping these records with their Package and Deliverable. Reference material, working records, checking evidence, and issued outputs have distinct uses even when a small project keeps them in one location.

EXAMPLE: PROJECT AND DELIVERABLE RECORDS

Project
  Accepted basis and decomposition
  Coordination record and current work graphs

  Package
    Reference material
    Working Deliverables
      Identity, scope, sources, and current state
      Production contract and evaluation record
      Dependencies and their satisfaction
      Supporting notes, where useful
    Checking evidence
    Issued outputs

Figure 3.2. One arrangement of project records. Their purposes remain distinct when the project uses another folder layout or combines several records in one document.

The initial context and description must preserve the accepted decomposition faithfully, including its conditions and exclusions. References identify the source revision and its relevance; an unavailable source remains an input to obtain. Dependency preparation records the supplied declarations, while later extraction develops additional relationships from the technical sources. Current status remains distinguishable from optional Memory, which supplies caveats and references to earlier work.

Preserve what already exists

Repeat preparation without replacing existing work. Record what was created, what was already present, and what remains incomplete. This allows preparation to resume after an interruption without treating a populated record as a blank form.

On resumption, compare the actual records with the accepted decomposition and the preparation record. A populated location may be complete. An existing empty or deficient record needs a defined repair; a missing record needs creation. State these conditions separately so that the manager can commission the appropriate next work.

A source comparison completes the structural check. Presence of the required paths establishes the inventory; examination of their contents establishes whether they carry the intended identity and basis. Report missing references, incomplete descriptions, mismatched parents, and outstanding state operations with the Deliverables they affect. The resulting account supplies local authoring with a definite starting position.

3.6Write the deliverable scope of work

A Deliverable's Scope of Work tells its participants what contribution they must produce, why it belongs to the project, and how its completion will be examined. It develops the allocated scope into outputs, requirements, acceptance conditions, production methods, and verification. Its objective and source references preserve the connection to the accepted project basis.

Write this as a connected account. The definition of the output determines what must be checked. The proposed examination can reveal a missing condition in that definition. Governing decisions explain which consequences must be preserved during implementation. A participant should be able to follow these relationships before using the document to plan or assess an assignment.

The following questions organise the account. Figure 3.3 brings them together as a useful outline for a Deliverable's Scope of Work.

Define the contribution and its grounds

Purpose and Objective Traceability explains the Deliverable's contribution to the project. State the result it serves, the included scope, and the relevant objectives. This gives a participant the reason for the assignment before they enter its details.

Deliverable Definition establishes the thing to be produced and the objects, states, and relationships involved. Identify expected outputs, conditions, limits, and interfaces. Define the terms needed to understand them. A reader should be able to determine what is included in the result and how it connects to adjoining work.

Completion and Reliance Basis states the requirements and acceptance criteria, supported by their sources. It makes assumptions, missing information, and conflicts visible. The criteria must describe conditions that the stated verification or human-review methods can examine. The reader needs to understand both the proposed completion and the grounds on which another participant may use the result.

Production and Verification Method describes how the contribution is to be prepared and checked. Identify prerequisites, relevant stages of work, verification methods, and evidence to retain. Explain a required order where one operation establishes the input for another. Leave implementation discretion where the accepted basis permits it, while making the limits of that discretion apparent.

Governing Values and Decisions preserves the reasons and authority that shape the choices. A decision to protect a user's ongoing work, retain an established interface, or require a particular independent examination may govern many later actions. Cite the decision and explain its application to this Deliverable. This prevents the reason from disappearing when a short requirement is passed from one contributor to another.

The Output and Evaluation Matrix connects the defined outputs to their objectives, requirements, criteria, methods, and expected evidence. Its detailed use follows in §3.7.

These questions develop the same contribution from its purpose through production and reliance. Keep the technical relationships visible across the sections. The four philosophical perspectives help distinguish the object being produced, the grounds for relying upon it, its production and examination, and the values governing the choices.

DELIVERABLE SCOPE OF WORK

Purpose and objective traceability

Deliverable definition
  Objects, states, and relationships: ontology.

Completion and reliance basis
  Requirements, criteria, and grounds: epistemology.

Production and verification method
  Preparation and examination: praxeology.

Governing values and decisions
  Purposes and consequential choices: axiology.

Output and evaluation matrix

Figure 3.3. An outline for the production contract. The practical questions lead; the philosophical terms name the perspective being applied.

Use identified statements

Give each maintained statement an identity that other records can cite without restating its wording. Distinguish outputs, requirements, descriptive claims, acceptance criteria, verification methods, governing decisions, unknowns, and conflicts. A reference from another Deliverable must identify both the owning Deliverable and the particular statement.

A claim requires a source or other stated ground. A proposed design choice retains its proposed standing until adopted under the appropriate authority. An unknown remains an identified question with its effect on the work. These distinctions allow local authoring to develop the accepted basis without silently replacing it.

Choose maintained claims at the level the project needs to preserve. Use three tests: making the statement false would require a recorded decision; another Deliverable, user, project, or governing document depends on it; or named verification can examine it beyond reading the implementation. A statement meeting any of these tests may belong in the production contract. Incidental mechanism descriptions belong in the code, tests, and developer documentation, with supporting references from the contract where useful.

For example, a required exchange format can constrain later work even when it looks like an implementation detail. A private helper name may change without altering the promised result. Their treatment follows the actual commitment and dependencies. Borderline cases return for human judgment. This preserves useful implementation discretion while keeping required behaviour and its examination definite. Temporary test counts, current revision summaries, and routine progress notes belong in their evidence or state records. Repeating them as production claims would require needless rewriting whenever work advances.

The author returns the completed contract, the checks performed, and the findings or missing inputs still requiring attention. The manager examines the account against the accepted scope. Record the standing actually established: a prepared contract, a contract examined for use, and an accepted production result are different achievements. Preparing the document does not itself complete the work it defines.

3.7Establish evaluation and boundary ownership

An acceptance criterion states a condition the output must satisfy. A verification method defines the examination intended to establish whether it does. Evidence records the actual preparation or observation, tied to the relevant input and candidate. The relationship among these three determines what a completion report can support.

Establish the criterion before using a test result as evidence of satisfaction. The test must implement an examination appropriate to the criterion. Its method needs enough detail to identify the conditions, actions, observations, and expected result. A test that covers part of the condition supplies evidence for that part, leaving the remaining examination to be performed.

A human-review method also needs a defined object and question. Identify the material to be examined and the purpose of the assessment. Where technical competence is required, arrange the appropriate reviewer. Agents can prepare comparisons, execute checks, and report findings. Human judgment determines the reliance to be accepted.

Build the Output and Evaluation Matrix

The matrix makes the route from an output to its examination visible. For each output, identify the objective and requirement served, the acceptance criteria that apply, the methods used to examine them, and the evidence expected. Account for every declared output, criterion, and method, so that a defined examination cannot be silently left unused.

The usefulness of a row depends on the relationship it establishes between a particular criterion and the examination intended to test it.

A row's verification references apply to every acceptance criterion listed in that row. Criteria may share a row when each has exactly the same method set and the row states that set. Criteria with different method sets require separate rows. This preserves the actual pairing when the checklist is derived.

ILLUSTRATIVE EVALUATION PAIRING

Output: Review and reject a proposal while preserving
        the specified editing state.

Criterion A: Preserve the required content and selection.
Method A:    Compare those properties before and after rejection.
Evidence:    Recorded states and their comparison.

Criterion B: Preserve the required editing-history behaviour.
Method B:    Inspect history and exercise its required next action.
Evidence:    History observation and the result of that action.

Use one matrix row for A and another for B, because their
methods differ. Add the applicable objective and requirement
references to each row.

Figure 3.4. Two criteria with different examinations. Separate rows preserve the criterion–method relationships. This is an illustrative pairing, not evidence that a particular implementation has satisfied either criterion.

Where one combined method examines several criteria, define its scope accordingly and link it to each. The evidence expectation should then let a reviewer find the observation supporting each condition. Grouping is useful when it preserves this relationship and reduces repetition without concealing the coverage.

Compile the review checklist from the accepted criteria, preserving their wording, order, identity, and linked methods. Identify the contract revision from which it was prepared. This gives a reviewer the same conditions the author was required to satisfy. If the contract changes, regenerate the checklist and examine which earlier findings still apply.

The worked undertaking in Appendix A carries a proposal-handling requirement from scope and evaluation into implementation, review, and correction.

Account for excluded acts

A local boundary can allocate an act elsewhere in the project. For each boundary-exclusion requirement, enumerate the excluded acts and identify an owner for each through a cited supporting claim. The ownership statement and the exclusion must concern the same act.

For example, a component that applies accepted changes may rely on an existing save service to write the resulting document. The service owns the storage operation under its accepted contract. A separate Deliverable may own the compatibility examination. Recording both responsibilities lets the project establish who performs the operation and who checks the relationship.

A broad exclusion such as “storage is external” leaves important questions unanswered. Identify the service or contribution, the applicable contract, the required input and output, and any conditions affecting its use. Where ownership has yet to be established, retain a gap with the affected reliance. This directs further work toward a specific missing relationship.

An ownership check compares each excluded act with the responsibility cited for it. Tools can identify missing references or unresolved identities. The substantive comparison still requires a reader to establish that the cited statement assigns the particular act under the conditions described.

Report readiness precisely

Local validation examines the prescribed format, identifiers, references, and matrix relationships. Content examination establishes whether the contract preserves the accepted scope and defines suitable production and verification. The actual tool returns establish which checks ran and what they found. Retain all three parts of the account.

If a required checker is unavailable, preserve the authored contract and identify the outstanding verification. If a conflict concerns scope or authority, return it with the source and its effect. When revising an existing contract, preserve its accepted basis and examine the affected relationships. The local record should give the manager enough information to arrange correction without discarding sound work.

3.8Complete setup and begin execution definition

At the end of FEED, the manager examines the prepared workspace against the accepted decomposition. Check that each expected identity has its working location, local context, source references, and the production contract required for the selected scope. Compare Package and Deliverable descriptions, responsibility fields, scope links, and objective links with their governing records. Bring missing sources, incomplete contracts, and outstanding checks into the handoff.

A bounded local consistency examination compares each Deliverable's identity, scope, sources, criteria, and state. An available deterministic scan can locate candidate omissions or mismatches; the examiner then reads the flagged content and compares the relevant sections. Findings retain their location and proposed correction. The manager examines relationships across Deliverables as part of the combined setup result.

Report the state actually established. A valid production contract, completed preparation, and approval to rely on the resulting work need different evidence. Where an assignment prepares a record but leaves its formal standing unchanged, report the authored result and the outstanding decision separately. The project-stage review considers that position together with the work that will rely on it.

Resolve changes exposed by preparation

Writing the local contracts can expose a missing responsibility or an impractical production boundary. Determine whether the finding requires completion of an existing instruction, a correction to an inaccurate record, or amendment of accepted scope. Preserve the evidence and identify the affected work.

For an amendment to the decomposition, the human considers the proposed change and its impact, the exact amendment and propagation plan, and the independently examined resulting records. Stable identities, affected descendants, mappings, and required regeneration remain part of that treatment. A scope change is carried through its consequences, including the local records and contracts required by the new division.

Give unaffected work a clear basis for continuing. A question about one shared interface may suspend its dependent implementation while allowing other bounded work to proceed. Record the question, its owner, the affected reliance, and the contribution expected to resolve it. This is the practical management of uneven development within an organised project.

Carry the records into the next session

Continuity arrangements begin during PRD development. Where practical, retain the working context through acceptance, decomposition, and completed workspace setup while recording decisions and their grounds. Once setup is complete, begin development through a fresh reading of the accepted basis and actual state. The records must support that recovery without requiring the next participant to inherit the preceding conversation.

The session's opening instructions identify the project, role, current objective, and recurrent working method. The incoming participant consults the accepted basis, relevant decisions, selected undertaking, and actual working state. Before the first DAG, the human's directed cycle-resolution undertaking determines the immediate work. Once the DAG exists, the selected local graph develops its route into executable contributions. Recent work records or a handoff can assist recovery when they contain needed facts.

The setup return identifies what is accepted, what is prepared, and what remains to be done. It preserves any handoff required by the chosen procedure and locates the controlling records. Subsequent sessions use current state and selected work; they need not reproduce the setup return as another standing account. Named branches and worktrees are inspected because unmerged work may be absent from the main line. Existing approved strategy is reused where applicable; material changes in strategy return to the human.

A setup procedure may coordinate several stages, including dependency analysis. Its task numbers indicate steps in that procedure; project phases express the maturity being established. Record both where they are relevant. Completing a procedural step establishes its stated result, while passage through a project gate requires the corresponding judgment of maturity.

3.9State the dependencies

A production dependency states what one contribution requires from another and for which part of its work. It can concern information, an artifact, an interface, an approval, or an explicit constraint. A useful statement identifies the supplier, the consumer, the required contribution, and the condition under which it is needed.

Readiness depends on that condition. A consumer may need an agreed interface before beginning implementation, an available component before integration, or examined evidence before acceptance. Those are different uses of the supplier's work. Recording the required maturity makes the dependency useful while the contributing Deliverables develop at different rates.

Establish the graph's objective

Before drawing edges, state what the graph is intended to represent. Build order, runtime interaction, knowledge dependence, data flow, and deployment involve different relationships. Fix the objective and the meaning of its edges together. The execution graph used at 30% represents the production relationships selected to govern subsequent work.

A runtime feedback relationship can be appropriate in the product design while requiring a different treatment in a production-order graph. Two software components may exchange messages in use, yet each can be developed from an agreed communication contract. Conversely, separate components can share a design decision whose absence prevents useful independent development. Examine the relationship required by the selected objective.

The dependency-extraction method looks for specific information or artifact transfer and explicit constraints. A general instruction to coordinate supplies a management need, but the production edge requires an account of what passes between the contributors. A document in a reference list becomes a dependency when the source establishes the required use.

Preserve definition and execution links

A Deliverable has a place in the accepted decomposition and relationships with the contributions on which its production depends. Preserve both. Definition links connect it to its Package, scope, and objectives. Execution links describe required inputs, interfaces, handovers, constraints, and enabling contributions. Keeping their meanings distinct allows the same records to support scope traceability and production analysis.

State the direction of each relationship. When one Deliverable needs an interface from another, it is the consumer for that exchange. The supplying Deliverable is upstream of it. A drawing may point from supplier to consumer, while a local register may express the consumer's reference back to its prerequisite. The convention must be explicit wherever the graph is used to select work. Reversing every arrow preserves cycle membership but reverses the precedence reading.

Give the relationship an inspectable basis

A dependency statement needs identifiable endpoints, the required contribution, the point at which it is needed, and the source supporting that reading. Distinguish an explicit source statement from an inferred relationship. Keep a proposed target match or required maturity recognisable as a proposal until its basis is established. An unresolved target retains the original reference and the question still to be answered.

The history of a relationship and its satisfaction answer different questions. A relationship may remain active in the current sources while the required input is still pending. A satisfied dependency may remain important when an upstream change is examined. Record both the relationship's standing and evidence of its fulfilment. Retain retired relationships as history rather than silently removing them.

A dependency register can preserve these distinctions in structured form, with a readable account of their meaning. The form should make the supplier, consumer, required contribution, source, and satisfaction condition recoverable. Keep a proposed production relationship distinguishable from one accepted for sequencing: an unresolved cyclic candidate cannot establish an execution order merely by appearing in the record.

3.10Extract and examine the project graph

Dependency extraction follows the local scopes of work. The assignment identifies its Deliverables, the accepted decomposition, the source documents, the extraction posture, and exact permitted writes. Supplying the accepted decomposition explicitly gives target and anchor checks a definite basis. Where a required source cannot be located, the return identifies the resulting limitation.

Extract dependencies in two passes. First establish the Deliverable's definition links from its parent and requirement traces, checking the identities against the accepted decomposition. Then read the execution material for required inputs, handovers, interfaces, and constraints. One Scope of Work can supply both bodies of material. The separate passes keep traceability and production order from being confused.

Target resolution follows the stated evidence. The extractor preserves existing dependency identities where rows match, updates their observed history, and creates new identities for new relationships. Declared rows are preserved. Extracted rows no longer present in the examined source are retired rather than deleted. Record the source set and any limited coverage so later readers can interpret a retirement in context.

Check the register's agreed structure, identifiers, source references, and internal consistency. Report missing or ambiguous parent links. Any human-readable summary must agree with the structured record. Keep source documents and decomposition records unchanged during extraction; report corrections they may need as separate work. The return gives the manager the dependency records, checks, and unresolved matters.

Assemble from a complete inventory

Project-level analysis begins with an inventory of the Deliverables in scope. Establish that inventory independently of the dependency files. A Deliverable whose register is missing must remain in the inventory so that its missing coverage can be reported. The same principle applies to an unreadable or invalid register.

The selected aggregation or graph-assembly procedure collects the relevant rows while preserving their source identities. Record the objective, scope, filters, input revisions, direction convention, and treatment of targets outside the selected scope. This defines what the resulting graph can answer. Keep the full dependency evidence available even when only a selected subset is used for sequencing.

A broad closure sweep can examine the recorded execution relationships together. A narrower sequencing inquiry uses the relationships admitted for its particular objective. Where these sets differ, retain the explicit selection or transformation and its source references. The chosen analysis procedure must support that selection before its result can be used for sequencing.

State which relationship types the topology includes. A sequencing analysis can omit external parties or reference documents while those remain material to a Deliverable's actual readiness. Preserve the wider dependency account and report the selection.

Read the graph

A directed graph consists of nodes and directed relationships between them. A path follows a sequence of those relationships. A cycle is a directed path that returns to its starting point. A directed acyclic graph, or DAG, contains no such cycle under its stated edge meaning.

ILLUSTRATIVE PRODUCTION ORDER

             [A: shared interface]
                /             \
               v               v
       [B: contribution] [C: contribution]
                \             /
                 v           v
              [D: integration]

Arrows run from supplier to consumer.
A supplies the required basis for B and C.
D requires their combined contributions.

Figure 3.5. A simple DAG. B and C have no precedence relationship in this drawing and may be developed concurrently when their actual inputs and working conditions permit it.

This graph locates required exchanges without calculating duration or allocating resources. A logic-linked schedule adds those matters under its adopted basis. The graph can also show that preparation for a later activity may proceed before all inputs needed for its completion are available. Integration scenarios, for example, can be defined before the components are ready to execute them.

Examine the coverage before the topology

The closure examination concerns the integrity of the dependency account within its declared scope. It establishes which units and relationships were represented, what could be checked, and which defects remain. Fulfilment of the production dependencies continues to be recorded through their satisfaction states.

The closure audit first checks the declared inventory and readable, valid registers. Invalid rows are reported with their evidence and excluded from the affected topology. A graph that omits such rows carries a coverage limitation, even when its remaining edges form a DAG. The report must show the part actually examined.

The audit distinguishes a target absent from the workspace, a target present but outside the chosen scope, and an included node with no selected execution edges. These findings lead to different inquiries. A missing target may be an incorrect reference or unprepared work. An outside-scope target requires examination of the chosen boundary. An isolated Deliverable may be independent, incompletely described, or missing its register. Read the sources before choosing the response.

Other checks identify strongly connected components, bidirectional pairs, and concentrations of connections. A high-degree node may be an important shared input whose changes deserve close coordination. A reported pair of opposite edges requires examination of their meanings. Each finding retains the relevant files and row identities so the manager can commission focused work.

Preserve a dated analysis with its report, issue log, coverage, graph evidence, input revisions, and the settings and tools needed to repeat it. Record both whether the examination completed and what it concluded. Later comparisons state any changes in scope or filters alongside changes in the graph. This makes a reduced cycle count interpretable: the reader can determine whether a relationship was resolved, reclassified, or simply left outside a different analysis.

3.11Resolve closely coupled work

A cycle in a production-order graph identifies work whose represented prerequisites cannot be satisfied in the stated order. Examine the source relationships as a connected problem. The cycle may arise from an overly broad Deliverable, an undefined common interface, an inappropriate edge meaning, or work that must be developed together.

A strongly connected component, abbreviated SCC, is a maximal group of nodes in which every node can be reached from every other by following directed paths. A non-trivial SCC contains a cycle; a self-loop also requires treatment. For a fixed graph, its SCC partition is determined. Replacing each component with a single analysis node gives an acyclic condensation graph. This locates the groups within which ordering remains to be resolved.

The condensation is useful for diagnosis. Its grouped nodes retain internal work whose execution still needs an arrangement. A manager must examine that work before treating the grouping as one production unit or assigning its members independently. The evidence needed for the decision lies in the actual dependencies and the scope each contribution carries.

Apply the four resolution moves

Use four resolution moves: decompose, invert, merge, and cut. Each records a reason tied to the graph's objective.

Decompose a node when it combines contributions that need different inputs or can be established at different times. Separating an interface definition from the implementation that uses it can provide a common basis for several consumers. The new division must account for the original scope and its verification. If it changes accepted decomposition, carry the amendment through its decision and propagation requirements.

Invert a dependency by introducing or refining a contract through which the required relationship can be supplied in the other direction. The design must support that reversal. Specify which obligation moves to the contract, how each participant uses it, and what examination establishes the revised relationship.

Merge a connected group when the work is to be accepted as one indivisible unit for the relevant objective. Identify its combined inputs, outputs, responsibility, and verification. The grouping has consequences for the way work is assigned and assessed. A merge requires a human decision.

Cut an edge when examination establishes that it falls outside the graph's objective. A runtime or optional relationship may remain relevant to the product while being excluded from the chosen sequencing graph. Record its reclassification, the evidence, and where the retained relationship will be considered. A cut also requires a human decision.

ILLUSTRATIVE RESOLUTION BY DECOMPOSITION

Candidate production relationships

       [B: complete design] <----> [C: complete design]

Examination identifies a shared interface that can be
established before either complete implementation.

Revised contribution structure, subject to its decision

                [A: interface]
                  /       \
                 v         v
                [B]       [C]

The source definitions, scope mappings, and dependency
records must carry the agreed refinement.

Figure 3.6. A possible treatment of an overly broad prerequisite. The new interface must resolve the actual exchange; the diagram records the resulting arrangement.

Keep the response proportional

A straightforward decomposition or inversion can be recorded with a short explanation. Contested, objective-dependent, cut, or merge decisions require a decision package showing the relationship, evidence, proposed treatment, and consequences. The amount of record follows what the human needs to judge. Ordinary analysis and correction remain part of preparation.

Large SCCs deserve particular attention. Their members may contain several different kinds of relationship or responsibilities too broad for useful sequencing. Examine the component's size and internal structure before attempting a remedy. Automated edge removal would select a graph shape without establishing the engineering basis for that selection.

An unresolved cyclic candidate cannot establish a valid execution order or a claim of readiness. Keep it distinguishable from relationships accepted for sequencing, and preserve the actual input constraints it reveals. A missing input can prevent dependent implementation even while the correct representation of its dependency remains unsettled. Its consequences can also justify giving resolution high priority. The priority follows from the missing input and its effect on the work; it is not an order inferred from the cycle.

In Figure 3.6, suppose B and C both lack the agreed interface needed for their connected implementation. Hold that implementation while A is defined. A permitted investigation can compare interface alternatives, trace the required exchange, or test an isolated assumption without committing either implementation to an unaccepted interface. Independently runnable work, such as documenting an unchanged export format with established inputs and separate write targets, can proceed on its own basis. Record the held work, the resolution assignment, and the independent work separately.

Organise the resolution work

WORKING_ITEMS owns the connected resolution undertaking. TASK can inspect a particular interface, trace a disputed dependency, test a proposed refinement, or prepare a bounded case update. Findings return to the manager with the relevant evidence and effects on other contributions. Consequential product questions return through the design relationship to the human.

Where several assignments and decisions are needed, retain a common case record. It identifies the affected component, source relationships, closure examination, findings, candidate remedies, human rulings, and the work needed to apply each remedy. The manager can then coordinate several bounded inquiries without losing their common question.

Changes to contracts, decomposition, and dependency registers remain with their respective owners. After the accepted remedy has been applied, examine the resulting records again and use that evidence to close the case. Retain the connection between the original question, the decision, the applied change, and the subsequent dependency examination.

Cycle analysis addresses ordering under the chosen semantics. It can locate circular dependence while leaving an incorrect acyclic relationship undetected. The manager's examination therefore includes the source meaning, missing relationships, and scope coverage as well as SCC results. The human receives the proposed execution arrangement with both its evidence and its remaining qualifications.

3.12Construct the DAG and complete the 30% phase

The work toward 30% culminates in an initial project DAG whose active relationships are acyclic, source-grounded, and fit for their declared execution purpose. Its nodes identify the included production commitments. Its edges preserve the required exchanges. Its supporting record explains the admitted relationships, resolved cycles, exclusions, open matters, and decisions that established the arrangement.

Construction takes place before passage through the 30% gate. The gate examines this result and the work it supports. Detailed development toward 60% then proceeds from the accepted execution basis, with design questions and continuing dependencies managed within that arrangement.

Preserve the graph's basis

An identifiable graph version includes its node inventory, edge records, objective and semantics, source revisions, selection rules, and audit evidence. Preserve the decisions for cycle treatment and any remaining candidate relationships. The project-local control record identifies the accepted graph, the working sources from which it was assembled, and the rules for keeping any local copies or derived views aligned.

The accepted sequencing graph remains acyclic. An unresolved cyclic candidate stays visible in the accompanying analysis. State why its ordering is unresolved, what will resolve it, and which work lacks a necessary input. Excluding the candidate from the graph does not establish that the affected work is ready. The project account must show whether the unresolved matter limits a particular assignment or the proposed phase transition.

A dependency can remain pending within an accepted DAG. The graph establishes the relationship and the order in which its required contribution can become available. The relevant production and verification will satisfy it during subsequent work. This permits the graph to guide development while retaining an accurate account of unfinished contributions.

The 30% review considers the graph with the accepted decomposition, local scopes of work, available inputs, and residual questions. The manager presents the proposed continuation, integration responsibilities, and limits on independent work. The human judges whether that position supports the next development phase, requires further resolution, or warrants a qualified direction for a stated scope.

Use the graph at two levels of detail

The project DAG carries the enduring Deliverables and their production relationships. The current undertaking's work graph translates that structure into current assignments, findings, blockers, departures, and integration points. It can span several sessions and cut across Package boundaries where the undertaking requires coordinated work.

Maintain traceable links between the two. A work-graph entry identifies the Deliverables it contributes to and the basis it uses. Newly discovered relationships and uncertain mappings remain explicit for reconciliation. The manager can adapt the immediate assignment arrangement while preserving the project commitments that still apply.

For selecting the next work, examine the currently blocking inputs and the standing of the contributions that supply them. For a wider audit, examine the complete relevant account: commitments, relationships, evidence, and the treatment of remaining work. These readings serve different management questions and use different extents of the record.

Concurrency follows the accepted relationships and actual working conditions. Independent input paths can permit parallel contributions. Shared files, interface decisions, test resources, and integration still need ownership. The strategy records the arrangement of managers and executors, write boundaries, review, and integration of returns. An applicable approved strategy supports continuing work; material changes return to the human.

Keep graph change deliberate

Renew the project graph when a change to its governing basis calls for a different execution structure. During 60%, design findings commonly produce that need, and several successor DAGs may be required before the route settles. Preserve the relationship between the finding, the source amendment, and the graph revision.

A substantive change to decomposition, scope, or a production relationship can require a successor graph. A new session or a rearranged local task alone gives no reason to rebuild a graph whose basis remains unchanged. Identify the particular changed relationship and its consequences before commissioning the revision.

When the change is authorised, repeat the affected extraction and closure examination, resolve newly exposed SCCs, and preserve the successor graph with its basis. Retain the previous graph and decisions as history. Changes in a relationship can require renewed examination of dependent work even where the affected files themselves have not changed.

The record of the 30% decision locates the accepted graph and decomposition, local contracts, audit evidence, decisions, and remaining conditions. Preserve the human's direction for the next undertaking and the actual state from which it begins. The responsible participant then selects or constructs the appropriate local graph and updates the reference through which others find it. Retain a separate handoff when recovery needs additional facts.

The project enters detailed development with defined contributions, local production contracts, and an examined execution structure. Its records retain the human decisions behind that arrangement and the relationships through which later discoveries will be carried into the work.