Projects organise human and artificial agency to produce a product. They bring together participants who can investigate, propose, act, and affect the work of others. The project manager gives these contributions a common direction, establishes responsibilities, and arranges the examination and integration through which the intended result can be achieved. As the work develops, the manager must also recognise when its organisation or accepted basis needs to change.

An AI agent is an other whose work you receive and may come to rely upon. It can carry out substantial parts of an assignment without your performing those actions yourself. Its interpretation of the request, the information it used, and the choices made during execution may therefore require examination. Before accepting responsibility for the result, establish an appropriate amount and level of verification and validation. What you examine, who is competent to examine it, and how thoroughly it must be examined depend on the proposed use and the consequences of error. Section 1.5 develops this relationship through the examination required before relying on work prepared by another contributor.

The word agency here concerns the ability to act within an undertaking. A person or an artificial agent can investigate a question, prepare a design, or carry out assigned work. Their participation does not give them the same relationship to responsibility. This manual reserves judgment for the human and calls the artificial agent's computational interpretation, comparison, inference, and selection reckoning. The agent may exercise substantial initiative within its assignment. People determine the purposes, constraints, and commitments under which that initiative is used, and answer for the work they accept.

This is a humanist account of artificial intelligence in project work. Human judgment shapes what the project is for, what its product should preserve, and which consequences are acceptable. A choice made during an early conversation can govern many later assignments. It can remain consequential after the original participants have left or the conversation has been forgotten. The project must preserve both the decision and enough of its grounds for those who later act upon it to understand what they are being asked to maintain.

The approach developed here adapts selected Alberta oil-and-gas project practices from the 1970s through the 2010s. Packages and deliverables, an accepted design basis, management of change, coordination across disciplines, and dependable project records provide its working vocabulary. The manual brings that view of project management into software development and agent-assisted work. Its application depends on the participants and their relationships: who prepares a contribution, who depends on it, who checks it, and who accepts responsibility for its use.

An engineering project manager can approach the agent system through those questions without first becoming a programmer. A programmer who already uses agents can use the same questions to understand why several completed assignments may still leave substantial project work undone. The following sections introduce the software arrangements where they become relevant and explain the management purpose each serves.

A project gives people a way to pursue an intended result through work that they must divide, examine, and bring together. At the beginning, they may have only a difficulty they want to overcome or an opportunity they want to explore. As the work proceeds, they develop a more definite account of the result, the means of producing it, and the conditions under which it will be worth using. They also discover where their earlier understanding was incomplete. Managing the project involves carrying those discoveries into subsequent work while preserving the commitments that still apply.

This chapter follows the formation of an undertaking and introduces the changes in working arrangement that accompany its development. A recurring example concerns an editor in which a user reviews changes proposed by an agent. Its decisions, findings, and records are constructed illustrations of the method. Appendix A brings the successive contributions together as a worked undertaking.

1.1An intended result and a reason to pursue it

Suppose a programmer has an application in which people prepare technical documents. The application already supports manual editing, saving, and reopening. The programmer wants to introduce agent assistance and begins with this request: “Let me try an agent’s changes and get my work back if I decide against them.” Several features might answer that request. The application could let an agent edit the document and provide an undo operation. It could show a proposed revision separately. It could make a working copy in which the user experiments before choosing what to retain.

The request gives a useful starting point, but choosing among these arrangements requires a better understanding of the intended use. Does the user expect to continue editing while considering the agent’s proposal? Is the proposal one change or a related set of changes? Does getting the work back include the selection, cursor position, and editing history? What should happen to changes the user makes after the agent begins? The answers determine what the proposed feature must preserve and which kinds of implementation are suitable.

In this example the product is the application and the behaviour made available to its users. The project is the organised undertaking through which the team develops and hands over the proposed capability. The distinction matters when assessing progress. A report comparing recovery methods may be a useful project result even though it adds no behaviour to the application. Conversely, a considerable amount of implemented behaviour may require further work before the user can rely on it.

The same distinction applies when the intended product is a physical facility, a modification to equipment, or a design package for another party to use. The project organises the work that produces and hands over that result. A product can remain in service through several subsequent projects. Completing the present project therefore requires an account of the result delivered and of any responsibilities continuing after handover.

The term undertaking also applies at a smaller scale. It identifies a bounded contribution whose result and remaining obligations can be assessed. Investigating the recovery methods is one undertaking. Implementing an agreed interaction is another. Integrating several contributions and preparing a release can each be managed in the same way. The boundary identifies what someone is responsible for carrying through. It need not coincide with a chat session, a folder, or the lifetime of an agent instance.

Progress is judged in relation to the purpose of that undertaking. The investigation may establish that restoring a whole document would discard later manual edits. That finding gives the team a reason to reject or constrain an approach. An implementation may establish that a selected interaction works in the situations examined. A review may expose an unsupported claim that must be resolved before further work relies on it. Each contribution advances a different part of the project’s understanding or result, and each needs an account of what it has actually established.

Here and in the later examples, the owner is the person directing the undertaking and making the decisions reserved to that role. On a project involving several responsible people, their respective decision rights and technical responsibilities must be identified. A project manager's coordination of the work does not confer the competence or authority to accept every technical contribution personally.

The judgment of success remains connected to the reasons for undertaking the work. In the editor example, a fast recovery mechanism has little value if it silently loses the user’s later changes. A slower arrangement may be preferable if it preserves the work and makes the consequences understandable. The person directing the project must decide which outcomes matter and which constraints limit the acceptable means. Those choices will continue to govern implementation long after the opening conversation.

1.2Developing the intention with an agent

Begin by establishing what the person is trying to accomplish and what is already underway. An apparently new request may refer to an existing product, an earlier decision, or work that was interrupted. Read the relevant material before replacing it with a fresh proposal. Ask about the difficulty in its setting: what the person was doing, what they expected to happen, and what made the present arrangement unsatisfactory. An example of use often gives a more definite starting point than a requested feature name.

The design partner then gives the person something they can examine. For the editor, a short comparison could show what happens under each proposed recovery arrangement. Under whole-document restoration, the user’s later edits may be lost. Under a separate preview, rejecting the proposal can leave the working document untouched, while applying it after further manual editing introduces a question about which revision it belongs to. An operation-based undo arrangement requires the team to define which actions belong together and how later actions depend on them. The comparison brings those consequences into the conversation before one approach becomes embedded in the implementation.

The human’s response develops the design. They may recognise the proposal as a useful expression of their intention, correct a particular interpretation, or explain that all the alternatives miss the point. In this example, the response might be: “I need to keep working while I look at the proposal. Rejecting it must leave my own edits alone.” That correction gives the team a clearer account of what is to be preserved. It also changes the question from generic recovery to the relationship among the live document, the proposed revision, and work performed while the proposal is open.

This exchange is part of conception. The human may recognise what they mean through the consequences of a proposal they had not previously considered. The agent contributes by finding examples, comparing possibilities, and making its interpretation inspectable. Keep those interpretations distinguishable from the human’s commitments. A summary that says the human selected separate preview is warranted only after that choice has actually been made. Until then, separate preview remains a proposal, however well it appears to answer the latest correction.

The design can remain open in some respects while becoming definite in others. The human might decide that the first implementation concerns one document and one proposal at a time, while leaving the handling of intervening manual edits for investigation. That supplies a boundary for useful work. It also identifies a question whose answer will affect the apply operation. The agent can continue developing alternatives without treating the unresolved question as permission to choose whichever behaviour is easiest to implement.

Preserve the reasons that led to significant choices. A brief statement that an approach was rejected because it could discard later edits helps a subsequent participant understand why it was unsuitable. Keeping the rejected alternative also helps when circumstances change. A method that was unsuitable for live editing may be appropriate for an isolated working copy. The record should preserve enough of the original circumstances for that later comparison to be made intelligently.

1.3Objectives, constraints, and commitments

An objective describes an outcome the project is intended to achieve. For the editor, an initial objective could be to let users examine and use agent-proposed revisions while retaining control of their own work. The wording gives direction, but it still needs development before it can guide implementation. The team must identify the situations that matter and what retaining control means in each of them.

A requirement states a condition or capability whose source, interpretation, and status can be examined. One requirement emerging from the example could state that rejecting an unapplied proposal leaves the live document unchanged, including manual edits made while the proposal is being reviewed. It names the affected object, the relevant action, and an observable outcome. Its source is the human’s expressed concern, and its wording is the team’s proposed interpretation until the human adopts it.

A constraint limits the means or result that the project can accept. Some constraints are inherited from the existing product or from an accepted external basis. Others follow from the resources, intended users, or consequences of the undertaking. In the example, preserving the established save and undo behaviour may constrain the new feature. The team should identify which existing behaviour is to be preserved and where it is specified or demonstrated. A vague instruction to maintain compatibility leaves each contributor to supply a different interpretation.

These distinctions help the team examine a proposal without prematurely turning every useful idea into a commitment. A side-by-side preview may be a proposed means of satisfying the objective. A comparison against an identified document revision may become an accepted design choice. Supporting proposals across several documents may remain a future possibility. The project record should let a reader distinguish these positions and recover the grounds for each. Merely listing all of them under “requirements” would make subsequent assignments difficult to interpret.

The values behind the choices deserve an explicit explanation. In this example, protecting the user’s work justifies examining rejection, interruption, and intervening edits even when the normal apply path is straightforward. The preference also gives a basis for evaluating alternatives. A proposal that conceals the possibility of overwriting later changes would conflict with it. An arrangement that exposes the conflict and asks the user to choose may preserve the objective, although its inconvenience must still be considered. The team needs both the chosen behaviour and the reasons for preferring it.

The four philosophical questions used throughout this manual can be seen in this one requirement. Ontology asks which document and which changes the requirement concerns. Epistemology asks what supports the claims about preservation and how those claims can be examined. Praxeology concerns the actions through which proposals are prepared, reviewed, applied, or rejected. Axiology concerns the value placed on the user’s work and the consequences of losing it. Their practical use is to reveal a missing part of the account. They need not produce four separate documents or four additional approvals.

At this stage, describe the authority attached to a statement as carefully as its technical content. A requirement can fix an outcome while leaving several internal designs available. A specifically adopted interface can narrow that discretion. A suggestion in an agent’s report may have no authority to alter either. The next participant needs to understand what they may choose within their assignment and what would require a further decision.

1.4Useful work while the design remains open

An incompletely defined product can still support a well-defined investigation. The team may need to inspect existing behaviour, compare candidate designs, or build a limited demonstration before deciding what to implement. Give this work a purpose that can be assessed on return. Identify the question, the material to examine, the permitted operations, and the decision the result is intended to inform.

For the editor, the agent could be assigned to examine how the current application represents document content, selection, undo history, and the saved revision. The return would identify the relevant implementation and tests, describe what they establish, and locate gaps that affect proposal review or recovery. The assignment would not authorise a new recovery design. It would prepare the team to judge which parts of the existing application can support one.

A separate undertaking could build a demonstration of reviewing a proposed revision without changing the live document. Its purpose would be to make the interaction tangible. The brief could limit writes to an isolated prototype, require a small set of observed scenarios, and ask for a report on the assumptions made. That boundary gives the executor room to solve the demonstration’s local problems while preserving the human’s decision about adopting the design.

Examine the return in relation to the question asked. A demonstration may show that users can compare two versions and reject a proposal without altering the live content. It may leave the selection, undo history, interrupted operation, or saved state unexamined. It may use a simplified representation that cannot be carried directly into the product. Those limitations determine what the team can do with the result. The prototype remains useful when its purpose and limits are clear.

A finding can also change the next investigation. Suppose inspection shows that the application’s undo mechanism groups changes by individual commands, while an agent proposal can contain several commands. The team now has a concrete question about grouping and reversal. An executor can examine how the commands interact and return alternatives. The design partner can explain the user-visible consequences. The human can then decide which behaviour the product should promise.

Keep investigative success distinct from success of the proposed product. An investigation that rules out a favoured approach may have fulfilled its purpose. Its result does not establish that an acceptable alternative exists. The owner may choose further investigation, a smaller undertaking, or an end to that line of work. Record which question was answered and which intended outcome remains unachieved so that the next decision is made on that basis.

Keep this permission for exploration distinct from authorisation to produce the project result. An isolated prototype can inform the product requirements document while its requirements are still being developed. Incorporating it into production follows confirmation and acceptance of that document, decomposition, and project setup. Its earlier demonstration remains evidence for the limited question it addressed; further work must establish its suitability for incorporation.

1.5Examining work received from an other

An artificial agent operates with a language model, instructions, supplied context, available tools, and the permissions its host provides. The host is the application or execution environment through which it reads files, uses tools, and performs actions. An instruction can prescribe a boundary, while the host determines which operations are actually available. The project needs an accurate account of both when assigning work and examining what occurred.

During an assignment the agent may interpret source material, select a method, make local choices, and encounter conditions the human has not seen. Its return is the result of that execution. Treating the agent as an other directs attention to this relationship between the preparation of the work and the person who proposes to rely on it. Receiving an answer to your own request does not establish that the answer embodies your intention or that the work was performed adequately.

For practitioners governed by APEGA in Alberta, Relying on the Work of Others and Outsourcing is a professional practice standard. Section 3.1 sets out the supervision or thorough review through which those practitioners may take responsibility for work prepared by others. APEGA's published AI guidance also confirms that the applicable practice standards continue to govern their development and use of AI, and that they remain responsible for AI-assisted work. [1, 2]

In this manual, other describes the contributor whose work the responsible person receives. It includes a human contributor or an artificial agent. The relationship calls for attention to what was assigned, how the work was prepared, and what examination supports its use. Applying it to an artificial contributor preserves those questions. The particular means of supervision and checking must suit the contributor, the work, and the consequences of relying upon it.

For this manual, the relationship applies throughout development. Reading a prototype to choose the next investigation calls for one kind of examination. Incorporating it into the product calls for a more extensive one. The human needs to establish which claims the result supports, whether its preparation was appropriate, and what remains uncertain for the intended use. The examination should be planned while the assignment is being prepared, so that the executor knows what evidence must accompany the return.

Verification and validation

Verification examines the result against specified requirements or declared checks. Validation examines whether it is suitable for the intended use. In the editor example, a comparison of the live document before and after rejection can verify a preservation requirement. Validation also asks whether the chosen review interaction lets people understand the proposed changes and protect their work in the circumstances in which they will use the application. These questions concern related but different grounds for accepting the result. These are the manual's working meanings; formally defined professional-practice acts retain their own requirements.

Consider a report stating that rejection preserves the document. Read what was actually exercised. Was the comparison confined to text, or did it include the selection and undo history? Which candidate was tested? Did the user make a manual edit while the proposal was open? What was expected to remain unchanged, and how was it compared? The report, underlying evidence, and implementation should allow these questions to be pursued. A conclusion that exceeds the evidence must be narrowed or supported by further examination before dependent work treats it as established.

A claim is an assertion that something is the case. A warrant supplies grounds for believing it. In a production contract, the claims selected for maintenance concern the obligations and relationships that the project needs to preserve. Requirements state what must be satisfied; descriptive claims state what is represented as the case. Their grounds and present standing must remain distinguishable. Here, the preservation claim might be supported by an identified execution showing before and after states for stated scenarios. A reviewer can find the observation accurate but too narrow for the claim, or discover that the comparison omitted a relevant property. Identifying the warrant makes this examination possible. Its adequacy for the proposed reliance remains to be assessed.

The amount and level of examination include several choices. Reading a short source extract may be enough to check that a requirement was transcribed correctly. Establishing that it has been interpreted correctly may require the surrounding source, the design rationale, and discussion with the person whose intention it expresses. Examining an implementation may require inspection of the changes, reproducible tests, and a reviewer with the relevant technical competence. A complete user activity may need to be observed in the actual application because isolated component tests leave the relationships among its parts unexamined.

The project should establish the required examination and who will perform it before accepting the contribution. A contractor's checked drawing, an agent's test report, and a working demonstration each need to be considered in relation to what another participant will do with them. In the software example, passing a test that compares text would not justify claiming that the whole editing state is preserved. Additional evidence must address the broader claim. An executor cannot reduce an agreed check merely because satisfying it has become inconvenient.

Some checking can be automated or assigned to another agent. Such work can inspect more material, repeat comparisons, and expose defects for attention. Its findings must retain their sources and limits. The responsible human uses those contributions in judging whether the examination supports reliance. In professional engineering work, the relevant competence, review, and authentication obligations continue to apply. APEGA's AI practice notice likewise places responsibility for AI-assisted work with the professional and calls for competent assessment of its results. [2]

Reckoning and human judgment

Brian Cantwell Smith gives a philosophical treatment of reckoning and judgment. This manual applies that distinction to the management of delegated work. [5]

Reckoning includes the computational organisation and use of information through comparison, inference, calculation, generation, and checking. It can expose consequences and prepare alternatives that the human would otherwise have difficulty bringing into consideration. An agent can carry this work far enough to recommend a design or select an implementation within an assigned boundary. Those selections remain part of its reckoning under the authority given to it.

Judgment concerns the person's situated understanding of the work and the commitments for which they will answer. In the editor example, the human judges what preservation should mean for the users, which limitations are acceptable, and whether the available examination supports the proposed reliance. This responsibility exists during conception and design as well as at final acceptance. Keeping it with the human is a premise of the method, including when the agent produces exceptionally capable work.

Human judgment remains open to error and revision. Recorded information must be distinguished from what a situated person knows from it. Another reader may notice an implication that the first reader missed, and the same person may understand an old record differently after further work. Preserve the result, the evidence, and the scope of the decision so that this later examination remains possible. An acceptance record identifies the reliance the person undertook; it does not make their understanding exhaustive or their decision infallible.

The organisation of the work should make assessment practicable. A parent checks an executor's return against the brief, a manager examines the combined result, and the human receives consequential choices with the evidence and reasons needed to decide. The detail follows what is being claimed and what will depend on it. This gives agents room to carry out useful work while preserving human attention for the questions that require judgment.

1.6Establishing a basis that another participant can use

As choices begin to govern further work, the project needs an identifiable accepted basis. This comprises the applicable requirements, decisions, commitments, and identified material under which the undertaking proceeds. Its scope matters. An accepted purpose can guide further design while a particular implementation proposal remains under examination. Authorisation of a bounded investigation establishes what its result is meant to inform; adoption of the investigated design requires its own decision.

The product requirements document, or PRD, carries the shared understanding of intent into formal project definition. It is authored from the conversation, the accepted directions, and the investigations that have helped the human and design partner understand the intended product. It gives that understanding a form that can be examined as a whole and subsequently used by participants who were absent from the conversation.

Engineering documentation uses DBM for design basis memorandum. [3] An engineering project manager can recognise the PRD's function through this document. The documents belong to different working contexts, but in the approach used here each gives the ensuing design and project organisation an identifiable basis. The PRD explains the intended product, its requirements and boundaries, and the choices and constraints that further work must preserve. The comparison concerns that management function; it does not prescribe identical contents for every PRD and DBM.

Suppose the owner adopts the following direction for the editor: develop review of one proposal against one document; leave the live document unchanged while the proposal is inspected or rejected; and prevent application from silently discarding intervening manual work. Changes across several documents and external actions are outside this undertaking. The PRD must preserve those choices, their meaning in use, and the questions that still need design work.

The design partner can prepare a technical interpretation alongside the source direction. That interpretation might identify a proposal's source revision and the live document's current revision as distinct objects that must be compared. Where adopting that distinction constrains the product, it must be apparent in the PRD the human examines. Keeping the human's words and the interpretation distinguishable allows a later participant to assess whether the translation preserved the intended meaning.

An open question also needs a useful account. “Handle intervening edits” gives little guidance. A fuller description would state that the team has yet to choose whether to require a fresh proposal, allow a reviewed reconciliation, or use another approach. It would identify the apply operation as dependent on that choice and retain the prohibition on silent loss of manual work. The PRD can distinguish the required outcome from a design choice still to be developed. Acceptance must make the treatment of that open choice clear; a blank field cannot authorise an arbitrary answer.

The human reviews the PRD for confirmation and acceptance before decomposition and project setup proceed. The authoring method in Chapter 2 prepares this decision through proportionate intake, development of the product account, writing, and a separate examination of the candidate. That review examines whether the document represents the intended product, whether its commitments and exclusions are understood, and whether the remaining questions have an acceptable treatment. It also considers what evidence will eventually support assessment of the result. Acceptance identifies the revision to be used. The team can then decompose that accepted basis without leaving each contributor to reconstruct the project from different fragments of conversation.

The depth needed in the PRD depends on the nature of the project. A small extension to a familiar product may inherit much of its basis from established behaviour and accepted specifications. A product with unfamiliar interactions, many dependencies, or substantial consequences may need a more developed account before its scope can be divided usefully. In each case, the accepted PRD records the position from which the next phase will proceed, including what remains to be developed.

An accepted PRD may still leave substantial design work ahead. The phase sequence in §1.7 places the development of execution arrangements and design details after conception and project setup. The human therefore considers an open question in relation to those later undertakings: what work will resolve it, what depends on it, and what commitments already constrain the answer. The same question may need an early answer in one project and be manageable as later design work in another.

A less-developed PRD can lead to a successful product. It may also leave the team to resolve interacting interpretations after detailed work has spread across several contributions. As product complexity increases, that possibility deserves closer attention. In the editor, leaving the response to a stale proposal open may be manageable while its affected interfaces remain under coordinated design. Discovering much later that different contributors assumed incompatible responses could require revisions to application, history, saved state, and tests. The risk follows the relationships allowed to develop around the open question. The amount of early definition should be judged with those relationships in view.

Keep the basis, work, and record distinguishable

The actual state of the project includes what exists and what it does: documents, code, demonstrations, incomplete changes, tests, and work that has not yet been integrated. The recorded state is the account available in the project's files, graphs, reports, and handoffs. The two require comparison. A report can be current about one contribution and stale about another, especially when work proceeds in separate locations.

The software arrangement uses a repository to hold project files and their version history. A branch identifies a line of development within that history. A worktree provides a separate working checkout in which a line of work can be edited. Merging combines changes into another line, usually the project's main line. These facilities allow work to proceed separately while retaining a means of comparing and integrating it. Their names will appear in handoffs because the location and revision of unfinished work affect what a successor should do.

For example, a handoff may say that the review prototype is complete while its last changes remain in a separate worktree. A successor who examines only the main line could mistakenly repeat the work. A successor who trusts only the handoff could rely on behaviour that was never checked. The successor must inspect the identified work and its evidence, including any changes made after the last recorded checkpoint.

Records also perform different functions. A test report describes an event and can be examined against its evidence. A properly made acceptance record constitutes a governed decision about identified work. It establishes what was accepted, by whom, and for what purpose, provided the prescribed human act actually occurred. An agent cannot supply that act by writing that approval was given. Similarly, the owner's acceptance of a report does not change what an earlier test exercised.

Versioned files give humans, agents, and tools a common place to inspect decisions, sources, and working state. Identify the applicable versions and retain links between decisions and affected work. A content hash is an identifier calculated from a file's contents; it can be used to check that the content matches the version being cited. Reading its sources and checking its attribution remain necessary to establish what the identified content supports.

Prepare continuity while the work is underway. A later participant should be able to recover the purpose, the accepted PRD and subsequent choices, what has been examined, and what requires further action. That participant will still have to interpret the material and inspect the present work. A dependable record supports that examination and allows a different or corrected interpretation to be brought forward. Section 1.10 explains how session entry and handoff use this record.

1.7How the project's work changes as it develops

The phases describe changes in what the project is organised to establish. Early work develops the intended outcome and its basis. Subsequent work gives that basis a division into packages and deliverables, establishes the means of execution, develops the design details, and carries them through to completed contributions and a delivered product. These changes give the project a course while allowing its parts to develop at different rates.

The six phases have counterparts in the traditional engineering execution model used by the author: Conceptual, FEED, 30%, 60%, 90%, and 100%. FEED means front-end engineering design. The correspondence below uses the development purposes the author assigns to those stages. It provides a way to carry lessons between engineering and software work without requiring their artifacts or technologies to be identical.

The percentage labels identify stage-gate positions in this account. They do not measure the fraction of effort spent, tasks completed, or code written. Reaching the 60% stage says something about the design position the project has established. It provides no calculation of how much work remains. A stage gate is the human assessment of whether the accumulated work supports the proposed transition. A phase is the work organised toward that development purpose. The owner can require further work, accept a stated limitation, or redirect the undertaking when considering the transition.

Conceptual: alignment and the PRD

Conception develops a shared understanding of what the product is intended to accomplish. Dialogue, alternatives, examples, and bounded investigation give that understanding increasing definition. The team authors the PRD from it and brings the document to the human for confirmation and acceptance. In a traditional engineering setting, the DBM carries the corresponding design basis. The accepted document is a result of the conceptual phase and an input to FEED.

In the editor example, conception establishes the intended review experience, what must be preserved, and the limits of the initial undertaking. Investigations may clarify whether the existing editing model can support those intentions. The PRD records the requirements and the position reached, including design questions left for later work. Its required depth follows the project's nature and the consequences of proceeding on that basis, as discussed in §1.6.

FEED: decomposition and project setup

Definition and preparation develop the accepted PRD or DBM into packages and deliverables. Decomposition divides the accepted scope into identifiable contributions. A package groups a defined portion of project scope. A deliverable is an identified unit of committed output with a scope and a basis for assessing it. The human examines whether the proposed division preserves the intent, covers the accepted scope, and gives the work intelligible responsibilities.

In the editor, the proposal-review capability may require an interface definition, review-and-application behaviour, changes to editing history, and connected verification. Their division into deliverables should make each contribution and its relationship to the intended result understandable. The executor's immediate assignment may be smaller. An investigation, implementation assignment, or review can contribute to a deliverable without becoming another item in the durable decomposition.

Project setup turns the accepted decomposition into a working environment. It establishes identifiable places for package and deliverable work, preserves their identifiers, and supplies the relevant context, status, source references, and initial working documents. It establishes where coordination, decisions, and continuation records will be maintained. A participant arriving at a deliverable should be able to find its scope, governing material, responsibility, and present condition.

The normal sequence is therefore shared intent, PRD development and acceptance, decomposition, and project setup. Production implementation begins after these foundations have been established. An isolated prototype or investigation can inform them while conception remains open; its earlier use does not give it the standing of a production contribution.

This is the initial course for the development undertaking described here. In an existing project, recover the accepted basis and completed preparation before deciding what remains to do. A repair, continuation, or bounded change does not restart conception and setup merely because it begins in a new conversation. Reopen only the affected decisions and proceed under the project's established responsibilities and change procedure.

30%: establish the means of execution

The next phase establishes how the deliverables will be developed and how their contributions depend on one another. Dependency mapping usually follows setup, when local scopes, specifications, and references can be read together. Some relationships will already appear in the PRD or decomposition. Mapping gathers them, examines further relationships, and records their grounds. The project DAG is formed from this work. Section 1.9 explains how it is read and used.

Closely coupled questions receive concentrated attention during execution definition. The editor's document revision, proposal application, and undo entry may each depend on decisions about the others. The team examines those relationships, defines workable interfaces, and establishes who will coordinate and integrate the affected contributions. Bounded implementation may help establish a proposed arrangement after setup, under the accepted basis and authorised scope.

The directed development loops construct and examine the first project DAG before passage through the 30% gate. That result gives the team an execution structure against which it can organise more detailed work. This includes what inputs a deliverable needs, how they will become available, and where the work needs sustained coordination. An initial map can expose cycles or incomplete relationships. Their treatment must preserve the engineering meaning of the dependencies; deleting an inconvenient arrow supplies no missing interface agreement. The accepted graph and recorded unresolved matters together establish what the next phase can use.

60%: develop the details and their relationships

Detailed development works out how the Deliverables will satisfy their requirements and dependencies. Local work graphs select routes through the project DAG and develop those routes into executable undertakings. Managers carry the work through design elaboration, implementation, checking, repair, and reconciliation. Independent scopes can proceed concurrently where their inputs, write boundaries, and shared resources permit. The project retains named responsibility for integration as that concurrency grows.

Findings during 60% commonly warrant successor versions of the project DAG. Carry each through the applicable source amendments, dependency examination, and human decisions. The human judges the end of this phase from the remaining route: further structural changes are no longer anticipated, although evidence can later require reconsideration. The same local-graph method then supports the longer undertakings of the 90% phase.

For the editor, the shared revision and history definitions can support separate work on preview, application, undo, and connected test scenarios. Each contribution develops its details against the agreed relationships. Findings can reveal that an interface needs further attention or that the current division leaves an integration problem without an owner. The manager carries those findings back into the work, and the human judges consequential changes to the accepted basis.

An insufficiently developed PRD may become troublesome here or in the movement from 60% to 90%. Contributors can elaborate different interpretations of an unresolved requirement, leaving the project to reconcile them after substantial work has been performed. That outcome is possible rather than inevitable. Familiarity, limited scope, and early coordination may allow a modest PRD to serve well. The phase reviews should examine the actual position, including whether unresolved questions are becoming embedded in several dependent designs.

90%: carry the details through to produced deliverables

Completion and reconciliation pursue the developed details to their culmination in the Deliverables. The established route permits substantial undertakings over many assignments and sessions. Implementation is completed, defects are repaired, dependent contributions are brought together, and the evidence needed to assess them is assembled. A bounded documentation and governance closeout connects the current account to the integrated result before the undertaking's final PR. The human continues to steer priorities, approaches, resources, and consequential decisions.

At the end of 90%, the emphasis changes from developing the planned capabilities to testing and debugging the produced product. Testing has accompanied development throughout; the later examination concentrates on its intended use. An agent with suitable Computer Use capabilities can conduct substantial scenario sets under human direction. The human judges the adequacy of the examination and the proposed reliance. The organisation’s 100% pipeline then carries the approved version into publication.

A local test of the editor's preview may pass while the connected sequence of editing, preparing a proposal, applying it, undoing, saving, and reopening exposes defects. These journeys should be exercised as soon as they become operable. As the project approaches completion, their coverage and the identity of the combined candidate become increasingly important to the account of what has been produced. The 90% position concerns produced Deliverables and the transition into concentrated product examination. Publication follows under its own approved pipeline.

100%: carry produced work into delivery

Delivery and handover encompass the steps between produced deliverables and a product available for its intended use. For software, these can include preparation of an identified release candidate, the applicable acceptance and release decisions, packaging, distribution, and transfer of continuing responsibilities. In another domain, the artifacts and delivery operations will differ. The management question remains what must occur for the produced work to become the result that the recipient is entitled to use.

A software build assembles the application into an executable form. A merge combines source changes. Each may complete a useful operation within delivery, while acceptance, publication, or handover remains outstanding. Report those conditions separately. The concluding account identifies what has been delivered, what limitations remain, and who is responsible for subsequent support, recovery, and change.

Stage gates and uneven progress

The owner steers consequential phase transitions using an account of what has been established, what remains unresolved, and what the next work would rely upon. Agents prepare that account from the actual contributions and evidence. A passing test, an empty queue, or a graph without cycles can inform the human's judgment. Their significance depends on the scope and completeness of what they represent.

An executor's assignment may be complete while its deliverable still requires integration or review. A deliverable may be substantially written while some material claims remain unsupported. Other deliverables may already be accepted. A late finding can return one part of a project to a design question while the rest remains in completion and reconciliation. Identify the affected scope, preserve the basis that still applies, and organise the work required to bring that part back into the whole. Project stage, deliverable state, and grounds for reliance should remain distinguishable in the record.

A project can also be reduced, suspended, or ended with objectives unmet. Its concluding account must preserve what was accomplished and what was not, together with the decisions about remaining work. A change in scope may be a sensible response to what has been learned. Success against the revised undertaking must remain distinguishable from achievement of the original one.

1.8Organising the roles around the work

The method uses four roles to keep alignment, design, managed execution, and bounded contribution recognisable as the work changes. HELP_HUMAN is Type 0; HELPS_HUMANS and WORKING_ITEMS are Type 1; TASK is Type 2. Agent 0, 1, and 2 are shorthand for these Types. They classify responsibility, independently of model capability or the depth at which an instance happens to be delegated.

These are the complete standing roles in the method. Technical specialisation is supplied by assignments, context, workflows, skills, and tools. The number of instances and their working arrangement can change without adding another permanent role.

HELP_HUMAN maintains alignment with the human and continuity across undertakings. In the editor example, it keeps the review feature connected to the wider application, brings relevant earlier decisions into consideration, and coordinates contributions from the managers. It notices when findings change the question that the project is trying to answer. Where an investigation is independently bounded and its return can be assessed directly, HELP_HUMAN can dispatch TASK without adding a manager to that assignment.

HELPS_HUMANS works with the human on conception and design. It develops interpretations and proposals, examines the categories and commitments they imply, and gives the human concrete material to refine. It helps author the PRD from the shared understanding of intent and prepares the document for human examination. Its work continues when implementation reveals a question that changes the design. For example, discovering that proposal application can invalidate the existing undo sequence may require renewed consideration of what the user should experience and what the feature promises.

WORKING_ITEMS carries a bounded undertaking through implementation and owns its integrated return. It can coordinate decomposition and project setup as well as production implementation. During conception, it may also manage an authorised investigation or isolated prototype that needs sustained coordination. These assignments retain their stated purposes and do not bypass the PRD and setup sequence. It assigns bounded work, checks returns, and examines interfaces and remaining dependencies. Design-changing questions return through the human or HELP_HUMAN to HELPS_HUMANS. The manager should describe the finding, its consequences, and the next contribution it recommends.

TASK performs one bounded assignment. The same role can inspect source material, implement an accepted design, exercise a workflow, or review another contribution. Its brief identifies the purpose, context, permissions, outputs, and checks for that instance. TASK applies a selected workflow when one is supplied, exercises discretion within its boundary, and returns the result with evidence and unresolved matters. It does not delegate. Coordination needs return to the caller, who must relate the contribution to the larger undertaking.

Consider the difference between two assignments in the example. A read-only inspection of the existing undo tests can be dispatched directly and checked against its stated question. Developing the connected proposal-and-apply behaviour may require repeated exchanges among implementation, testing, and repair. A WORKING_ITEMS manager can own that continuing coordination. Several executors can contribute, but the manager remains responsible for checking how their results work together. Otherwise the human receives separate completions and must reconstruct an integration assignment that nobody was given.

The working arrangement therefore changes with the project. Early attention is concentrated in the conversation and its investigations. As the basis develops, managers and executors can carry larger bodies of work forward. During completion and reconciliation, the same repertoire supports focused repair and examination of a common candidate. The human may engage either manager directly, and every undertaking need not instantiate the full hierarchy. Choose the arrangement by the responsibility that needs to be maintained.

One human and a few agent instances can carry these responsibilities on a small project. A continuing design partner can prepare the basis; a bounded executor can implement a contribution; a fresh reviewer can examine the candidate. The human can coordinate those returns directly where their relationships remain manageable. A separate working manager becomes useful when repeated assignments, coupled interfaces, or concurrent work require sustained integration. The four responsibilities remain recognisable without requiring four agents to be active at every stage.

Model capability and reasoning effort are separate choices. A difficult bounded review may warrant more capable execution than routine coordination. That allocation does not change the reviewer’s role, enlarge its authority, or establish that its conclusion is correct. Likewise, a fresh review instance can examine another instance’s work, but its independence depends on its assignment, preparation, and relationship to the candidate. Its report supplies further material for assessment.

The role name describes a responsibility within the agent arrangement. It does not appoint an artificial agent as an accountable professional or remove the human's judgment. Research, decomposition, setup, testing, and review are performed through these same roles using the relevant methods and briefs. A workflow supplies a way to perform the work; it does not create another permanent agent role.

1.9Responding when the work changes the basis

Development exposes differences among what the project intended, what the team built, and what the record says. Begin by determining the nature and extent of the difference. The response may require correction of the implementation, correction of a record, further investigation, or a decision to amend an accepted commitment. More than one kind of correction may be needed in the same episode.

Suppose a later integration test shows that applying a proposal overwrites a manual edit made after the proposal was prepared. The accepted requirement prohibits silent loss of that work. A previous report says the requirement was satisfied. The manager should first identify the candidate now being exercised and the basis of the earlier report. Perhaps the earlier tests covered rejection but omitted application after an intervening edit. Perhaps the behaviour changed after those tests. The recorded claim and its applicability need examination alongside the defect itself.

Where the requirement is clear and the observed behaviour violates it, the implementation must be brought into conformity within the applicable authority. Preserve the failed result and organise repair, review, and renewed testing of the affected behaviour. Correct any overstatement in the current account of coverage while retaining the earlier record as history. The defect does not supply a reason to weaken the requirement merely because the original implementation was convenient.

A request to retain pending proposals after closing and reopening the application presents a different question. If that capability was outside the accepted undertaking, adding it changes the commitment and may affect saving, proposal identity, recovery, and tests. The agent can investigate the consequences and prepare a recommendation. The human must decide whether the project should take on that work and on what terms. Where the accepted decomposition must be amended, use the project's change procedure to examine the impact, accept the exact amendment and its consequences, and check the resulting state.

A third situation arises when a handoff describes the reopen capability as accepted, but the cited source contains only an agent proposal. The team must recover the actual direction before treating it as authority. A plausible recollection or a later summary cannot establish that the human made the decision. The proposal can remain useful for consideration, and existing work should be preserved with its actual status. The affected commitment remains unresolved until a sound basis for it is established.

In each case, locate the work that depends on the disputed matter. An interface question may require pausing a particular implementation while independent investigation or documentation proceeds. Give the affected work an owner and a route back into integration. Keep the decisions that remain applicable, and reopen only those whose grounds or consequences have changed. This allows the team to revisit design without treating every discovery as a restart of the entire project.

Reading dependencies and following consequences

A dependency is a relationship under which one contribution bears on another. For management, the statement needs to explain what is required, by which contribution, and for which part of its work. “Application depends on editing history” is incomplete. It could mean that the apply design needs a definition of history entries, that its implementation needs an existing operation, or that connected verification needs both components available. These relationships create different conditions for proceeding.

A graph represents the contributions as nodes and their relationships as connecting edges. In a dependency drawing, the nodes are usually boxes and the edges are lines with arrows. The direction must be stated. Figure 1.1 uses an arrow from the contribution supplying a required input to the contribution using it. A points to B because B needs an output from A for the dependent result shown. Some software registers record dependencies in the opposite direction, so the convention must be checked when reading another representation.

A directed acyclic graph, abbreviated DAG, has directed edges but no directed path that returns to its starting node. Following the arrows in Figure 1.1 always moves toward a dependent result. A project manager familiar with a logic-linked network schedule will recognise the precedence relationship. This drawing contains no durations, resource assignments, or dates; those would require further information before it could support a schedule.

Figure 1.1. A simple dependency graph after the shared interface has been resolved. Boxes identify illustrative deliverables. Arrows run from a supplier of required input to its consumer: A → B, A → C, B → D, and C → D. The labels A–D are local to the illustration. They are not project identifiers. Preparatory work may proceed where its own inputs are available.

Here, A establishes the shared definition of document revision and history entries. B uses it to develop proposal review and application; C uses it to develop the corresponding history and recovery integration. Once the required definition is available, B and C may proceed in parallel where their assignments and working boundaries permit it. D requires their combined behaviour for the connected scenarios it must exercise. Planning those scenarios can begin earlier, but completing that verification depends on having the relevant behaviour available.

The graph is developed from the project's sources. The accepted decomposition supplies the identified deliverables. Their scopes, specifications, and local dependency records supply the relationships, with references to the material supporting each one. An agent can extract a stated relationship or propose an inferred one. The distinction must remain visible during examination. A tool can collect the records and check their structure, but it cannot make an unsupported dependency true by drawing an arrow.

A composition tree and a dependency graph give different information about the same deliverable. The tree shows which package contains B. The dependency graph shows what B needs and which other work uses its result. Contributions in different packages may have a close production relationship. Contributions in one package may be sufficiently independent to proceed separately. The organisation of execution should take account of both relationships.

Two further views help recover what the work means. A source and decision network connects claims to evidence, constraints, provenance, and supersession across folders. Attention brings the material relevant to a present question into consideration through comparison, decomposition, and synthesis. Its traces include briefs, decisions, and outputs. Choose the views needed for the question. A dependency inquiry may require the graph and a cited decision; an investigation of intent may need the original exchange and its later corrections. Git ancestry supplies change history, while the cited records establish production dependencies and accepted authority.

Coupling, readiness, and change

The first mapping may contain cycles. Suppose B is defined as waiting for the completed recovery design in C, while C is defined as waiting for the completed apply design in B. Taken literally as prerequisites, neither can proceed first. The team needs to examine whether the nodes are too broad, a common interface remains undefined, a relationship has been classified incorrectly, or the work needs to be developed together.

In the illustration, a shared interface deliverable A allows the required agreement to be made explicit. B and C can then use that agreement rather than each waiting for the other's finished design. That arrangement must be justified by the actual engineering relationships. Creating a new box or deleting an arrow would not resolve a disagreement about the contents of the interface. Where the resolution amends accepted decomposition, carry the amendment and its consequences through the project's change procedure.

For current execution, read the graph to find which required inputs are available and which dependencies still block the work under consideration. Availability must include the appropriate standing of the input. A file can exist while its relevant content remains unexamined or superseded. For closure, examine a wider question: whether the applicable commitments, interfaces, evidence, and remaining obligations have been accounted for. An empty list of current blockers does not establish that the whole undertaking is complete.

The project DAG describes deliverables and their production dependencies at the level of the project. The local work graph describes the smaller assignments, discoveries, blockers, and integration points of a current undertaking. It can carry that undertaking across many development sessions. It gives each incoming participant a current account of the work being continued.

If a later requirement changes the state that A must preserve, B and C become candidates for impact examination, and D's evidence may need reconsideration. The arrows help locate those consequences. They do not prove that every dependent item must be rewritten. The team examines what changed, records which earlier work remains applicable, and organises the necessary redesign, repair, or checking. This is one way an early human decision can continue to shape work far beyond the conversation in which it was made.

Local work graphs change as execution proceeds. The broader project DAG can also acquire successor versions during 60% as the delivery route becomes clearer. Its revision follows the accepted basis and change procedure; a changed local node does not by itself require another project DAG. Preserve discoveries, departures, and uncertain mappings until their appropriate treatment is established.

Ordinary pending work has a place in a local graph, including work awaiting an input or a human decision. Reserve deferred work for a concern that cannot presently find a home there. Preserve its source and the missing allocation or precursor for examination at the owner's direction. A register helps the owner decide whether and where to take up those concerns. Maintaining it does not introduce another entry gate for development. Chapter 5 explains this last-resort route.

The ordinary sequence completes the intended implementation and evidence integration before its planned documentation/governance closeout. A proposed departure from that closeout requirement needs the owning human decision: identify the affected scope, substitute completion terms and surviving record obligations. The original commitments remain in force until amended.

The recurrence of work does not contradict an acyclic representation of its prerequisites. A later finding can give rise to a new investigation or revised contribution, with a new set of inputs and obligations. The project records how that work relates to the earlier result and which decisions change. Updating the local graph does not itself amend project commitments or authorise a phase transition.

1.10Carrying the undertaking through successive development sessions

Continuity begins while shared intent is being developed into the PRD. The conversation carries examples, corrections, and reasons that must acquire a durable expression before other participants can use them. Record consequential decisions and their grounds while the work is underway. Keeping the same agent context through conception and setup can help preserve the discussion, but the project must also be able to continue after an interruption.

A session is a period of interaction with an agent in its host. Its context is the material supplied to that instance, including instructions, conversation, file contents, and tool results. A fresh session establishes its position from the material supplied at entry and the records it reads. Those records must identify the undertaking, its basis, and the actual work available for continuation.

During execution definition toward 30%, the human's direction concentrates the team on dependencies and coupled questions. In the subsequent phases, local graphs develop routes through the project DAG into executable undertakings. The continuing method must support both positions. An interruption before setup is complete does not make the missing preparation exist. Record the point reached and direct the incoming participant to the decisions, drafts, and work actually present.

Direction and working records

A fresh session needs a dependable route to the project, applicable instructions, and selected undertaking. It also needs the human's present objective and limits. Keep these functions distinguishable. A recurrent entry procedure can remain stable while priorities and assignments change. A previous agent's recommendation must remain distinguishable from a human direction.

For example, the owner may direct the team to map dependencies among the accepted deliverables, preserve their scope and identity, and return the coupled questions with a proposed execution route. That direction supplies a result, a basis, and a limit. It need not rewrite the procedure for all later sessions. Another direction may authorise implementation or concentrate attention on a verification gap. Retain the terms and reasons that materially affect the work.

Continuation requires an account of the selected undertaking, its accepted basis, work already performed, and matters still outstanding. A local graph can bring that position together and point to the PRD, decomposition, project dependencies, decisions, deliverable records, evidence, and retained returns. Preserve a useful existing arrangement. A new conversation need not create a new graph or repeat every earlier record.

A handoff explains a position to a successor. It is useful when an interruption or transfer leaves facts that the ordinary working record does not yet contain. It should identify the relevant work and explain what requires examination, rather than reproduce an entire archive. The successor still compares the account with the actual candidate and current direction.

The recurrent sequence

The recommended loop carries an undertaking from orientation through execution and reconciliation to its next useful result. Figure 1.2 shows its six steps. Before a first project DAG exists, the same responsibilities support dependency examination and resolution of coupled work. Once a DAG is available, the loop develops and carries out local routes through it.

1. Orient and recover
2. Construct or revise the local graph
3. Organise and advance ready work
4. Execute, verify, and record the result
5. Close documentation and governance; record the run
6. Complete the graph and merge the final PR

Figure 1.2. The recommended six-step development loop. Its operations recur within the project phases. The order follows their dependence on an intelligible current position and a bounded assignment; implementation and examination advance through the graph, followed by one bounded closeout and final integration.

The steps may be carried within one session or spread across several. Implementation and examination continue as their inputs and results require; the documentation and governance closeout follows the completed result. Orientation must establish enough of the position to support the next assignment. Required inputs must be available before dependent work proceeds. Review can occur alongside independent execution. The bounded closeout follows the implementation and evidence work; a finding returns affected work to the graph or its owning decision. Chapter 4 develops this arrangement in more detail.

Orient and recover. Read the current work record and latest direction, then compare their material claims with the working files, named unmerged changes, and referenced evidence. Edits or test results may have followed the last update. Confirm that earlier workers have stopped, or transfer their ownership explicitly, before reassigning files or shared test resources. Preserve useful work while its state is established.

An incomplete or missing record requires investigation. Recover the intended result from the human's direction, conversation, and relevant project records. Where that basis is adequate, state the interpretation and organise the work within the authorised scope. Seek a decision where an unresolved matter would materially change that scope, the course of the work, or its completion conditions. Historical records can help recovery, but their age or prominence gives them no authority over current direction.

Construct or revise the local graph. Interpret the intended result, examine its relationship to the project dependencies, and inspect the corresponding deliverables and actual work. Define the contributions required to reach that result. Include investigation where an answer is needed before implementation, and include review, integration, and reconciliation where completion depends on them. Preserve an existing graph's identity and useful results when the undertaking continues.

Each contribution needs an outcome, prerequisites, scope, permitted writes, and completion evidence. A broad implementation intention becomes executable when these are sufficiently definite. Keep its relationship to the deliverables it serves. Examine a scope or dependency mismatch before treating the proposed relationship as settled.

Organise and advance ready work. Assign contributions through the responsibilities described in §1.8. The working manager owns the internal coordination and integrated return of its undertaking. The coordinating role relates undertakings to the human's purpose and to one another. A bounded executor returns its contribution without adding a further delegation layer. An independently assessable contribution can be managed directly.

Technical independence, write ownership, and shared resources determine useful concurrency. Two branches can have separate files and still rely on one unsettled interface. Two tests can have separate source trees and still compete for the same application window. Give those shared matters a definite arrangement. Select model capability and reasoning effort for the particular assignment, independently of its role.

Execute, verify, and record the result. Carry the assignment through the work its conditions require. Retain the actual brief, source basis, changes, checks, limitations, and returned evidence. Apply the project's examination and independent-review requirements to the candidate being integrated. A completed check and a satisfactory result are separate facts: a check can run correctly and find a defect.

Exercise changed user activities as soon as they become operable. Tools for controlling an application can carry substantial test execution under human direction. Preserve the identity of the running candidate, starting conditions, actions, and observations. The responsible person examines whether the evidence addresses the requirement and supports the intended use. Chapter 5 develops that relationship for a produced product.

Close documentation and governance. After the undertaking's intended implementation and evidence work, compare the affected deliverable statements with implementation, decisions, and evidence in both directions. Make warranted corrections within the assignment and preserve outstanding obligations. The production contract retains stable commitments and evaluation relationships. Detailed mechanisms remain in supporting technical records unless they are themselves adopted or depended-on choices. Here reconciliation means bringing the project record and work into agreement; it does not refer to automatically merging an editor proposal with a changed document.

Perform this bounded closeout once for the undertaking, after the intended implementation/evidence integration (normally the penultimate merge) and before the final PR. Ordinary document changes needed to perform an implementation remain production work. Closeout applies the warranted documentary and governance consequences of the combined result. Missing required work returns to production and receives an affected backcheck. A finding that changes scope or an accepted commitment follows its owning decision procedure. A substantive PR or the final closeout can route a material concern without an executable home through the same conditional Task Management process. Link the actual transfer or pending intake from its originating PR and graph node.

Complete the graph and merge the final PR. Advance through ready authorised work while the selected purpose remains applicable. Refresh the record at meaningful results and transfers. Identify the current candidate, local changes, outstanding checks, active operations, evidence locations, blockers, and next action. A successor can then establish the position from that record and the actual work.

Near final PR preparation, add a terse MEMORY run entry in each affected Deliverable: what the run did here and pointers to its PR, central evidence, decisions and transfers as applicable. Complete the graph's promised work, closeout and applicable checks and decisions. The development loop ends when its final PR merges. The candidate may state ready for final merge and cite the PR; Git or the PR service establishes the later merged state. Deliverable issue and product publication retain their own authority.

Preserve a usable position

The current record should explain the next action without becoming a second archive of every observation. Retain detailed evidence and executor returns at their identified locations. A concise entry can preserve the relationship among the commitment, work, evidence, and outstanding examination.

Example — a repair awaiting examination. The editor's application check failed after an intervening manual edit. A repair now refuses application when the live and source revisions differ, and the previously failing scenario passes on the changed candidate. Independent review and the affected history scenarios remain outstanding. The continuation record identifies that candidate and its test evidence, assigns the outstanding examination, and states whether any earlier worker or shared application session remains active. It reports a prepared repair, with its remaining work, rather than a completed undertaking.

If the owner changes priorities, preserve that outstanding examination. If another edit changes the candidate, identify which review and test results still apply. If work is interrupted, inspect the actual state before resuming. A handoff can preserve an unfinished diagnosis or an active external operation that the main record has not yet captured.

This practice preserves the information needed both to continue the work and to question it. The entry procedure locates the undertaking, the human's direction sets its present purpose, and the graph describes its route and condition. Production contracts, decisions, and evidence retain the grounds on which that route is pursued. Later participants can continue from an intelligible position and bring forward a corrected interpretation when new evidence warrants one.