Realization Artifacts
Realization Artifacts
Introduced in In++ v2.0 (§16). A Realization Artifact is a derived, typed artifact produced during and as a result of realizing an intenture - in contrast to artifacts of explication such as the Canvas, Object Card, or Explication Record.
> A Realization Artifact is NOT a one-time intent. It is an output of realization. The intenture is the intent; the Realization Artifact is something the realization process produces to carry that intent forward.
Examples from practice:
- Inspark CVD: SP (Strategic Proposal), IRS (Intenture Realization Strategy), TB (Talent Brief), PB (Performance Brief)
- WiseTeam: Architecture Doc, Agent Spec, API Contract, Pricing Model
- Generic dev: Spec, Plan, Report, ADR (Architecture Decision Record)
These artifacts are domain-specific. The core language does not ship concrete types - it provides only the typing and extensibility mechanism, plus the link back to the intenture. This parallels Knowledge Card Types.
Lifecycle
| State | Description | Transition trigger |
|---|---|---|
| Draft | Artifact created, partially filled | Creation |
| Active | Artifact complete and used in realization | Approval (substantive decision) |
| Stale | Underlying intenture has evolved; the artifact may be out of date | Signal of change in the linked intenture |
| Superseded | Replaced by a new version or another artifact | Approval of the new artifact |
| Archived | Realization complete, or the artifact is no longer relevant | Explicit decision |
Relations
| Relation | Direction | Semantics |
|---|---|---|
| realizes | Directed (artifact → intenture) | The artifact supports realization of the intenture. At least one required. (formula 23) |
| derived_from | Directed (artifact → upstream artifact) | The artifact derives from an upstream Realization Artifact; forms a realization chain. (formula 24) |
| supersedes | Directed (artifact → replaced artifact) | The artifact replaces a previous one. |
'derived_from' lets you build a realization chain - a sequence of artifacts from the initial proposal through to final delivery (for example, in Inspark CVD an IRS depends on an SP, and a TB derives from an IRS).
Type Extensibility
The core language does not define concrete Realization Artifact types - that is the domain's job. Each domain declares its types in a namespace manifest (type_id, schema_url, description, version policy). The 'realization_artifact_type' string carries an optional namespace prefix - for example 'inspark:SP', 'wiseteam:ArchitectureDoc', or the unnamespaced fallback 'Plan'.
Inspark CVD as reference implementation
| Type | Purpose | Created at lifecycle stage |
|---|---|---|
| inspark:SP (Strategic Proposal) | Mirror → Gap → Bridge → Action proposal for the client | Structuring → Realizable |
| inspark:IRS (Intenture Realization Strategy) | Full realization strategy (11 sections) | Realizable |
| inspark:TB (Talent Brief) | Specification for the Hunter agent (creator selection) | In Realization |
| inspark:PB (Performance Brief) | Specification for the Holmes agent (performance tracking) | In Realization |
JSON-canonical form
A Realization Artifact uses the standard envelope plus 'realization_artifact_type', 'realizes', and 'fields'. The core does not enforce the structure of 'fields' - that is defined by the domain manifest for the given type.
{
"$schema": "https://intenture.org/schemas/v2.0/realization-artifact.schema.json",
"artifact_type": "RealizationArtifact",
"schema_version": "2.0.0",
"artifact_version": "1.2.0",
"id": "shkipin-pilot-sp",
"namespace": "inspark",
"realization_artifact_type": "inspark:SP",
"lifecycle_state": "Active",
"realizes": [
{ "intenture_id": "shkipin-pilot", "intenture_namespace": "inspark" }
],
"fields": { "compass": { "objective": "..." } }
}> Principle: Realization Artifacts are derived artifacts, not part of the core language. The core needs only the typing mechanism and the link to the intenture. Concrete types and their semantics are a domain extension responsibility.