Concrete registries and governance of `tag_id` live in separate documents.
---
### 2.3 Artifact
An **Artifact** is the fundamental immutable value in ASL/1:
```text
Artifact {
bytes: OctetString
type_tag: optional TypeTag
}
```
Properties:
* Immutable logical value.
* Two identity-sensitive dimensions:
*`bytes` — exact content bytes.
*`type_tag` — presence + `tag_id` if present.
> **ASL/CORE-ART-EQ/1**
> Two Artifacts `A` and `B` are identical in ASL/1-CORE iff:
>
> * `A.bytes` and `B.bytes` are byte-for-byte equal; and
> * either both have no `type_tag`, or both have a `type_tag` and `A.type_tag.tag_id == B.type_tag.tag_id`.
No encoding profile, store, or runtime may alter this equality.
> **ASL/CORE-IMMUT/1**
> Once an Artifact value is created, it is considered immutable. Any change to `bytes` or `type_tag` produces a **different** Artifact.
---
### 2.4 HashId
```text
HashId = uint16
```
A `HashId` identifies a particular hash algorithm in a given family.
ASL/1-CORE itself is hash-family agnostic. The Amduat 2.0 core stack uses the "ASL1" family defined in HASH/ASL1 as the canonical family for identity-critical References.
---
### 2.5 Reference
A **Reference** is a content address for an Artifact:
```text
Reference {
hash_id: HashId
digest: OctetString
}
```
Interpretation:
*`hash_id` selects a hash algorithm (e.g. `HASH-ASL1-256`).
*`digest` is that algorithm’s digest of a canonical encoding of some Artifact.
> **ASL/CORE-REF-EQ/1**
> Two References `R1` and `R2` are identical iff:
>
> * `R1.hash_id == R2.hash_id`, and
> * `R1.digest` and `R2.digest` are byte-for-byte equal.
No cross-`hash_id` equivalence is defined at this layer. If two different `(hash_id, digest)` pairs refer to Artifacts that happen to be “the same” in some application sense, that is strictly a higher-layer interpretation.
---
## 3. Encoding Profiles
ASL/1-CORE separates logical values from concrete encodings via **encoding profiles**.
### 3.1 EncodingProfileId
```text
EncodingProfileId = uint16
```
Each encoding profile (e.g. `ASL_ENC_CORE_V1`) is defined in its own document and specifies:
* canonical `ArtifactBytes` encodings;
* optionally `ReferenceBytes` encodings;
* invariants required to preserve ASL/1-CORE identity.
The baseline encoding profile in Amduat 2.0 is:
*`ASL_ENC_CORE_V1 = 0x0001` — defined in `ENC/ASL1-CORE v1.x`.
### 3.2 Profile requirements
Any encoding profile used with ASL/1-CORE MUST satisfy:
1.**Identity preservation**
For all Artifacts `A` and `B`:
*`A` and `B` are identical under ASL/CORE-ART-EQ/1
⇔ their canonical encodings under that profile are bit-identical.
2.**Injectivity**
Distinct Artifacts MUST NOT produce identical canonical encodings.
3.**Stability and determinism**
For any Artifact, canonical encoding:
* MUST be stable across time and implementations,
* MUST NOT depend on environment, clock, locale, or configuration.
4.**Explicit structure**
Field ordering and numeric formats MUST be fixed and unambiguous.
5.**Byte transparency**
`Artifact.bytes` MUST be encoded exactly as-is (no hidden transcoding).
6.**Streaming-friendliness**
Canonical encodings MUST be producible and consumable in a single forward-only pass.
Encoding profiles MAY impose extra constraints (e.g. on particular `TypeTag` subsets) but MUST NOT break the above.
---
## 4. Hashing and Reference Derivation
ASL/1-CORE defines how canonical encodings and hash functions combine to produce References.
### 4.1 Canonical encoding step
Given:
* Artifact `A`,
* encoding profile `P` with canonical encoder `encode_P(A) -> ArtifactBytes`,
> Any component that claims to derive References from Artifacts for a given `(EncodingProfileId, HashId)` **MUST** use this exact procedure, including the domain separator.
Encoding profiles and hash functions MUST preserve this identity; they MUST NOT introduce alternative notions of “the same artifact” at this layer.
### 6.2 Reference identity
> **ASL/CORE-REF-ID/1**
> Reference identity is purely:
>
> * `hash_id` equality + `digest` byte equality.
Different `(hash_id, digest)` pairs are always distinct References, even if they logically point to the same underlying Artifact as understood by some higher layer.
### 6.3 Collision assumptions
ASL/1-CORE assumes the configured hash algorithms are **cryptographically strong**:
* collisions are treated as extraordinary substrate failures, not supported behavior.
If two distinct Artifacts produce the same `(hash_id, digest)`:
* ASL/1-CORE itself does not define remediation;
*`ASL/1-STORE` is responsible for surfacing this as an integrity error;
* higher profiles (e.g. CIL/1, FCT/1) MAY define detection and response strategies.
---
## 7. Relationship to Other Layers (Informative)
### 7.1 ASL/1-STORE
`ASL/1-STORE`:
* models StoreInstances as partial mappings `Reference -> Artifact`,
* parameterizes each StoreInstance by a single `StoreConfig = {encoding_profile, hash_id}`,
* uses ASL/CORE-REF-DERIVE/1 to compute References in `put`,
* respects ASL/CORE-ART-ID/1 and ASL/CORE-REF-ID/1.
STORE adds persistence, error semantics, and StoreConfig; it does not change the core value model.
### 7.2 TGK/1-CORE
`TGK/1-CORE`:
* treats `Reference` as graph nodes,
* treats specific Artifacts (EdgeArtifacts) as encodings of graph edges,
* defines a ProvenanceGraph as a projection over Artifacts and configured profiles.
TGK relies on ASL/1-CORE to ensure:
* Artifacts are immutable,
* References are stable and deterministic across implementations,
* all provenance evidence is expressed as Artifacts and References.
### 7.3 PEL/1, CIL/1, FCT/1, FER/1, OI/1
These layers:
* allocate specific `TypeTag` ranges and schemas,
* encode programs, execution traces, certificates, facts, overlays as Artifacts,
* use References consistently via ASL/CORE-REF-DERIVE/1,
* may store those values in ASL/1-STORE and expose them through TGK.
They must not override or reinterpret ASL/1-CORE equality; they build on it.
---
## 8. Conformance
An implementation is **ASL/1-CORE–conformant** if it:
1.**Implements the value types**
* Provides logical structures for `Artifact`, `TypeTag`, and `Reference` with at least the fields described in §2.
2.**Respects Artifact and Reference equality**
* Implements identity exactly as in ASL/CORE-ART-EQ/1 and ASL/CORE-REF-EQ/1 (and the derived ID invariants).
3.**Uses encoding profiles appropriately**
* Uses only encoding profiles that satisfy §3.2.
* For any encoding profile it claims to support, can produce canonical encodings for all Artifacts.
4.**Derives References correctly**
* Derives References strictly according to ASL/CORE-REF-DERIVE/1 for the declared `(EncodingProfileId, HashId)` pair.
5.**Enforces immutability**
* Treats Artifacts and References as immutable logical values.
* Does not leak any mechanism that would let a consumer mutate an Artifact or Reference “in place”.
6.**Maintains separation of concerns**
* Does not embed storage, execution, policy, or graph semantics into ASL/1-CORE constructs.
* Leaves stores, execution engines, and graph kernels to their respective layers.
Everything else — API design, transport formats, performance characteristics, deployment topology — lies outside ASL/1-CORE and MUST be specified by separate surfaces.
