2. A basis that supports action

2.1 What a project basis must do

Establish a project basis that lets you and the other participants act toward the same result without inventing missing commitments. Identify intended users, outcomes, scope, constraints, interfaces, exclusions and acceptance responsibilities. Identify what remains unresolved. Use the person's direction and the governing sources to distinguish what is already established from what you need to propose or investigate.

Scale the form and detail of the basis to the decisions and coordination it must support. 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.

A new session alone is no reason to create a new project definition. Establish a more explicit basis when the intended use or consequence requires it; an informal request may then be insufficient.

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

Prepare a reserved choice so that the person can inspect what you are asking them to decide. 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 assigned responsibility? 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.