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 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 also transcribes an explicit request to develop shared guidance from that experience. The recorded changes and the revision 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.