Differences

This shows you the differences between two versions of the page.

--- dido:99_annexes:annex-b-terms-and-definitions:a:artifact [2026/07/19 11:32] – nick_dido
+++ dido:99_annexes:annex-b-terms-and-definitions:a:artifact [2026/07/20 00:51] (current) – nick_dido
@@ Line 5: / Line 5: @@
 ===== Discussion =====
-An Artifact is an identifiable work product created, acquired, used, modified, generated, exchanged, delivered, or preserved during an engineering, development, integration, deployment, operational, assurance, or governance activity.
+An Artifact is an identifiable digital work product created, acquired, used, modified, generated, exchanged, delivered, or preserved during an activity.
-An Artifact may be atomic or composite. A composite Artifact may contain, reference, package, or organize other Artifacts.
+An Artifact may be atomic or composite. A composite Artifact may contain, organize, or reference other Artifacts.
-An Artifact may contain information, source content, compiled content, executable content, configuration content, model content, policy content, metadata, or evidence. Examples include:
+An Artifact may have multiple versions. A version may have one or more representations in different formats or media types. Copies of the same representation may exist at multiple locations.
-* Source code
+An Artifact remains distinct from:
-* Executable files
-* Binary files
-* Software libraries
-* Software dependencies
-* Packages
-* Archives
-* Configuration files
-* [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_configuration|Infrastructure Configurations]]
-* [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_blueprint|Infrastructure Blueprints]]
-* Models
-* Schemas
-* Scripts
-* Policy files
-* Build specifications
-* Container Images
-* [[dido:99_annexes:annex-b-terms-and-definitions:m:machine_image|Machine Images]]
-* Manifests
-* Software Bills of Materials
-* Reports
-* Logs
-* Test results
-* [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]]
-An Artifact remains distinct from the physical, logical, or conceptual subject that it describes, configures, instantiates, evaluates, or records. For example:
+The subject that the Artifact describes
+The activity that creates or uses the Artifact
-* An Infrastructure Configuration is an Artifact that represents the desired state of an Infrastructure Environment
+The metadata that describes and manages the Artifact
-* A Machine Image is an Artifact used to instantiate a computing environment
+The repository or location in which the Artifact is stored
-* A software library is an Artifact that provides reusable executable or linkable functionality
+The physical object, system, or storage medium associated with the Artifact
-* A package is an Artifact that organizes one or more related Artifacts for identification, versioning, distribution, installation, or use
-* A report is an Artifact that communicates selected information
-* A test result is an Artifact that records the outcome of a verification activity
-* Evidence is an Artifact retained to support an assertion, decision, or determination
-An Artifact may be:
-* Human-readable
-* Machine-readable
-* Executable
-* Atomic
-* Composite
-* Version-controlled
-* Generated
-* Derived
-* Signed
-* Approved
-* Released
-* Delivered
-* Archived
-These characteristics do not apply to every Artifact and require separate specification where relevant.
 ===== Definition =====
-//identifiable work product created, acquired, used, modified, generated, exchanged, delivered, or preserved during an activity//
+//identifiable digital work product created, acquired, used, modified, generated, exchanged, delivered, or preserved during an activity//
 ===== Source =====
@@ Line 73: / Line 29: @@
 ===== Note =====
-An Artifact may exist in physical, digital, or conceptual form.
+Within Crucible, an Artifact exists in digital form.
-An Artifact may contain or reference other Artifacts. A package, archive, container image, Machine Image, or bundle may therefore constitute a composite Artifact.
+A physical object, system, or storage medium may contain, embody, or be produced from an Artifact, but does not become an Artifact solely for that reason.
-Identification of an Artifact does not by itself establish its revision, approval status, release status, provenance, authenticity, integrity, suitability, or retention status.
+Identification of an Artifact does not by itself establish its version, provenance, authenticity, integrity, approval status, release status, retention status, or suitability for a particular purpose.
-A [[dido:99_annexes:annex-b-terms-and-definitions:v:version-controlled_artifact|Version-Controlled Artifact]] is an Artifact managed through a [[dido:99_annexes:annex-b-terms-and-definitions:v:version_control|Version Control]] system.
+An Artifact may exist independently of Crucible. An Artifact placed under Crucible control is described by an Artifact Catalog Record.
-The term does not require a particular file format, repository, storage medium, packaging mechanism, tool, or implementation technology.
+The term does not require a particular format, media type, repository, storage medium, location, tool, or implementation technology.
 ===== Example =====
-A third-party software package containing an executable, software libraries, configuration files, dependency metadata, and a manifest is a composite Artifact.
+A software package delivered by a third party is an Artifact. Different versions of the package remain associated with the same identifiable work product while constituting distinct managed versions.
----
-<WRAP centeralign>
-© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.
-</WRAP>
+<WRAP centeralign> © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc. </WRAP>