PACKAGE-STANDARD.md — Package Component Type (a cell composing >=2 heterogeneous typed components)
Type-layer standard, sibling of the TEMPLATE / PROFILE / SERVICE / SYSTEM standards. Inherits CLAUDE.md (operator context, altitude doctrine §4, analytic floor §6) and the component-composition model (COMPONENT-REGISTRY.md). Governs the
(package)component type ONLY. A package is a PRESCRIPTIVE product — its value is a build instruction that tells the producer which typed components to assemble, in what dependency order, into one delivered composite — NOT knowledge about a subject, so it does NOT carry the report anatomy (BLUF / Key Judgments / ACH / KAC / PIR). It has its own spine, below.
Living standard. Reconciled 2026-07-04 to the prose-
.mdcell form the package cells actually use (EP-018 Travel Security Package, BIZ-003 Mobilization Package). The prior revision described the package as amanifest.yaml+ materializedcomponents/tree; the cells are instead single markdown deliverables whose Component Manifest table is the composition contract. The load-bearing composition rules (>=2 heterogeneous typed components, per-component standard binding, explicit cross-component dependency, no nested packages) are unchanged — only the artifact form is corrected.
1. What a package is
Value = a composition contract: a markdown cell whose Component Manifest names >=2 heterogeneous typed components, binds each to its own type standard and a resolvable source, and records the cross-component dependencies/traceability that make them one coherent deliverable. The package itself asserts nothing about a subject — its constituent components do that, each under its own standard. Imperative/compositional voice: assemble these components, in this order, conforming to these standards. A package may NOT contain a package (no nested composites).
2. Required anatomy (every package cell carries this spine; restate in each file)
# <PACKAGE NAME>+ a one-line as-built descriptor (composition discipline: >=2 heterogeneous typed components, no nested packages).## 1. Package Definition— what the composite is and what it bundles, in one narrative.## 2. Component Manifest— the composition table: Component | Type | Source (DID or path) | Standard, with >=2 entries spanning >=2 distinct component types (never a package; never two of one type alone). Each row binds a component to its own type standard and a resolvable source (DID link or path).## 3. Dependency and Traceability Notes— which component feeds, scopes, or depends on which, so the assembly / build order is unambiguous; note where a referenced component resolves.## 4. Systems Engineering Specifications— the composite-level engineering the package adds beyond its parts (interfaces, integration, tailoring the components into one deliverable).## N. Deliverable Manifest Per Engagement— what is actually handed over per engagement instance.- Package-specific sections as the composite warrants (e.g. activation flow / master timeline, assembly & delivery, risk-tier scaling, in-country support integration) — additive; specialize or cut, never pad.
3. Mandatory caveat(s)
This package is a composition contract, not an analytic product. Each constituent component is governed by its own type standard and carries its own scope, sourcing, and legal/ethics caveats; those caveats are NOT superseded by inclusion here. No unlawful collection, and no component may be assembled or disseminated outside the authorization and handling caveat of its most restrictive constituent.
4. Sourcing & confidence discipline
Admiralty grading does not apply at the package level — a package asserts no graded datum of its own.
Sourcing and confidence live inside each constituent component under that component’s standard (e.g. a
(profile) carries Admiralty A–F × 1–6 in its evidence log; a (report) carries it in its source
register). The Component Manifest only records which components are bound, to which standard, and
where referenced ones resolve.
5. Package-specific discipline (the load-bearing rule)
Every Component Manifest row names a composable type and a resolvable source, the set is heterogeneous (>=2 distinct types), and no entry is itself a package; cross-component dependencies are stated so the assembly order is unambiguous. If any two components could be sold/delivered with no dependency between them and no shared composite intent, they are not one package — split them.
6. Format
Pure heading hierarchy; a markdown table for the Component Manifest and for any matrix; bracketed
[placeholders] where a template cell leaves content to fill. No emojis anywhere (verify-enforced);
operational language renders to lawful effects per DOCTRINE.md. Each constituent component is
authored as its own cell under its own type standard and referenced from the Component Manifest by
DID; the package cell does not re-embed them.