Ref-002: Identity Token Specification (Semantic Identity)

Type

Reference Documentation - Specification

Bounded Context

Cognitive Extension / Shared Infrastructure

Purpose

Defines the Semantic Extended Artifact Token (Identity Token) — a semantic identity primitive that provides unique identity, provenance, versioning, and ownership for SEA™ artifacts, governed by DomainForge™ SEA™ DSL.

Terminology Note: This project uses “Identity Token” and “Provenance Token” rather than “NFT” to clarify these are immutability/provenance primitives, not public-chain assets. There are no execution fees, execution costs, or token economics.

1. Introduction

Identity Tokens are not cryptocurrencies. They are semantic identity objects that map intellectual, cognitive, and informational artifacts to a cryptographic ledger (IFL).

They allow SEA™ to describe:

2. Core Semantics (DomainForge™ Integration)

Identity Tokens are defined as first-class semantic entities in the DomainForge™ SEA™ DSL.

2.1 Concepts

1
2
3
4
5
6
7
8
9
10
11

Concept: IdentityToken
  is a: Semantic Asset
  has: Unique Identifier
  has: Artifact Type
  has: Version
  has: Immutable Hash
  has optional: Metadata Block
  has: Owner
  has: State
  may have: Lineage Specification
  may have: Public Anchor

1
2
3

Concept: Artifact Type
  examples: CALMModel, SemanticVersion, OntologyVersion,
            CognitiveArtifact, InformationProduct, SourceCodeArtifact

1
2
3
4
5

Concept: Lineage Specification
  has optional: Derived From (0..n IdentityToken)
  has optional: Supersedes (0..1 IdentityToken)
  has optional: Composes (0..n IdentityToken)
  has optional: Manifests Into (0..n IdentityToken)

1
2
3

Concept: Token Ownership
  has: Owner (Actor)
  has: Assigned Permissions

2.2 Fact Types

3. SEA™ DSL Policies (Normative Rules)

These policies are enforced by the IFL ↔ DomainForge™ Adapter running the SEA™ DSL Policy Engine.

3.1 Policy: Ownership (Obligation)

It is obligatory that every IdentityToken has exactly one Owner.

3.2 Policy: Immutability (Constraint)

It is necessary that the Immutable Hash of an IdentityToken never changes.

3.3 Policy: Version Traceability (Obligation)

It is obligatory that every IdentityToken with a Version greater than 1 has a Derived From lineage pointing to at least one prior IdentityToken.

3.4 Authorization Policies

It is permitted that an Actor updates Metadata of an IdentityToken only if the Actor has Update Permission.

It is forbidden that an Actor changes the Owner of an IdentityToken unless the Actor has Ownership Transfer Permission.

3.5 Governance Policies (CALM-aware)

It is necessary that a CALM Model IdentityToken is in an Approved state before Deployment.

3.6 Public Anchoring Policies

It is permitted that an IdentityToken has one or more Public Anchors. It is necessary that Public Anchors reference only Merkle Root Checkpoints.

4. DomainForge™ Syntax Extensions

The following template syntax illustrates how Identity Tokens are defined in the DSL:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Template IdentityToken<ArtifactType> {
  key: id
  fields:
    id: Identifier
    type: ArtifactType
    version: VersionIdentifier
    hash: Hash
    owner: Actor
    metadata: MetadataBlock
    lineage: LineageSpecification?
    permissions: PermissionBlock
    state: TokenState
}

Template LineageSpecification {
  fields:
    derivedFrom: IdentityToken[]?
    supersedes: IdentityToken?
    composes: IdentityToken[]?
    manifestsInto: IdentityToken[]?
}

5. Constraint Blocks

Constraints are programmatically enforceable invariants:

1
2
3
4
5
6
7
8

Constraint Block IdentityToken {
  invariants:
    hash is immutable check on update
    version is monotonically increasing check on create
    owner must be valid Actor
    type must be recognized ArtifactType
    lineage.derivedFrom must reference lower versions
}

6. Semantic Policies for SEA™ Systems

6.1 Semantic Core Integration

A DSL-Version must be represented by an IdentityToken of type SemanticVersion.

6.2 CALM Integration

A CALMModel is deployed only if its IdentityToken.state = Approved.

6.3 Knowledge Graph Service (KGS) Integration

Every OntologyVersion must be represented by an IdentityToken and anchored in the IFL.

7. Data Transport Objects (DTOs)

Used by the IFL Node API and Client SDKs.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

interface IdentityTokenDto {
  id: string;
  artifactType:
    | "CALMModel"
    | "SemanticVersion"
    | "OntologyVersion"
    | "CognitiveArtifact"
    | "InformationProduct"
    | "SourceCodeArtifact";
  artifactId: string;
  version: string;
  hash: string;
  owner: string;
  state: "Draft" | "Approved" | "Deployed" | "Retired";
  lineage?: {
    derivedFrom?: string[];
    supersedes?: string;
    composes?: string[];
    manifestsInto?: string[];
  };
  metadata?: Record<string, unknown>;
}