# Chirality in Practice
**Extending Human Capability with Agents**
First edition
Ryan Tufts
## Authorship and the character of this book
This book develops the reflective side of Chirality. It continues the argument of [Purpose, Participation, and Judgment](../thesis/README.md) through an examination of work. It asks how an undertaking gets its direction, how contributions become usable together, and how experience can change the means that the next undertaking uses. Agents help with interpretation, comparison, drafting and examination. The author decides the intended meaning and which text to accept and publish. The account uses an impersonal voice, and a constructed case is not testimony about the author's experience.
People and agents can use the book as material for thought and criticism. The commitments and selected instructions of their own undertaking remain the basis for execution. An explanation can disagree with an instruction, and the disagreement can matter. But the explanation does not automatically replace the instruction.
The account distinguishes the author's commitments, interpretations of documented experience, and proposals for how practice could develop. Agreement with the thesis gives conceptual grounding. It is not independent empirical confirmation. A plausible arrangement can remain a design hypothesis, even when particular cases support some of its relationships.
The cases rest on different grounds. Chapter 4 examines one App episode in which the owner redirected the work and asked for the resulting lessons to inform shared guidance. Chapter 9 examines the concentrated Root library undertaking. Chapters 10 and 11 contain constructed examples, including work after acceptance. The thesis gives a separately dated account of App and SWBPIPE experience. Earlier App and Piping work took place in a shared repository, before the projects separated.
This book selects a small part of those records, mostly about library maintenance. That selection is a boundary of the inquiry. It does not mean that product experience is absent. The book reports no new product trials.
The distinctions in this book are selective. A chapter can make one relationship easier to see and leave out something that matters in another situation. So agreement with a description is different from an adequate understanding of the work. The contents invite inquiry. They are not a checklist of every question that can arise.
## Contents
1. [A wider undertaking](#wider-undertaking)
2. [Purpose, knowing and responsibility](#purpose-knowing)
3. [Commitments that support action](#commitments)
4. [Contributions and their relationships](#contributions)
5. [Ownership and coordination](#ownership)
6. [What evidence can carry](#evidence)
7. [Change, continuity and delivery](#continuity)
8. [After completion](#after-completion)
9. [A library learning from its own work](#library-case)
10. [A constructed document-review undertaking](#document-case)
11. [Two constructed contrasts](#contrasts)
12. [Reflection across undertakings](#reflection)
13. [Distinctions used in this book](#vocabulary)
## 1. A wider undertaking
Chirality is the wider undertaking expressed through its three projects: the library, App and SWBPIPE. The library repository is one particular place where that undertaking develops its shared understanding and means of working. App develops an environment for work with agents. SWBPIPE develops a product for piping design and stress analysis. Each project has its own commitments, technical circumstances and responsibilities. Their differences give the shared practice different occasions to learn.
One view treats a library as a supplier of files. That view describes an important operational relationship. A consumer needs identifiable material, its resources and a way to assess changes. But the view is an incomplete account of how these projects relate. People can question and change shared methods through the work of producing actual results. A project can reveal a defect in a method, a misleading explanation, or a useful possibility that the library's authors did not expect.
The [thesis introduction](../thesis/INTRODUCTION.md#one-undertaking-three-perspectives) describes a mainly normative emphasis in Root, an operative emphasis in App and an evaluative emphasis in the engineering product. These are emphases, not exclusive allocations. All three projects involve purposes, action and examination. So a difficulty in a project that receives a shared claim can qualify that claim. The difficulty is not merely a failure to follow it.
The library gives form to part of that understanding. A role expresses a contribution. A workflow offers a way to carry work through. A tool performs an operation, and people can examine the meaning and limits of that operation. Publications develop arguments and cases that do not reduce comfortably to short operational instructions. These forms have different uses, and how they relate matters more than whether they follow one document pattern.
The thesis uses *chirality* to name the gap between information that can be externalized and accountable knowing. An artifact that people can inspect can support a person's understanding and commitment. It does not become identical with them. In practice, the gap appears, for example, when a person receives work from an agent: an explanation, a calculation, a proposed change or a product. The person can examine and correct that work. But receipt of the work does not settle what the person knows or will stand behind.
The term does not claim that every distinction in the architecture has a chiral structure. It names one particular difficulty in purposeful work. Roles, source identities and examination matter because they help people live with that difficulty. Their resemblance to a metaphor is not the reason.
This account leaves room for the projects to disagree. A numerical tool and a document editor need different forms of assurance. An arrangement that reduces interruption in library maintenance can be unsuitable for an operation with irreversible consequences. A shared practice becomes more useful when it can explain those differences. Uniform instructions alone cannot show that one arrangement serves every use.
## 2. Purpose, knowing and responsibility
### An activity that must become possible
A request often names an implementation before its purpose is clear. “Build a review panel” can mean that a person needs to do three things. The person needs to tell proposed text from accepted text, understand the consequence of an edit, and reject a proposal without losing work. A panel is one possible means to make those activities possible. The existence of a panel would be weak evidence that they had become possible.
This distinction changes the inquiry. Questions about visibility, rejection, recovery and the consequences of error can change the design before much code exists. They can also show that an existing interface already supports the activity. Purpose gives work a direction and leaves room to reconsider a mechanism.
Purpose does not make an undertaking unlimited. A useful improvement can stay outside the work that is currently authorized. Otherwise each discovery becomes another condition for completion, and an agent that appears diligent can keep a useful result from its recipient. The tension is between responsiveness to experience and fidelity to the commitment. It is not a tension between curiosity and obedience.
### Reckoning and judgment
The thesis separates the agent's **reckoning** from the person's **judgment**. Reckoning includes investigation, interpretation, inference, planning, criticism, checking and adaptive action. The distinction does not reduce an agent to mechanical calculation. It concerns how capable contribution relates to the person's situated engagement with what matters and with what they will stand behind.
Judgment is present when a person forms the question, recognizes consequences, accepts some uncertainty and changes direction. It is not limited to a signature at the end. A person can authorize substantial autonomous work and still keep responsibility for the commitments and reliance involved. A demand for new approval of each ordinary operation would confuse accountability with direct performance.
To attribute a decision to someone does not by itself establish accountability. A meaningful attribution has a subject and conditions: which result, which purpose, which authority, and what the person actually decided. Permission to investigate, selection of a design, acceptance of a product and authorization to release it have different consequences. A generic approval label can hide those differences.
### Information and situated understanding
People can record, transmit and compare information. In the thesis's usage, knowing is a situated achievement of a knower. Knowing can be mistaken, incomplete or revised. A source record and a successful check can support understanding. They do not transfer that understanding intact to another person.
The same information can matter differently in different circumstances. A test result can answer an implementation question and leave the intended user's practical concern untouched. A distinction that is obvious to a specialist can be absent from an agent's current context. The thesis calls attention to this openness through configurational multiplicity: a representation does not exhaust what people can understand from the work.
This openness does not make every interpretation equally well grounded. Instead, it creates a need to explain how the source, the inference and the intended use relate. Confidence, repetition and agreement among agents cannot supply a missing relationship by themselves.
### Four connected perspectives
Ontology, epistemology, praxeology and axiology are four ways to examine the same undertaking. Ontology asks what exists in the undertaking, how it is represented, and how those things relate. Epistemology asks what can be known, and what supports or limits a claim. Praxeology asks how intended work becomes action and usable results. Axiology asks what matters, to whom, and what consequences the work has.
People can confuse a proposed change with an accepted requirement, an artifact with the condition it represents, or a passing check with a permitted use. These confusions concern what the work contains. They also affect evidence, action and value. For example, when a record treats an approval field as an actual human act, it changes both the claim and the responsibility that it attributes to a person.
The thesis describes these perspectives as [mutually corrective](../thesis/03_philosophical_framework.md#34-mutually-corrective-perspectives). Purpose helps determine which uncertainty matters. Evidence can expose a flawed category or intended use. The cost of a control can change how people carry out examination. If participants turn the four questions into four compulsory reports, those relationships can stay untouched. Whether the perspectives are adequate remains open to reflection, through the work they help participants understand and do.
## 3. Commitments that support action
### Enough basis for the next work
An undertaking needs a basis that lets participants act without inventing missing commitments. Intended users, required outcomes, constraints, interfaces and unresolved matters can take different forms. A substantial product can need a PRD and specialist companions. A bounded repair can need the person's direction and the current requirements that the repair affects.
The form is adequate when it supports the decisions and coordination at hand. A new session does not by itself create a need for a new project definition. But an informal request can leave consequential questions open. The question is what dependent work will assume, not whether a preferred template exists.
A behavioral commitment differs from its implementation. Recovery of the accepted document after an interrupted save can remain an obligation while the transaction mechanism changes. But a particular algorithm can also be an explicit adopted commitment. The amount of detail does not show whether a statement is incidental or governing. Its standing comes from the actual decision and context.
### Different kinds of statement
A commitment governs work through an applicable decision or source. An assumption gives a provisional basis for reasoning. A proposal is a candidate choice. An observation tells what occurred under identified conditions. These distinctions stay important after the work is authorized.
A person can authorize a prototype that assumes an operating range. That authorization permits the experiment. It does not prove the range or make it a product promise. A requirement such as “handle large documents efficiently” can hide unresolved values behind definite language. If someone fills in those values only to complete a document, an unknown becomes an invented commitment.
Uncertainty can stay local. An open question about a visual detail need not stop a persistence test. An open question about a coordinate convention can invalidate every dependent numerical result. One “blocked” label for the whole project hides that difference. A useful account tells which action depends on which remaining condition.
### The work of a source
Each source supports particular claims. An interview can support an account of a difficulty that a user reported, while a test supports an observed behavior. A publication can explain a method without proof that its implementation works on a particular platform. Recency is not a universal rule to resolve a conflict between sources.
Extraction adds another relationship. A trustworthy original can produce an inaccurate transcription: a missing unit, a changed symbol or a flattened diagram. The authority of the source and the fidelity of the derivative need different grounds. An exact hash can establish content identity. It cannot establish that someone understood the identified content correctly.
A conflict can come from different subjects, editions or meanings, or from a real disagreement that nobody has resolved. The difference matters. A record can accurately hold a historical requirement and a current proposal while neither is the current commitment. If an agent chooses whichever statement is easier to implement, it suppresses the question instead of resolving it.
### A decision that can be considered
A reserved decision is easier to make when its subject is concrete. A proposed text, a candidate interface or a comparison gives the person something to inspect, together with alternatives and their consequences. A request for approval before the useful choice is ready can move ordinary production back to the person.
The opposite failure occurs when someone treats permission to investigate as acceptance of future content. Both errors lose the actual decision. Continuity requires an understanding of what was authorized and what remains open. It does not require a repeated approval question each time work changes hands.
The Root undertaking made this distinction visible in its separate content decisions and gate decisions. The owner approved the revised maintenance and reflective guidance in PR #1785, before the later readiness and product decisions that chapter 9 describes. Each was an actual approval with a different subject. If the first approval had counted as acceptance of every later consequence, it would have erased the choices that the later work was meant to prepare.
A project basis can contain sections that are each sound but conflict as a whole. One section can promise recovery while another excludes the state that recovery needs. When someone follows one representative activity across the sections, the conflict can become visible. Structural checks help with representation. Substantive examination asks whether the assembled basis supports the intended result.
## 4. Contributions and their relationships
### Responsibility and representation
A deliverable is an intended contribution within an undertaking, with conditions and assigned responsibility. Its files, identifier and graph node represent that contribution. Their existence is not the same as production or fulfillment. A package groups related scope. An assignment identifies the work that a participant currently holds. These boundaries can have different sizes.
This distinction matters when a useful undertaking crosses several source files, or when one deliverable needs several contributions. Smaller records can improve ownership. But they can also split up the context that a participant needs to carry a result through repair and integration. A decomposition succeeds through the responsibilities it makes clear, not through the number of entries it creates.
Exclusion also has meaning. Work outside the present commitment can still affect the intended result and need an explicit disposition. “Out of scope” sets a boundary. It does not erase the consequence of that boundary.
### A production contract
A production contract connects the intended contribution, the required outputs, the governing criteria, the relevant interfaces and the means of examination. It helps a producer understand what the recipient can use. It also helps the recipient assess what the producer supplied.
In the Root library undertaking recorded in 2026, `ScopeOfWork.md` held commitments and criteria, `deliverable.yaml` expressed needs, and `Work/` held reasoning and execution material. Outputs such as tools and publications stayed in their source homes. That arrangement was one instance of the relationship, not its definition. Current project instructions identify the actual locations. Historical references keep the locations and meaning of their recorded basis.
A condition belongs together with the evidence that can examine it. A valid schema can still misrepresent the meaning of a source. A correctly rendered table can contain the wrong calculation. The chain from required contribution, through examination, to actual observation and permitted use has value even when it needs no separate table.
### Needs from the consumer's position
“Needs the persistence module” names a supplier but says little about suitability. “Needs atomic replacement that leaves the earlier accepted document recoverable on failure” identifies the condition that matters. The second form supports more useful reasoning about partial completion and alternative implementations.
A product relationship also differs from an execution prerequisite. Two components can exchange information in the final product and still be developed against a stable interface. A temporary fixture can constrain production and never appear in the shipped product. If every dependency becomes a finish-to-start gate between whole deliverables, both kinds of relationship become hard to see.
The consumer is in a good position to state its condition, because it bears the consequence of relying on the input. Participants can then examine supplier evidence against the actual use. A merged contribution can meet one consumer's condition and leave another consumer's condition open. Unknown suitability is a meaningful finding. It is not a defective status that someone must fill.
### Graphs and cycles
A graph expresses selected relationships for a purpose. An acyclic graph can omit necessary conditions. A cyclic graph can accurately describe mutual design. An edge can be correct but too coarse to decide the next action.
A cycle can indicate coupled design, an overbroad contribution or an impossible order. Each interpretation calls for a different response. A defined interface can let two implementations proceed. One integration owner for coupled work can keep a relationship that should not be cut. If someone narrows an accepted requirement to get a cleaner graph, they change the commitment while they appear to repair a representation.
The App's passage through its 60% position on October 4, 2026 gives a more difficult instance. At that time the App and the shared library were in the same repository. The agent's [recorded lessons](https://github.com/sgttomas/chirality/blob/34a83250a15d81f0c2239496858e16450cc82840/projects/chirality-app-v4/execution/_Coordination/AgentRuns/APP-V4-GRAPH-CLOSURE-20261004/LESSONS_60PCT.md) describe attempts to remove cycles by rewording dependencies. Each pass found more coupling, while no usable product advanced. Some proposals narrowed obligations to improve the graph. The owner redirected the work toward a coupled contract core and a working path through it.
The [owner-direction record](https://github.com/sgttomas/chirality/blob/24e9117b9c2d9d10f57642da4eef0d13c90bb166/projects/chirality-app-v4/execution/_Coordination/AgentRuns/APP-V4-GRAPH-CLOSURE-20261004/OWNER_DECISIONS.md) also transcribes an explicit request to develop shared guidance from that experience. The [recorded changes](https://github.com/sgttomas/chirality/blob/a8d835ad7bb687e1d4283fdbda8ca1ce85cfafb1/projects/chirality-app-v4/execution/_Coordination/AgentRuns/APP-V4-GRAPH-CLOSURE-20261004/MANUAL_CHANGES.md) and the [revision](https://github.com/sgttomas/chirality/commit/0c45aba0e987d5c9e65e1786bab680def5d56169) that followed separate structural concerns from finer relationships. They also qualify the guidance as the experience of one project, without fixed thresholds or tiers.
This trace connects a project difficulty, the owner's intervention and an actual change in shared explanatory material. It does not establish a routine learning process, later adoption in every project, or an effect on later outcomes. The episode matters because the owner redirected the use of the graph toward producing the required result. It also shows the person's part in carrying that experience into an account that others could examine.
Tools can derive neighborhoods and potential impact from declarations. Their usefulness depends on the sources and limits that they show. A supplier file that is present is an observation about a path, not proof of suitability. Missing mappings remain possible. Local inquiry combines those observations with inspection of the relationships that matter to the actual action.
## 5. Ownership and coordination
### Contributions rather than staffing positions
Chirality names several contributions: continuity with the person, conception and design, implementation and integration, and bounded execution. Roles make these contributions available for discussion. They need not require a different agent for each kind of thinking.
One person-facing agent can investigate, propose, implement and examine one coherent undertaking. Another owner becomes useful when a contribution benefits from sustained separate attention or independent preparation. Model capability is a further question. A difficult bounded review can need more reasoning than routine coordination. For a deterministic operation, a tool can be the better choice.
Contribution ownership means responsibility for carrying assigned work through examination, repair and transfer. Integration ownership concerns how contributions become a usable result. Neither one transfers the person's accountability for reliance. This distinction helps participants delegate work while keeping responsibility for integration explicit.
### Capability, authority and enforcement
A capable agent can perform an operation that it is not authorized to perform in the present undertaking. A host can permit a write that the project's instructions prohibit. And an authorized operation can remain technically unavailable. Capability, authority and host permission concern different relationships. Treating one as evidence of the others can cause practical errors.
Written instructions can set a procedural boundary without enforcing it. In the Root custody case in chapter 9, a separate process could still write to the held material. The useful finding was the actual limit of the arrangement. Coordination identified who should act, but it did not exclude other writers at the filesystem. A description of that arrangement as an enforced lock would have encouraged reliance on a protection that did not exist.
The distinction also affects how records represent action. A role name or a permission field cannot establish what an operation actually did. These distinctions let people examine a claim about control, and they do not require every practical safeguard to take the same technical form.
### Continuity through repair
An owner who knows the input basis, the attempted approaches and the governing conditions can often repair a finding better than a newly introduced agent. A separate reviewer can challenge assumptions while the implementation owner keeps continuity. If each small correction goes to a new agent, the result can be many completed tasks but little completed work.
The boundary of the assignment matters. A contributor that was asked only for a first fragment can reasonably stop there, even when the intended result needs connected repair and reconciliation. A broader boundary can remove interruptions without a reduction in scrutiny. Chapter 9 examines such a change in Root's practice.
Independence remains necessary where the claim needs it. A review adds little when another agent only confirms the author's summary. Its value depends on access to the actual candidate and the relevant sources. It also depends on the possibility of finding a premise that the author did not test.
### Concurrent work and shared conditions
Separate source files do not ensure independence. Contributors can share a model state, a fixture, a numerical convention, a machine budget or limited review capacity. More simultaneous production can increase unfinished work if integration becomes the bottleneck.
A common premise can make concurrent work possible, and it can also multiply a defect. A small connecting exercise can expose a mistaken interface before many components depend on it. After the relevant premise is established, its evidence can support further work. That evidence need not be repeated simply because another agent now carries the work.
A temporary resource limit belongs to its setting. If someone treats it as a permanent staffing doctrine, they confuse a condition of one undertaking with the general method. In the same way, the absence of a declared dependency cannot prove that two actions are independent.
### A return that reaches its recipient
Coordination depends on actual communication mechanisms. A prepared prompt, a dispatched task, a completed operation and a received result are different events. A contributor can finish in a separate session while the coordinator receives only silence. A summary of expected behavior can hide the fact that nothing ran.
These distinctions have a practical consequence. When a return is uncertain, examining the actual operation and available result helps the coordinator distinguish missing work from missing communication. A repeated request for status does not fix an assignment that was never dispatched or a broken return route. The necessary mechanism belongs in the host and project instructions that use it. The general lesson is that the relationship must actually exist.
Useful coordination includes the cost of preparation, waiting, review and repair. Neither the number of workers nor the frequency of messages measures progress toward a result that someone can use. Ownership earns its value through that result and through the continuity that makes it possible.
## 6. What evidence can carry
### Claims and their grounds
Evidence has a subject and a scope. A parser test, a visual inspection, a source comparison and a user trial answer different questions. A polished representation cannot establish semantic correctness. A correct calculation does not establish that its published rendering keeps the result.
Verification concerns conformity to an identified requirement, claim or reference. Validation concerns fitness for intended use. Tools also use these words for narrower operations, so the actual subject matters more than the label. Acceptance of a document's format alone does not show whether the document promises a useful product.
The Root F-02 case in chapter 9 shows why a claim needs grounds that suit its actual subject. A current caller and executable behavior challenged a plausible broad interpretation and required a narrower explanation with better support. A successful check alone would not have explained what was wrong with the earlier interpretation.
### Consequence, detectability and independence
A wrong result that looks plausible can be more dangerous than an obvious failure. So numerical errors, permission mistakes and silent data loss often need stronger examination than a reversible change of wording. The value of a check depends on the failure it can expose and on the consequence of missing that failure.
A shared oracle can make many results agree while it carries the same mistaken assumption into all of them. Independent examination concerns preparation and grounds, not only different identities in a review record. It can use a source comparison, another derivation, a difficult case or scrutiny of the oracle itself.
Proportionate examination is an argument about adequate grounds under the governing conditions. It does not permit anyone to abandon an adopted criterion because the criterion is inconvenient. If a criterion is wrong, that becomes a substantive question for the appropriate decision. It is not an excuse to redefine a failed result as a pass.
### Candidate identity and evidence reuse
An examination needs a candidate that people can identify. A moving branch name, a screenshot from an earlier build or a flattened extract of a source can refer to a different subject from the one under discussion. A hash can make that identity precise. It does not show that the check was adequate.
Earlier evidence can stay applicable when the conditions that support its claim stay unchanged. Those conditions can include requirements, inputs, implementation, the check and the environment. A changed document does not necessarily invalidate an executable path that was tested before. And an unchanged executable can still face a new use that its earlier tests did not address.
So the question is whether evidence applies. It is not a choice between universal reuse and universal repetition. A copied table can need checks of placement and rendering without a new derivation of unchanged numbers. A different consumer can need new interface evidence even when the copied bytes are identical.
The library delivery case separated two kinds of support that a summary can easily merge. The match between the complete archive and Git established which source was supplied. Selected operations on an extracted archive established bounded behavior. The first result could be exhaustive about file identity, while the second stayed selective about use. Neither result had to claim more than it established for the combination to be useful to a recipient.
Retained evidence serves examination or recovery. The form and duration of retention depend on that use and its governing obligations. A raw log can be essential for one claim, while a reproducible fixture and a source binding are enough for another. Missing evidence remains a limit. A narrative written afterward cannot silently become an observation made at the time.
### What a failure changes
A failure can come from the product, the environment, the test or its assumptions. A passing rerun can reveal variability without proof that the cause is repaired. If someone changes an expected value only to silence the failure, they change the question and keep the appearance of an answer.
A consequential finding can invalidate one dependency without invalidating everything around it. Keeping valid work depends on understanding what changed. A simple reduction in testing does not give that understanding. The same understanding lets independent work continue while participants investigate the affected claim.
A useful examination stays open to the possibility that its own framing is wrong. The question then becomes which response fits: repair the implementation, improve the evidence, or reconsider the commitment. Those responses have different consequences and different decision rights.
## 7. Change, continuity and delivery
### Where a decision takes effect
People can discuss a decision accurately while the decision fails to reach the source that governs work. A person approves a changed behavior, but the requirement still promises the old behavior. Or the implementation changes, but its consumer still relies on the earlier interface. The problem is the broken connection between the decision and its use.
The right source depends on what changed. A product commitment, a technical realization and a shared method have different homes. One decision can affect several owners, and each owner is responsible for the consequences in their contribution. A second register that repeats all their decisions cannot replace those changes.
Version history keeps earlier meaning, so each current document need not narrate it. Historical evidence describes its actual subject. An update to a present account does not make an old test describe new bytes. And a later understanding does not erase the significance of a failed attempt.
### Records and recovery
Records can support a decision, an examination, an operation or recovery. They can also be part of the product: an accepted model history or a required professional record can be an output that someone relies on. Their value depends on that use, not on a general preference for more documents or for fewer.
A growing history of routine activity can make the current question harder to find. A replaceable recovery note can help when the existing artifacts and review records leave a real gap in continuity. The note becomes another burden if it only restates state that people can recover more reliably from the source.
Interrupted operations show why actual state matters. If a write or a release occurred but its confirmation was lost, a repeat can cause a second, unintended action. A successful preparation step is different from execution. An absent narrative is different from absent work. Recovery concerns the usable basis, the actual operation, the remaining conditions and the present authority.
Committed history and untracked local work need different care. A reproducible build directory can be disposable. A unique local fixture or an active operation may not be. Retirement can keep an identifiable earlier result while it removes that result from current work. Restoration of an old source does not by itself reactivate the undertaking that once used it.
### Discovery and reliance
A stable discovery pointer helps someone find a current edition. Reliance on exact content needs a more specific subject. A decision or comparison can depend on a named edition and revision after the discovery pointer has moved elsewhere.
These relationships are compatible. An index can show a successor without adopting it for every consumer. A project can follow development on a branch or keep a published source. The participants who rely on the chosen relationship need to understand it.
A historical citation can keep a meaning that a later explanation develops differently. If people treat every old reference as stale, they erase the difference between current discovery and an actual earlier reliance. But an old citation is not enough if a current instruction silently promises a different behavior.
### Positions in development
Development can be discussed in positions: conceptual, front-end engineering design, 30%, 60%, 90% and delivery. These positions describe what has become established enough for dependent work. They do not measure code, cost or elapsed effort. Their usefulness depends on the questions they expose in a particular undertaking.
Conceptual work concerns the intended result and plausible means. Front-end engineering design develops scope and the principal interfaces. Around the 30% position, the execution responsibilities and the conditions for useful production should be clear. Around 60%, consequential design and integration premises become important grounds for more dependent work. Around 90%, the intended contributions come together for concentrated examination of their combined use.
These descriptions are abstractions. A small undertaking can combine several questions in one conversation. A substantial project can have different contributions at different positions. A late interface finding can reopen one premise without a return of the whole project to its beginning. The descriptions become harmful when a label demands ceremonial outputs regardless of the actual work.
Where a person adopts a gate, its decision has an identified subject and authority. Where nobody adopted a gate, a chapter heading does not create one. The Root case in chapter 9 records actual gate decisions by the owner and keeps their limited meaning.
### Completion and the recipient
Completion concerns fulfillment of the agreed work and its required examination. Integration concerns whether contributions form a usable combined result. A source merge can contribute to integration without establishing it. The recipient's activity gives the distinction practical meaning: each component can pass its own checks while the assembled product fails to keep accepted state.
Before another closing activity can be justified, there is a question: what claim would it establish? Existing evidence may already support the agreed result. Or the connecting path or the actual form of delivery may still be unexamined. If all remaining uncertainty counts as missing work, completion becomes impossible. If missing required work counts as mere uncertainty, the work looks complete when it is not.
Delivery transfers an identified result, with the information and continuing responsibilities that its use needs. Acceptance is an authorized act concerning a subject, a scope and a purpose. Release authorizes making an identified result available for a stated audience or use. Reliance is someone's use of a contribution as a basis for action or decision. These events can occur together, but their subjects and consequences stay different.
A source archive, an installed application and an issued technical document make different demands on their recipients. Identity, instructions, limitations and recovery matter according to the selected form. A narrower result can be useful when its scope is explicitly authorized. It does not fulfill a broader obligation merely because it is ready to deliver.
## 8. After completion
### An undertaking ends while its result continues
People can use, depend on and question a result long after the undertaking that produced it ends. A library edition, an installed application or an issued calculation can remain in use after the producing undertaking ends. If people confuse the undertaking with its result, maintenance becomes hard to describe.
One error treats each later improvement as evidence that the earlier work was never complete. The accepted result goes back to an earlier percentage position, and its whole basis becomes a candidate for repeated examination. The opposite error treats completion as the end of responsibility, so a recipient's consequential finding has no owner. Between these errors lies a quieter failure. Current sources move on while users stay uncertain about what changed since the edition they adopted.
An acceptance remains an actual historical decision about an identified subject, evidence and limitations. It is not a guarantee that the assessment was infallible. Later evidence can show that an earlier completion claim was wrong, that a commitment was not fulfilled, or that a result people relied on needs correction or withdrawal. The record of the decision can stay while the present assessment changes.
Anyone can raise such a finding and its evidence. The decision to revise acceptance, restrict authorized use or withdraw a release belongs to whoever holds the relevant acceptance or release authority. A new need is different. It does not become an unfulfilled old commitment merely because it is now important.
The phrase “after 100%” is useful only when this distinction stays intact. It identifies work after people have considered an undertaking complete. It does not mean that every possible use was qualified, or that the product has no further room for change. A completed result can stay adequate for its selected use while a later undertaking develops something further.
### Different findings, different consequences
A defect is a failure to meet a commitment that applies to the accepted subject. A repair can keep the commitment and change the implementation. The finding also raises a question about past or continuing reliance, because someone can depend on behavior that the edition does not provide. Those who hold the relevant authority consider that consequence when deciding whether notice, correction, restricted use or withdrawal is warranted. A merged repair does not by itself answer the recipient's question.
A recipient can also show that the result meets its stated commitments but is unfit for the use that those commitments were meant to serve. This is a validation gap. The examination may have established conformity accurately, while the chosen criteria missed something consequential about the purpose. The finding goes back to the people responsible for the commitments and the intended use. It can warrant a revised basis, a changed permitted use or further examination.
Passing checks alone cannot resolve such a gap. And not every later preference shows one. What matters is how the finding relates to the original intended activity, and what evidence shows that the result is inadequate.
An implementation refinement can improve the means without a change to the promised behavior. A factual clarification can improve the explanation without a change to what the product did. Both can be small, but neither is automatically harmless. A person can rely on an explanation to decide whether an operation is suitable. A changed implementation can affect a consumer whose assumptions were not recorded locally.
A changed environment or dependency gives another possibility. The source can stay identical while the operating system, the input range or a supporting component changes. Earlier evidence can remain an accurate account of its subject without establishing the new use. The maintenance question then concerns how the retained result relates to the changed circumstances. It is not necessarily a question of an original defect.
A new priority or a requested capability can change the intended result itself. Its authority comes from a current undertaking or an applicable standing grant, not from the earlier acceptance of a product. Some of this work is an ordinary bounded extension. Other work changes the product's commitments enough to need a revised basis. A full definition exercise for every repair is no more adequate than treating every extension as maintenance that is already authorized.
One report can contain several of these meanings. A misleading behavior can expose a product defect, a poor explanation and an examination method that missed a class of failure. A product repair addresses one consequence, and reflection on the shared practice addresses another. These distinctions help people understand the report. They are not an exhaustive classification that every finding must pass through.
### The reach of a later change
A change can be local in how it is made and wide in its effects. One validator condition can change which inputs the validator accepts from many consumers. A substantial explanatory revision can leave all their adopted instructions untouched. Examination follows the changed claim, the relationships it affects and the consequences of error. It does not follow the age of the product or the number of edited lines.
The account of evidence reuse in chapter 6 applies here too. A repaired interface can warrant focused regression and consumer checks without a repeat of an unrelated product qualification. When the subject of each check stays explicit, people can understand both the reuse of evidence and the need for new verification.
A published edition keeps its identity while maintained sources continue to develop. A correction can appear as an identified successor with a meaningful account of the change. It need not silently replace the bytes that earlier evidence and decisions named. A consumer can then assess the consequences and keep its own basis for current reliance.
This separation also means that a merged source repair is not necessarily delivered. The recipient can use an older package, a copied instruction or a product that embeds a selected library revision. Publication and adoption connect the changed result to those actual uses. Whether accumulated changes warrant another edition is a decision about their usefulness, their risk and their intended recipients. A calendar interval or a count of commits can prompt that decision but cannot make it.
Current descriptions matter between releases. A sentence can mislead a reader when it presents development material as part of a published edition. An old statement that an approval is still pending can also mislead. History can keep the sequence. But a person should not have to reconstruct that history only to identify what a current statement refers to.
### Continuing ownership without endless work
The participants in a later undertaking can differ from those who produced the original result. Continuity depends on the maintained project's responsibilities, recoverable source, evidence and limitations. It also depends on the actual arrangements with recipients. It does not need one agent session to stay alive indefinitely, or a comprehensive registry of every possible consumer.
Each later piece of work still needs a clear purpose, authority and a usable result. A request and a focused examination can be enough. An adopted support obligation can itself authorize and require responses. Its scope matters, just as the scope of a new assignment does. Without such an obligation, an old improvement idea does not become an active task.
A maintained product can also reach the end of its maintained life. Retirement concerns which work and support will continue, how existing reliance is treated and which source stays recoverable. Retirement need not erase earlier editions, and recovery need not reactivate development. Where known reliance or an adopted arrangement continues, its consequence deserves explicit treatment. An assumption that silence ended the relationship is not such treatment.
So maintenance lets completion stay meaningful without making the result immune to further understanding. The work can end. Responsibility and later inquiry take the forms that the actual product, commitments and people warrant.
## 9. A library learning from its own work
The following episodes concern the concentrated Root library undertaking from PRD acceptance on October 31 to the release record on November 1, 2026. That undertaking built on months of earlier development. This chapter is a documentary examination of identified source and review records. It does not execute the reported tests again, and its conclusions concern these cases. App and SWBPIPE appear through bounded consumer evidence, not as freshly qualified products. The source references at the end of this chapter identify the maintained accounts and the actual integrated revisions.
### A draft interpretation challenged in review
The F-02 undertaking addressed how shared references apply. Some passages mixed reusable concepts with historical product ownership, or appeared to impose Root governance on independent projects. An agent wrote a draft qualification that treated part of the format-validation account as legacy-only.
Before integration, an independent examination compared the draft with the actual code. It exposed a counterexample: a current ScopeOfWork caller and validator still depended on the distinction that the account described. The broad interpretation would have made the explanation easier to simplify, but only by misdescribing a live use. The repair qualified the actual scope. It did not erase current behavior or historical adopted contracts.
The episode supports the value of review with access to the actual code and its consumers. A plausible proposed explanation was corrected before it became integrated guidance. It was not a deployed interpretation whose failure appeared later through user experience. Consistency among the draft documents alone would not have exposed the error.
### A boundary that made work too small
During F-02, the owner also questioned the scale of what the undertaking returned. An early touchpoint for interpretation had become a stop before the connected publication work was carried through. The owner authorized a trial of a more coherent boundary. The implementation owner then carried the reference changes, the rendered publication and the reconciliation through as one result.
The first reflective conclusion was that the existing ownership guidance could stay while its application changed. Later discussion separated orchestration from reflection and led to a small separate `reflect-on-work` method. The two have different subjects. Orchestration carries connected contributions to a result. Reflection examines whether the chosen practice serves the intended purpose.
The record supports those interpretations and their actual consequences. It gives no controlled comparison of productivity. Fewer fragmented returns can be useful to the person without support for a general numerical claim about efficiency.
### Reconsidering where instructions belong
The owner questioned the value of the bundled change workflow given the agents' capability and actual use. The owner said: “It's seldom used in the right manner when agents are the ones invoking it. The task is easy for agents to do.”
The library undertaking removed the change workflow and the Root change skill. It moved the needed Git conventions and a recovery entry into the repository instructions that agents read every turn. Detailed recovery guidance stayed available on demand. The removal of two packages redistributed guidance. It did not by itself establish a reduction in attention, interruption or maintenance cost.
The retirement did not silently substitute an unrelated method. Explicit selections of the removed packages and of the historical CHANGE route failed, while historical identities and source pins stayed recoverable. Bounded inspections of consumers separated known present uses from uses that were not searched or that were selected dynamically.
The episode connects a poor fit with agent use to a changed assessment of what agents can carry without a separate procedure. Their consequences depend on the functions that stayed and on the actual consumers. Deleted text is not by itself evidence of reduced burden.
### Reflection and the 60% decision
The owner asked for an actual use of the newly adopted reflective method to examine readiness at 60%. Its first recorded application here was by the Agent 0 that had developed it. The inquiry considered what was established, what the next work would rely on, and whether more activity was necessary. It found stale standing descriptions, together with bounded evidence that supported a decision to proceed.
The consequence was factual reconciliation and further concrete work, including fresh-reader discovery and a broader source-delivery candidate. The owner made the gate decision. The later 90% assessment assembled evidence for specific claims across the seven deliverables. It kept the limits of the named-reader, custody and archive cases.
The reflection did not need to find a new mechanism to be useful. It helped separate work that would improve the result from activity that would only repeat an examination. The outcome also showed why current descriptions matter. A correct historical account can mislead when a sentence in the present tense still says that a decision is pending.
### An identified delivery
Library 1.0.0 was accepted and published from `fc73de583d25bf792d5c3abb3bf1ac8e0c38f7d6`. The delivery preparation checked that the complete source archive matched the Git bytes and executable modes. It also checked that resources and notices were retained. It reused selected behavioral evidence where operational sources were unchanged. After publication, the public archive and checksum were downloaded and compared with the prepared result.
The named App-reader case had established capture, declaration and content identity for particular package bytes, through a reader at an identified App revision. It did not supply evidence of runtime execution or universal adoption. The custody case was labeled, and the holder and the maintainer were the same. A write from a separate process exposed the absence of filesystem exclusion. These limits were part of the accepted result.
So a useful library edition could be completed without proof of every imaginable later use. Its usefulness depended on how four things related: actual commitments, bounded evidence, an identifiable delivered subject and the owner's decision. The publication remained available for each consumer to inspect and adopt independently.
### After the edition
The selected post-completion record is one improvement made on the same day. It is not a longitudinal study of maintenance. PR #1791 recorded the acceptance and the release pointer in current sources and kept the approved archive. PR #1792 then clarified how readers could select material, follow releases and inspect updates. Its owning records separated guidance in the source about subscription from a subscription that was actually configured and from a notification delivery that was tested.
The change addressed a usability need that was newly stated. Its records did not present it as proof that the published edition had failed an accepted commitment. The owner authorized the concrete improvement and its integration. Publication of another edition remained a separate decision. The archive stayed at its original source, while the README on the development branch gained later guidance.
This small case gives post-completion work an identifiable subject. An accepted edition, its maintained source, an authorized improvement and a future publication were related but not interchangeable. The case is evidence of that relationship. It is not evidence of how well readers used the guidance, or of the adoption of any later edition. The sources are [PR #1791](https://github.com/sgttomas/chirality/pull/1791) and [PR #1792](https://github.com/sgttomas/chirality/pull/1792), the latter integrated at `843824e10e0664a2cb5251280e863fd7b4f3e4f8`.
### Sources for the case
- [F-02 applicability and repair](../../execution/PKG-02/DEL-02-02/Work/Applicability.md), integrated in [PR #1783](https://github.com/sgttomas/chirality/pull/1783) at `1357d706ea77497903976bf159f3880bea4d1360`.
- [Reflective basis](../../execution/PKG-04/DEL-04-02/Work/ReflectiveBasis.md) and [maintenance basis](../../execution/PKG-02/DEL-02-01/Work/MaintenanceBasis.md), including [PR #1785](https://github.com/sgttomas/chirality/pull/1785), integrated at `047da79894bc5631dca564a30113f2cd26ec7ae1`.
- [PR #1786](https://github.com/sgttomas/chirality/pull/1786), integrated at `547e7d7f833f9bec351f7a034bddd7c1a37db15a`, records the 60% standing and the bounded fresh-reader examination. [PR #1788](https://github.com/sgttomas/chirality/pull/1788) carries the later factual reconciliation of needs. [PR #1789](https://github.com/sgttomas/chirality/pull/1789) records the owner's 90% decision.
- [Consumer basis](../../execution/PKG-05/DEL-05-01/Work/ConsumerBasis.md) keeps selected evidence about obtaining, readers, the archive and change inspection. [Library 1.0.0](https://github.com/sgttomas/chirality/releases/tag/library-v1.0.0) identifies the released source and artifact. [PR #1791](https://github.com/sgttomas/chirality/pull/1791), integrated at `ceb2d9bd72bd8bdd6c8b959836d6fe83a60d802c`, records its acceptance and verified publication in current source.
## 10. A constructed document-review undertaking
This is a constructed example. It shows relationships among purpose, state, evidence and responsibility. It is not a report of App behavior or a new requirement for that product.
### From an implementation request to a useful result
A person asks for an agent review panel in a document editor. Discussion shows that the required activity is to inspect proposals while the person keeps control of accepted text. A rejection must leave the document unchanged. An accepted change must be recoverable through undo and persistence.
The implementation owner finds an existing proposal representation, a document store and a history mechanism. The display can show several proposals, but the apply operation assumes one current proposal. This finding changes the next useful work: the connecting behavior needs examination before the interface becomes broader.
The bounded undertaking includes display, acceptance, rejection, undo and the behavior on save and reopen. It excludes automatic acceptance and unrelated redesign of the editor. The need on the document store is stated as rejection of a stale base revision. The need on the history mechanism is the ability to reverse the accepted change without a change to unrelated edits.
The difference between a component and the condition it must meet makes parallel work possible. An interface illustration can proceed independently of the store implementation, while persistence and permission behavior receive separate examination. The boundary of the assignment concerns a usable path, not only a set of edited files.
### A private success that fails in combination
The implementation generates a proposal against a known revision. The person accepts it, and the result is saved and reopened. Display checks and storage checks pass separately. The connected exercise shows that reopening loses the proposal identity that undo needs.
The finding is not a reason to discard the whole design, and it is not evidence that the passing unit checks were worthless. It identifies a relationship that those checks did not establish. The implementation owner repairs the history representation and repeats the affected path, including rejected and stale proposals. Unchanged display evidence stays applicable to its actual subject.
Next, the participants consider a simpler repair that looks convenient: remove undo for changes that agents generate. That repair would change the commitment instead of fulfilling it. The proposal needs a substantive decision about consequence. A revised expected result that makes the existing test pass is not such a decision.
### What the person receives
The final result includes a path that can be demonstrated: proposal, acceptance or rejection, persistence and recovery, with the relevant limitations. The product description matches what the implementation actually does. The person can see the difference between a permitted design refinement and a changed promise.
A merge identifies a source result. Whether it is enough for acceptance or release depends on the selected subject and the remaining conditions. If the same path later meets a different persistence backend, the earlier case gives relevant questions and partial evidence. It does not give an automatic qualification.
The force of the example lies in the connection among the activity, the commitment and the examination. Its sequence is one constructed way for those relationships to become visible. A repeat of its steps in another product would not guarantee that the important failure was found.
### A constructed continuation after acceptance
Suppose the document editor has been accepted for the stated use. A later recipient finds that a rejection after an interrupted save leaves a proposal applied. The report concerns an apparent failure of the accepted commitment, not a request for a new feature. Reproduction and diagnosis would establish the affected conditions. The consequence for people who already rely on that behavior would stay a separate question from whether a patch passes its checks.
A request for batch acceptance has a different subject. It changes the activity that the person wants to perform, and it can need new commitments about which proposals are considered together. An upgrade of the storage library raises a third question. The intended behavior can stay the same while the conditions that supported earlier persistence evidence change.
These situations can warrant work of different scope, even though each arrives after completion. The earlier edition and its evidence stay identifiable. The current assessment can change where a defect undermines it, while valid evidence stays useful elsewhere. The constructed continuation shows why a maintenance label alone cannot decide the necessary authority, examination or delivery.
## 11. Two constructed contrasts
These examples are also constructed. Their difference in scale helps to examine proportionality without equating it with vagueness or weak assurance.
### A small correction
A person asks for a correction to a confusing error message. The agent reads the current message, its caller and the relevant test. The message describes a format error as a permission failure. The distinction matters because the message sends the user toward the wrong remedy.
The bounded change repairs the wording and exercises the affected path. It leaves permission behavior unchanged. Under suitable project rules, one agent can carry this work through without a manager hierarchy, a new project definition or a global census of relationships.
Small work still has a substantive question: does the corrected message accurately explain the condition and a useful next action? The nature of the claim and its consequences justify a shorter process. The number of changed lines alone does not. If the investigation had instead exposed an authorization defect, the appropriate work and examination would change with that finding.
### A parallel technical investigation
A project compares approaches to a consequential calculation. The contributors share an input definition, an acceptance basis and an independent reference. The coordinator examines whether that reference supports the intended range, and whether the contributions use compatible units and conventions.
Several approaches can then proceed at the same time. One contributor reports a discrepancy outside the range that the reference supports. That observation limits the comparison. It does not by itself establish an implementation error or invalidate the other results. Another contributor finds a units inconsistency in the shared input definition. That finding can affect all dependent results, even when each implementation is sound.
The two findings need different responses. The first needs an adequate basis for the disputed comparison. The second needs a correction of the common input and a reasoned assessment of which results it affects. More workers cannot make up for a mistaken shared premise. And an adequate shared premise does not justify holding independent work behind an unrelated delay.
The final comparison states its actual coverage, limitations and material differences. The responsible person chooses on the basis of the intended use and its consequences. The person does not select a winner by test count or execution speed. These are explanatory possibilities, and the case gives no benchmark result for SWBPIPE or any other named solver.
## 12. Reflection across undertakings
### Experience that changes the question
Reflection can examine whether a local result fulfills its commitment. It can also reach the framing of that commitment, or the chosen practice itself. A troublesome result can show missing behavior, inadequate evidence, a mistaken interpretation or an unsuitable approach. These possibilities are related but not interchangeable.
In the Root case, review against an actual caller changed a draft explanation. The owner's experience of fragmented returns changed the size of a useful undertaking. The first concerned how a shared claim applies. The second concerned how work was carried. They did not need the same mechanism, although both affected the library's practice.
A repeated difficulty can suggest a shared cause. Recurrence alone cannot establish that cause. Similar symptoms can come from different conditions, and one consequential event can be enough to expose a serious defect. The value of reflection depends on how experience, explanation and consequence relate.
### Learning across projects
The thesis brings App and SWBPIPE into its argument through identified documentary and implementation bases. Its evidence account of October 30 includes App redevelopment and stored SWBPIPE comparison material, with the limits that the [thesis source account](../thesis/README.md#source-basis-and-historical-editions) states. That work makes project experience available for a wider inquiry. It does not turn this book into a report of fresh tests.
The differences between the projects give material for this inquiry. A workflow-authoring environment raises questions about proposal, review and use. An engineering analysis product raises questions about assumptions, numerical meaning and reliance. The library's own development raises questions about instructions, explanation and the maintenance of the means used to maintain them. These are areas of inquiry. The book does not claim that they are resolved, or that the named products exhaust them.
The author describes the connections made so far as occasional interventions, made when they seemed particularly necessary. The October 4 episode is one documented instance. A systematic practice of learning across the projects has not been established. Developing that relationship is a direction for the wider undertaking. An established learning practice cannot be inferred from shared vocabulary or from the availability of a communication route.
Project owners and their Agent 0s can bring consequential experience into shared reflection. That experience can warrant a changed explanation, method or tool. It can also give a reason to keep the existing practice. Further selection and use can then challenge the result. A development instruction and a method embedded in a product are different consumers. When the library makes a revision available, that does not show that either consumer has adopted it.
This movement has no necessary cadence, and no report is due for every event. Not every local repair must become a change to the shared library. A particular constraint of one project can stay local. The reflective question is what should travel, what should stay situated, and what evidence supports that distinction.
### The book among the means of working
The book is one possible expression of this reflection. It develops connections and tensions that would overwhelm concise instructions. A workflow can offer a practical course of action. The book can examine why that course is useful, where it becomes a burden, and what its abstractions leave out.
A publication's lack of operational authority does not make its reasons irrelevant. Those reasons, and experience, can challenge instructions. A contradiction can become a finding for the people responsible for the practice. While they examine that question, the current commitments keep their actual standing. The inquiry itself does not give permission to abandon them.
The relation also runs toward the publication. A method that works under conditions the book did not expect can expose a weak generalization. A clear instruction can show that an elaborate explanation has lost contact with its purpose. Reflection can revise the account. It does not require practice to conform to every sentence of the account.
The book's contents can make its subjects easy to find without predicting every occasion for reading. A person can read the book on its own, or people and agents can explore it through their actual inquiry. Reading can change what a participant notices. It does not establish shared understanding merely because the same text has entered several contexts.
### Burden and the cost of a useful result
A fast draft can be expensive after people count preparation, review, correction and recovery. More concurrent work can increase waiting. Fewer interruptions can be valuable, but silence can also hide an unexamined choice. Counts of files, agents, tests or messages are observations. Their significance depends on what was produced and what it cost to make the result usable.
The length of an instruction is a poor measure of its burden. One sentence can require hundreds of artifacts. A substantial explanation can prevent repeated misunderstanding without assigning any recurring work. A retired control can return under a new name when people no longer understand its original purpose.
The thesis's [reading of Polanyi](../thesis/03_philosophical_framework.md#365-what-the-chirality-metaphor-contributes) gives this concern a positive account. Attention can proceed from subsidiary particulars toward a meaningful whole. Records and instructions help when they support attention to the work. They cause trouble when their maintenance becomes the focal activity and displaces what they were meant to make understandable. This is the thesis's interpretive grounding, not a new empirical finding about every record system.
The thesis's [development history](../thesis/appendix_e_development_history.md#e32-the-warrant-sequence) describes an earlier sequence that treated citation, review and authentication as stages of improving warrant. Later reconsideration separated unlike relationships instead of adding another stage. The [coordinated-knowledge-work experience notes](../../workflows/coordinated-knowledge-work/REVIEW-NOTES.md) similarly connect guidance to reported incidents and keep their evidential limits. These accounts make changes to an abstraction open to examination. They do not prove that every later simplification improves practice.
The effects of an instruction change also depend on its actual consumers and on the tools that enforce it. If a validator still rejects a newly authorized operation, the revised prose has not made that route usable. If CI still requires a retired artifact, the retired duty still consumes work. The F-02 counterexample exposed the complementary mistake in a draft: the draft treated behavior as legacy while a current caller still used it. Reflection on practice must reach these relationships if its conclusions are to take effect.
Mechanical repetition sometimes warrants a tool. That tool brings its own costs of selection, failure and maintenance. Automation can answer the wrong question reliably. Its value depends on how the operation relates to the decision it supports. The fact that an agent no longer performs the operation by hand does not establish that value.
### Questions that remain open
How much common orientation helps an agent recognize a consequential distinction, without making every task carry a growing set of instructions? How can a project keep the reason for a practice while it lets later experience change that practice? When does a useful local solution deserve a shared form? And when does generalization erase the circumstances that made the solution useful?
These questions are not missing steps in a universal process. They stay open because situations, capabilities and commitments can change. The available evidence supports particular conclusions and leaves room for people to discover an important relationship elsewhere.
The thesis identifies [self-confirmation](../thesis/09_discussion.md#95-summary) as a danger for its own practice. The danger applies here too, because the agents that draft and examine this book share much of its conceptual basis. And the first use of the reflective method in the Root case was close to the design of that method. Agreement among these agents can improve an argument. It does not independently demonstrate the framework's efficacy. Documented local achievements still count for what they establish.
The continuing worth of this account depends on whether it helps people and agents make these relationships understandable and discuss their consequences. The same work from which it draws its substance can correct it. A coherent book is an achievement in explanation. The practice remains larger than the explanation.
## 13. Distinctions used in this book
These terms express distinctions that the argument uses. The [thesis glossary](../thesis/glossary.md) develops their conceptual background. In a particular undertaking, their use still depends on identifying the actual subject and conditions.
| Term | Meaning in this account |
| --- | --- |
| Accountability | Answerability for commitments and consequences. Execution responsibility can be delegated without transferring the person's responsibility for reliance. |
| Reckoning | The investigation, interpretation, inference, planning, criticism, checking and adaptive action that this framework attributes to the agent. |
| Judgment | The person's situated, committed engagement with what the work means, what matters and what they will stand behind. |
| Knowledge | A knower's situated achievement of understanding. It can be incomplete, mistaken or revised. |
| Information | Material that can be recorded, transmitted and compared. It can support knowing without being identical with it. |
| Commitment | In a production contract, an adopted obligation. In the account of judgment, the person's engagement with what they will stand behind. The subject and context show which of these related senses applies. |
| Assumption | A provisional basis for reasoning. Its grounds and consequences remain open to examination. |
| Proposal | A candidate choice. Permission to develop it does not imply its acceptance. |
| Observation | An account of what occurred under identified conditions. |
| Claim | An assertion about a subject. Its grounds, if any, and its limits can be examined. |
| Evidence | Observation or reasoning that supports an identified claim under stated conditions. |
| Capability | What a participant or tool can do under the stated conditions. |
| Authorization | Authority to undertake an action within the assignment and the governing commitments. |
| Host permission | A technical allowance or restriction that a controlled execution path enforces. |
| Agent 0 | Responsibility for purpose, alignment and continuity with the person, including keeping reserved choices visible. |
| Role | A description of a contribution and its responsibility. Its name alone grants neither authority nor host permission. |
| Contribution owner | The participant responsible for assigned work through examination, repair and transfer. |
| Integration owner | The participant responsible for how contributions become a usable combined result. |
| Deliverable | An intended contribution with conditions and assigned responsibility. It is distinct from the files or identifiers that represent it. |
| Production contract | The connection among a contribution, its outputs, the governing criteria, the interfaces and the basis for examination. |
| Dependency condition | What a consumer needs from a supplier, and at what point. |
| Integration | Bringing related contributions into a usable result and examining their relationships and remaining conditions. |
| Source integration | Bringing a change into a selected source revision, for example by a Git merge. |
| Completion | Fulfillment of agreed work and its required examination within the authorized scope. |
| Edition | An identified state of a work, made available for selection, with its own content and standing. |
| Maintained source | The source that can continue to develop after an edition is identified. Later changes do not silently alter that edition. |
| Delivery | Transfer of an identified result with the information and continuing responsibilities that its use needs. |
| Acceptance | An authorized act concerning an identified subject, scope and purpose. |
| Release | Authorization to make an identified result available for a stated audience or use. |
| Reliance | Use of a contribution as a basis for a decision or action, with responsibility for that use. |
| Verification | Examination of conformity to specified requirements, or to an identified claim or reference. |
| Validation | Examination of fitness for intended use. Narrower uses of the term in tools need their actual subject identified. |
| Reflection | Examination, with the person, of the meaning, framing and usefulness of the work or the practice. It can support retention as well as change. |
| Reconciliation | Comparison of actual results and evidence with the affected commitments and descriptions, and transfer of warranted corrections into the sources that own them. |
## Sources
The philosophical distinctions draw on [The Chirality Framework](../thesis/CHIRALITY_FRAMEWORK.md), particularly its account of knowing, judgment and the accountability gap. The maintained [thesis](../thesis/README.md) contains the fuller argument, the references and the dated evidence. This book does not extend the empirical claims of the thesis by restating them. The source revision and content identity of this edition accompany its rendered form. The publication index distinguishes discovery of an edition from adoption of its content.