Artifacts

What question does this solve?

Work leaves things behind: a requirements document, a prototype, a code change, a set of tests, a deployment record. It is tempting to treat their existence as proof of progress. The model needs a way to name these products while keeping clear that producing something and showing it is adequate are different.

Definition and role

Artifacts are products of the work: concrete outputs such as requirements, prototypes, code and tests, available for evaluation or later use. They make the result of a transformation available to whoever needs to judge it or build on it.

A Delivery Stage states which artifacts are expected and what they will be used for, and its Stage Contract indicates the relevant content of each output and the purpose it must serve. The nature of an artifact depends on the transformation: clarified rules, a prototype, a code change, a test suite or an analysis record.

The model does not give artifacts a chapter of their own. They are defined by their relation to inputs and acceptance in the Stage Contract, and distinguished from the information that supports a decision in Evidence.

How it works

Content and purpose, not just format

Asking for a document does not say which questions it must resolve. Asking for code does not define the behaviour it should implement. The contract should state the relevant content of the output and the use it is meant to serve. Format and organization matter when they affect that use: an integration must provide information the receiving system can use; an analysis must let the person deciding understand its conclusions.

Partial and exploratory outputs

A stage can produce partial outputs or exploratory material. Their existence must be distinguished from the accepted delivery. When there is partial acceptance, its scope must be explicit so that the rest is not considered complete by association.

From artifact to decision

Four things are related but distinct:

Concept	What it is	Example
Artifact	A product of the work	A test that has been written
Evidence	Information that supports a judgment	The result of running that test
Evaluation	Examining the information against a criterion	Interpreting the result against the acceptance criterion
Decision	What is accepted, authorized or routed	The acceptance recorded by a Quality Gate

The same object can play more than one role. A report is an artifact of one stage and can present evidence used in the next. The classification depends on how it is used, not on keeping each role in a separate file.

Delivered with their conditions of use

When an artifact is part of what the customer receives, the conditions of its use should be understandable in the agreement. This matters most for intermediate deliveries: an artifact that nobody can use does not fulfil a purchase, however carefully it was produced.

In the running example

The barbershop’s discovery delivers rules, a prototype, an architecture and the dependencies. These artifacts and their references are handed to the barbershop with their permitted use stated, including use to guide a purchase from another provider under the agreed conditions. Their usefulness never becomes an obligation to buy construction.

During construction, the implementation is an artifact (A3), and the results of integrated validation are another (A4). The first revision of the implementation exists as an artifact long before it is accepted: evaluation finds two overlapping confirmations, and only a corrected revision, evaluated again, receives acceptance. See the example Delivery Unit.

Boundaries and failure modes

An artifact is not evidence of its own adequacy. A requirements document tells you an artifact exists; accepting it requires evaluating whether it meets its purpose. The same applies to an implementation, a set of tests or a deployed change. A document that merely restates the request does not meet the purpose of clarification, however long it is.

Volume is not quality. If AI makes artifacts cheap to generate, it becomes easier to produce many of them. Producing documents that help neither decide nor execute does not show that the purchased advance was delivered, and it adds to the cost of evaluation.

Acceptance is scoped. An accepted artifact shows that the stage’s conditions were met within the scope of the evaluation. It does not guarantee the absence of unknown problems, nor does it show that the business benefit expected from the demand will follow.

Connected concepts

• Structures overview
• Previous: Delivery State
• Next: Evidence, the information that supports judging artifacts
• Stage Contract, where expected outputs are specified
• Glossary