3. Contributions and their relationships

3.1 Divide by responsibility

Divide authorized work into coherent responsibilities. Each contribution should advance the result the person needs. Decomposition is not merely division into smaller files or more agents.

A package groups related scope under a meaningful objective. A deliverable is an intended work product within the undertaking, with a defined contribution, conditions and assigned responsibility. Its outputs are the artifacts that realize that contribution. A folder, identifier or graph node can represent the deliverable without establishing that its outputs exist or meet their conditions. 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 scope-of-work document 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. In Chirality, ScopeOfWork.md, Design/ and deliverable.yaml provide homes for these different subjects. Other undertakings can use forms suited to their consumers.

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:

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.

Derive a local view from current declarations and actual code or artifact changes. Plan finer steps within your 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.