Artifact-Oriented AI Architecture

1. The response is not the system

The natural abstraction for generative AI is an interaction:

Prompt → Model → Response

For many applications, that is entirely appropriate. A user asks a question, the model produces an answer, and the interaction ends. The response may be useful without ever becoming persistent organizational state.

Consequential workflows create a different problem.

Suppose the output will be reviewed by another model. Suppose a human can approve or reject it. Suppose the system can generate another version tomorrow. Suppose a downstream process will use the approved version as evidence or input. Suppose the application crashes halfway through the workflow and must recover without repeating work. Suppose, six months later, someone needs to establish which version was actually used.

The model response has now become part of a larger system of state and decisions.

A common response-oriented architecture can still save the output. It can assign a filename, database record or conversation identifier. But persistence alone does not answer the important questions:

• What exactly is this object?
• Which version is it?
• What did it consume?
• Has it been validated?
• Has it been reviewed?
• Is it authoritative?
• Has it been superseded?
• Which downstream artifacts depend upon it?
• Can the system reconstruct the decision that made it authoritative?

These are not primarily model questions. They are architecture questions.

The underlying engineering concerns are not new. Configuration-management practice has long addressed identifiable configuration items, controlled change and formally agreed baselines [2,3], while provenance models represent how entities are generated, used and derived through activities [1]. NR-02 examines what those concerns become when the objects being created and revised are generated probabilistically by AI systems.

The distinction that emerged while building EPS was therefore:

A response describes something a model produced. A governed artifact describes something the system knows exists.

That difference became increasingly important as EPS moved from a sequence of AI calls toward an end-to-end governed workflow.

2. From model output to governed artifact

In EPS, a governed artifact is not simply a JSON file containing model output. It is an identifiable, versioned system object whose state, authority and relationships to other artifacts are explicitly represented.

Identity, controlled state and lineage have established precedents in configuration-management and provenance disciplines [1–3]. NR-02 combines those familiar mechanisms around AI-generated work and adds an explicit distinction between the existence of an artifact and the authority granted to a particular version.

Four dimensions are especially important.

Identity

An artifact must first be independently identifiable.

Configuration-management guidance treats configuration identification as a foundational activity in managing controlled items [3].

EPS artifact metadata includes an artifact identifier and type, schema and contract versions, case identity, creation time and creator. The content therefore does not have to carry the entire burden of explaining what it represents.

Identity also separates the logical artifact from a particular model execution. A model call may help create an artifact, but the call itself is not the artifact.

Version

Once an artifact can change, identity alone is insufficient.

Provenance models similarly distinguish entities and relationships between derived or revised entities. W3C PROV explicitly represents derivation and revision relationships [1]. NR-02 applies that principle to governed AI artifacts by preserving version identity separately from logical artifact identity.

EPS records a separate version identifier and version number, whether the version is current, what version it supersedes, what later version superseded it, whether it represents regeneration of another artifact, and the reason the version exists.

This creates an important distinction:

• artifact identity answers what object is this?
• version identity answers which state of that object is this?

Without that separation, "the approved artifact" becomes ambiguous as soon as another version is generated.

Lifecycle

Artifacts also move through states.

At the repository level, EPS implements lifecycle states including:

Draft → In Review → Promoted → Published

and additional states including:

Superseded · Invalidated · Archived

Only promoted and published states are classified as authoritative within that repository lifecycle.

Configuration-management practice distinguishes identified configuration state and controlled change over time [2,3]. The specific EPS lifecycle above is application policy; it is not terminology taken from either source.

This matters because a system may legitimately contain several versions of an artifact at the same time while only one is permitted to serve as authoritative input.

Lineage

Finally, an artifact exists in relation to other artifacts.

EPS lineage structures record parent relationships, consumed inputs and produced children. Consumed inputs include the identity and exact version of the source artifact together with the role it played.

Formal provenance provides direct precedent for representing generation, use and derivation relationships among governed entities [1]. Software-supply-chain work such as in-toto likewise treats integrity as an end-to-end property of a chain of development and delivery steps [4].

The architecture therefore treats lineage as part of system state rather than as documentation added after the fact.

3. Generation does not create authority

One of the most important architectural decisions in EPS is also one of the simplest:

Promotion creates authority.

Traditional configuration management already distinguishes an existing configuration from a formally agreed baseline. NIST defines a baseline as a configuration that has been reviewed and agreed at a specific point in time and subsequently changed only through controlled procedures [2]. NR-02 applies an analogous distinction to AI-generated artifacts while separating existence, admissibility and authority more explicitly.

This decision arose because the system can contain many legitimate artifacts that should not control downstream behaviour.

An AI model can generate a draft. An evaluator can review it. An optimization process can create another round. A user can compare alternatives. The system can preserve all of them.

Their existence does not make them authoritative.

This separates three concepts that are easily conflated.

Existence means that an artifact has been created and persisted.

Admissibility means that the artifact has satisfied the validation and review requirements necessary for it to advance.

Authority means that a particular version has been explicitly designated for governed downstream use.

In simplified form:

Generation creates a candidate.
Validation establishes admissibility.
Promotion creates authority.

This three-state formulation is the EPS authority model. It is not terminology taken from configuration-management standards. Its purpose is to prevent probabilistic generation itself from functioning as an implicit state transition.

This is more than workflow terminology.

If generation itself creates authority, every new model response can potentially change the state upon which downstream processes rely. A retry can become a state transition. Regeneration can silently replace previously reviewed work. "Latest" can accidentally become synonymous with "approved."

EPS deliberately prevents that collapse.

A downstream stage is expected to resolve the promoted artifact or promoted version reference rather than simply consume whatever happened to be generated most recently.

This moves authority away from probabilistic generation and into deterministic system control.

4. A governed artifact has more than one kind of state

Artifact orientation also exposed a second problem: there is no single useful meaning of "current."

Consider an iterative optimization process.

The system generates Round 1. Round 1 is reviewed and accepted. A second round is then generated in an attempt to improve it.

Round 2 is now the latest artifact.

But what if independent review finds that Round 2 introduced a material regression?

The system may need to preserve Round 2 because it is part of the optimization history. It may even display it so that the user can inspect what happened. But Round 1 may remain the best valid version and the version authorized for downstream use.

EPS therefore separates concepts such as:

• latest_round
• active or displayed round
• best-valid round [7]
• promoted_round

They can point to different artifacts.

Tests in the implemented system explicitly exercise conditions in which these values diverge. In one tested case, a later round receives a higher score but introduces a material regression. The system retains the earlier round rather than allowing the higher-scoring successor to replace it as the governed choice.

Conceptually:

The specific values are less important than the architectural result:

Recency, quality and authority are independent properties.

A new artifact can exist without being better. A better-looking artifact can fail a material integrity requirement. A valid artifact can exist without having been promoted. And an authoritative artifact does not cease to be authoritative merely because the model has subsequently generated something else.

This distinction is especially important for AI systems because probabilistic generation makes iteration inexpensive. The easier it becomes to generate another version, the more dangerous it becomes to equate generation with state transition.

5. Approval should resolve to an exact version

Saying that something is "approved" is useful to a person. It is not necessarily sufficient for a system.

Approved what?

EPS represents promotion using explicit artifact and version references. In the resume optimization architecture, for example, the promotion record identifies the optimization session, section definition and exact promoted round. It can also preserve the basis for promotion, validation decisions, reviewer decisions and source references.

The downstream selection manifest then pins the exact promoted artifact versions used to construct the next governed state.

Its version-pinning mode is explicitly defined as:

explicit_only

This leads to an important architectural principle:

Approval should not merely be a status. It should resolve to an exact governed version.

The general configuration-management principle has strong precedent: an agreed baseline identifies a controlled state and provides a basis for later builds, releases and changes [2]. NR-02 applies that idea to AI approval by binding authority to the exact artifact version that was actually reviewed.

Consider the alternative.

A human approves Version 3. The system later generates Version 4. If downstream processing retrieves "the current document," the meaning of the original approval becomes uncertain. Did the approval apply to the logical document, regardless of subsequent changes? Did it apply only to the content that existed at the time? Can the system still retrieve that content?

Version-pinned authority removes that ambiguity.

The approval applies to a specific object in a specific state.

That becomes particularly important when AI systems begin operating across multiple stages. A downstream model should not silently receive a newer version merely because one exists. It should receive the version that the governing process authorized.

6. Revision should create history, not rewrite it

A related EPS architectural decision states:

Promoted artifacts are immutable.

Once an artifact has become authoritative, subsequent revision creates a new round or successor version rather than modifying the authoritative artifact in place.

The reason is not simply record keeping.

Suppose an approved artifact is edited after promotion. Any prior evaluation now refers to content that no longer exists in its evaluated form. Any downstream artifact that claims to have consumed it may no longer be reproducible. The approval itself becomes historically ambiguous.

Mutation can therefore destroy lineage even when the resulting content appears perfectly reasonable.

EPS's implemented lifecycle tests exercise the alternative explicitly. A first version can be created, submitted for review, promoted and published. A successor is then created as a new version. The predecessor remains in the repository. When the successor becomes authoritative, the original is marked as superseded and the relationship between the two versions is retained.

The history is not erased by improvement.

Controlled revision and preserved configuration status are established configuration-management concerns. ISO 10007 identifies change control and configuration status accounting as core activities [3], while NIST requires agreed baselines to be changed through controlled procedures [2]. The EPS immutability rule is stronger and application-specific: a promoted artifact is preserved while revision creates a successor version.

This produces a broader principle:

Revision should create history, not rewrite history.

For traditional deterministic systems this may sound familiar; versioning is hardly new. What changes with generative AI is the frequency and ease with which alternatives can be created.

An AI system may generate, critique, rewrite and compare several versions in minutes. Immutability and explicit succession therefore become more — not less — important as generation becomes cheaper.

7. Lineage must follow versions

Once artifacts are versioned, lineage cannot stop at the document level.

Saying that Artifact B was derived from Artifact A may not be enough. If Artifact A has five versions, which one did B actually consume?

EPS's common lineage contract records consumed inputs using both an artifact_id and version_id, together with the consumption role.

That allows lineage to answer a more precise question:

Which exact governed state contributed to this downstream artifact?

W3C PROV provides established relationships for use and derivation among identifiable entities [1], while in-toto provides an end-to-end integrity model across a sequence of software-development steps [4]. NR-02 applies comparable precision to the exact versions of governed AI artifacts consumed downstream.

This distinction separates structural lineage, which is the focus here, from the more detailed evidence traceability addressed in NR-03 [6]. Structural lineage asks:

• Which artifact was consumed?
• Which version?
• In what role?
• What artifact resulted?
• What is the predecessor/successor relationship?

Evidence traceability asks a different question:

• Which evidence supports this particular assertion or conclusion?

Both matter, but they operate at different levels.

Artifact lineage establishes the chain of governed system state. Evidence traceability establishes the support for meaning within that state.

A system can have one without fully having the other. A robust consequential workflow may require both.

8. One authoritative source means one authoritative source

As EPS evolved, another architecture problem became visible.

A mature application often accumulates representations of the same information: historical snapshots, compatibility files, UI state, intermediate outputs, repository artifacts, cached projections.

The problem is not necessarily that these representations exist. Compatibility is often necessary during system evolution.

The problem appears when more than one can plausibly claim authority.

Configuration management addresses a related concern by controlling identified items and agreed states rather than allowing uncontrolled changes to redefine the managed configuration [2,3]. NR-02's one-authoritative-source rule is the EPS response to the additional problem of multiple technically valid representations coexisting in a multi-stage AI workflow.

EPS therefore adopted another explicit architectural decision:

Each stage has one authoritative source contract.

In the implemented workflow, Stage 08 consumes approved Stage 07 governed packages. Stage 09 consumes promoted Stage 08 section versions. Stage 10 consumes the promoted Stage 09 assembled resume together with governed evidence references. Stage 11 consumes promoted Stage 09 and Stage 10 artifacts.

Compatibility sources may remain, but fallback must be explicit rather than silent.

This gives us a useful general principle:

Compatibility is acceptable. Competing authority is not.

That principle matters well beyond EPS.

Organizations introducing governed AI into existing platforms rarely have the luxury of replacing every historical data path at once. Legacy representations will remain. Transitional architectures will exist. Governance does not require pretending otherwise.

It does require the system to know which representation wins when two representations disagree.

9. The interface should project authority, not invent it

Artifact orientation also changes the relationship between the user interface and the underlying system.

In EPS's governed artifact lifecycle, presentation clients can issue operations such as: load, review, edit, validate, save, regenerate, promote, materialize, assemble, publish and reload.

But the workspace does not become the authority for the resulting state.

The implemented lifecycle deliberately keeps repository authority outside presentation code. Persistence, validation, version resolution, lineage and publication truth remain repository responsibilities. After an operation, repository-backed context is rebuilt and returned to the interface.

Conceptually:

User action → Governed lifecycle command → Repository/runtime operation → Authoritative state rebuilt → Interface refreshed

This distinction is easy to overlook.

A UI often knows which item the user clicked, which draft is visible and what local state appears active. It can therefore be tempting to let the interface infer what the authoritative state must be.

But local interaction state and governed system state are not the same thing.

The architectural principle is:

Presentation state should describe governed truth, not create it.

This also improves recovery. After interruption or restart, the application can reconstruct state from governed artifacts rather than attempting to infer authority from what the interface previously displayed.

10. Governance has to survive the final mile

One of the more useful lessons from EPS came not from model generation but from publication.

The governed runtime had evolved to use promoted artifacts and explicit version references. Parts of the final export path, however, still reconstructed documents from historical run-folder snapshots.

Both could be technically correct in isolation.

Architecturally, they represented two competing ideas of truth.

Software-supply-chain research provides a useful analogue. in-toto treats integrity as a property that must be verifiable across the chain from project inception to deployment, because compromise at any step can affect the delivered software [4]. The EPS publication issue is not a software-supply-chain attack, but the architectural lesson is similar: governance can be lost at a transition between otherwise well-controlled stages.

The publication architecture was subsequently changed so that export resolves repository-authoritative publication artifacts and their pinned dependencies before translating them into the existing document-rendering contracts.

The authoritative publication path now includes governed objects such as the optimization selection manifest, assembled resume, cover-letter package, package assembly manifest, final application package and publication manifest, together with pinned section artifacts.

Historical snapshot files can continue to exist for compatibility, but they no longer determine the authoritative resume or cover-letter export.

This is a useful example because governance can otherwise disappear at the boundary between the governed system and its final output.

An organization may build careful approval and evidence controls upstream, only to have an export service, reporting layer or integration reconstruct its own version of state from a convenient cache.

The final document may look correct.

The authority chain is still broken.

A governed architecture therefore needs to preserve authority through the entire path by which information becomes operational output.

11. Artifact orientation changes recovery

A response-oriented AI workflow can make recovery surprisingly difficult.

If a process stops after six model calls, what exactly should happen next?

One option is to reconstruct the conversation and ask the models to continue. Another is to regenerate missing work. Both approaches can be appropriate in lightweight applications.

They are less attractive when previous work has already been reviewed or approved.

Governed artifacts provide another option.

The system can inspect persisted state to determine: which artifacts exist; which versions were completed; which versions were validated; which artifacts were promoted; which dependencies they consumed; and what remains unfinished.

Recovery can therefore resume from governed state rather than treating model context as the primary record of what happened.

This is an important operational consequence of artifact orientation.

The architecture is not only about auditability after the fact. It changes how the system behaves during failure.

12. Artifact orientation does not eliminate probabilistic reasoning

None of this requires removing the model from meaningful decision work.

In EPS, models remain responsible for activities where probabilistic reasoning is valuable: interpretation, writing, semantic judgment, evaluation and recommendations.

The deterministic architecture is responsible for a different class of questions:

• What artifact is this?
• Which version is it?
• Does it satisfy the required schema?
• What source versions did it consume?
• What state is it in?
• Has it been promoted?
• Which version is authoritative?
• What downstream artifacts depend upon it?

This is an important boundary.

Trying to make model behaviour deterministic would sacrifice much of what makes generative AI useful. Allowing probabilistic reasoning to determine system authority, however, creates a different problem.

Artifact-oriented architecture provides a way to combine the two:

Probabilistic reasoning can create and assess possibilities. Deterministic controls govern what those possibilities are allowed to become.

This is one of the deeper connections between NR-01 [5] and NR-02.

The objective is not deterministic AI. It is deterministic governance around probabilistic work.

13. What an organization needs to decide

Existing configuration-management and provenance disciplines provide much of the underlying machinery — identity, controlled change, baselines, status and lineage [1–3]. The questions below are NR-02's interpretation of when those mechanisms become necessary around consequential AI-generated work.

An organization does not need EPS's architecture simply because it uses a language model.

For a disposable conversational response, governed artifact infrastructure may add cost without corresponding value.

The architecture becomes more relevant as AI output acquires persistence and consequence.

Five questions help establish whether that threshold has been crossed.

What are the governed objects? Not every intermediate model response deserves independent identity. But an output that will be approved, reused, published, relied upon downstream or defended later probably does. The first design task is therefore to determine which objects require governance.

What creates authority? Organizations should be explicit about whether authority is created by generation, successful validation, model evaluation, human approval, formal promotion, or publication. Those states are not interchangeable.

Can authority resolve to an exact version? If the system says a document is approved but cannot establish which version was approved, the approval mechanism is incomplete.

Can downstream processes identify what they consumed? A reliable lineage chain should identify exact source versions rather than merely logical document names.

Can a new version exist without replacing the authoritative one? This becomes increasingly important as AI systems iterate on their own outputs. If generating a successor automatically changes downstream truth, optimization and governance have been coupled too tightly.

14. The cost of artifact orientation

Artifact-oriented architecture is not free.

It introduces additional engineering responsibilities: artifact identity, schema management, lifecycle services, version management, lineage, dependency handling, authority resolution, migration, persistence, recovery, validation and testing.

These controls can themselves become poorly designed. Excessive schema complexity can slow development. Overly rigid lifecycle rules can make legitimate iteration difficult. Maintaining artifacts that have no consequential role can create bureaucracy without reducing risk.

EPS should therefore not be read as evidence that every AI system needs the same artifact model.

It is an implemented case from which a more limited proposition can reasonably be drawn:

As AI-generated work becomes persistent, iterative and consequential, the system increasingly needs an explicit representation of identity, state, version, lineage and authority outside the model itself.

The appropriate implementation depends on consequence, workflow complexity, regulatory requirements, reconstruction cost and the degree of human oversight required.

The design question is not:

Should every AI output become a governed artifact?

It is:

Which outputs are consequential enough that the system must know what they are, where they came from, which version matters and whether they have authority?

15. From artifact lineage to evidence traceability

Artifact orientation solves an important part of the governance problem, but not all of it.

A system may know that Artifact B consumed Version 3 of Artifact A and still be unable to establish which evidence inside Artifact A supports a particular statement in Artifact B.

That distinction becomes increasingly important as AI systems synthesize information rather than merely transform it.

Structural lineage can tell us where an artifact came from. It cannot, by itself, tell us whether a conclusion is adequately supported.

That is the next problem in this research series.

NR-03 examines how deterministic evidence diagnostics can measure proof coverage, evidence reuse, complementary support, evidence availability and selection traceability without asking the model to decide what its own evidence relationships should have been [6].

Conclusion

Language models produce responses. Consequential systems need durable state.

The shift from response-oriented to artifact-oriented architecture is therefore not primarily about storage. It is about authority.

When an AI system can generate alternatives, revise its own work, recover from interruption, feed downstream processes and preserve decisions over time, its surrounding architecture must distinguish what exists from what is admissible, what is admissible from what is authoritative, and what is authoritative from what came before.

The mechanisms surrounding this architecture have established precedent. Provenance models represent generation, use, derivation and revision among identifiable entities [1]. Configuration management establishes controlled items, formally agreed baselines, change control and status accounting [2,3]. Software-supply-chain research demonstrates the importance of preserving integrity across chains of artifacts and processing steps rather than considering individual operations in isolation [4].

NR-02's contribution is the authority model built around those mechanisms for probabilistic AI workflows: generation creates candidates, exact versions remain independently identifiable, revision preserves history, downstream stages consume explicitly authorized states, and creation of a newer output does not itself alter what the system is entitled to trust.

The implementation examined here suggests three particularly important rules:

Authority must be explicit.
History must be preserved.
Authority must not be ambiguous.

In EPS, those rules became concrete architectural decisions: promotion creates authority, promoted artifacts are immutable, and each stage has one authoritative source contract.

Together with explicit identity, versioning, lifecycle state and lineage, those controls allow probabilistic model operations to participate in a system whose state does not itself have to be probabilistic.

The model contributes intelligence. The artifact architecture makes that intelligence governable over time.