SDS-008: Context Materialization Service

Document Type

Software Design Specification (SDS)

Purpose

Defines the Context Materialization Service (CMS) — a projection target that takes a canonical ContextSpec from the Semantic Core and produces a runnable ContextInstance with auditable provenance and governance evidence.


1. Overview

The Context Materialization Service is a projection engine, not a semantic editor. It takes canonical semantic specifications and materializes them into executable runtime contexts (sandboxes, containers, tool bindings) while maintaining full provenance and governance compliance.

Role in SEA-Forge™

Key Invariant

CMS must not author semantics. It can only propose diffs.

This preserves the isomorphic principle where downstream layers can emit feedback, but the Semantic Core remains authoritative.


2. Domain Objects: Three-Layer Context Model

2.1 ContextSpec (Canonical, Versioned)

What the enterprise means/wants.

Conceptually aligned to SEA™’s Entity/Resource/Flow/Policy primitives.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
  "specId": "ContextSpec:v5-uuid",
  "version": "1.2.0",
  "concepts": ["Entity:User", "Entity:Transaction", "Resource:PaymentAPI"],
  "policies": ["Policy:ComplianceCheck", "Policy:DataResidency"],
  "capabilities": {
    "tools": ["ToolSpec:Database", "ToolSpec:HTTPClient"],
    "resources": {
      "cpu": "2",
      "memory": "4Gi"
    }
  },
  "constraints": ["CALM:BoundedContext:Payments"]
}

2.2 ContextInstance (Materialized Runtime)

What was actually built.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
  "instanceId": "ContextInstance:runtime-uuid",
  "specRef": "ContextSpec:v5-uuid",
  "status": "running",
  "endpoints": {
    "api": "http://localhost:8080",
    "tools": ["http://localhost:8081/db", "http://localhost:8082/http"]
  },
  "digests": {
    "image": "sha256:abc123...",
    "dataset": "sha256:def456..."
  },
  "provenanceRef": "Ledger:token-uuid",
  "calmComplianceRef": "CALMReport:report-uuid"
}

2.3 ContextSnapshot (Observed State for Agents)

What is true right now about the instance.

1
2
3
4
5
6
7
8
9
10
11
12
{
  "snapshotId": "ContextSnapshot:snap-uuid",
  "instanceRef": "ContextInstance:runtime-uuid",
  "timestamp": "2025-12-21T10:30:00Z",
  "health": "healthy",
  "activeConnections": 5,
  "resourceUsage": {
    "cpu": "1.2",
    "memory": "2.1Gi"
  },
  "capabilities": ["database:connected", "http:available"]
}

3. Ports & Adapters (Hexagonal Boundary)

3.1 Inbound Ports (Driving)

MaterializeContextPort

“Given ContextSpecRef, create a ContextInstance

1
2
3
4
5
6
interface MaterializeContextPort {
  materialize(
    specRef: string,
    parameters: MaterializeParams
  ): Promise<ContextInstance>;
}

LifecyclePort

Start/stop/pause/resume/terminate instance

1
2
3
4
5
6
7
interface LifecyclePort {
  start(instanceId: string): Promise<void>;
  stop(instanceId: string): Promise<void>;
  pause(instanceId: string): Promise<void>;
  resume(instanceId: string): Promise<void>;
  terminate(instanceId: string): Promise<void>;
}

IntrospectPort

Get status, capabilities, logs, provenance receipts

1
2
3
4
5
6
interface IntrospectPort {
  getStatus(instanceId: string): Promise<InstanceStatus>;
  getCapabilities(instanceId: string): Promise<Capability[]>;
  getLogs(instanceId: string, options: LogOptions): Promise<LogEntry[]>;
  getProvenance(instanceId: string): Promise<ProvenanceReceipt>;
}

3.2 Outbound Ports (Driven)

SemanticCorePort (Read-Only)

Resolve ConceptIds, validate semantic refs, fetch policies/rules.

KgsPort

Persist instance + edges (implements/provides/dependsOn), attach receipts.

CalmGovernancePort

Validate “this instance topology is allowed” + attach compliance report.

LedgerPort

Mint IDs, store provenance attestations, link instance → spec → artifacts.

RuntimeAdapterPort

Docker / k8s / Firecracker / remote sandbox / etc.

Implication: Runtime is swappable without affecting semantics/governance.


4. REST API Surface

4.1 Create / Materialize

POST /context/materialize

1
2
3
4
5
6
7
8
9
{
  "contextSpecRef": "ContextSpec:v5-uuid",
  "requestedBy": "user:alice",
  "parameters": {
    "region": "local",
    "cpu": "2",
    "memory": "4Gi"
  }
}

Response:

1
2
3
4
5
{
  "instanceId": "ContextInstance:runtime-uuid",
  "status": "provisioning",
  "estimatedReadyTime": "2025-12-21T10:35:00Z"
}

4.2 Get Status

GET /context/instances/{instanceId}

4.3 Freeze (Immutable Recipe)

POST /context/instances/{instanceId}/freeze

Produces an immutable “instance recipe” (digests only) for replay.

4.4 Terminate

POST /context/instances/{instanceId}/terminate

4.5 Get Snapshot

GET /context/instances/{instanceId}/snapshot


5. Event Contracts

5.1 Primary Events

ContextMaterializationRequested

Emitted when API called / pipeline starts.

1
2
3
4
5
6
{
  "eventType": "ContextMaterializationRequested",
  "specRef": "ContextSpec:v5-uuid",
  "requestedBy": "user:alice",
  "timestamp": "2025-12-21T10:30:00Z"
}

ContextMaterialized

Emitted on successful materialization.

1
2
3
4
5
6
7
8
9
10
{
  "eventType": "ContextMaterialized",
  "contextSpecRef": "ContextSpec:v5-uuid",
  "contextInstanceId": "ContextInstance:runtime-uuid",
  "runtimeDigest": "sha256:abc123...",
  "capabilities": ["database", "http"],
  "provenanceRef": "Ledger:token-uuid",
  "calmComplianceRef": "CALMReport:report-uuid",
  "timestamp": "2025-12-21T10:35:00Z"
}

ContextMaterializationFailed

Emitted on failure with structured reasons.

1
2
3
4
5
6
7
8
9
{
  "eventType": "ContextMaterializationFailed",
  "specRef": "ContextSpec:v5-uuid",
  "reasons": [
    { "code": "RESOURCE_UNAVAILABLE", "detail": "GPU quota exceeded" },
    { "code": "POLICY_VIOLATION", "detail": "DataResidency constraint failed" }
  ],
  "timestamp": "2025-12-21T10:32:00Z"
}

ContextSnapshotUpdated

Canonical feed for agents + Context Analyzer consumers.

5.2 Governance/Drift Events

ContextComplianceViolationEvent

Produced when CALM/SBVR constraints fail for spec→instance mapping.

ContextDriftDetected

Produced if runtime topology diverges from declaration.

Note: Drift detection is not optional; ADR-001 treats it as a deployment gate.


6. Knowledge Graph Projections

CMS writes instance facts as nodes/edges:


7. Design Constraints

7.1 CMS Does Not Author Semantics

It cannot redefine “User” or “Transaction.” It can only emit feedback suggesting changes.

7.2 Immutability + Digest Discipline

Everything materialized must be addressable by digest (images, datasets, tool versions). Otherwise, context replay is theater.

7.3 Policy Enforcement is Runtime Responsibility

Cannot just validate spec; must attach evidence that runtime complied (reports + receipts).

7.4 Projection Contracts

Clear separation between:


9. MVP Scope

Post-MVP (advanced context execution)

References