D369 Chip Spec — Specification Overview

Purpose of This Document#

This file is the single‑sitting specification summary of the D369 Chip Spec module. It condenses the full module — 17 files, 76 numbered identifiers, 182 checklist items, and a three‑page contract package — into one executive‑readable profile.

What this file is: A standalone reference that answers: What does D369 specify, why, and how is it bounded?

What this file is not:

• Not a reading guide → see README.md
• Not a machine manifest → see Meta.md
• Not a Q&A walkthrough → see FAQ.md
• Not a session handshake → see Session_Context.md

If you read only one file, read this one.

1 — What D369 Is#

D369 defines a structural observability reservation for silicon.

It asks fabrication partners to reserve minimal metadata channels — alongside existing functional data paths — that preserve three properties:

1. Where a signal came from
2. What lifecycle state it was in when emitted
3. When it was emitted

These channels impose no functional behavior. They do not alter architectures, change yield math, slow tape‑out, expose IP, or lock manufacturers into any vendor. They simply prevent future observability from requiring a silicon re‑spin.

The specification's entire philosophy reduces to one sentence:

"Nothing here tells us what to build — only what not to erase."

Cost Profile#

Reservation is cheaper than redesign by every measure that matters.

2 — The Three Tags#

The irreducible unit of structural observability is three tags. Every requirement, checklist item, and architectural diagram in the module traces back to these:

-
┌─────────────────────────────────────────────────────┐
│                THREE TAGS                           │
│                                                     │
│   ┌───────────────┐   Source ID                     │
│   │  Tag 1        │   Origin identifier.            │
│   │               │   Statically assignable at      │
│   │               │   design time.                  │
│   └───────────────┘                                 │
│                                                     │
│   ┌───────────────┐   Lifecycle State               │
│   │  Tag 2        │   Externally writable.          │
│   │               │   Not inferred internally.      │
│   │               │   Not dependent on function.    │
│   └───────────────┘                                 │
│                                                     │
│   ┌───────────────┐   Monotonic Time                │
│   │  Tag 3        │   Non‑resettable within clock   │
│   │               │   domain. Survives batching     │
│   │               │   and buffering.                │
│   └───────────────┘                                 │
└─────────────────────────────────────────────────────┘

If all three tags survive from origin to observation, structural observability is preserved. If any one is erased, it cannot be recovered without redesign.

"Erasure is permanent and reservation is cheap."

3 — The Twelve Requirements#

The specification defines 12 formal requirements (R1.1–R7.1) using SHALL/MAY contract language. These are the binding obligations in Page 1 of the three‑page contract.

Summary Table#

Key properties of this requirements set:

• No performance guarantees implied
• No behavioral semantics defined
• No interpretation of metadata required or expected
• No aggregation mandated
• Mandatory aggregation explicitly excluded

"This doesn't touch my design — but I see why we'd regret not having it."

4 — The Three‑Page Contract#

The complete contract package is exactly three pages. No Page 4 exists or will be added.

-
┌──────────────────────────────────────────────────────────┐
│                 THREE‑PAGE CONTRACT                      │
│                                                          │
│  ┌────────────────────────────────────────────────────┐  │
│  │  Page 1 — Contractual Requirements                 │  │
│  │  (Contractual_Requirements.md)                     │  │
│  │  Role: obligation                                  │  │
│  │  Content: 12 requirements (R1.1–R7.1)              │  │
│  │  Voice: SHALL / MAY                                │  │
│  └────────────────────────────────────────────────────┘  │
│                          │                               │
│                          ▼                               │
│  ┌────────────────────────────────────────────────────┐  │
│  │  Page 2 — Engineering Rationale                    │  │
│  │  (Engineering_Rationale.md)                        │  │
│  │  Role: justification                               │  │
│  │  Content: 10 rationale statements (ER‑1–ER‑10)     │  │
│  │  + Design Freedom clause (DF‑1–DF‑3)               │  │
│  │  + Historical precedents                           │  │
│  └────────────────────────────────────────────────────┘  │
│                          │                               │
│                          ▼                               │
│  ┌────────────────────────────────────────────────────┐  │
│  │  Page 3 — Non‑Claims and Boundaries                │  │
│  │  (Non_Claims.md)                                   │  │
│  │  Role: boundary                                    │  │
│  │  Content: 10 non‑claims (NC‑1–NC‑10)               │  │
│  │  + 4 boundaries (B‑1–B‑4)                          │  │
│  │  + Silence Clause (S‑1–S‑3)                        │  │
│  └────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────┘

Why Three Pages#

A specification's credibility is inversely proportional to its claim surface. Three pages is enough to define what must be preserved, why it matters, and what is explicitly not claimed. Anything more would trigger the immune response that kills adoption.

"They know exactly what they're not building — and they said so in writing."

5 — Architecture Targets#

D369 applies to two silicon architecture families. The specification is identical in both — only the topology of metadata routing differs.

5.1 — SoC (System‑on‑Chip)#

The SoC target addresses monolithic designs containing:

• CPU / DSP cores
• AI / ML accelerators
• GPU / DSP subsystems
• Memory controllers
• I/O subsystems
• Security enclaves
• Power management units

-
═══════════════════════════════════════════
        SoC — Functional Architecture
═══════════════════════════════════════════

  ┌──────────┐  ┌──────────┐  ┌──────────┐
  │ CPU/DSP  │  │  AI/ML   │  │ GPU/DSP  │
  │ Cores    │  │  Accel   │  │ Subsys   │
  └────┬─────┘  └────┬─────┘  └────┬─────┘
       │             │             │
  ═════╪═════════════╪═════════════╪═════
       │      NoC / Interconnect   │
  ═════╪══════════════╪════════════╪═════
       │              │            │
  ┌────▼─────┐  ┌─────▼────┐  ┌────▼─────┐
  │ Memory   │  │ I/O      │  │ Security │
  │ Ctrl     │  │ Subsys   │  │ Enclave  │
  └──────────┘  └──────────┘  └──────────┘

─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
  Structural Observability Layer (metadata)
─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
  Source ID │ Lifecycle State │ Monotonic Time

Key structural boundaries identified:

• NoC (Network‑on‑Chip) — the primary structural boundary; five erasure modes documented (N‑1 through N‑5)
• Cache hierarchy — persistence boundary where metadata may be silently dropped
• Power domains — metadata must survive power‑gating without corruption

5.2 — Chiplet (Multi‑Die)#

The chiplet target addresses disaggregated designs with four canonical topologies:

Critical chiplet concerns:

• Die‑to‑die (D2D) interfaces — metadata must survive UCIe and CXL protocol crossings
• The HBM Problem — HBM stacks use standardized interfaces with no metadata provisions; requires interposer‑level or controller‑level solutions
• Interposer types — passive vs. active interposers have different metadata routing capabilities

A six‑layer structural observability stack governs chiplet deployments:

1. Intra‑die (within functional blocks)
2. Die‑edge (at D2D boundaries)
3. Interposer (routing between dies)
4. Package (substrate‑level)
5. Board (PCB‑level)
6. System (cross‑board)

6 — Memory Alignment#

The specification extends structural observability through the full memory hierarchy.

6.1 — Memory Tiers#

6.2 — The Volatility Line#

The boundary between Tier 3 (DRAM) and Tier 4 (persistent memory) is the volatility line — the point where metadata either persists or vanishes. The memory controller sits directly on this line and functions as the structural gateway.

6.3 — Memory Alignment Principles (MA‑1 through MA‑5)#

6.4 — Structural Events (ME‑1 through ME‑7)#

Seven events in the memory subsystem where metadata may be structurally affected:

7 — Board‑Level Alignment#

When metadata exits the chip package and enters the PCB, a different set of preservation rules applies.

Four Preservation Rules#

Four Board Failure Modes#

Board‑level failures are distinct from chip‑level failures: they involve physical topology, signal integrity, and multi‑chip coordination rather than RTL logic.

The board‑level design review checklist contains 27 items across topology, routing, power, signal integrity, and documentation sections.

"The board's job is to preserve, not interpret."

8 — The Checklist Cascade#

The module defines a four‑level checklist hierarchy. Each level hands off to the next, and all trace back to the 12 requirements.

-
┌──────────────────────────────────────────────┐
│  Internal Design Review     ──── 62 items    │
│  (chip‑level, pre‑tape‑out)                  │
└──────────────────┬───────────────────────────┘
                   │ hands off to
┌──────────────────▼───────────────────────────┐
│  Memory Controller Checklist ──── 55 items   │
│  (controller pipeline, 9 stages)             │
└──────────────────┬───────────────────────────┘
                   │ hands off to
┌──────────────────▼───────────────────────────┐
│  DIMM Module Checklist      ──── 38 items    │
│  (module‑level, DDR interface)               │
└──────────────────┬───────────────────────────┘
                   │ hands off to
┌──────────────────▼───────────────────────────┐
│  Board‑Level Checklist      ──── 27 items    │
│  (PCB topology, cross‑chip)                  │
└──────────────────────────────────────────────┘

                Total: 182 items

Failure Mode Coverage#

Every checklist item maps back to at least one requirement (R1.1–R7.1) and at least one failure mode. Every failure mode maps forward to the checklist items that address it.

9 — Engineering Rationale#

Page 2 of the contract provides 10 rationale statements (ER‑1 through ER‑10) and a Design Freedom clause (DF‑1 through DF‑3).

Rationale Statements (abbreviated)#

Design Freedom (DF‑1 through DF‑3)#

Historical Precedents#

The rationale draws on four documented cases where structural erasure caused catastrophic failure:

• Therac‑25 — state inference without source separation
• Ariane 5 — data reuse without lifecycle context
• Intel FDIV — optimization that erased verifiability
• Boeing 737 MAX — behavioral dependence without structural visibility

These are not analogies. They are documented instances where the absence of what D369 reserves contributed directly to failure.

10 — Non‑Claims and Boundaries#

Page 3 is the specification's most unusual feature: it defines what D369 explicitly does not claim.

Ten Non‑Claims (NC‑1 through NC‑10)#

Four Boundaries (B‑1 through B‑4)#

Silence Clause (S‑1 through S‑3)#

"A specification's credibility is inversely proportional to its claim surface."

11 — Adoption Roadmap#

Adoption follows six phases with a deliberate ordering: fabs before students.

Why Fabs Before Students#

"Fabs before students."

If students arrive first, the specification looks academic. If fabs arrive first, the specification looks inevitable. Once silicon exists that quietly supports source identity, lifecycle state, and temporal lineage, students don't need to be convinced — they just use what's there.

This is the adoption pattern of CUDA, POSIX, and TCP/IP.

12 — The Complete Identifier Map#

The module uses 76 numbered identifiers across 14 categories. All identifiers are immutable once published.

13 — Module File Map#

The complete D369 module contains 17 files plus this overview:

14 — What Engineers Should Conclude#

After reading this specification, the target response is:

"This doesn't touch my design — but I see why we'd regret not having it."

After reviewing the non‑claims:

"They know exactly what they're not building — and they said so in writing."

After examining the checklists:

"We didn't add behavior — we just didn't erase structure."

The specification asks for space, not change. It reserves structure, not function. It defines curbs, not walls.

And it fits in three pages.

Canon Alignment#

• Traces to Capture_Source.md
• Opens with Session Context table
• Uses engineer‑facing, student‑ready voice
• Contains zero hype, zero marketing language
• All numbered identifiers match module‑wide registry
• ASCII diagrams use solid lines (═══) for functional, dashed (─ ─ ─) for metadata
• Does not duplicate FAQ (Q&A format) or README (navigation)
• Closes with Canon Alignment checklist
• Role confirmed: reference · profile
• SARG assignment: profile (executive shape), reference (lookup tables)