FROM THE DEVELOPED DESIGN THROUGH THE 90% POSITION

The work toward 90% carries the developed design through to produced Deliverables. Its starting point is an execution basis whose remaining route to the product is sufficiently understood. Interfaces, responsibilities, and governing choices have been developed during 60%, and further changes to the project DAG are no longer anticipated. Considerable production may still remain. The management task is to carry that work through, examine the combined result, and preserve a dependable account of what has been accomplished.

The development loop continues by the same method. Steering selects the intended outcome and its limits. HELP_HUMAN relates that direction to the project, and WORKING_ITEMS organises bounded contributions along the local work graph. The clearer route permits an undertaking to extend over many assignments and sessions. Verification, review, integration, and reconciliation remain part of that undertaking, with their own inputs and completion conditions.

The established route makes the 90% phase a substantial opportunity for optimisation. Independent branches can proceed concurrently, and repeated operations can be performed by suitable tools. The manager improves the flow through production, examination, integration, and reconciliation, using the human's priorities and the actual constraints of the work. The object is to reduce the time and cost of producing the required, examined result.

As contributions accumulate, attention increasingly turns to their combined effect. The team examines whether required outputs exist, whether dependent work uses compatible inputs, whether evidence applies to the current product, and whether any obligation has been left between assignments. Reconciliation brings accepted commitments, produced contributions, evidence, and recorded state into a dependable relationship. Keep decisions and evidence accurate as that work proceeds. The formal bounded reconciliation method is one planned documentation/governance closeout stage after the undertaking's implementation/evidence integration and before its final PR. Further product examination may select a later undertaking with its own closeout.

The end of 90% marks a change of emphasis from development to user testing and debugging. Testing has already accompanied development wherever the relevant behaviour could be exercised. The later work concentrates on the produced product, the activities it is intended to support, and the correction of deficiencies found in use. The 100% pipeline follows for the verified, validated, and approved version. This chapter follows completion into that examination and establishes the position from which publication can be considered.

5.1Establish the completion undertaking

Begin with the remaining result the human wants to achieve. Read the selected local graph, its steering basis, and the applicable project DAG. Establish which Deliverables contribute to that result and what condition each must reach. Inspect the actual outputs and evidence before determining how much work remains. A developed specification can coexist with incomplete implementation; a working contribution can coexist with an outdated account of its verification. Each condition leads to different next work.

The boundary of a completion undertaking follows a coherent outcome. It may cover a capability across several Packages, the completion of a connected group of Deliverables, or the remaining development of a small product. Include the enabling work, combined examination, and document updates needed to reach that outcome. Work belonging to a later undertaking should retain its location and the reason it is left there.

State what completion will establish

Give the undertaking an observable result and an extent of examination. “Finish the selected capability through integration and reconcile its affected Deliverables” supplies a different boundary from “prepare the changes for independent review.” The first includes work beyond the individual implementations. The second may properly return an unintegrated candidate. State the intended boundary before the managers divide the work, so that their returns can be assessed against the same purpose.

Completion conditions should use the applicable requirements and accepted decisions. Identify the outputs to be produced, the behaviour to be established, the examinations required, and the continuing limitations. Where the undertaking contains several Deliverables, explain the combined result as well as the local obligations. This supplies the basis for examining whether the division of work still covers the intended whole.

For example, separate contributions may implement a command and its result display. Their combined undertaking also needs to establish that the displayed result belongs to the command and input actually used. That relationship can remain unexamined when both contributors report local success. Include its verification in the completion conditions and give it an owner.

A remaining uncertainty belongs in the route with its consequences. A narrow diagnosis can be followed by repair once its result is known. A question that could change the accepted product behaviour needs the human's judgment. Identify which work depends on the answer and what can continue from an unaffected basis. This keeps the undertaking usable while preserving the significance of the open question.

Carry steering over the longer horizon

The longer undertaking needs the same five subjects of steering developed in Chapter 4: objective and scope, priorities and sequencing, approach, execution strategy, and continuation or decision points. Their expression can be brief when the project already supplies the detail. Preserve the source of the direction so later sessions can recover why the work was selected.

Steering may concentrate the team on finishing a connected capability before starting another, closing a verification gap before visual refinement, or preserving a particular behaviour through integration. The agent should translate that direction into the required contributions and report any conflict with a prerequisite or existing hold. A priority can change which route is selected; the required inputs still have to be obtained.

COMPLETION STEER: ILLUSTRATIVE

Carry the selected capability through integrated development.
Use the adopted DAG and the current Scope-of-Work requirements.

Complete the shared behaviour before presentation refinements.
Preserve the accepted treatment of interruption and recovery.

Use separate execution where scopes and writes are independent.
Include review, connected checks, and bounded reconciliation.

Continue through the agreed result. Bring back choices that
change product commitments or the remaining delivery route.
Report the position for user testing; do not publish the product.

Figure 5.1. A completion steer states how far the undertaking should proceed and which consequences still require the human. The specimen gives these directions in one place; ordinary conversation can supply them as the undertaking develops.

A new steer can alter the order while work is active. HELP_HUMAN and the affected managers should identify the resulting changes to assignments, active operations, integration, and outstanding obligations. Preserve work already completed and explain its continued use. Record a deliberate pause where the human has called for one. A later session can then distinguish an abandoned direction from a temporarily displaced contribution.

Confirm the route remains suitable

Read the remaining route for questions that could still change the project structure. The end-of-60% expectation provides a reason to undertake longer work, and it remains open to correction by evidence. An unexpected dependency or missing Deliverable may require an amendment even during 90%. Keep that possibility visible without routinely rebuilding the project DAG.

Ordinary elaboration of the local graph can continue within the accepted undertaking. A broader change follows the project's adopted decision and graph-revision rules. When the distinction is uncertain, identify the exact affected commitment and relationship. The human can decide a concrete issue while independent authorised work proceeds.

Use what the preceding phases have established

The work completed before 90% supplies the basis for organising this larger effort efficiently. An accepted product basis gives separate contributors a common intended result. Decomposition assigns that result to identifiable Packages and Deliverables. Each Scope of Work states what its contribution must satisfy and how it will be examined. Dependency resolution establishes which inputs permit further work. Detailed development settles enough of the interfaces and behaviour for substantial branches to proceed independently.

Each preparation gives the next assignment an established starting point. A worker can use the stated output and verification basis to understand the required result before selecting an approach. A manager with an explicit dependency can arrange the needed input without revisiting the whole design. A reviewer with stable claim identities can connect a finding to the relevant obligation. These are mechanisms through which earlier work can reduce repeated interpretation; their benefit depends on the definitions being adequate and kept current.

That preparation also exposes the limits of concurrency. A shared decision left unresolved belongs before the branches that depend on it. A common write target requires an integration arrangement. Missing verification capacity limits how quickly results can become usable. Optimising the completion phase consists partly in recognising and removing such avoidable restrictions, while preserving the necessary decisions and examinations.

A long horizon gives the team repeated occasions to improve this route. It can reuse a verified inventory, automate a stable comparison, or adjust branch size after observing review and integration. The expected gain should be assessed over completed, examined work. More output awaiting repair or reconciliation is additional work in progress, even when it was produced quickly.

5.2Sustain work over many assignments and sessions

A long task horizon becomes manageable when the graph gives successive participants a clear result, dependable inputs, and a recoverable position. Each participant can then carry a bounded contribution through its checks and return it to the manager. The undertaking retains its identity while its executors, sessions, and immediate priorities change.

The length of the undertaking and the size of an executor's assignment are separate choices. A manager may carry a substantial body of work through dozens of bounded returns. Individual assignments should remain small enough for their context, permitted writes, and result to be examined. Extend the horizon by maintaining the relationships among those contributions and by making their continuation dependable.

Develop the route to the required level of detail

The local graph should describe the route to its intended outcome, including verification, review, integration, and reconciliation. The next executable nodes need enough detail to assign them. Later work can retain a clearly stated dependency on a result still being produced. Give an unresolved diagnosis a question to answer before claiming that its resulting repair is ready. This preserves an honest account of what is known about the route.

Use the existing node identities and maintain their results as the work develops. A finding may require a further check, a correction, or a division of an oversized node. Record why the arrangement changed and which preceding result remains usable. A reader should be able to follow the development without reconstructing the history from renamed tasks.

The graph's completion conditions extend beyond a node list. Walk the remaining dependencies to establish whether each consumer can receive the required result, at a suitable revision and standing. Check that integration has an owner and that the document updates needed by later work are placed before that work. This is especially useful where a long undertaking crosses several Deliverables and uses results from more than one manager.

Maintain the two management responsibilities

HELP_HUMAN maintains the relation between the human's direction and the undertakings in progress. It keeps cross-undertaking decisions, dependencies, and priorities in view. WORKING_ITEMS maintains the execution of its assigned undertaking: the availability of inputs, the condition of active contributions, their integration, and the return of the result as a whole. Both responsibilities continue while the route is being traversed.

Give graph maintenance an identifiable writer within the available authority. HELP_HUMAN can coordinate the intended changes while an authorised manager or executor records them. Children return their findings to their parents; one maintainer integrates the resulting graph changes against the current revision. This avoids concurrent workers replacing one another's accounts of progress. The selected graph remains the point of continuation for the undertaking.

Refresh the position when the work changes

At a meaningful result or transfer, update the graph with the checked source revision, local and unmerged changes, outstanding checks, evidence locations, blockers, active operations, and next safe action. Keep the update concise enough to read at entry. Detailed observations remain linked to their canonical records. The current account should tell a successor where investigation is necessary and where completed work can be retained.

A fresh session reads this position and tests material claims against actual work. It inspects named branches and worktrees before recreating an implementation. It also checks whether previous workers or tests are still active before reassigning their files or resources. An interruption can leave edits after the last recorded checkpoint, so the comparison must include the working state as well as the last committed revision.

A separate handoff can preserve an unfinished diagnosis, running operation, or decision after an outside interruption. During ordinary continuation, the current graph and linked results may already supply these facts. Keep the completed undertaking identifiable when another is selected, and retain any additional transfer record required by the chosen method.

5.3Arrange parallel completion

The developed project offers several kinds of independence. Different capabilities may use an established interface without changing it. Several Deliverables may need the same comparison against a fixed source. Documentation, implementation, and test preparation may proceed together where each has the inputs it needs. Find these opportunities in the local graph and organise their returns so that useful results can advance as they become available.

Start by identifying the result that releases each branch. A consumer may need an agreed interface before implementation, and a working component only before its integration test. Giving both activities the later prerequisite would delay useful work. Conversely, beginning implementation against an unsettled interface can spread one open question through several branches. The dependency must state the required contribution and the point at which it is needed.

Establish independence at the working boundary

Examine technical dependence, write ownership, and shared resources together. Two branches can edit different files while relying on incompatible interpretations of an error or a state change. Two technically independent contributions can still collide by editing the same generated index. Tests with separate source files can disturb one another through a shared service, application window, database, or output directory. The manager must arrange the actual working boundary for each case.

Use a common identified basis for shared definitions. Give each branch its own writable targets and retain one owner for shared artifacts. Allocate separate test instances where the harness supports them; otherwise schedule exclusive access to the shared resource. Computer Use on a shared desktop requires the same arrangement, including coordination with the human using that machine. Separate branches do not isolate a common pointer, keyboard focus, or open document. Include generated files, temporary outputs, and ignored working directories in this examination where the operations can affect them. A source diff alone will not reveal every interaction between concurrent processes.

Branch size follows the contribution and the cost of its coordination. Very small assignments repeat preparation and return handling. Large assignments hold more work behind one review and make a failed or interrupted return more expensive to recover. Choose a unit that can be developed and examined coherently, then adjust it from the observed work. Several such units can form a long route under one manager without requiring the executor to carry the whole route in a single context.

PARALLEL COMPLETION: A POSSIBLE WORK ARRANGEMENT

Identified common input available
  Branch A: produce -> check -> independent review -> integrate
  Branch B: produce -> check -> independent review -> integrate
  Branch C: prepare connected tests from the accepted requirements

A and B have disjoint writes and controlled test resources.
Each branch advances when its own required inputs are available.

Connected examination uses the integrated A and B candidate.
One bounded closeout updates affected claims and governing records.
A terse local run entry points to the PR and central evidence and decisions.
The combined return identifies evidence and unresolved obligations.

Figure 5.2. Parallel branches meet at the result that actually requires their combination. Internal checking and review can proceed before that meeting point. The arrangement is illustrative; the work graph supplies the actual dependencies and integration ownership.

Keep ready work advancing

At each useful return, establish which dependent work it releases. A branch with complete inputs and authority can continue while an unrelated branch awaits a decision. Review can begin on a stable result while independent production continues. The undertaking's bounded documentation/governance closeout waits for the intended combined implementation and evidence result. A common wait is appropriate where the next operation needs the combined candidate or a shared decision.

This distinction governs the use of waves. A wave can provide a convenient bound on source state, supervision, and review. Requiring every member to finish before any independent continuation begins adds a dependency that may have no technical purpose. Retain a common boundary when the selected method needs one, such as accepting calibration conventions before larger dispatch. Within that boundary, organise work according to its actual prerequisites. Independent work can proceed while affected dependants remain held.

Observe the waiting work as carefully as the active work. Identify why a ready-looking node has not advanced: an input, a human decision, an execution slot, review, a shared environment, or integration capacity. Each calls for a different response. A missing decision needs a prepared question. Necessary human judgment is part of the work; preparation and timely presentation can reduce avoidable waiting while leaving the decision intact. A congested review stage may need additional independent reviewing capacity. A scarce test environment may require shorter exclusive reservations or an approved isolated instance. Launching more implementation does not address all of these conditions.

A project's dependency graph supplies order. Durations and resource availability are needed to establish which sequence governs elapsed completion time. Without that information, the manager can still identify a dependency holding the next intended result and direct attention to it. Avoid reporting a calculated critical path from an unweighted graph or assuming that its largest branch is necessarily the slowest.

Match production to examination and integration

Concurrent production should feed a rate of checking and integration the team can sustain. Returns waiting for examination remain unfinished project work. They can also become more costly as their common basis changes. Allocate resources across the complete route, including review, correction, connected tests, and record maintenance.

Integrate suitably bounded changes as their required checks are completed. A manager may group compatible changes when that reduces repeated setup or a costly common validation. Such grouping enlarges the candidate that must be reviewed and can delay otherwise independent results. Select the grouping by the shared work it saves and the consequences of a failure within it. Required review and evidence must still cover the actual combined revision.

As the product approaches concentrated user examination, hold the selected candidate steady enough to observe it. Independent preparation and production can continue on clearly separated candidates. Their later integration requires examination against the version selected for publication. This permits substantial concurrency through 90% while giving final product observations an exact subject.

The useful measure is the rate at which required, examined contributions become available to the project. Observe that rate alongside total cost, elapsed time, defects, and unresolved obligations. Counts of running agents or closed nodes describe activity; their value follows the results those activities make possible.

5.4Reduce the recurring cost of the loop

A repeated operation deserves examination when it consumes a material part of each cycle. Repository discovery, preparation of a bounded brief, selection of checks, comparison of structured results, and compilation of a completion account may each be small on one occasion. Across many branches and sessions, their repetition can consume substantial attention and execution time. Optimisation begins by identifying the operation, its required result, and the reason it is repeated.

The earlier phases make these operations tractable. Stable Deliverable identities provide subjects for queries. Scope-of-Work definitions identify outputs and criteria. Dependency records identify prerequisites. Declared write scopes provide a basis for checking changes. Registered verification methods supply commands and expected evidence. Once these relationships have an inspectable form, tools can perform parts of the recurring work without asking an agent to reconstruct them each time.

Use tools for defined operations

Prefer an available, qualified tool where the operation and its result are sufficiently defined. A tool can enumerate manifests, compare a changed-path list with an allowance, identify registered checks whose path rules match a change, or reproduce totals from accepted rows. The agent supplies the appropriate inputs, examines failures and exceptions, and relates the returned facts to the undertaking. The human retains the judgments reserved by the project's basis.

Reconnaissance, test planning, code review, and defect diagnosis can combine these tool operations with bounded agent examination. Select methods that preserve the required scope, evidence, and decisions. Their briefs should distinguish finding a command, planning to use it, and having authority to execute it.

A useful tool-first reconnaissance starts with a bounded inventory and follows the relevant entries into source. Its result can be retained with its coverage and input revision for later assignments. Repeating a complete survey at every session entry would waste the earlier work when the relevant basis is unchanged. Trusting it indefinitely would conceal subsequent changes. Inspect the changed material and refresh the affected part of the map.

Derived indexes and caches can serve the same purpose. Identify the source state they represent and return references to that source. Regenerate an affected projection when its inputs change. A fast query is useful when it leads the participant to the governing or evidential record; a stale summary that is treated as authority increases the cost of later correction. Retain the source references needed to check the result.

Select checks without weakening their purpose

Mechanical selection can remove repetitive work from test planning. Given an adopted profile and a complete changed-path list, a selector can identify registered checks, retain checks required for every change, and report the path matches behind the remaining selection. This is a starting point for coverage assessment. A shared interface can affect consumers in files that did not change. A requirement may call for a human examination or an application-level observation beyond the selected commands. An agent equipped for Computer Use can perform the latter under a suitable test brief; any required human examination retains its stated purpose. A profile may itself be incomplete.

Read the selected checks against the behaviour and risks of the change. Add proposed coverage where the current method leaves a gap, and obtain the required authority for its execution or adoption. An empty selection means that the adopted profile selected no check for the supplied paths, including any checks configured to run on every change. It supplies no conclusion about the safety or adequacy of the change. The same restraint applies when a runner reports a successful exit: the result supports the properties the check actually examined.

Manage expensive setup deliberately. A registered runner can prepare a temporary service, wait for its stated readiness condition, run the selected check, preserve the result, and stop the service. That replaces a sequence of repeated instructions and manual follow-up with one defined operation. Isolation, cleanup, and evidence capture still need examination. A repeatable service-start sequence can reliably reproduce the wrong starting condition if its contract is inadequate.

A successful substitution removes repeated model turns from the defined operation and can reduce handling errors. The total saving depends on the tool's execution, setup, and validation costs, and on the work still needed to interpret its result.

Tool development and maintenance also cost time. Introduce a helper where its expected reuse, reduced variation, or stronger evidence justifies preparing and checking it. The comparison is the whole operation: tool preparation, execution, failures, review, and later upkeep against the recurring agent work it replaces. A single unusual comparison may be better handled as a bounded assignment. Repeated comparisons against a stable schema may warrant a reusable tool.

Calibrate before increasing scale

Before dispatching a large population of similar work, use a bounded sample to examine whether the assignment, conventions, tools, and return format work together. Include variation relevant to the task. For concordance, that may mean different claim types, evidence classes, states, and risk. For implementation, it may mean different interface and verification demands. A uniform easy sample supplies little information about the difficult work that follows.

Check the first returns before producing many more. Determine whether the worker interpreted the brief correctly, stayed within scope, supplied usable evidence, and distinguished unresolved questions from decisions. Use an independent examination where required to expose errors or inconsistent dispositions. Agreement between workers is useful evidence about repeatability; both can still share an unsupported interpretation.

Use those observations to adjust task size, context, model, reasoning effort, and review capacity. A stronger model may reduce diagnosis or repair effort in a difficult assignment. A less costly configuration may be adequate for well-bounded work with dependable checks. Record performance against comparable task conditions, including the time required to inspect and correct the return. Role and Type remain organisational choices and do not determine this resource selection.

Do not convert a single run's capacity limit or failure pattern into a permanent staffing rule. A manager may need replacement because the current context has become too broad, execution limits intervene, or its returns deteriorate. Preserve the current graph, actual candidate, evidence, unresolved questions, and ownership before replacement. The next instance can then establish which work to retain and where to resume.

Improve the method from observed work

Track recurring causes of delay: repeated discovery, unnecessarily broad checks, unresolved common questions, idle intervals between valid returns, defective ledgers, or an integration queue that continues to grow. Change the part of the method that produces the difficulty, within the authority governing that method. Record what changed and examine its effect on subsequent comparable work.

For example, several workers may encounter the same uncertain interpretation of a requirement. Give that question an identity and gather its affected claims. A common ruling can then guide all relevant assignments. Workers retain references to the question while it remains open, instead of independently supplying different answers. The common ruling can remove repeated preparation of the same question. Its application and the treatment of cases outside its scope still require work.

The object is a shorter, less costly route to an adequately examined result. Appropriate measures include elapsed time to integration, execution expenditure, time spent waiting for each kind of input, review and correction effort, and unresolved defects. Compare like work and preserve the qualifications. Lower expenditure on the first attempt is of little benefit if it is followed by greater repair and reconstruction.

Changes to reusable instructions or an agreed verification method need their own review and adoption. Decide when continuing work should use the revised method, and preserve which procedure produced each result. Earlier observations retain their meaning only when their conditions remain identifiable.

5.5Read completion from the production contract

The production contract gives completion a definite subject: the contribution promised, the conditions it must satisfy, and the means of examining it. Read the actual outputs and evidence against that contract. Then trace claims of completed behaviour back to the requirement or accepted choice they fulfil. Unmapped work and unsupported claims become particular matters to resolve.

In the Scope-of-Work arrangement developed in Chapter 3, the production contract and its Output and Evaluation Matrix hold these relationships. Use the applicable contract for the Deliverable being examined.

Establish the output that exists

Locate the actual output and identify its revision. Depending on the Deliverable, this may be code, a schema, an interface definition, a test suite, a configuration, a report, or another defined artifact. A production contract describes what is required; the completion record must identify where the corresponding work can be examined.

Software outputs can lie outside their Deliverable folder. The folder supplies their production basis and references, while the repository contains their implementation. Verify that the references reach the intended files and candidate. Generated artifacts need their input and generation basis where those affect what the artifacts mean. A stale generated file can appear complete while representing an earlier design.

Inspect the content against the declared output. A file's existence establishes only that something has been stored at the path. Read enough to establish whether it contains the intended contribution and whether material sections remain provisional. Where a required output is divided among several artifacts, account for each part and their relationship.

Follow the evaluation relationships

Follow each output through its objective, requirements, acceptance criteria, verification, and evidence. Stable identities let another participant follow the same route. The table below states the questions asked along it.

A test result should have an identifiable place in this relationship. It may support one acceptance criterion, several criteria where the method covers them, or only part of a broader criterion. Preserve that extent. A result that covers normal operation leaves any separately required interruption or recovery behaviour to its own examination.

Use a checklist derived faithfully from the production contract. Preserve each criterion's exact wording, order, identity, and linked verification so the review examines the obligation assigned to production. Identify the contract revision from which the checklist was prepared. Findings and human decisions remain in their appropriate review records.

Do not recreate the criteria from a summary or renumber them for convenience. A second set of paraphrased criteria can change the meaning of completion and make findings difficult to trace. Where a criterion itself is defective or incomplete, preserve the problem and use the governing amendment route. Compilation should expose the adopted criterion faithfully, including a problem that still needs human attention.

Preserve the extent of the conclusion

An implementation can satisfy several local criteria while connected verification remains ahead. The current account should state those useful achievements and the work needed to assess the remaining relationship. This permits dependent work to use the established result within its supported scope.

COMPLETION BASIS: ILLUSTRATIVE CONTENT

Deliverable:       <identity and current Scope of Work>
Output:            <qualified OUT reference and artifact revision>
Applicable terms:  <REQ, AC, and governing decision references>
Examination:       <linked VER or human-review method>
Evidence:          <candidate, conditions, and observed result>
Open extent:       <unperformed checks or unmet conditions>
Next reliance:     <what another participant may use this to do>

Keep the adopted criterion's wording and identity intact.
Record observations separately from acceptance decisions.

Figure 5.3. Information needed to examine a produced output against its contract. The canonical checklist supplies the exact criteria; existing result records can supply the observations and evidence.

Keep claims at the level the project needs to preserve

The stability of the production contract affects the cost of completing and maintaining it. A Deliverable should state the obligations that subsequent implementation must continue to satisfy. Details used only to explain the present mechanism belong in code, tests, and developer documentation, with references where they support a claim. This leaves the contract sufficiently definite to examine while allowing the authorised implementation to develop.

Three tests help determine whether a statement belongs among the maintained claims. First, would an implementation change that made it false require a recorded decision or scope change? Second, does another Deliverable, user, project, or governing document depend on it? Third, can named verification evidence examine it beyond simply reading the implementation? A statement that meets any of these tests may belong in the production contract. One that fails all three is implementation detail. Apply the tests to the particular statement and retain doubtful cases for human judgment.

For example, preserving a user's accepted document after a failed save is a product obligation. The name of a private helper used to achieve it may be incidental. A mandated storage format, however, can itself be a decision-bound mechanism because another system depends on it. The test therefore concerns the commitment and its consequences, rather than the apparent technical detail of the wording.

This distinction reduces avoidable reconciliation. If a private helper is replaced while the required behaviour and verification remain valid, the production contract may need no substantive change. Evidence and developer documentation can record the new mechanism. If the contract repeats the old mechanism as a requirement, each harmless refactor creates an apparent disagreement that someone must investigate. The saving follows from reducing unnecessary assertions about changing details, while preserving the claims on which the project relies.

Where existing wording is too closely tied to the mechanism, propose the appropriate repair. Prefer a statement of the commitment it represents, with useful implementation detail retained through evidence references. Rewriting the mechanism description to match current code remains appropriate when that mechanism is itself decision-bound, with the reason recorded in the ruling. A general preference for higher-level claims gives no authority to weaken a requirement, remove a depended-on statement, or decide a contested boundary.

Name the evidence by which the retained claim can be checked. A statement so broad that no meaningful examination can be attached to it gives little assistance to the manager or reviewer. The aim is a contract whose obligations remain recognisable as implementations change, with enough precision to judge whether those obligations have been fulfilled.

5.6Manage the remaining obligations

Unfulfilled obligations are found by comparing the production contract with actual work and evidence under the human's steering. The local graph carries the work selected to address them. The deliverable's memory indexes the actual work and central sources for each run; it does not maintain another future-work list. Lifecycle remains a separate record of the deliverable's governed standing.

An identified gap should name its affected requirement or output and the evidence that would establish the result. Give executable work an appropriate graph node, including its input and decision dependencies. A concern with no current or identified successor home follows the conditional Task Management route below.

Turn residuals into executable work

First seek a place for each active remainder in the current local work graph. An implementation gap needs production or repair. An evidence gap needs an examination. A disputed requirement needs clarification or a decision before affected implementation proceeds. An outdated description needs bounded reconciliation. Add or revise nodes within the authorised undertaking, preserving the dependencies among these contributions. Work already allocated to a later undertaking retains its identified home.

An item waiting for an input or an execution slot still belongs to its graph. Its state and prerequisites explain why it cannot run yet. A decision node can likewise hold the affected work while the human considers a prepared question. Keeping these relationships in the graph lets the manager resume the work when its actual condition changes.

For instance, an operation can be implemented and tested through its direct interface while the required native application route is still unexamined. The remaining contribution is to perform that examination in the relevant environment. Reimplementing the operation would have no established purpose. If the native exercise then reveals a defect, its evidence can support a bounded repair assignment.

Keep the condition for closing an item visible through these changes. A repair node may complete while its independent backcheck remains open. The parent can retain the repair result and direct the next examination without describing the original obligation as fulfilled prematurely. When the full condition is met, update the graph result and retain the evidence through the project's history or linked result.

Preserve work that cannot yet be placed

In this manual, deferred work means an identified obligation that cannot find a present allocation in the current local work graph or another owned undertaking. The missing allocation may depend on a scope decision, an unassigned responsibility, or a precursor outside the present undertaking. Use this description after examining the existing route and its decision paths. Work merely scheduled later remains ordinary planned work.

Preserve the obligation where it is found. Record the affected commitment, why allocation failed, and the owner or precursor needed to make allocation possible. Arrange who will reconsider it and when, or upon what event. A concern with no execution owner still needs someone responsible for bringing it back to attention. Recording it leaves priority, scope, and execution authority unchanged.

An ordinary issue tracker can carry this account. Suppose a product team discovers that a shared conversion service drops document revision identifiers, while another team owns the service. An entry might read: “Issue 47 — preserve revision identity in converted documents. Supports requirement R-12. No service-change owner allocated. Product owner to seek allocation from the service team; reconsider at the next interface review, or when that team names an owner. Current integration remains blocked on R-12.” The issue points to the affected requirement and evidence. It does not mark the requirement complete or imply that the receiving team has accepted the work.

A separate action register may be useful when unresolved concerns span many undertakings. A small team may use one tracker with links and clear states. The representation is adequate if it retains the unmet obligation, exposes the missing allocation, and provides a dependable way to reconsider it. Maintaining a second list that merely copies the first adds no useful control.

Reconsider unallocated concerns

Review these concerns when their recorded conditions change or at an agreed interval. Establish what the current records support before proposing a disposition. A concern may already have been resolved elsewhere, its evidence may have changed, or a precursor may now permit allocation. Examine the relevant records, including those of another team where available. Report missing information so a local review is not mistaken for an exhaustive account.

WORKING_ITEMS can gather the concerns and prepare their treatment. HELP_HUMAN relates cross-undertaking questions to the human's direction. The human decides changes to commitments, responsibility, or priorities that the governing arrangement reserves to them. Routine allocation already within a manager's authority can proceed under that authority. Keep proposed decisions distinct from those actually made.

A useful review asks whether the necessary condition now holds, whether bounded work by an identified owner could establish it, or whether an external decision is still required. Each answer leads to different next work. A general reminder to reconsider later should be replaced by a checkable condition wherever the condition can be stated.

Route the result into its owning work

A disposition may direct a scope change, establish precursor work, or send a concern to another project. Prepare the affected owner's intake with the source, the decision, and the work required. Establish that owner's authorised allocation before describing the concern as executable there. Communication preserves the request; it does not by itself assign responsibility to its recipient.

Use the procedure that owns the resulting act. A Deliverable amendment returns to its production owner. A change to accepted decomposition follows the scope-change procedure. An appropriately bounded contribution can be assigned to TASK. The issue or action entry retains the disposition and points to the receiving work, whose records now carry execution.

A satisfied precursor can provide a home for the work while leaving its underlying obligation unfinished. Record what has changed, who now carries the contribution, and where its completion will be examined. This distinction prevents an allocation decision from being mistaken for a production result.

Retain the commitment while its treatment is settled

Deferral preserves an obligation that still requires attention. It supplies no acceptance, scope reduction, or lifecycle transition. If the obligation belongs to the current Deliverable, its production records continue to show the unfulfilled condition until completion or an authorised amendment changes it. Warranted unfinished production keeps that Deliverable in progress. An action-item disposition cannot supply a missing examination or checking-entry decision.

The human may accept a reduced undertaking after considering the consequences. Carry that decision through its actual scope and propagation requirements. The record should continue to distinguish success against the revised commitment from achievement of the original one. Dependent outputs and claims may need revision even when the removed item has little code of its own.

Read the pattern of the remainder

Counts can help locate work, but the items' consequences determine their management significance. A missing shared input may hold several Deliverables. A single unexamined recovery path may limit reliance on the whole capability. A group of small documentary corrections may be independent and straightforward. Read the relationships before selecting where to concentrate effort.

Look also for remainders that persist without a new contribution being defined. Their persistence may reflect an unresolved authority question, an unavailable environment, an inadequate diagnosis, or an assignment that has never included the necessary integration. Prepare the particular obstacle and a proposed next step. Repeating the same reminder gives the human little new basis for action.

Keep the work graph connected to the owning records

A local graph arranges the contributions needed to fulfil an undertaking. Deliverable records retain the obligations against which those contributions are assessed. Keep explicit links between them as work is selected, completed, or rearranged. An unallocated concern retains the same reference. When completion is reported only in a graph or a conversation, the next participant may find a different account in the Deliverable folder and have to reconstruct which account governs.

Apply the same intake eligibility during a substantive PR and the final closeout. A concrete allocation problem need not wait for the end, but the PR boundary does not itself make ordinary unfinished work eligible. Preserve the actual human disposition and link its source from that PR or graph node; a routine harvest is unnecessary.

Give each kind of information one maintained home. Decisions belong with their ruling records. The Scope of Work carries the production commitment. The local graph carries execution. Deliverable-local MEMORY.md contains a terse Runs table: stable run ID/date, work performed here, and links to the PR, central evidence, rulings, scope changes or Task Management transfers. Decision authority and detailed rationale stay at their central sources; a pending proposal remains identifiable as pending. It contains no future-work queue. These relationships avoid several independently maintained task lists.

One obligation can require several nodes, and one integration can coordinate several obligations. Closing those nodes must return to the owning record and its current evidence. The graph should identify the obligation or other authorised activity from which each contribution derives.

Implementation and evidence integration normally precede the planned documentation/governance closeout. If the human authorises a departure from that closeout requirement, record its affected scope, substitute completion terms and surviving obligations under the applicable decision rules. Do not infer such a departure from an intermediate merge or an unrecorded declaration of completion.

Apply decisions through their affected records

A ruling can govern several Deliverables. Identify those records and the changes each must receive. Where application is incomplete, retain the propagation work in its owning graph and a reference from the decision record. The fact that the human has decided a question should not conceal unfinished propagation of that decision.

Check that affected Scopes of Work refer to the applicable decomposition basis. Different revisions may be legitimate during a controlled transition, but their applicability and remaining propagation must be clear. Record a newly accepted basis before dependent participants are directed to rely on it. When scope moves to another project, carry its ownership and references through the authorised change rather than leaving the original Deliverables pointing to work they no longer govern.

A short association between a proposed source change and the claim it serves can catch an omitted ownership relationship during review. It may be carried by the existing brief or change record. When no claim appears to own the change, examine whether it is evidence for an existing obligation, a missing claim within accepted scope, or a proposed addition. Unexplained notes should receive the same examination before they accumulate in the production contract.

For an explicitly authorized one-time retirement of a legacy work list, first account for every source entry and current addition, then present grouped treatments with named exceptions for human disposition. Preserve future commitments in their actual governing records and apply approved amendments before removing source entries. The finite disposition account closes with the migration as historical evidence. Its source inventory is not a complete project backlog and does not become another maintained work list.

5.7Bring the contributions together

Integration carries separately developed contributions into the product and establishes how they behave together. It continues throughout development. During the work toward 90%, more of the intended whole becomes available for examination, and the manager must account for relationships that cross the individual assignments. The receiving candidate, its inputs, and its examination belong to an identified integration undertaking.

Start with the result the integration is intended to establish. Identify the contributions to combine, the revisions they were developed against, and the interfaces they share. Include the configuration and generated artifacts needed for the result to operate. State the checks that will examine the combined behaviour and the records that must be reconciled afterward.

Confirm the inputs as they are received

Where a consumer requires a particular input, confirm the content it receives and the meaning it uses. Compatible labels or file formats can conceal different assumptions about units, identity, ordering, validity, or failure. Follow the interface far enough to establish the exchange and its effect on subsequent work. A software manager and a traditional engineering manager face the same coordination question here: whether the receiving contribution uses the supplying work within its applicable terms.

Preserve the evidence for dependency satisfaction at the relevant local records. A supplying Deliverable may be largely complete while the particular output needed by its consumer remains pending. Conversely, an accepted and verified input may permit dependent work before the supplier's unrelated obligations are finished. The dependency statement identifies which result matters to the present route.

Allocate integration ownership and resources

Keep independent production concurrent where its scope, writes, and inputs permit. Assign shared files and common integration state to one owner, or arrange serial access. Coordinate test resources as carefully as source writes. A shared application, test database, or working directory can be altered by one operation while another relies on its earlier state.

A manager responsible for a connected group can integrate its internal contributions. HELP_HUMAN coordinates relationships that span managers and retains their connection to the human's intended outcome. The corresponding graph nodes should identify where combined results meet, which manager carries each integration, and what must return before further work proceeds.

Examine the combined behaviour

Exercise a connected activity once the relevant contributions are available. Follow the data or state through the complete path under examination, including what the next user or consumer receives. Observe persistent state and recovery as well as the immediate response. In a graphical product, this can include input, operation, result inspection, saving, and reopening. In a service, it can include the request, downstream operation, response, retained state, and failure handling. Select the actual route from the product basis.

A local check can remain correct while a combined exercise exposes an unexamined relationship. Preserve both observations with their scope. The new finding should identify the relationship that failed and the candidate in which it occurred. This gives repair a definite subject and avoids dismissing earlier evidence that still supports its original claim.

After combining changes, assess which earlier checks still apply. Changes to shared inputs, generated content, configuration, or the expected result may require renewed examination. Preserve the receiving revision and the final candidate actually checked. The integrated return should explain what has been established, which evidence supports it, and what remains for the next contribution.

5.8Close the records against the integrated result

The closeout preserves the relationship among accepted commitments, produced work, evidence, and unresolved obligations. During production, maintain the decisions and records actually needed to perform the work. After the intended implementation/evidence integration, one planned bounded closeout examines the affected documents and governing records against the combined result. Its scope follows that undertaking's changes and dependencies, rather than a standing requirement to repeat earlier whole-project audits.

Two scales of work are useful here. A bounded closeout follows the completed undertaking into its affected Deliverables and governing records. A corpus-concordance programme examines a declared body of Deliverables under a common source basis and conventions. The latter needs agreement on its scope, calibration, decisions, and final examination. An ordinary undertaking performs its own bounded closeout without activating a whole-corpus programme.

Keep comparison in the route of production

Place one bounded documentation/governance closeout after the undertaking's implementation and evidence work, before its final PR. It follows the intended implementation/evidence integration, normally the penultimate merge; bounded deliverable comparisons may share that single closeout stage. Its completion remains distinct from production completion, and a finding of missing required work returns to the graph for repair and affected comparison. Ordinary document work needed by an implementation remains part of that production assignment.

The bounded method identifies the work and affected Deliverables, reads their current contents, compares them with implementation and evidence in both directions, makes and checks authorised changes, and returns the remaining consequences. Future requirements remain in the production contract. An implementation that has yet to satisfy them leaves corresponding work open. A supported no-change result can close the bounded comparison when the record already gives an accurate account.

When the assignment authorises document changes, a report alone does not complete the node: apply and check the warranted edits. If writes are outside the brief, return exact proposed changes and leave their application outstanding. The boundary between routine factual updates and decisions changing scope, lifecycle, acceptance, or the governing basis remains as described in §4.11.

A comparison needs an identifiable source state. When the target changes while it is being examined, determine which observations still apply and repeat affected work. Preserve earlier evidence with its original basis. Rewriting an old result to describe a newer candidate would destroy the history needed to understand the correction.

When delivery work proceeds for an extended period without maintaining these relationships, different records can drift in different ways. Some decisions reach the Deliverables while others remain elsewhere. A later comparison must distinguish claims that received a decision from those that merely acquired new wording. The current code supplies evidence of implementation; the grounds for changed commitments must be sought in the relevant decisions and sources.

The practical response is to preserve the relationship at the time it changes. Apply accepted rulings to their named records, record actual checks with results, and account for the resulting work in its owning graph. Near the final PR, index the run in affected MEMORY files with pointers to those central sources. At a milestone, check whether these local updates collectively cover the work that was produced. A closeout bounded to the selected undertaking has fewer intervening versions and decisions to reconstruct than a later whole-project audit. Its actual cost still depends on scope, evidence quality, and the adequacy of the previous passes.

Establish a common basis before scaling an audit

A programme-level comparison needs a common basis before work is divided. Identify the corpus, implementation state, governing decisions, evidence limits, and overlapping activity. Fix the method and conventions that workers will apply. Separate discovery from repair so the evidence being interpreted remains stable.

Record the agreed scope and comparison basis before dividing the programme into assignments. Workers need the same identified material and conventions if their findings are to be combined.

Calibration tests whether the workers can apply that basis consistently. Select a varied sample, validate the returns, and examine disagreements independently. Put the conventions, proposed addenda, and scale-out choice to the human before expanding the work. A structurally valid ledger can still contain a mistaken interpretation or an unsupported verdict. Calibration examines both the form and the substance of the return.

Include events outside the source repository in the intake. Signing, a manual inspection, an installation trial, and publication may leave evidence in other systems or in records supplied by responsible people. Ask which such events occurred, what candidate they concerned, what result was obtained, and where it can be examined. A record that an operation was attempted may still leave its result unknown. Absence of an artifact from the examined code establishes a search limit, not that the event never happened.

Preserve the source and strength of each answer. A retrospective account can identify where further evidence should be sought, but should remain distinguishable from a contemporaneous result. Where no adequate warrant can be recovered, report the claim as unknown or partly supported. The next contribution may be a new examination rather than reconstruction of an observation that was never retained.

Use bounded waves and independently examine their returns

Divide the corpus into waves with declared dependencies and disjoint artifact writes. Give workers the accepted conventions and a bounded source. Validate each sub-batch before expanding further. Return defective work for correction and independent re-examination, preserving the earlier findings. Silent managerial repair of the ledger would obscure who made the interpretation and bypass its examination.

Each claim is examined separately. A Deliverable can contain aligned requirements, obsolete wording, unimplemented obligations, and unresolved authority at the same time. Derive its summary from the claim rows so these differences remain available. An overall verdict alone would discard information needed to select the next action.

Arrange independent package or wave verification over flagged and non-aligned rows and an agreed representative sample of aligned rows. Establish the sample, escalation, and coverage in the programme's conventions. Broaden the examination when disagreement, defects, or task variation show that the initial arrangement is inadequate. Agreement rates and finding counts can inform this choice, but they do not establish correctness without checking the disputed claims and their actual warrants.

Before adding another complete pass, identify what it would establish beyond the checks already performed. Some repetition provides an independent test of interpretation; other repetition merely recalculates a result already covered by a qualified tool and an independent reviewer. Reducing the latter can save effort when the remaining examination still covers the complete population, exceptions, and escalation conditions.

Resolve shared questions once and retain their consequences

Cross-package synthesis examines repeated ownership, inconsistent decisions, incompatible uses of evidence, and work with no owning claim. It also groups discrepancies caused by mechanism-level wording. These groups can reveal that many rows depend on one question about the repair posture rather than many independent product decisions.

Name a recurring question as soon as it becomes evident. Give workers its identity so they can record the affected cases while the question remains open. At the decision stage, present the common issue with its evidence, alternatives, and reach. The human can then decide the shared matter once. Each row retains its relationship to that ruling and any distinction that the common answer does not resolve.

Apply this approach to obsolete mechanism descriptions. Before deciding the individual cases, the human can settle the proposed treatment: lift incidental mechanisms into supporting evidence and retain the stable claim, or retain the mechanism as a claim for a stated reason. Sort the packets by whether that posture resolves their question, narrows it, or leaves it unchanged. Cases requiring judgment about whether the mechanism is decision-bound remain explicit.

This preparation reduces repeated explanation without suppressing consequential differences. It also directs the human's attention to the choice with the widest effect. The agent's synthesis remains a proposal until the decision is made and recorded. A run-wide convention cannot supply authority to change scope beyond the ruling's terms.

Repair and backcheck the actual changed state

Apply only the adopted repairs, through their owning scopes. Partition Deliverable writes or give shared changes one integration owner. Keep product repair separate from amendment of agent instructions or reusable governance. Lifecycle changes and accepted baselines retain their own decision paths. Record each changed claim and its authorised treatment, including cases where the adopted outcome requires no change.

Backcheck the repaired state after the authorised changes have been applied. Re-examine every changed claim against the current sources and account for it against the repair decision. Preserve authorised no-change outcomes as well as edits, held work, and remaining consequences. A check completed during discovery concerns the discovery state; the later repairs require their own examination.

Retain the backcheck as a new result tied to the repaired source and preserve the earlier evidence. Postponed repair that already has an owner stays with that owner. A concern with no executable home follows §5.6. Its treatment depends on the missing allocation, rather than the presence of a deferral label in a table.

Produce a complete account of remaining work for the programme's declared corpus, including an explicit absence where supported. Record stale derived records, outstanding questions, blockers, and conditions requiring another examination. The closing account identifies the scope compared, repairs checked, and consequences left to others. Ordinary development sessions can continue from current graph state when that state already contains the necessary facts.

Local consistency scans and dependency audits can assist this work. Their output must retain the input coverage, filters, source revision, and limits of the analysis. A topology audit can expose a missing target or cycle, while claim concordance examines whether the asserted result and its evidence agree. Their contributions are complementary and should be selected for the question being investigated.

Checking findings or changes to an issued baseline may require a later authorized undertaking. Its comparison follows the changed work, evidence and owning decisions. This does not turn the development closeout into a continuously running audit. Stable, checkable claims and current evidence make the affected comparison manageable. The resulting records should let a successor establish what the product must satisfy, what it actually does, and what remains to be undertaken.

5.9Assemble the grounds for a completion judgment

The manager prepares the completion account from the contract, produced work, evidence, and dispositions. Its purpose is to let the human judge what has been accomplished and what reliance the result can support. The account should preserve the difference between a completed operation, a completed undertaking, a produced Deliverable, and an approved product. Each has its own extent and authority.

An executor's completion report establishes a claim about its assignment. The parent examines that claim against the actual brief and return. A manager then examines how the contributions fit the undertaking. HELP_HUMAN relates the integrated result to the human's objective and the remaining project route. The human's judgment applies to the decision being requested, with enough evidence and explanation to understand its consequences.

Examine three forms of coverage

First, examine scope coverage. Follow the accepted project scope and objectives into the Deliverables selected for completion. Identify every contribution on which the claimed outcome depends. Account for exclusions, adopted changes, and unfinished work. A complete list of graph nodes can still omit an obligation that was never represented in that graph.

Second, examine relationship coverage. Read the applicable dependency and interface statements, including relationships to work outside the selected scope. Establish what each required input supplied and how the consumer used it. Trace consequential changes through their affected consumers and record the treatment of earlier evidence. The readiness view used to dispatch current tasks is narrower than this completion inquiry.

Third, examine evaluation coverage. Follow the applicable acceptance criteria to their verification methods and actual results. Include independent review where required, the correction of findings, and any remaining human examination. Preserve the limits of a check's environment, candidate, and exercised conditions. Evidence can be adequate for one claim while leaving another unsupported.

Bind conclusions to the current candidate

A completion account needs an exact subject. Identify the product source or artifact revision, the included contributions, and relevant configuration. Refer to the evidence by the candidate and inputs actually examined. A mutable branch name alone leaves the reader uncertain about which content the result describes.

For each material change since an earlier examination, determine whether that evidence still applies. Follow changes through the requirement, input, implementation, method, expected result, and operating environment where relevant. Record the reason for retaining a prior observation or commission the affected rerun. Keep the earlier result attached to its original basis.

This examination also applies to review findings. A corrected candidate needs the required backcheck and coverage of its changed content. The previous review remains evidence of what its reviewer examined. The completion account should reach the candidate proposed for the next use, including corrections made after that review.

EVIDENCE APPLICABILITY: ILLUSTRATIVE ENTRY

Claim and criterion: <exact scope and qualified reference>
Earlier evidence:   <candidate, input, method, observed result>
Current candidate:  <identity of the result now proposed for use>
Intervening change: <affected source, input, configuration, or method>
Assessment:         <which parts of the earlier evidence still apply>
Further work:       <required rerun, review, or unresolved question>
Grounds:            <changed content and supporting references>

Figure 5.4. A concise account of why an earlier result can or cannot support a present claim. An existing review or result record can carry the assessment.

Prepare a decision about identified work

Present the result, the evidence for its material claims, remaining deficiencies, and the action recommended. Explain limitations in terms of the intended use. “The connected save route has been exercised; recovery after interruption remains unobserved” gives the human a more usable position than an undifferentiated pass or failure for the entire product.

Make the proposed decision clear. The human may be asked to direct further completion, commence concentrated user testing, resolve a departure, or consider a particular acceptance. The evidence package should match that decision. A request for one act should not silently include another, such as permission to publish the candidate.

Establish the candidate's checking basis

Formal checking needs a settled object of examination. Reviewers must be able to relate their findings to the same defined contribution, and the human must know which obligations are included in the proposed decision. Before submitting a Deliverable, examine its remaining work and establish the preparation needed for the review to be meaningful. Development reviews continue while work is incomplete; entry into a frozen-candidate review is a further decision.

Current evidence bound to the candidate must account for every applicable production obligation within the proposed checking scope and establish that none remains unfulfilled. Compare the production contract, actual outputs, dependency evidence and required production checks. An empty graph or an absent or empty work list does not establish that coverage: it may omit a requirement or an unresolved decision. This account is a completion comparison against the candidate, not a separately maintained work list.

The formal checking arrangement used here requires that warranted absence before a candidate enters review. It also requires a checking basis suited to the Deliverable's claims and risk. These are separate questions: whether production has left work outstanding, and whether the proposed examination is adequate for what the candidate asks others to rely upon. The human considers both and declares the basis on which the candidate will be frozen.

The review plan assigns each examination to its place. In the editor example, suppose the agreed production checks require stale-proposal refusal through both the command interface and the native Apply control, with the live document and editing history preserved. A passing command test leaves production unfinished while the native route remains unexamined. Once both checks and the other specified production work are complete on the identified candidate, it can be prepared for freezing. The planned independent formal review and practitioner examination are still ahead: they are the purpose of the next stage and remain visible in its plan. Relabelling the missing native-route test as future formal review would change the agreed preparation and require a decision; it would supply no evidence of the required behaviour. Appendix A carries this distinction through a complete undertaking.

An unresolved obligation stays with production until it is fulfilled or the accepted boundary is changed. A proposal to reduce the scope must therefore be decided and applied before freezing. Recording an item as deferred does not remove it from the contribution under review. This preserves a definite subject for the reviewers and a definite extent for the eventual decision.

During formal checking, hold the candidate's claims unchanged and record findings separately. A needed correction reopens production through the governing authority, producing a new candidate for the appropriate examination. Earlier work and review remain attributable to the versions they concerned. Production, formal checking, and an issued baseline are distinct conditions of control; none is established merely by the project's 60% or 90% position.

5.10Deal with late findings and changes

A late finding should receive prompt examination because more work may already depend on the affected result. Establish the observed condition, candidate, governing requirement, and likely extent before selecting a response. Preserve the evidence that exposed the issue. The manager can then decide what investigation or authorised repair is needed and which consequences require the human.

The absence of anticipated DAG changes at the end of 60% describes an expectation about the route. A subsequent discovery can invalidate part of that expectation. The response depends on what the finding changes. Some defects are repairs within a settled design. Other findings expose missing scope, conflicting commitments, or a production relationship that requires renewed definition.

Diagnose the difference before changing the basis

Begin with the requirement and the actual result. An incorrect operation calls for repair against the applicable basis. Missing evidence calls for an examination. A stale record calls for examination of the claim and correction of its account, including an authorised granularity repair where incidental mechanisms have been treated as commitments. An uncertain requirement calls for clarification or a design decision. More than one can apply to the same finding, and their order matters.

For example, a test may report that recovery restored the document, although it compared only its text. A later observation shows that the restored selection refers to a different position. Read the accepted recovery requirement and the recorded design decisions. If selection is already included, the finding identifies incomplete implementation or verification. If its treatment was left open, the human needs to settle that product behaviour before a particular remedy becomes the accepted design.

The earlier passing observation remains evidence for its actual comparison. Correct any current summary that overstated its coverage. Preserve the failure and the later repair evidence so that the relationship between them can be examined. This keeps the technical problem and the record problem visible together.

Contain the affected work

Locate consumers of the disputed result through the project and local graphs, source references, and actual implementation. Identify the actions that need to wait and the independent work that can continue. Shared writes and test resources may require temporary reassignment or serial access. Tell affected workers what has changed and confirm their actual basis before relying on their continuation.

An affected Deliverable can return to a design question while other work remains in completion. HELPS_HUMANS can develop that question with the human through HELP_HUMAN, and WORKING_ITEMS can preserve the implementation and evidence pending a usable decision. The graph records the route back into integration, including any changed checks and reconciliation.

Re-examine the remaining horizon where the finding changes its foundation. A long tranche previously suitable for largely independent execution may now contain a shared unresolved choice. Reduce the affected assignments to the work that can be carried out responsibly until that choice is settled. Restore the longer route once the revised basis supports it.

Carry an amendment through its consequences

Where accepted decomposition changes, use the adopted scope-change procedure. Prepare the proposed change and its effects, obtain a decision on the exact amendment, and carry it through the affected records and work. Examine the resulting state against that decision. The authorised scope determines who can make each change and which dependent results must be renewed. Preserve the decision and the resulting position.

A late amendment can affect the product requirement, Deliverable contracts, local graphs, dependency records, evidence, and planned testing. Identify those consequences during impact assessment. A rewritten scope statement leaves propagation unfinished until the dependent work has received the change and its actual condition is recorded.

If the change calls for a successor project DAG, identify and examine the revised relationships, resolving cycles under the project's chosen dependency meaning. Examine each affected local graph against the successor. Preserve unaffected contributions and reopen only the decisions and checks whose basis or consequences changed. Record the resulting limitations on any earlier completion or acceptance claim.

Keep an unresolved late finding in the local graph whenever the undertaking can carry its investigation, decision, or repair. If it has no such home, preserve the obligation and arrange reconsideration as described in §5.6. Give the human its effect on use, dependencies, and remaining verification. Any change to an accepted outcome follows the governing authority and scope-change arrangements; recording the concern for later allocation leaves those obligations intact.

Keep correction bounded

Commission the smallest coherent repair that addresses the finding and its relevant consequences. Preserve unrelated user work and existing checks. Avoid coupling the correction to opportunistic cleanup whose effects make the candidate harder to examine. Where a broader change is needed, explain that need and obtain the corresponding scope before proceeding.

The repaired result passes through the required review, verification, integration, and reconciliation. Return the evidence of the correction and the obligations still open. A completed repair node can be a useful contribution while another part of the affected undertaking remains blocked. Report the resulting position at its actual scope.

5.11Establish the position at 90%

The 90% position marks the culmination of the planned development into produced Deliverables and a product that can become the principal subject of user testing and debugging. The human judges this change from the actual work and its remaining obligations. Percentage labels describe the development position in this method; they provide no arithmetic measure of effort spent or work remaining.

An undertaking can reach its own completion before the project reaches this position. Its result may enable another substantial development route. Read the selected completion claims against the remaining project scope. Determine whether the intended capabilities and their connected behaviour are available, which planned production is still absent, and what kind of work dominates the remainder.

Distinguish incomplete development from examination of the produced product

A missing capability or unresolved production interface leaves development ahead. A produced capability awaiting examination has a different condition. Its intended behaviour can now be exercised, findings can be compared with a definite basis, and corrections can be directed to an identified candidate. The transition depends on that change in the subject of the work.

User testing provides further opportunities to discover defects and limitations in the produced product. The transition account should identify the product available for examination, the development-time evidence already obtained, and the deficiencies known to affect that examination. It should also identify who will perform the planned exercises. An agent with suitable Computer Use capabilities can operate the application through substantial scenario sets under the human's direction. Practitioner examination is arranged where the questions require that person's experience or the governing criterion requires their participation. State any condition that prevents a proposed test from being performed meaningfully.

A product can contain areas at different positions. The human may direct user examination of a completed capability while another area is still being developed. Describe the selected scope accurately and preserve dependencies on unfinished work. Such a bounded exercise can be useful without implying that the whole project has reached the same stage.

Prepare the transition account

HELP_HUMAN brings the managers' integrated results together against the project's intended outcome. The account should identify the candidate and scope, produced Deliverables, relevant verification and review, reconciled records, open obligations, and the proposed next work. It should also identify any unresolved design or scope issue that could still alter the expected route.

WORKING_ITEMS supplies the technical position within each undertaking. It accounts for outputs, interfaces, known failures, outstanding checks, and residual work. Where one manager's completion depends on another's result, establish the actual received input. A collection of local completion reports needs this examination of their relationships before it can support a project-level conclusion.

POSITION PRESENTED AT 90%

Product and scope
  Identified candidate and the capabilities available for use.
  Produced Deliverables and the accepted basis they satisfy.

Development result
  Integrated contributions; required development checks and review.
  Reconciled records, actual dependencies,
  and outstanding obligations.

Remaining difficulty
  Known defects, unavailable examinations, and explicit holds.
  Any issue that still changes the intended product or delivery route.

Proposed next work
  Scope and conditions of user testing and debugging.
  The human's direction, decision points, and publication boundary.

Figure 5.5. Subjects for the human's assessment at the 90% position. The human considers this position against the project's adopted transition requirements.

Report evidence at the scope it supports. An implemented and checked operation may still have a usability limitation. A completed local review may leave a cross-Deliverable relationship unexamined. An available application build may omit a required environment. These qualifications help the human determine what the next work can reasonably undertake.

The human may direct further development, commence the bounded user-testing work, or revise the intended course. Preserve the actual decision and its scope. The graph then represents the authorised next undertaking, with the examination, repair, and reconciliation work it requires. Existing holds continue until their owner changes them.

Give the next undertaking a usable starting state

Retain the exact candidate and the records needed to examine it. Verify that product artifacts, configuration, instructions, and evidence references agree about what is available. Preserve unfinished branches and active operations with their current ownership. The people arranging user examination need to know which state is being held stable and which changes are still underway.

Carry the ensuing examination through the continuing local graph when it remains the same undertaking. Preserve completed results and revise the selected scope under the human's direction. When a new undertaking is selected, identify its starting state and its relationship to the preceding result. Retain a handoff when recovery needs additional facts or when the chosen workflow requires it.

5.12Examine the product in use

User examination concerns whether the produced product supports its intended activity under the conditions of use. Verification supplies evidence against specified requirements. Validation examines suitability for the intended purpose. Both may use observations from the same exercise, while asking different questions of them. The responsible human judges what those observations support.

The PRD, accepted decisions, and Deliverable contracts provide the starting basis. Read their account of users or consumers, intended outcomes, constraints, and significant operating conditions. Plan an examination that makes these matters observable. The amount and level of examination follow the proposed reliance and the consequences of error.

Start with the activity the product is meant to support

Select activities that exercise the intended result from beginning to end. Include the preparation the user must perform, the choices they must make, the feedback they receive, and what they can do with the result. Examine relevant interruption, cancellation, recovery, and persistence conditions alongside ordinary use. The selected scope determines which activities belong in the undertaking.

The activity should have a purpose understandable to the person performing it. In a technical application, producing a result may involve establishing an input, selecting a method, carrying out the operation, interpreting the output, and retaining or communicating it. A technically correct intermediate calculation can still be difficult to use if its input basis or result status cannot be understood. The examination follows the whole activity where that relationship matters.

For a service, library, or command-line product, identify the intended consumer and the actual route through which it uses the result. The examination can involve requests, responses, returned files, error conditions, persistent effects, and the next operation. The appropriate user may be a technical person operating or integrating the software. A screen-based scenario should be used only where the product provides that form of interaction.

Use the environment needed to observe the claimed behaviour. A requirement involving the native host calls for examination through that host. A connected integration may require the actual participating components. If a required environment or input is unavailable, record the missing examination and its consequence for reliance. A substitute can support the claims within its stated limits; the owning criterion determines whether it is sufficient.

Direct an agent-operated test run

With Computer Use available in its harness, an agent can observe the application display and operate its controls through pointer and keyboard actions. This lets it carry out a sequence of tests in the application on the user's machine or in another authorised test environment. The human can commission a substantial run rather than perform each interaction personally. Actual access and supported actions depend on the selected host. [4]

Give the run an objective, an identified candidate, and a set of activities to examine. State the expected behaviour and the requirements or decisions supporting it. Name the permitted application, working files, test data, account or service connections, and allowed changes to persistent state. Include how far the agent may pursue an unexpected result and which events require a return to the human. The brief should make clear whether it authorises observation only, bounded diagnosis, or a separately controlled repair.

HELP_HUMAN relates this examination to the user's intended outcomes and current priorities. WORKING_ITEMS can coordinate test preparation, scenario execution, investigation, and the integration of repairs. TASK can conduct a bounded scenario group and return its observations. The model and harness are selected for the actual demands of operating and interpreting the application, alongside the context and reasoning effort needed. The four-role arrangement remains sufficient for this work.

A long test run can proceed through many such groups. The manager retains coverage of the intended activities, the candidates used, and the unresolved findings. Completed scenarios can release diagnosis or repair while independent scenarios continue against an identified unchanged candidate. A shared application instance requires serial control; isolated instances can support concurrent runs. The graph records these resource and evidence dependencies just as it records production dependencies.

Establish a controlled starting state

Before execution, confirm the running application and candidate. An installed application may differ from the source currently checked out. Identify the build actually opened and the configuration relevant to the test. Prepare suitable test data and establish the document, database, or application state from which the scenario begins. Retain the means of restoring that state where a repeat or comparison will require it.

On the user's machine, agree how control will be shared. The person and the agent can otherwise change focus, input, or document state during the same observation. Protect unrelated work and restrict the run to the authorised applications and records. Test data should permit the required actions without exposing private material or risking the user's only copy. Actions that affect external systems need their own declared boundary; permission to exercise the interface does not establish permission to send messages, overwrite operational records, or publish a result.

These preparations are part of the test assignment. Record a failure to establish them as an execution limit. If the application, permission, or input needed for a scenario is unavailable, identify the unperformed examination and continue only with scenarios whose conditions remain valid. A substitute environment must retain its stated limits in the resulting evidence.

Execute, observe, and preserve the result

Operate the sequence through the route being examined. Where the requirement concerns the user's interaction, use the actual controls and observe their effects. A direct call to the underlying function can help isolate a fault, but it exercises a different route. Keep the results of the application exercise and the lower-level probe separately attributable.

Observe the resulting state after significant actions. A command to click a control records an attempted action; the subsequent display or state establishes what happened. Check relevant feedback, enabled actions, selections, retained results, and errors. Where persistence matters, complete the appropriate save, close, and reopen sequence and examine what survived. Screen observations can be supplemented by authorised inspection of files or logs when the claim requires it.

For example, a save-and-reopen scenario can establish whether an edited document returns with the required content and state. A success message is one observation. The reopened document supplies a further comparison with the expected result. The agent can perform both, preserve their evidence, and identify the particular property that failed. This gives the human a definite result to examine and the repair team a reproducible starting point.

Treat a change in focus, an unexpected dialogue, or a human interruption as a change to the test conditions. Re-establish the state before continuing a dependent scenario. Distinguish an application defect from an unsuccessful control action or a lost observation. The latter can require a corrected test procedure or another attempt; it should not be reported as evidence that the product passed or failed a condition that was never exercised.

Retain enough non-secret evidence to support the claim: starting state, actual actions, relevant observations, expected result, and the candidate. Screenshots, resulting artifacts, logs, or a bounded action record can each contribute. Choose their extent by what another participant needs to check. Record failed, blocked, and unperformed scenarios as well as successful ones. Evidence from the run then supports a coverage account rather than a collection of favourable examples.

Make the observation intelligible

Identify the candidate, starting conditions, actions, expected outcome, observed result, and resulting state. Record the particular point at which the activity failed, became uncertain, or required an unexpected intervention. A useful finding can then be connected to the product basis and investigated. General reactions can be valuable, but they often need a concrete example before they support a technical assignment.

An observed difficulty may concern the implementation, the instructions, the user's interpretation, or an assumption in the design. Keep the observation separate from its proposed explanation. The human who understands the intended use can help determine what the difficulty means. The agent can investigate the mechanism, compare alternatives, and prepare the consequences for judgment.

Where the intended result includes preserving the user's control, examine what the product lets the user recognise before and after an action. The user may need to understand which input produced a result, whether it remains current, and what will be changed by accepting it. These matters carry the objectives and values established during conception into the examination of the finished behaviour.

PRODUCT EXAMINATION: ILLUSTRATIVE RECORD

Activity and purpose: <what the user or consumer is trying to achieve>
Basis:                <requirement, intended use, relevant decisions>
Candidate and setting: <running build and necessary conditions>
Executor and means:   <human or agent; actual harness and controls>
Starting state:       <test data, setup, and reset reference>
Actions:              <steps actually performed>
Expected result:      <outcome and the source of that expectation>
Observed result:      <behaviour, feedback, and resulting state>
Finding:              <difficulty or failure, with its consequence>
Open question:        <cause or interpretation not yet established>
Evidence:             <retained non-secret observation>
Coverage and limits:  <completed, failed, blocked, unrun scenarios>

Figure 5.6. A specimen linking a product observation to its intended use. Use the project's chosen testing records to preserve these relationships.

Examine what the run supports

Agent-operated testing can provide substantial verification evidence and observations relevant to validation. The responsible human examines their adequacy for the intended reliance. This includes considering whether the scenarios represent the activity, whether the expected outcomes express the requirements correctly, and whether the observations support the conclusions drawn. The human can use independent review, selected repetition, and further testing appropriate to the consequences.

The operator's identity also matters to particular claims. A run performed by an agent shows how that agent completed the stated scenarios. It does not establish how an unfamiliar practitioner understands the interface, where they hesitate, or which assumptions they bring from their work. Questions of that kind need observation involving the relevant people. Where practitioner participation or a specific human witness is required, retain it as a distinct contribution with its own conditions.

The resulting arrangement gives agents substantial responsibility for test execution and evidence preparation while keeping the human's judgment directed toward the product and its use. Findings return to the current work graph for diagnosis, correction, and re-examination. A concern without a home in that undertaking is retained with an arrangement for allocation and reconsideration under §5.6. An ordinary test failure already within scope remains part of the debugging work.

5.13Debug the identified candidate

Debugging carries an observed deficiency through diagnosis, correction, and renewed examination. Start with an identifiable failure or difficulty and the conditions under which it occurred. Locate the affected requirement, product behaviour, and candidate. The first useful assignment may be to reproduce or isolate the observation, particularly when the report leaves its cause uncertain. Begin with the symptom and reproduction boundary, use the narrowest suitable probe, and trace the earliest divergent state before selecting a repair.

The local graph can represent this sequence directly. An investigation produces a diagnosis or a narrower question. A repair uses the established basis. Independent review and affected checks examine the correction. Integration brings it into the candidate, and reconciliation updates the records that describe the result. Preserve these dependencies so an unverified repair cannot disappear into a general claim that debugging is finished.

Establish a cause that the correction addresses

Collect enough evidence to distinguish a product defect from an invalid test condition, incompatible input, or contaminated environment. Confirm the actual version used and inspect relevant state. Where the failure is intermittent, retain the observations obtained and the uncertainty that remains. A successful attempt under different conditions supplies limited evidence about the original failure.

Use focused investigations to test competing explanations. The agent's proposed cause remains an interpretation until the available evidence supports it. Each attempt should establish something about the mechanism or narrow the unresolved conditions. If repeated repairs produce no new evidence, change the diagnosis or the means of observation before another implementation attempt.

Define the repair by the required behaviour and the known failure. Include the relevant source, allowed writes, checks, and expected return in its brief. The bounded method used for new implementation applies to repairs as well. Preserve the accepted basis, make a coherent change, perform the authorised checks, examine the actual writes against the permitted scope, and return evidence and residuals.

Protect the meaning of the check

Inspect any change to a test, expected result, tolerance, or reference as part of the repair. A legitimate correction to a test needs its own basis. A protected criterion stays in force until the authorised person changes it. Preserve a measured conflict between design and criterion and bring it to the human with the relevant evidence and proposed treatment.

When adding regression coverage, make the new check represent the failure and the required behaviour. It should help determine whether the correction addressed the original defect. Record limitations where the test represents only part of the conditions. The requirement and its governing verification method remain the basis for the broader completion claim.

A passing rerun is an observation to assess with the diagnosis and changed content. Confirm that the failed path is still exercised, the expected result remains justified, and the change has not excluded the case that exposed the defect. Retain the earlier failure as part of the history of the correction.

Review, integrate, and repeat affected examination

Apply the project's independent-review requirements to the complete changed candidate. Give the reviewer the reported failure, its governing basis, the proposed correction, and the relevant evidence. Backcheck actionable findings and cover later changes before relying on the review for integration. Keep the candidate identity visible throughout.

Assess the effect of the repair on connected activities. A local correction can alter shared state, error handling, persistence, or another consumer's interpretation. Repeat the affected journeys and required checks after integration, using the candidate that will be proposed for acceptance. A Computer Use executor can restore the test starting state and repeat the failed application sequence, then exercise the connected scenarios affected by the correction. Identify the new running build and retain the earlier observations with their original candidate. Record any examination that remains unavailable or blocked.

Keep the user's observed difficulty in view during the final check. A correction may pass its new code test while leaving the original activity awkward, ambiguous, or still unsuccessful. Re-examine the activity to the extent required by the finding. The human can then judge whether the intended result has been restored or whether a further design choice is needed.

Make production-document changes when the repair itself needs them. After the intended implementation and evidence integration, the one planned documentation/governance closeout stage compares the affected Scope of Work, dependency statements and evidence references with the combined result. Recheck affected comparisons if later repair changes that basis. Preserve unfulfilled obligations and any limitation accepted by the responsible human. A repair requiring a change to product scope follows its owning decision process.

Keep unfinished debugging recoverable

An interruption may occur while the defect is isolated, while a candidate repair is unreviewed, or after a test has run without its result being recorded. Refresh the graph at useful boundaries with the observation, current hypothesis, actual diff, checks performed, and next safe action. Retain the evidence needed to resume outside temporary worktrees. Before reassignment, establish that prior workers and shared test operations have stopped or transfer their ownership explicitly.

Close a debugging contribution against its stated conditions. Record whether the correction has been checked and integrated, whether the affected activity has been re-examined, and what remains. The parent can then use the result in the product-level assessment without reconstructing the entire investigation.

5.14Prepare the product for the publication decision

The work described in this chapter produces an identified result, an account of its examination, and explicit treatment of what remains. The human then judges whether the candidate is suitable for the intended use and whether the governing conditions for publication have been met. The 100% pipeline carries the approved version into delivery. Its operations and authority belong to the selected product and release arrangement.

Bring together the production and evaluation records without duplicating their contents. Identify the candidate, included capabilities, relevant environment, and limits of the proposed use. Connect the accepted intent to the produced Deliverables, their integrated behaviour, and the evidence for the proposed reliance. HELP_HUMAN prepares the project-level decision from the managers' integrated returns; WORKING_ITEMS accounts for the technical result and remaining work within each undertaking.

Explicit holds must remain visible. The owner may have reserved a usability decision, required a particular witness, or prohibited publication until an external input arrives. A general report of readiness cannot supply the missing decision or observation. Describe each limitation in terms useful to the intended recipient, and retain the return path for further testing, correction, or a changed decision. Recheck affected evidence and closeout comparisons when later work changes the candidate or its account.

Acceptance applies to identified content, scope, and purpose. Preserve the human's words and the decision actually made. Distinguish acceptance of a particular contribution, direction to continue testing, approval of the product for its stated use, and authority to publish. A single decision may address several of these matters when it says so explicitly. Changed content requires examination of the decision's continuing applicability. Earlier acceptance remains attributable to what the person actually examined and accepted.

POSITION FOR THE 100% PUBLICATION UNDERTAKING

Candidate
  Exact product version and the basis of the proposed delivery.

Examination
  Applicable verification, user examination, review, and corrections.
  Evidence locations and the limits of the results.

Decisions
  Recorded approval for the stated use and publication authority.
  Any unlifted hold or outstanding decision.

Delivery work
  The selected pipeline, its prerequisites, and responsible actors.
  Required recipient information and continuing obligations.

Figure 5.7. The position from which publication can be organised. The actual pipeline and decisions come from the product's governing delivery arrangement.

The development record remains available to explain what was achieved and why. Chapter 6 follows the approved candidate through delivery, receipt of continuing responsibility, and the starting basis for later work.