Global Corp Platform – System Manifest

Tracking

Profile

Per D-11 Option A (Profile declared in manifest only), this Profile block is the single authoritative declaration of the profile active across the collection. Individual specs do not re-declare the profile; they inherit it from this manifest.

System

This manifest governs the specification collection for the Global Corp Platform, a fictional multinational supply chain visibility and trust platform. The collection comprises: the enterprise base system spec (global-corp.architecture.spec.md), 10 application-domain subsystem specs (APP-CX through APP-SO), 2 cross-cutting platform specs (aspire-apphost.spec.md, service-defaults.spec.md), and 8 external gate simulator specs (carrier-gate, wms-gate, iot-gate, idp-gate, customs-gate, dpp-registry-gate, fsma-gate, audit-gate). Two additional gate specs (PayGate, SendGate) are reused by reference from the SpecChat samples collection at src/MCPServer/DotNet/Docs/Specs/.

The enterprise-level BTABOK concept specs (stakeholders, ASRs, decisions, governance spec, viewpoint catalog, and so on) remain planned for Phase 2c of the SpecChat BTABOK implementation per SpecChat-BTABOK-Implementation-Plan.md Section 7.3.

The narrative design artifact describing the full enterprise architecture is Global-Corp-Exemplar.md. That document is prose and not machine-validated; this spec collection is the authoritative, validator-targetable representation.

Lifecycle States

Every spec document moves through a defined sequence of states. Each transition is recorded in the Tracking block with a date.

Rules: - States are sequential: Draft, Reviewed, Approved, Executed, Verified. - A spec cannot skip states. - Decision specs enter Approved when the recommendation is accepted. - Feature and bug specs enter Executed when their code implementation is complete. - Amendment specs enter Executed when their corrections are applied to the base spec. - Waiver specs enter Approved when the EARB records the approval; they enter Executed when the waiver becomes active; they enter Verified at expiration. - The base spec enters Executed when it has been used to generate or validate source code. - Verified requires an independent check (test pass, audit, or review) confirming the execution is correct.

CoDL publishStatus interop mapping: SpecChat’s Draft, Reviewed, Approved, Executed, Verified map to CoDL’s Draft, Review, Approved, Published, Published (with a Verified audit record). See SpecChat-Versioning-Policy.md Rule 3 and CoDL-CaDL-Integration-Notes Section 5.1.

Tracking Block Convention

Every spec document must contain a Tracking block immediately after the title, before the first content section. The block includes all fields required by Core SpecLang SpecItem metadata per D-13 Option A.

Required fields:

Rules: - slug matches the filename base (for app-cx.customer-experience.spec.md the slug is app-cx-customer-experience). - Retention policy defaults per D-15 Option B: Base and Subsystem specs default to indefinite; evolution specs (Feature, Bug, Amendment, Decision, Waiver) default to archive-on-deprecated. - Date fields are set when the corresponding state transition occurs.

Document Type Registry

Per D-13 Option A (all CoDL-required fields required) and the Manifest Type Registry design, every spec file has a declared itemType matching one of the entries below.

Conventions

Writing Style

• No em-dashes. Use commas, semicolons, colons, or separate sentences.
• No emoticons.
• No purple prose or marketing-type phrases.
• Precise file paths and source references.

SpecLang Syntax

• Formal declarations (authored component, entity, trace, contract, constraint, rationale) follow the grammar defined in SpecLang-Grammar.md.
• requires and ensures take expressions; guarantees takes prose strings.
• invariant requires a name string, colon, and expression.
• rationale uses either simple form (rationale STRING;) or structured form (rationale { context ...; decision ...; consequence ...; }).

BTABOK Profile Syntax (CoDL and CaDL)

• Concept records use CoDL syntax per SpecLang-Design.md Section 5.
• Canvas definitions use CaDL syntax per SpecLang-Design.md Section 6.5.
• Cross-references use ref<ConceptType> for same-collection strong references, weakRef for cross-collection or pre-resolution references, externalRef for non-SpecChat targets (per D-07 Option B).

Subsystem Specs

• The 10 application-domain specs (APP-CX through APP-SO) are each subsystem specs with their own authored components, entities, contracts, and deployment.
• Subsystems may be built and operated independently of each other; cross-subsystem contracts are declared explicitly.
• The base spec (once authored in Phase 2c) references the subsystems as system nodes, describes the enterprise-scope topology, and holds the collection’s invariants that span multiple subsystems.

Standard BTABoK Metadata (BTABoKItem extension)

• For concept records defined by the BTABOK profile (ASRCard, DecisionRecord, StakeholderCard, etc.), the CoDL Standard BTABoK Metadata extension adds fields beyond the Core SpecItem profile: accessTier, bokStatus, certainty, baseVersion, and BTABoK-specific identity fields (topicAreaId, publishedBokId, etc.).
• Authors of BTABOK concept specs populate these fields per the CoDL 0.2 specification.

Governance Posture

Per D-09 Option D (manifest as floor, CLI can escalate), this collection’s default validation posture is warnings. Individual validator runs may escalate to strict via CLI flag; the manifest does not permit de-escalation below warnings since warnings is already the softest permitted posture.

Severity Overrides

No per-validator severity overrides declared at this version. Future overrides may appear here per the format:

Spec Inventory

Per D-13 Option A, every spec in the inventory carries the Core SpecItem metadata. For brevity this table shows the identifying fields; the full metadata lives in each spec file’s Tracking block.

Authored spec files (21)

Enterprise base spec (1)

Cross-cutting platform specs (2)

Gate simulator specs authored in this collection (8)

Subsystem specs (10)

Reused gate specs (from SpecChat samples collection; referenced, not authored here)

Planned spec files (10 Phase 2c BTABOK concept specs, not yet authored)

These files do not exist yet. Validator reference-resolution runs against this manifest will produce weakRef warnings for references that target these planned specs; such warnings are expected pending Phase 2c completion.

Other planned spec files (not tied to the collection root but part of Phase 2c)

Execution Order

Specs are grouped into tiers by dependency. All specs in a tier can be executed in parallel. A tier cannot begin until all dependencies from prior tiers have reached Executed state. Local Simulation Profile execution launches via dotnet run --project GlobalCorp.AppHost after the Aspire AppHost spec, ServiceDefaults spec, and gate specs are Executed.

Tier 0a: Platform substrate (no in-collection dependencies)

These platform specs must reach Executed state before any subsystem spec can be executed against the Local Simulation Profile.

1. global-corp.architecture.spec.md (enterprise base system spec; declares Package Policy, Aspire Composition, Gate Inventory, and Deployment profiles)
2. service-defaults.spec.md (shared cross-cutting library; every subsystem project consumes it)
3. aspire-apphost.spec.md (single composition root; launches every project and container)

Tier 0b: Gate simulators (depend on Tier 0a architecture spec for Package Policy and composition slot)

These gates must reach Executed state (Docker image available locally) before the consuming subsystem spec can launch in the Local Simulation Profile.

1. carrier-gate.spec.md (consumed by app-pc)
2. wms-gate.spec.md (consumed by app-pc)
3. iot-gate.spec.md (consumed by app-pc; depends on shared mosquitto container)
4. idp-gate.spec.md (consumed by app-es federation path)
5. customs-gate.spec.md (consumed by app-cc)
6. dpp-registry-gate.spec.md (consumed by app-sd)
7. fsma-gate.spec.md (consumed by app-cc)
8. audit-gate.spec.md (consumed by app-cc)
9. PayGate.spec.md (reused from samples; consumed by app-es billing)
10. SendGate.spec.md (reused from samples; consumed by app-cx notification engine)

Tier 0c: Foundation Subsystems (depend on Tier 0a; consumed by every other subsystem)

1. app-es.enterprise-services.spec.md (identity, tenant, billing; every other subsystem depends on it)
2. app-so.security-operations.spec.md (security and observability; consumed by every subsystem for telemetry)
3. global-corp.stakeholders.spec.md (planned)
4. global-corp.asrs.spec.md (planned)
5. global-corp.viewpoints.spec.md (planned)
6. global-corp.standards.spec.md (planned)

Tier 1: Ingestion and Planning (depend on Tier 0c)

1. app-pc.partner-connectivity.spec.md (depends on app-es, app-eb, carrier-gate, wms-gate, iot-gate)
2. app-eb.event-backbone.spec.md (depends on app-es; feeds all downstream data)
3. global-corp.decisions.spec.md (planned; references ASRs from Tier 0c)
4. global-corp.governance.spec.md (planned; references stakeholders and decisions)
5. global-corp.roadmap.spec.md (planned; references capabilities and decisions)
6. global-corp.views.spec.md (planned; requires viewpoints from Tier 0c)

Tier 2: Data and Aggregation (depend on Tier 1)

1. app-tc.traceability-core.spec.md (depends on app-eb, app-es; graph store on Apache AGE)
2. app-dp.data-platform.spec.md (depends on app-eb, app-tc, and app-cc for compliance snapshots; MinIO + DuckDB)
3. global-corp.waivers.spec.md (planned; references principles and governance rules)
4. global-corp.outcome-scorecard.spec.md (planned; aggregates MET-XX metrics)

Tier 3: Customer-Facing and Compliance (depend on Tier 2)

1. app-oi.operational-intelligence.spec.md (depends on app-eb, app-tc, app-dp, app-es)
2. app-cx.customer-experience.spec.md (depends on app-oi, app-tc, app-es, SendGate reused)
3. app-cc.compliance-core.spec.md (depends on app-tc, app-eb, app-so, app-es, customs-gate, fsma-gate, audit-gate)

Tier 4: Regulatory Layer and Long-Horizon Items (depend on Tier 3)

1. app-sd.sustainability-dpp.spec.md (depends on app-tc, app-cc, app-eb, dpp-registry-gate)
2. legacy-globaltrack-apac.decommission.spec.md (planned)
3. experiment-cold-chain-fusion.spec.md (planned)
4. experiment-dpp-electronics.spec.md (planned)
5. experiment-multimodal-eta.spec.md (planned)

Relationships to BTABOK Concepts

This manifest itself is a CoDL concept instance of type CollectionManifest. Its relationships:

relationships {
  uses<StakeholderCard>      as stakeholders      cardinality(0..*) via weakRef
  uses<ASRCard>              as requirements      cardinality(0..*) via weakRef
  uses<DecisionRecord>       as decisions         cardinality(0..*) via weakRef
  uses<WaiverRecord>         as waivers           cardinality(0..*) via weakRef
  uses<ViewpointCard>        as viewpoints        cardinality(0..*) via weakRef
  uses<GovernanceBody>       as governanceBodies  cardinality(0..*) via weakRef
  uses<StandardCard>         as standards         cardinality(0..*) via weakRef
  contains<SystemSpec>       as subsystems        cardinality(1..*)
}

The via weakRef annotations reflect that the targeted concept records live in planned specs (Phase 2c). Once those specs are authored, the relationships can be promoted to ref<T> (strong, same-collection references).

Validator Diagnostic Expectations (pre-Phase-2c)

Running the core validators (SPEC- prefix) against this collection as-is should produce:

• Expected errors: none for the 10 authored subsystem specs when run in isolation with governancePosture: warnings.
• Expected warnings:
  • SPEC-REF-002 warnings for every weakRef that points to a planned-but-unauthored enterprise-level spec.
  • SPEC-FRS-001 warnings possible for specs whose lastReviewed + freshnessSla will appear stale once real usage passes the SLA window.
• Expected info:
  • SPEC-RET-001 info diagnostics on any spec that did not explicitly declare retentionPolicy (relies on the per-type default from D-15).

Running the BTABOK-profile validators (BTABOK- prefix) against this collection as-is will produce many SPEC-REF-002 warnings because ASRCard, DecisionRecord, StakeholderCard, and other BTABOK concept instances live in planned specs that do not exist yet. These are expected and resolve when Phase 2c completes the collection.

Open Items

• Phase 2c completion: 10 enterprise-level BTABOK concept specs (stakeholders, ASRs, decisions, governance, waivers, roadmap, viewpoints, views, standards, outcome scorecard) plus 4 additional planned specs (legacy modernization, 3 experiments) need authoring to round out the collection. Per SpecChat-BTABOK-Implementation-Plan.md task group E-2c.
• Samples relocation: Once the collection is validator-clean, move the entire WIP/global-corp-specs/ folder to src/MCPServer/DotNet/samples/global-corp/ to match the existing samples convention (blazor-harness, TodoApp, PizzaShop, todo-app-the-standard).
• Validator run infrastructure: Validators do not exist until Phase 2a ships. Until then, this manifest serves as a design artifact rather than an operational input.
• Sample migration coordination: The existing samples (blazor-harness, TodoApp, PizzaShop, todo-app-the-standard) will also be migrated to the Core SpecLang post-Option-X metadata requirements during Phase 2a. Their manifests will receive similar treatment to this one, though they use Core or TheStandard profile rather than BTABOK.
• Gate image build pipeline: Each of the 8 new gate specs defines its own Docker image (globalcorp/<name>-gate:latest). A shared build script or per-gate CI pipeline needs to produce and tag these images into the local Docker cache before the Aspire AppHost can launch. Candidate: tools/build-gate-images.ps1 that iterates every gate solution.
• Reused gate cross-collection path: PayGate.spec.md and SendGate.spec.md live under src/MCPServer/DotNet/Docs/Specs/ (their historical SpecChat samples location). Subsystem specs that reference them use relative paths. Decide whether to hard-copy them into this collection or keep the cross-collection reference pattern as-is. Default: keep cross-collection reference; review after samples relocation.
• Aspire version drift: The collection targets Aspire 13.2.x. As Aspire ships new minor versions, some subsystem NuGets may require a bump. Per SpecChat Versioning Policy Rule 3 (warnings-first compatibility), version drift surfaces warnings rather than blocks.

Source References

• Parent exemplar narrative: Global-Corp-Exemplar.md
• Language design: SpecLang-Design.md
• Versioning policy: SpecChat-Versioning-Policy.md
• Settled decisions: SpecChat-Design-Decisions-Record.md
• Implementation plan: SpecChat-BTABOK-Implementation-Plan.md
• MCP server integration: MCP-Server-Integration-Design.md
• Glossary: SpecChat-BTABOK-Acronym-and-Term-Glossary.md
• Out-of-scope boundary: BTABOK-Out-of-Scope-Models.md