# Project Management for Human Agent Teams

## Purposeful work with capable agents

Edition 9

Ryan Tufts

## Authorship and use

This manual develops the owner's approach to professional knowledge work with artificial agents. Agents assist with interpretation, drafting, comparison and revision. The owner determines the intended meaning and decides what to accept and publish.

The method concerns responsibility, knowledge and action. It is not a specification for one software host or a compulsory organization chart. Its recommendations require examination in the conditions of use. Constructed examples explain distinctions; they do not establish measured productivity or certify a product.

The primary readers are people directing substantial work with agents. A programmer may need help organizing contributions and integration. An engineering manager may need to distinguish an agent's useful reasoning from the human responsibility for reliance. Both need a way to carry work to a usable result without making administration the result.

The [Field Book](Project_Management_for_Human_Agent_Teams_Field_Book_v2.md) is a shorter decision and navigation aid. The [Agent User Manual](CHIRALITY_AGENT_USER_MANUAL_v4.md) explains repository application. The [manual index](README.md) identifies current editions. Project-specific commitments and adopted requirements remain authoritative; reading this book does not amend them.

## Contents

1. [Purpose and accountable reliance](#ch_1)
2. [A basis that supports action](#ch_2)
3. [Contributions and their relationships](#ch_3)
4. [Ownership and coordinated execution](#ch_4)
5. [Evidence and examination](#ch_5)
6. [Change, records and recovery](#ch_6)
7. [Development positions and decisions](#ch_7)
8. [Completion and delivery](#ch_8)
9. [Improving the course of work](#ch_9)
10. [A worked undertaking](#ch_10)
11. [Two contrasting cases](#ch_11)
12. [Working vocabulary](#vocabulary)

<a id="ch_1"></a>

# 1. Purpose and accountable reliance

## 1.1 Start with the activity that must become possible

A project brings contributions together so that someone can use a result. The intended use gives those contributions their purpose. A list of completed tasks does not establish that purpose has been served.

Suppose a person wants to review proposed edits to a document before applying them. “Build a review panel” names a possible implementation. It does not yet establish which changes must be visible, which decisions the person controls, or what happens to rejected changes. Those questions define the useful result.

Begin with the person, activity and conditions. What must the user understand or do? What must remain protected? Which failure would make the result misleading, unusable or unsafe? These questions help separate a desired outcome from an early solution.

The answer need not be complete before useful work begins. A small experiment may clarify the activity. An existing interface may reveal a constraint. Investigation is productive when it resolves a question that changes the next action or decision.

Avoid treating a broad objective as permission for every related improvement. The assignment identifies the work currently authorized. New opportunities can be proposed without becoming hidden completion conditions.

## 1.2 Work received from another

An agent is an other whose contribution a person receives and may use. The agent can investigate, interpret, propose and act without the person performing each operation. That capability creates useful distance between directing work and executing it.

It also creates a need for examination. The person may not know which sources the agent used, what it assumed or how it interpreted a requirement. A confident return does not resolve those questions. The required examination follows the claim, use and consequences of error.

A person can rely on a bounded contribution without redoing every operation. A traceable calculation, a meaningful test or an independent source comparison may supply the needed warrant. Conversely, a polished report may leave the essential claim unsupported.

This manual uses **reckoning** for the agent's interpretation, comparison, inference and selection. It reserves **accountable judgment** for decisions for which a person accepts responsibility. These terms distinguish responsibility; they do not deny agents substantial reasoning or initiative.

Human accountability does not require human approval of every action. The person can authorize coherent work, ordinary choices and defined operations in advance. Reserved choices remain visible at their actual points of need.

## 1.3 Four perspectives on the same work

Ontology, epistemology, praxeology and axiology are connected perspectives. They help participants examine the work rather than merely name its parts.

**Ontology** asks what exists in the undertaking and how those things relate. A requirement, a proposed design, an implementation, a test result and an acceptance decision are different things. Confusing them produces practical errors. A code branch is not an accepted requirement. A graph node is not necessarily a deliverable.

**Epistemology** asks what supports a claim. A test may establish one behavior under specified inputs. A source may support a definition but not a numerical equation extracted from it. Agreement among agents can show consistency without proving their common assumption.

**Praxeology** concerns the course of action. How does an input become a contribution, how is that contribution examined, and how does it reach the user? A method is incomplete when it produces private successes that nobody integrates.

**Axiology** concerns purposes, values and consequences. Two designs can satisfy the same narrow test while differing in maintainability, user control or consequences of failure. These considerations guide which uncertainty is worth investigating and which decision belongs to the person.

The four perspectives do not require four documents or four review rounds. They are ways to inspect one undertaking. Their value appears when they expose a distinction that changes what someone does.

## 1.4 Capability and authority

A role describes a contribution. An assignment supplies the present objective and limits. A workflow provides a method. A tool performs an operation. The host supplies actual capabilities and enforces some permissions.

None of these elements alone establishes all the others. A tool may exist without authorization to use it for the current purpose. A written prohibition may be instruction-asserted rather than mechanically enforced. A prepared launch prompt does not establish that a child agent ran.

State boundaries accurately. Do not describe instruction compliance as a technical guarantee. Do not treat a broad host capability as permission to exceed the assignment. When a required capability is absent, identify the specific effect and continue work that does not depend on it.

The same discipline applies to acceptance. The agent can prepare a recommendation and its evidence. It cannot attribute an approval to a person who did not give it, or broaden a decision beyond the subject actually considered.

## 1.5 Initiative within a continuing relationship

Agent 0's responsibility is continuity with the person: understanding purpose, keeping consequential choices visible and relating current work to the wider undertaking. Other roles can assist, but their participation is not a required sequence.

A session can discuss a design, investigate a detail, implement a bounded change and examine its result. It need not create a new agent for each kind of thinking. Delegation becomes useful when another contribution can proceed independently, needs distinct preparation or improves assurance.

The relationship develops as evidence changes the question. A person can discover that the requested feature does not solve the original problem. An agent can expose a consequence the initial wording did not address. Useful continuity preserves the distinction between the person's commitment and the agent's interpretation.

Alignment therefore depends on more than a complete instruction file. The person and agent need concrete work they can inspect together. A prototype, proposed requirement or actual failure can improve understanding more than another abstract statement of intent.

<a id="ch_2"></a>

# 2. A basis that supports action

## 2.1 What a project basis must do

A project basis lets participants act toward the same result without inventing missing commitments. It identifies intended users, outcomes, scope, constraints, interfaces, exclusions and acceptance responsibilities. It also identifies what remains unresolved.

The document form follows the undertaking. A substantial engineering product may need a PRD, a design basis and specialist companions. A bounded improvement to an existing product may need only a clear assignment and the affected current requirements.

Do not create a new project definition merely because a new session begins. Do not treat an informal request as sufficient when the intended use or consequence requires a more explicit basis. Scale the representation to the decisions and coordination it must support.

A basis should distinguish enduring commitments from proposed mechanisms. “The user can recover the accepted document after an interrupted save” is a behavioral commitment. A selected transaction mechanism may be a design choice, unless a governing source specifically requires it. Keeping that distinction allows implementation to improve without disguising a scope change.

## 2.2 Establish what each source can support

A source is useful for particular claims. Its existence, title or acceptance does not make every possible inference from it valid.

A user interview can support an account of the reported activity and needs. It does not prove that a proposed implementation will work. A benchmark can support a result for its actual candidate, inputs and environment. It may not support another platform or operating range.

Extracted material requires particular care. A reliable source document can produce an unreliable machine extraction. Tables can lose units; equations can lose symbols; diagrams can lose relationships. Evidence about the original source does not automatically establish the fidelity of its derivative.

Record enough source identity and location to let the relevant claim be examined. A source path and section may suffice. Exact bytes or hashes are appropriate when a consumer needs content identity. They are not a substitute for reading or interpreting the source.

When sources conflict, identify the conflicting claims and their standing. Some differences are changes over time, different scopes or different meanings of the same term. Others require a decision. Do not resolve a consequential conflict merely by selecting the newer file or the more confident statement.

## 2.3 Write requirements that preserve meaning

A requirement states a needed result or constraint. It should identify a meaningful condition whose fulfillment can be examined. It should not hide an unresolved decision inside apparently definite language.

Consider “the application shall handle large documents efficiently.” The statement leaves the document size, supported activity and acceptable behavior undefined. Those may be legitimate open matters, but the text should identify them rather than imply that a usable criterion exists.

Requirements also need context. A fast preview that changes the saved model may violate the user's intent even when its speed is acceptable. State the protected behavior and the condition under which the requirement applies.

Avoid incidental detail that will become stale without any change in obligation. A transient file count or implementation line number rarely belongs in a durable production contract. Retain a specifically adopted mechanism when its selection is itself a commitment.

A requirement can remain partly open. Identify the missing value, its consequence, the means of resolving it and the work that depends on it. Do not fill an engineering value merely to complete a template.

## 2.4 Separate commitments, assumptions and proposals

A commitment governs work through an applicable decision or source. An assumption is a provisional basis for reasoning. A proposal is a candidate choice. An observation reports what occurred under identified conditions.

These distinctions survive permission to proceed. A person may authorize a prototype using an assumed operating range. That authorization permits the experiment; it does not establish the range as a product requirement or prove the assumption true.

Keep the uncertainty at the level where it matters. An unresolved color choice need not block a persistence test. An unresolved coordinate convention can invalidate dependent numerical work. Describe that dependency rather than applying a global “blocked” label.

The useful question is what the next work will rely on. Some unknowns can be investigated in parallel. Others require a decision before dependent production expands. The person can accept a stated qualification where the governing context permits it.

## 2.5 Prepare the decision before requesting it

A reserved choice should be concrete enough to inspect. Describe the current basis, alternatives, recommendation, consequences and remaining uncertainty. Include the proposed text, interface or artifact where feasible.

Separate distinct acts. Choosing a design, permitting an experiment, accepting a candidate and releasing a product have different effects. A generic request to “approve” can obscure which act is intended.

The person does not need another prompt for a choice already made. Apply the decision to its current governing source and follow its actual consequences. If later evidence invalidates the basis, bring that change back with a clear explanation.

A decision record should preserve the decision and its conditions, not produce an additional narrative of every operation. Its location should make it discoverable by the work it governs. History belongs in the version system or other established record mechanism.

## 2.6 Check the assembled basis

Independent sections can be individually sound but collectively inconsistent. Before relying on the assembled basis, inspect its terminology, coverage, interfaces and open matters.

Follow a representative user activity across the relevant requirements. Does every required operation have an owner? Does one section promise behavior another excludes? Are terms such as “saved,” “accepted” or “current” used consistently?

A structural validator can identify malformed fields or missing references. It cannot establish that the requirements express the intended product. Source comparison and informed examination address that different claim.

Once the basis is adequate for the next work, preserve its identity and unresolved conditions. Do not require complete certainty about later details merely to authorize a useful bounded next step.

<a id="ch_3"></a>

# 3. Contributions and their relationships

## 3.1 Divide by responsibility

Decomposition assigns coherent responsibilities. It is not merely division into smaller files or more agents.

A Package groups related scope under a meaningful objective. A Deliverable identifies a contribution with a usable boundary. An assignment is the work currently given to a participant. These can have different sizes.

An agent may work through several connected sections of one deliverable while another participant examines a completed portion. Integration can combine several stable contributions. The working unit need not equal the assignment or the merge batch.

Give every scope item an accountable treatment, including exclusions and unresolved items. “Out of scope” does not mean “unaccounted for.” It identifies a boundary whose effect on the intended result may still require explanation.

Avoid duplicated responsibility. If two deliverables both claim the same interface, identify which defines it and which consumes it. Shared code does not itself resolve that ownership question.

## 3.2 The deliverable production contract

A production contract connects intended contribution, required outputs, governing requirements, interfaces, examination and evidence. It lets the producer and receiver understand what will count as a useful result.

A ScopeOfWork can hold this contract. Design material explains the selected realization. Dependency declarations state required inputs and their conditions. Code, drawings, calculations or other outputs supply the result itself.

The contract must remain useful through implementation changes. It should preserve the required behavior without copying every incidental mechanism. A specifically accepted algorithm or interface is not incidental merely because it is detailed.

Define production and examination together. If a claim cannot be examined by the proposed method, either the method is incomplete or the claim is too broad. A deliverable that produces a valid schema may still fail to preserve the meaning of the source it represents.

A useful connection is:

```text
Required contribution
  -> governing requirement or criterion
  -> examination that can establish it
  -> actual observation or result
  -> decision or permitted use
```

This connection need not become a separate table for every small change. Use a structured form where a real consumer needs it. Preserve the relationship without multiplying representations of it.

## 3.3 State needs from the consumer's position

A dependency is not merely a line between two named deliverables. It states what the consumer requires, from which supplier and at what point.

“Needs the persistence module” is weaker than “needs atomic replacement of the accepted document, with failure leaving the earlier saved state recoverable.” The latter states a condition that can be examined. It also helps the supplier understand the consequence of partial completion.

Distinguish a product relationship from an execution prerequisite. Two components may exchange information in the final product without preventing both from being developed against an agreed interface. Conversely, a test fixture can be a critical production input even if it is not part of the shipped product.

State gating only where the condition actually limits dependent work. A relationship does not become a blocker merely because it is recorded. Unresolved evidence should remain unknown rather than becoming a false satisfied state.

The consumer maintains its needs. A tool can derive reverse links to consumers, neighbourhoods, impact views and graph differences. These views need a known source revision and clear limits. They do not need to be copied into another maintained register.

## 3.4 Use graphs without assigning them authority they do not have

A graph expresses selected relationships for a purpose. It can help find order, missing targets, coupled groups or potentially independent work. Its usefulness depends on the meaning and completeness of its inputs.

A graph with no cycles can still omit necessary relationships. A graph with a cycle can describe legitimate mutual design. An edge can be correct at one level and too coarse to determine the next implementation step.

Use graph queries to locate relevant work, then inspect the conditions that matter. A present supplier file does not prove suitability. A passing test establishes only the condition it actually examines. A merged contribution does not automatically satisfy all its consumers.

A baseline may be useful for planning, a release or an external commitment. Preserve the accepted subject and conditions where such a decision exists. A routine change to a current declaration does not inherently require a new human acceptance of the entire graph.

The applicable project can impose additional gates. Those are project commitments, not automatic consequences of drawing a DAG. The general method should not silently add them to every undertaking.

## 3.5 Interpret cycles before changing them

A cycle can indicate coupled design, an overbroad contribution, a reversed contract, or an impossible production order. Identify which case applies before selecting a treatment.

One treatment separates a contribution into parts that need different inputs. Another defines an interface before either implementation depends on the other. Closely coupled work can be developed together under one integration responsibility.

Merging responsibilities or cutting a relationship can change scope. Such a change requires the applicable authority. Grouping work for coordinated development does not, by itself, merge deliverables or erase their obligations.

Do not narrow an accepted requirement merely to obtain a cleaner graph. Do not count a held relationship as resolved because it was excluded from a diagram. State what is still needed and which work can proceed without it.

A useful experiment can establish a consequential interface before the complete design exists. The experiment's result may then support independent implementation. Its limitations remain explicit; a temporary mock is not evidence that the final supplier already meets the condition.

## 3.6 Keep the working view local enough to act

Development rarely needs a global census of every past and present item. It needs the current objective, the affected contribution, its required inputs and the consumers of its changes.

A local view can be derived from current declarations and actual code or artifact changes. The agent can plan finer steps within the session. Persistent planning is useful where another participant needs it, but it should not repeat a status already available from the source.

Missing mappings and undeclared relationships remain possible. Treat tool output as an aid to inquiry, not proof that unrelated work cannot be affected. Inspect shared paths and interfaces where the consequences justify it.

Update the source when a relationship changes. Leave unchanged declarations alone. Repeated date refreshes or provenance re-pins do not improve the underlying relationship unless a consumer needs the new observation.

<a id="ch_4"></a>

# 4. Ownership and coordinated execution

## 4.1 Roles are available contributions

HELP_HUMAN maintains purpose and continuity with the person. HELPS_HUMANS develops conception and design. WORKING_ITEMS owns implementation and integration. TASK completes a bounded contribution without further delegation.

These roles do not prescribe a fixed staffing arrangement. The owner-facing agent carries Agent 0's responsibilities regardless of the role through which the session began. Other contributions are taken up or commissioned when useful.

A single session may complete a substantial coherent task. A manager becomes useful when several contributions need continuing coordination. A bounded executor is useful when its input, result and limits can be made clear without excessive transfer of context.

Model choice is separate from role. A difficult bounded review may need more capability than ordinary coordination. A deterministic operation may be better performed by a tool. Evaluate the whole assignment, including preparation, review and repair.

## 4.2 Keep an owner through ordinary repairs

Give a contributor responsibility for a result, not merely for the next isolated step. A coherent assignment includes the purpose, relevant basis, limits, checks and conditions that require another decision.

The assignment can be a conversation. A formal brief is appropriate when multiple participants, contractual conditions or recovery needs require it. Its purpose is to make work executable, not to prove that a form was completed.

Keep the same owner through ordinary findings and repairs where possible. Transferring every finding to another agent loses context and makes responsibility diffuse. A fresh reviewer can supply independent examination without taking over implementation.

One integration owner establishes how contributions combine. That owner can be the current agent, a manager or the person, depending on the undertaking. Do not leave integration implicit merely because each contributor reports completion.

## 4.3 Make useful concurrency possible

Independence creates an opportunity to proceed concurrently. Do not hold independent work behind an unresolved branch. The absence of a declared edge, however, is not proof of independence.

Check shared writes, interface assumptions, memory, test environments and review capacity. Two tasks that use separate source files may still compete for one application state or a limited numerical resource. Their logical independence does not remove that physical constraint.

Choose task boundaries that preserve enough context for sound work. Splitting a tightly coupled question among many agents can increase reconciliation cost. Keeping unrelated work serial can waste available capability. The manager's question is which arrangement shortens the route to a usable combined result.

Review is part of this capacity. Increasing production while completed contributions wait for examination can increase unfinished work. Size queues to actual demand and keep owners available for repairs.

Do not turn a temporary host limit into a permanent staffing rule. Preserve the constraint where it currently applies. Reassess it when the environment or work changes.

## 4.4 Establish consequential premises early

An early usable path tests whether the undertaking can work through its difficult relationships. It is more informative than several isolated easy components when integration is the main uncertainty.

For the document-review example, the path might generate a proposal, display its meaning, apply an accepted change, preserve undo and save/reopen the result. The interface between proposal and document state may reveal a design error before broad feature implementation.

Do not expand work that depends on an unproved consequential premise simply because private component tests pass. Hold that dependency, not the whole undertaking. Independent work can continue from a sufficient basis.

Once a premise is established, reuse it. Revisit the part invalidated by a material change rather than restarting every earlier check. Evidence has an applicable scope; it is neither universally reusable nor automatically obsolete after any edit.

## 4.5 Receive and integrate actual returns

Use the host's actual completion mechanism. A prompt can be prepared but not dispatched. A message can be queued without starting another turn. A manager's turn can end before its contributors return.

Account for dispatched work and inspect the actual result. Do not require a separate return file if the host message, artifact location and existing change record provide what the receiver needs.

A useful return identifies the output, completed scope, checks, limitations and unresolved choices. It distinguishes prepared work from executed changes and actual results from expected ones.

Before integration, compare the contribution with the receiving state. A shared interface may have changed while the contributor worked. Reuse unaffected evidence and examine the changed relationship.

The integration owner must verify that a shared correction reached the actual outputs. Sending a message does not prove adoption. A contributor can repeat passing tests while still implementing a superseded interpretation.

## 4.6 Diagnose waiting before adding machinery

Locate the next useful result and what releases it. Is the work actually dispatched? Does a partial result already exist? Is time going to reasoning, tool execution, resource contention, review or integration?

Ask a focused question when the available evidence cannot answer it. Repeated status probes can consume context without releasing work. A missing report does not establish that a worker is idle.

If a contributor cannot continue, transfer unfinished responsibility at a known boundary. Preserve useful output and evidence. Where an earlier operation's state is unknown, avoid overlapping writes until that state is established.

Add a tool or process only when it removes an identifiable obstruction. A recurring mechanical comparison may justify a small tool. A one-time uncertainty may be better handled directly. Do not let preparation for a general framework displace the usable result it was meant to support.

<a id="ch_5"></a>

# 5. Evidence and examination

## 5.1 Match evidence to the claim

Evidence supports a claim under identified conditions. It does not become stronger through repetition, formatting or a more formal record name.

Verification examines conformity to specified requirements. Validation examines fitness for intended use. A structural check can establish that an artifact follows a schema. It cannot establish that the represented engineering meaning is correct.

A source comparison can establish fidelity to the source while leaving the source itself unverified. Several agents can agree because they inherited the same mistaken assumption. The common basis may need independent examination.

For every consequential claim, ask what observation or reasoning could establish it. If the proposed check answers a different question, change the examination or qualify the claim.

## 5.2 Select assurance by consequence and detectability

A routine reversible edit may need only inspection or direct exercise. A wrong numerical result, data loss or permission error may remain plausible until serious consequences occur. These conditions justify stronger and often independent checks.

Consider what the check detects, whether another check already covers it, its cost, and whether the failure would otherwise become visible in time. A cheap oracle that usually passes can still protect an important boundary.

Testing every component broadly after every change can consume effort without adding warrant. Testing only the edited file can miss a consumer whose behavior depends on it. Affected selection should follow actual dependencies, including shared fixtures and indirect inputs.

Required professional, contractual and project examinations remain applicable. Proportionate verification is not permission to discard an inconvenient adopted criterion. It is a way to choose suitable assurance within authority and to expose conflicts when requirements need reconsideration.

## 5.3 Preserve independence where it matters

A reviewer should examine the actual candidate and governing criteria, not merely confirm the author's account. Independence includes preparation and assumptions, not only a different agent name.

Where several contributors use one oracle, independently inspect the oracle's relevant assumptions and coverage when consequence warrants it. Agreement with a shared basis establishes consistency, not the basis's correctness.

A reviewer returns a precise finding, its evidence and consequence. The owner repairs the work. The reviewer who raised the finding normally checks the repair and affected behavior. A new reviewer is useful for a concrete competence, independence or assumption problem, not as a routine review of reviews.

Review must not become an approval stop above every harmless operation. Arrange it where the risk and governing requirements need it. Small work can remain small while still receiving adequate examination.

## 5.4 Identify the actual candidate

A result needs an identifiable subject. A moving branch name alone may be insufficient. A commit, retained artifact revision or other stable identity can identify what was examined.

Record the relevant inputs and environment at the level needed for the claim. A browser exercise does not establish native application behavior unless the required equivalence is itself supported. A fixture result does not prove the live integration used that fixture's assumptions.

Retain raw output only when a consumer needs it for examination or recovery. Keep bulky captures in suitable artifact storage when that meets the requirement. The current change record can point to them without copying every byte into the project tree.

Where evidence is missing, describe the limit. Absence from a searched folder does not prove an operation never occurred. A retrospective account can direct further inquiry without becoming contemporaneous evidence.

## 5.5 Reuse evidence without overstating it

Earlier evidence can remain valid when its relevant conditions have not changed. Examine changes to the requirement, inputs, implementation, check and environment before deciding whether a rerun is necessary.

Mechanical result reuse needs a trustworthy identity for the inputs that affect the result. A cache hit must identify the earlier result and must not claim that new tests ran. Near matches are not equivalent merely because they are convenient.

Human or agent judgment may still be needed where the relationship cannot be captured by a reliable executable condition. A tool should report facts and uncertainty rather than infer unsupported completion.

Repeated checking is justified by a changed or unresolved claim. It is not justified solely because another stage, agent or PR now carries the work. This distinction reduces cost while preserving the meaning of evidence.

## 5.6 Handle failures without changing the question

A failure can arise from the product, the test, the environment or the test's own assumptions. Preserve the observed result, establish a reproducible condition where possible, and identify the cause before claiming a repair.

Do not silence a failure by changing the expected result without a substantive reason. If the accepted criterion is wrong, bring that conflict to its decision owner. A newly passing result does not itself authorize the criterion change.

A rerun that passes after a suspected timing race is evidence about variability. It does not prove the race was repaired. Report the distinction and choose further work according to consequence.

Continue unaffected work while a failure is investigated. A blocked acceptance claim need not become a claim that the whole project cannot proceed.

<a id="ch_6"></a>

# 6. Change, records and recovery

## 6.1 Change the source that governs the work

A decision should reach the artifact where its meaning takes effect. A product-wide requirement belongs in the product basis. A deliverable commitment belongs in its production contract. A technical realization belongs in Design or the relevant implementation source.

The existing change record explains why the source changed and what consequences remain. Version history preserves earlier text. A separate append register is unnecessary when it repeats decisions already available through those sources.

A cross-cutting decision can affect several owners. Establish one shared resolution within authority before conflicting repairs spread. Different owners may need different implementations of the same decision. Verify adoption in their actual results.

Do not edit history to make an old result describe a new candidate. Preserve the earlier observation and record the current consequence where needed.

## 6.2 Distinguish kinds of change

A factual correction, implementation refinement, changed accepted commitment and new human priority require different treatment.

An authorized implementation owner can usually refine a design without renewed approval when the commitments and boundaries remain satisfied. A change to an acceptance criterion, reliance condition or out-of-scope interface may require another decision.

State the proposed effect before applying a reserved change. Which commitment changes? Which consumers rely on it? What existing evidence becomes inapplicable? Which work remains valid?

Apply already-authorized decisions directly. Do not ask the person to approve the same act again because it moved into another file or session. Equally, do not treat approval of a plan as acceptance of all future unknown content.

## 6.3 Give records a concrete purpose

A record is useful when someone needs it to decide, act, examine or recover. A test report, accepted qualification or operational instruction can meet that test. An activity narrative may not.

Identify the consumer and the question the record answers. If the information already exists in a current source, query or change history, prefer a link or query over another maintained copy.

Avoid routine receipts, reading logs, status mirrors, copied source trees and memory rows that exist only because earlier runs produced them. Their combined cost can exceed the work they describe.

Some records are product requirements. A model history, signed operational decision, user checkpoint or regulated record may be part of the product itself. Reducing development administration does not remove those obligations.

The method therefore does not ban a filename or record type universally. It requires a concrete consumer, an acceptance requirement or a demonstrated recovery need. The representation should be the smallest one that reliably serves that purpose.

## 6.4 Recover only what continuation needs

Begin with current artifacts, actual state and the latest steering. Use history to resolve relevant uncertainty. Do not rebuild a complete chronology simply because a session restarted.

A replaceable recovery note can identify the current candidate, completed work, pending checks, active operations, local-only output, holds and next useful action. Its purpose is continuity, not an accumulating record of every session.

If an operation executed but confirmation was lost, inspect the actual state before repeating it. A duplicate write or release can be worse than a delayed confirmation. Preparation and execution must remain distinguishable.

When transferring ownership, establish the boundary of responsibility and the work retained. A new worker should not overwrite an active operation or discard an unmerged result merely because it was absent from the latest narrative.

## 6.5 Preserve history without keeping every working copy

Version control can preserve earlier committed work while the active tree contains only current sources. A recovery tag can identify an archived product or completed undertaking. Removing a working copy need not erase its history.

Untracked and ignored files require separate attention. Build caches can be reproducible; local notes, fixtures or session data may not be. Establish what needs preservation before removing a worktree or directory.

Retirement is a current decision about development and reliance. A frozen product can remain recoverable without occupying the active working surface or receiving routine verification. Restoring its files is not the same as reactivating its commitments or authorizing release.

Do not build new compatibility machinery solely to keep a retired consumer alive. Preserve a specific fixture, schema or contract if current work genuinely needs it. Give that artifact a maintained home and identifiable provenance.

## 6.6 Separate discovery from reliance

A versionless pointer is useful for finding the current edition of a document. It reduces obsolete links and gives a new participant a stable entry point.

That pointer is mutable. It cannot identify the exact content used in an earlier decision unless its revision and resolved target are also known. A project that depends on specific wording should identify the selected edition or source revision.

These uses can coexist. Human navigation can follow “current.” A reproducible comparison can use a particular edition at a commit. A later edition can be assessed for adoption without silently changing the earlier result.

Do not create an elaborate receipt merely to record a document read. Record exact identity where a real consumer needs it: an accepted basis, a content-bound test or a consequential comparison. Ordinary discovery remains lightweight.

<a id="ch_7"></a>

# 7. Development positions and decisions

## 7.1 Positions describe the work, not percent complete

Conceptual, FEED, 30%, 60%, 90% and delivery positions are useful descriptions in the management approach. They indicate what has become sufficiently established for the next kind of work.

They are not percentages of code, effort, cost or tasks completed. Different parts of a project can occupy different positions. A late finding can reopen one interface without returning the entire project to its beginning.

A small undertaking can combine positions. A substantial or regulated project may require formal decisions at particular boundaries. This manual neither creates those gates automatically nor cancels adopted gates.

The question at each position is what the next work will rely on. Prepare evidence for that question rather than satisfying a percentage label through document production.

## 7.2 Conceptual and FEED positions

Conceptual work establishes the intended outcome, affected users, governing constraints and plausible approaches. It examines alternatives before treating one as a commitment.

FEED develops the basis into coherent scope, contribution boundaries and principal interfaces. It should make major assumptions visible and identify the consequential choices that determine later work.

An accepted basis can contain open matters. Acceptance identifies what was decided and what remains conditional. It does not transform every source statement into a universal instruction.

Before expanding production, establish whether the contribution boundaries preserve the intended whole. A decomposition with every row populated can still divide a coupled responsibility badly.

## 7.3 Execution definition around 30 percent

Execution definition makes production contracts, inputs, examination methods and responsibility usable. Participants should understand what they can produce and what their consumers require.

Dependency analysis helps identify the production order and unresolved coupling. A project may adopt an initial DAG as a baseline, but the meaningful result is an intelligible course of work. The diagram is a representation of that result.

The project can preserve a baseline when planning or external commitments need one. Finer implementation relationships can remain in Design or local declarations until a query or consumer needs more structure.

## 7.4 Detailed development around 60 percent

The 60% position concerns whether consequential design and integration premises are established well enough to expand dependent production. It does not require that all uncertainty disappear or every relationship fit an acyclic diagram.

Examine developed interfaces, closely coupled groups, remaining technical conditions and the proposed order of work. Identify matters that could change the deliverable set or invalidate work already produced. State how each such matter will be resolved, contained or presented for a qualified decision.

Grouping co-designed work can make progress possible without changing its deliverable identities. The group needs a coherent integration responsibility and an examined path through its difficult interfaces. Grouping alone does not establish that every input is already supplied.

A warning sign is repeated analysis that finds more coupling while no product advances. Another is narrowing designs merely to close graph cycles. Ask which experiment or real integration would answer the consequential question more directly.

Where the project has an adopted human gate, present a short assessment with its actual evidence and qualifications. The person decides the gate. An agent's check does not substitute for that decision.

## 7.5 Produced work around 90 percent

At this position, intended contributions are integrated and ready for the remaining concentrated examination in use. Establish scope coverage, relationship coverage and applicable evaluation coverage.

Do not postpone all testing until this point. Earlier checks establish local behavior and consequential premises. The later examination addresses the assembled result and any claims not yet established.

An incomplete product may still be useful under an authorized reduced scope. State that scope and its limitations. Do not relabel missing required work as uncertainty merely to claim completion.

## 7.6 Delivery and continuing responsibility

Delivery requires an identified result, the applicable acceptance and release decisions, and a receiving responsibility. The recipient needs usable instructions, limitations and recovery information where relevant.

The amount of ceremony follows the actual delivery obligations. A routine internal change and a professional reliance product do not have identical requirements. Neither should inherit the other's process by analogy alone.

Acceptance, source integration and release remain distinct. The record should establish what actually occurred without inventing approval from an intermediate technical operation.

<a id="ch_8"></a>

# 8. Completion and delivery

## 8.1 Establish the remaining claim

Before adding a closure activity, identify the required claim that remains unsupported. If existing evidence already establishes the agreed result, another general review is optional improvement rather than a hidden completion gate.

Three questions organize the examination. Does the result cover the commitments? Do the required relationships work together? Do the actual checks support the proposed use?

Follow both directions where the scope warrants it. A commitment may lack an output. Implemented behavior may exceed or contradict the accepted scope. Current source documents should reflect the decisions that govern those differences.

This comparison belongs with the work when its meaning changes. A separate documentation closeout is useful only when a real uncovered relationship remains. Do not require it after every undertaking by default.

## 8.2 Examine the product in use

Begin with the activity the product should support. Define the candidate, starting state, user action or scenario, relevant environment and expected observations.

Exercise the actual connecting path. An interface can display a success message while failing to preserve data. An exported artifact can be valid in isolation while unreadable by its intended consumer.

Use representative difficult cases, not only the easiest valid example. Consider invalid input, interruption, cancellation, state restoration and the limits of the environment where these affect the claim.

An agent-operated exercise can provide evidence. It does not replace practitioner assessment where the question concerns professional usability or reliance. State what the exercise establishes and what it leaves to another examination.

## 8.3 Repair without losing valid work

A late finding should identify the affected requirement, candidate and consequence. Diagnose the cause and preserve unrelated valid work.

The repair may invalidate only part of the earlier evidence. Recheck that part and its affected consumers. Do not repeat a whole programme automatically, and do not retain a result whose governing conditions changed.

A change to a protected criterion requires its own substantive reason and authority. Keep the distinction between correcting implementation and changing what the product promises.

If the authorized result cannot be achieved, present the actual position. A narrower proposal, a deferral or termination can be responsible outcomes when the person understands their consequences. They are not completion of the original obligation unless that obligation changes.

## 8.4 Transfer an identified result

The recipient should be able to identify what was delivered, what it is for, its limitations and who carries the continuing responsibilities.

For software, a source merge is not necessarily the artifact a user installs. For a technical document, an editable source is not necessarily the issued edition. Check the actual delivery form where that distinction matters.

Preserve operational instructions, known limitations and recovery information with the result. Reference existing evidence rather than copying the entire development history into a handover packet.

The final account should make the outcome understandable: fulfilled commitments, authorized changes, remaining responsibilities and the relevant acceptance or release acts. It need not narrate every intermediate action.

<a id="ch_9"></a>

# 9. Improving the course of work

## 9.1 Measure the result and its whole cost

A fast first draft can be expensive if it creates extensive review and repair. More simultaneous agents can increase unfinished work when integration is the constraint. Fewer questions can hide uncertainty rather than improve preparation.

Compare coherent completed contributions. Include preparation, execution, waiting, review, correction and integration. State differences in task conditions and uncertainty in attribution.

Counts of files, words, PRs or tests are observations, not direct measures of productivity. A larger PR can reduce the PR count without reducing effort. A deleted record can be beneficial or can remove necessary evidence.

The useful comparison is effort and elapsed time to an adequately examined result, with consequential defects and recovery considered alongside it.

## 9.2 Remove repeated mechanical work

A stable comparison, inventory or affected-check selection often belongs in a tool. The tool can report facts and its limits while agents interpret their significance.

Tools also have preparation, failure and maintenance costs. Do not create a general service for a one-time comparison unless the broader need is demonstrated. The smallest useful operation is often easier to inspect and preserve.

A deterministic tool can reliably answer the wrong question. Check its input selection, assumptions and actual consumer. Automation does not remove the need to establish the relationship between its result and the claim.

## 9.3 Improve from observed constraints

Look for recurring causes of delay: repeated discovery, excessive context loading, broad reruns, unclear ownership, unresolved common assumptions or stalled integration.

Change the mechanism that produces the problem. If a shared interpretation blocks several owners, resolve it once and verify its application. If an unchanged check dominates waiting, examine whether its result can be reused safely. If a manager relays every message, examine whether the assignments are too narrow or the return mechanism is wrong.

Use existing telemetry and project evidence where sufficient. Do not create another reporting programme merely to prove that administration has decreased.

## 9.4 Prevent the burden from returning

A control can survive after the reason for it disappears. It can also return under a new name: a small register, a universal state service or a proof folder for every run.

Ask what concrete consumer, required decision or recovery problem needs the control. If it merely repeats available state, remove the repetition. If it protects a consequential boundary, preserve that function and simplify its implementation where possible.

Do not mistake short wording for a light process. A sentence can require hundreds of files. Conversely, a substantial explanation can prevent repeated misunderstanding without creating any recurring duty.

Review changes to instructions through their actual consumers and enforcing tools. A new permission in prose is ineffective when a live validator still forbids it. A retired requirement continues to consume work if CI still demands its artifact.

<a id="ch_10"></a>

# 10. A worked undertaking

This constructed example concerns an editor that lets a person inspect proposed changes before applying them. It illustrates the method. It is not a claim about the current status or requirements of any named product.

## 10.1 Establish the intended use

The person wants help revising a document while retaining control over what becomes accepted text. The initial request is “add an agent review panel.” The agent asks what must be visible and what the person must be able to reject.

The discussion establishes that proposed changes must remain distinct from saved text until accepted. Rejection must leave the document unchanged. Accepted changes must be recoverable through the editor's undo and persistence behavior.

The implementation owner identifies an existing proposal representation, document store and history mechanism. The investigation finds that the display can show several proposals, but the apply function assumes only one current proposal. This is a consequential interface question, not a reason to repeat the whole project definition.

## 10.2 Define the contribution and its needs

The undertaking is bounded to one complete proposal-and-apply path. Its contract identifies display, acceptance, rejection, undo and save/reopen behavior. It excludes automatic acceptance and unrelated editor redesign.

The consumer needs the document store to reject a stale base revision. It also needs a history operation that can reverse the accepted change without altering unrelated edits. Those conditions are stated as needs rather than as a claim that the store is simply “ready.”

The owner of the implementation queries relevant consumers and inspects the interfaces. One session can perform the initial slice. A separate reviewer is arranged for persistence and permission behavior. An independent interface illustration can proceed concurrently because it does not write the shared store.

No work graph is authored merely to record these assignments. The current contract, need declarations, candidate and conversation provide sufficient continuity. If the work later spans sessions, a short recovery note can identify the current candidate and pending check.

## 10.3 Prove the difficult path

The implementation creates a proposal against a known document revision. The user accepts it. The resulting text is saved, reopened and undone under controlled conditions.

The first connected test reveals that reopening the document loses the proposal identity needed by undo. Unit tests for display and storage both pass, but the assembled path does not fulfill the undertaking's contract.

The owner preserves the failure and repairs the history representation. It does not weaken the undo requirement to fit the implementation. The independent illustration work continues because the failure does not invalidate its inputs.

This early path prevents broader implementation from multiplying the same assumption. It establishes a useful premise before adding many proposal types or interface variations.

## 10.4 Distinguish refinement from a reserved change

During repair, the owner changes an internal record layout. The behavior and accepted interface remain the same. This is an implementation refinement within the assignment.

A different proposal would remove undo after save because the new layout makes it difficult. That would change an accepted criterion. The owner must present the consequence and obtain the applicable decision rather than silently adopting it.

The distinction depends on meaning, not the number of edited files. A small text change can alter a commitment. A substantial refactor can preserve it.

## 10.5 Examine the result

The reviewer receives the current candidate, relevant requirements and actual test results. The review examines stale-base rejection, unauthorized application, rejection without mutation, persistence and undo.

A schema check confirms that records have valid structure. Behavioral checks establish that the actions preserve the required state. Neither alone establishes that the display makes the user's choice understandable; that question needs an appropriate interface exercise.

The reviewer finds that a second proposal can still refer to the old document revision after the first is accepted. The implementation owner repairs the refusal path and reruns the affected cases. The same reviewer confirms that repair. Unchanged rendering evidence remains usable.

## 10.6 Update meaning where it changed

The Design now explains the accepted proposal's identity and the stale-base behavior. The dependency condition names the consumer's required refusal. The change record explains the repair and checked scope.

The owner does not add a lifecycle file, local memory row, receipt and copied test log. Existing candidate identity and check results already let the reviewer and next session recover the claim.

If a required result were available only in a temporary environment, the owner would preserve it at a stable location or record how to reproduce it. The absence of routine records is not permission to lose necessary evidence.

## 10.7 Complete the undertaking

The integrated candidate supports the required complete path. The implementation owner establishes scope, relationship and examination coverage. No applicable requirement remains missing within the selected undertaking.

There is no additional governance closeout solely because the final change is ready. A final source comparison can still be necessary if integration introduced a new relationship. Its purpose must be the unresolved claim, not the name of the stage.

The return identifies the usable result, candidate, checks and any remaining limitations. Product acceptance and release remain separate owner acts. An opportunity for broader proposal types becomes future work only when selected; it does not make the completed bounded undertaking incomplete.

<a id="ch_11"></a>

# 11. Two contrasting cases

## 11.1 A small single-session correction

A person asks for a clearer error message in an internal tool. The agent locates the message, the condition that produces it and the user's expected next action.

The agent discovers that the wording suggests data was saved when the operation was actually refused. The correction therefore concerns meaning, not merely style. It changes the message and exercises both the refusal and success paths.

If no permission, persistence or other consequential behavior changes, a focused examination can be adequate under the applicable rules. A new manager, project basis and global dependency audit would add no useful warrant.

The agent reports the change and actual check. The work is complete when the message accurately guides the intended action under the authorized scope. No separate activity record is required.

This case demonstrates proportionality without vagueness. Small work still needs the correct question and a real observation. It does not need the organizational structure of a programme.

## 11.2 A parallel technical investigation

A project must compare several approaches to a consequential calculation. The team has a common input definition, acceptance basis and independent reference. Some assumptions remain unresolved.

The coordinator first checks that the shared reference supports the intended range and that each worker will use the same units and conventions. It selects a difficult connecting case rather than only easy examples.

Independent approaches can then proceed concurrently. The assignment identifies each contribution's outputs, limits and expected comparison. Shared files have one owner. Resource-intensive runs are scheduled around actual memory and machine limits.

One worker reports a discrepancy outside the supported reference range. That finding does not invalidate all other work. The coordinator distinguishes an unsupported comparison from a demonstrated implementation error and identifies the additional evidence needed.

Another worker finds a units inconsistency in the common input definition. That affects all dependent results. The coordinator resolves the shared interpretation within authority, updates the governing source and checks which results must be repeated.

The final comparison explains actual coverage, limitations and material differences. It does not select a winner solely by test count or execution speed. The responsible person makes the consequential choice using evidence appropriate to the intended use.

The case shows why concurrency and shared-basis examination belong together. More workers cannot compensate for a mistaken common premise. A sound common premise does not justify holding independent work behind an unrelated delay.

<a id="vocabulary"></a>

# Working vocabulary

| Term | Meaning in this manual |
|---|---|
| Accepted basis | The identified commitments and conditions established by the applicable decision. |
| Agent 0 | The responsibility for purpose, continuity and reserved choices in work with the person. |
| Assignment | The current objective, context, authority, outputs and conditions for a contribution; it may be conversational. |
| Consumer | The person, component or undertaking that uses a contribution. |
| Dependency condition | What a consumer needs from a supplier and when it needs it. |
| Deliverable | A stable, coherent responsibility for a useful contribution. |
| Evidence | Observations or reasoning that support an identified claim under stated conditions. |
| Integration | Bringing contributions into the actual receiving result and examining their relationships. |
| Judgment | Accountable human determination of what is accepted or relied upon. |
| Method | A reusable approach, selected and adapted within the assignment's authority. |
| Package | An accountable grouping of scope around a meaningful objective. |
| Production contract | The deliverable's required contribution, criteria, interfaces and examination basis. |
| Reckoning | The agent's interpretation, comparison, inference and selection within its assignment. |
| Recovery note | A replaceable account of facts needed to continue when current artifacts and conversation are insufficient. |
| Role | A description of contribution and responsibility, not a mandatory staffing position or permission grant. |
| Validation | Examination of fitness for intended use. |
| Verification | Examination of conformity to specified requirements. |
| Workflow | An expressed reusable method for performing an undertaking. |

# Further use

Use the [Field Book](Project_Management_for_Human_Agent_Teams_Field_Book_v2.md) for a concise route through the questions in this manual. Use the [Agent User Manual](CHIRALITY_AGENT_USER_MANUAL_v4.md) for current Chirality repository practice.

Earlier editions remain useful for historical interpretation of work that named them. Their exact source identity does not automatically make every former procedure applicable today. A current edition is a discovery aid; specific adopted commitments retain their own authority.