Global Corp. Enterprise Architecture

A Fictional BTABOK-Complete Enterprise Architecture for Global Supply Chain Tracking

Status

This document is a narrative design artifact, not a SpecChat spec collection. The data it enumerates (personas, ASRs, ASDs, waivers, viewpoints, views, entities, contracts, invariants, metrics, and the rest) describes what a BTABOK-complete enterprise architecture looks like, but is not itself in a form that SpecChat validators can process.

The actual spec collection derived from this narrative lives alongside this document in the same directory (docs/examples/global-corp/). The spec files are authoritative for all cross-references, counts, and IDs. This narrative remains as human-readable context and fiction backstory. For background on the staging plan that produced this layout, see SpecChat-BTABOK-Implementation-Plan.md Section 7.3.

Users looking to run SpecChat validators against Global Corp should point the tooling at the spec collection, not at this document.

Tracking

1. Purpose

This document defines a fictional global corporation, Global Corp., whose mission is to provide end-to-end visibility, traceability, compliance, and decision support for goods moving through the global supply chain.

The company is fictional. The realism is intentional. Its market pressures, standards choices, regulatory drivers, and operating constraints are derived from current public sources on global logistics, traceability, security, and BTABOK architecture practice. [R1][R2][R3][R4][R5][R6][R7][R8][R9][R10][R11][R12][R13]

The goal is to model an enterprise architecture that fully exercises the BTABOK Engagement Model, including:

• strategy and business value
• lifecycle thinking
• stakeholders and concerns with named owners and approvers
• views and viewpoints with a concrete view gallery
• architecturally significant requirements and decisions with full traceability
• governance with waiver handling
• repository operating model with freshness and ownership rules
• lightweight but durable deliverables
• metrics, risks, waivers, experiments, legacy modernization, and roadmap transitions

Every artifact in this document carries a stable, human-readable identifier, a named owner, and a named approver. This is intentional. The document is meant to exhibit the governance discipline it prescribes, not merely describe it.

1.1 CoDL and CaDL Alignment Note

This document is designed as a BTABOK-complete exemplar. Following the April 2026 publication of the Concept Definition Language (CoDL) and Canvas Definition Language (CaDL) by IASA Global on the BTABoK 3.2 education portal, it also doubles as a seed for CoDL concept instances and CaDL canvas definitions.

A subsequent decision recorded in SpecLang-Design.md (Option X) absorbs specific infrastructure concerns into Core SpecLang. As a consequence of that decision, several conventions used throughout this document are no longer BTABOK-profile-specific; they are Core SpecLang features that apply to every spec collection regardless of profile.

The stable IDs used throughout this document (ASR-01, ASD-01, WVR-01, STK-01, VP-01, V-01, and so on) correspond to the Core SpecLang slug field. The first column of each artifact table therefore maps to the Core SpecItem metadata profile field slug (URL-safe stable identifier). Slug uniqueness and format rules are enforced by core validators and apply to every SpecChat collection.

The Owner and Approver fields used throughout this document correspond to fields in the Core SpecItem metadata profile. Owner aligns with committer (the single owning steward) and with membership in authors. Approver aligns with membership in reviewers, or with committer when the approver is also the owning steward. These fields are core infrastructure, not BTABOK-specific.

The ever-green declaration, freshness SLA, and retention policy used throughout this document are Core SpecLang features. The retentionPolicy enum (indefinite, archive-on-deprecated, delete-on-superseded) applies to every spec regardless of profile.

The BTABOK profile contributes on top of the core infrastructure: the 19 BTABOK concept types (StakeholderCard, PrincipleCard, ASRCard, DecisionRecord, GovernanceBody, GovernanceRule, WaiverRecord, ViewpointCard, CanvasDefinition, QualityAttributeScenario, StandardCard, CapabilityCard, RoadmapItem, TransitionArchitecture, RiskCard, ExperimentCard, LegacyModernizationRecord, MetricDefinition, ScorecardDefinition), the BTABoKItem metadata extensions (accessTier, bokStatus, certainty, baseVersion, and BTABoK-specific identity fields), and the 20 CaDL canvases. These remain profile-scoped and activate only when the BTABOK profile is declared.

The View Gallery in section 28 serves as a catalog of CaDL canvases defined over the document’s concepts. Following the governing CaDL principle that “a canvas is a view of a concept, not a separate stored object type,” each V-xx entry describes a rendering over concepts defined elsewhere in this document, not a new stored object.

For the full alignment between CoDL, CaDL, and the SpecLang/SpecChat vocabulary, and for the Core SpecLang absorption decision, see SpecLang-Design.md. Two architectural decisions recorded there are relevant here: Option A (CoDL syntax is canonical, with optional SpecLang-style aliases) and Option X (infrastructure concerns absorbed into Core SpecLang).

2. Design Intent

This architecture deliberately incorporates the BTABOK Engagement Model elements that are often underrepresented in delivery-centric specification systems:

• business case and benefits realization
• stakeholder management beyond simple actor lists
• owners, approvers, and decision rights for every artifact
• decision registry with traceable ASDs linked to ASRs
• governance boards and waiver handling with concrete examples
• repository stewardship, freshness SLAs, and usage rules
• viewpoint cataloging with one instantiated view per viewpoint
• roadmap and transition architectures with capability baselines and targets

That design intent reflects the main lesson from the earlier BTABOK/SpecChat alignment work: architecture description alone is not enough. A BTABOK-aligned enterprise architecture must also carry value, governance, repository discipline, stakeholder concerns, and measurable outcomes. [R14]

3. External Context and Realism Anchors

Global Corp. operates in a world where international supply chains are large, distributed, multi-party, and increasingly regulated. The business context is shaped by five realities.

3.1 Reliability and resilience matter

The World Bank’s Logistics Performance Index emphasizes reliability, quality of logistics services, infrastructure, and border processes as core determinants of how effectively goods move across borders. [R7]

3.2 Event interoperability matters

GS1 EPCIS 2.0 is designed to capture and share supply-chain visibility events across organizations, including the what, when, where, why, and how of tracked objects. It also supports sensor data and developer-friendly APIs. [R8]

3.3 Ocean visibility needs common milestones and APIs

DCSA Track & Trace standards provide common data semantics, APIs, and milestone structures for container shipping across shipment phases and carriers. [R9]

3.4 Traceability is becoming regulatory infrastructure

The EU Ecodesign for Sustainable Products Regulation introduces the Digital Product Passport as a digital identity for products, components, and materials. [R10] The U.S. FDA FSMA 204 final rule requires Critical Tracking Events and Key Data Elements for covered foods. The original January 20, 2026 compliance date has been subject to FDA extension proposals; current enforcement timing should be confirmed against FDA rulemaking status at time of reference. [R11]

3.5 Security must extend into the supply chain itself

NIST CSF 2.0 guidance now includes focused quick-start guidance for cybersecurity supply chain risk management. [R12] ISO 28000:2022 provides requirements for security management systems relevant to supply chain security and resilience. [R13]

These realities make Global Corp. credible as a business. They also make it a strong vehicle for exercising BTABOK in a realistic way.

4. Global Corp. at a Glance

Global Corp. is a fictional multinational business technology company that provides a Supply Chain Visibility and Trust Platform to manufacturers, retailers, logistics providers, and regulators.

4.1 Corporate profile

• Legal HQ: Zurich
• Operational headquarters: Singapore
• Regional hubs: Rotterdam, Dubai, Atlanta, Sao Paulo, Johannesburg
• Primary customers: global manufacturers, consumer goods firms, pharma distributors, food shippers, 3PLs, ocean-forwarding networks, customs brokers
• Core business model: subscription SaaS plus premium data services, integration services, regulatory reporting packs, and managed control-tower operations
• Primary differentiator: normalized event visibility across ocean, air, road, warehouse, and product-level traceability domains
• Headcount: approximately 4,200 employees
• Revenue (current year): USD 780M, with 22% year-over-year growth
• Strategic horizon of this document: 36 months

4.2 What Global Corp. sells

Global Corp. does not move freight itself. It sells:

1. Visibility shipment, container, pallet, lot, serial, and product-level event visibility
2. Trust chain of custody, audit trails, provenance, and evidence retention
3. Compliance regulatory traceability, sustainability reporting support, digital product passport readiness, food-traceability workflows
4. Decision support ETA prediction, exception management, delay risk scoring, route disruption signals, inventory exposure analytics
5. Partner interoperability onboarding, mapping, standards mediation, and API/EDI normalization

5. Strategic Thesis

Global Corp.’s strategy is built on one premise:

The winning supply-chain platform is not just a data collector. It is the system that turns fragmented, partner-specific logistics signals into trusted, governed, decision-ready architecture.

5.1 Strategic objectives

1. Become the preferred cross-enterprise traceability platform for global manufacturers and retailers.
2. Reduce customer time-to-detect supply disruptions from hours to minutes.
3. Reduce partner onboarding effort through standards-first integration.
4. Support regulated traceability and sustainability reporting in major markets.
5. Create a reusable enterprise architecture repository that allows the business to scale without architecture drift.

5.2 Business outcomes

• lower disruption cost for customers
• faster recall and quarantine support
• stronger auditability
• improved compliance readiness
• higher trust in multi-party event data
• reusable integration and domain patterns
• reduced architecture rework inside Global Corp.

6. Business Case (NABC)

The Business Case is deliverable #1 in the Minimum Durable Deliverable Set (see section 24). It is structured using the NABC framing (Need, Approach, Benefits, Competition).

7. How This Enterprise Fully Exercises BTABOK

This model intentionally covers the main BTABOK Engagement Model practice zones.

8. Business Architecture

8.1 Core value streams

Global Corp. operates six primary value streams.

8.2 Business capabilities

Each capability carries a stable ID, a baseline maturity (current state), a target maturity (36-month horizon), a strategic importance, and a named owner.

9. Personas Directory

Named personas referenced throughout this document. In a real deployment these would be actual employees. Here they are consistent fictional roles that let ownership and approval discipline be exhibited rather than prescribed. The ID column in this table maps to the CoDL slug field for each concept instance.

10. Stakeholders and Concerns

CoDL itemType: StakeholderCard

BTABOK insists that views exist for stakeholders, not for the comfort of the architecture team alone. [R3]

Each stakeholder has a stable ID, a named occupant (from the Personas Directory), concerns, influence classification, required viewpoints, and an engagement strategy. The ID column in this table maps to the CoDL slug field for each StakeholderCard concept instance.

The Influence column maps cleanly to a CoDL enum field on the StakeholderCard concept: influence: enum(high, medium_high, medium, low). The power/interest grid positioning in section 10.1 is data that would be stored on each StakeholderCard instance (typed fields for power and interest scores, with the quadrant derived).

10.1 Power and interest positioning

Stakeholders are positioned on a power/interest grid. Engagement intensity is calibrated to this positioning per BTABOK’s guidance on stakeholder management.

11. Architecture Principles

CoDL itemType: PrincipleCard

Global Corp. uses the following enterprise principles. Each has a stable ID, an owner, an approver, and explicit links to the ASRs and ASDs that implement or depend on it. The ID column in this table maps to the CoDL slug field for each PrincipleCard concept instance.

In CoDL terms, the Owner column corresponds to the committer field on each PrincipleCard (the single owning steward). The Approver column corresponds to membership in reviewers, or to committer when the approver is also the owning steward. The Implements and Depends on columns correspond to CoDL relationship declarations on the PrincipleCard concept, expressed as typed references such as implements<ASRCard> and uses<ASRCard>.

12. BTABOK Lifecycle Applied to Global Corp.

BTABOK’s Architecture Development Life Cycle spans innovation, strategy, planning, transformation, utilize-and-measure, and decommission. [R2]

12.1 Innovation

• Identify new market needs such as DPP orchestration, multimodal ETA, and cold-chain analytics.
• Evaluate customer pain signals and partner ecosystem shifts.
• Track with Innovation Experiment Cards (section 13).

12.2 Strategy

• Define priority business cases (section 6).
• Select funded architecture assignments.
• Establish target and transition architectures (section 30).

12.3 Planning

• Define architecture deliverables.
• Assign owners, approvers, standards, and review gates.
• Prepare transition sequencing.

12.4 Transformation

• Execute product and platform changes.
• Operate architecture governance and waiver control.
• Manage architecture change as product realities emerge.

12.5 Utilize and Measure

• Compare delivered business outcomes with target metrics (section 32).
• Refine decisions, standards, and patterns.
• Retire underused artifacts and dead-end variants.

12.6 Decommission

• Retire obsolete partner protocols, regional components, and unneeded reports (section 29).
• Preserve decision records and compliance evidence.
• Migrate customers off deprecated interfaces.

13. Innovation Experiment Cards

CoDL itemType: ExperimentCard

Innovation experiments are time-bounded, budget-capped, and carry explicit kill criteria. Cards below are active or recently concluded. The EXP-xx identifiers map to the CoDL slug field for each ExperimentCard concept instance.

13.1 EXP-01 Cold-Chain Anomaly Detection via Sensor Fusion

13.2 EXP-02 DPP Orchestration for Electronics Category

13.3 EXP-03 Multimodal ETA with Carrier Consensus

14. Target Enterprise Architecture

14.1 Enterprise context view

flowchart LR
    classDef internal fill:#2E6295,stroke:#1A3D5C,color:#fff
    classDef partner fill:#438DD5,stroke:#2E6295,color:#fff
    classDef external fill:#999999,stroke:#6B6B6B,color:#fff

    Customers["Global Customers"]:::partner
    Carriers["Ocean / Air / Road Carriers"]:::partner
    Suppliers["Suppliers and Manufacturers"]:::partner
    Warehouses["Warehouses / 3PLs"]:::partner
    Customs["Customs and Regulators"]:::external
    Standards["GS1 / DCSA Standards"]:::external

    GC["Global Corp. Platform"]:::internal

    Customers --> GC
    Carriers --> GC
    Suppliers --> GC
    Warehouses --> GC
    GC --> Customs
    GC --> Standards

14.2 Business services

Global Corp. exposes the following business services.

15. Application Architecture

The target application landscape is modular but not fragmented.

15.1 Core application domains

15.2 Logical application view

flowchart TB
    classDef edge fill:#85BBF0,stroke:#5D99CF,color:#000
    classDef core fill:#438DD5,stroke:#2E6295,color:#fff
    classDef data fill:#999999,stroke:#6B6B6B,color:#fff

    Channels["Portals / APIs / Notifications"]:::edge
    Connect["Partner Connectivity"]:::core
    Events["Event Backbone"]:::core
    Trace["Traceability Core"]:::core
    Ops["Operational Intelligence"]:::core
    Compliance["Compliance & DPP"]:::core
    Enterprise["Identity / Tenant / Billing"]:::core
    Data["Lakehouse / Graph / Archive"]:::data

    Channels --> Enterprise
    Channels --> Ops
    Channels --> Compliance
    Connect --> Events
    Events --> Trace
    Trace --> Ops
    Trace --> Compliance
    Trace --> Data
    Ops --> Data
    Compliance --> Data

15.3 Application design rationale

• Partner Connectivity (APP-PC) is isolated because partner protocols change faster than core business semantics (implements P-01, depends on ASD-01).
• Event Backbone (APP-EB) is separated from Traceability Core (APP-TC) so ingestion elasticity does not contaminate canonical model quality (implements P-02, depends on ASD-02).
• Compliance and DPP (APP-CC, APP-SD) is separated from general analytics because auditability and retention obligations are stricter and more explicit (implements P-04, depends on ASD-05).
• Operational Intelligence (APP-OI) consumes normalized events and graph context, not raw partner payloads.
• Enterprise Services (APP-ES) are shared platform primitives; they are not buried inside product modules.

16. Information Architecture

16.1 Canonical information objects

Global Corp. normalizes the following enterprise objects.

16.2 Event entity (formal definition)

ENT-13 Event
  id: EventId                       // UUIDv7, time-ordered
  subjectId: SubjectRef             // points to Item, Container, Shipment, etc.
  eventType: EventType              // ObjectEvent, AggregationEvent, TransformationEvent, AssociationEvent
  businessStep: BusinessStepCode    // EPCIS CBV-aligned
  timestamp: UtcInstant             // event occurrence
  receivedAt: UtcInstant            // platform receipt
  sourceSystemId: SourceSystemRef
  sourceEvidenceRef: EvidenceUri    // required, see INV-01
  location: LocationRef             // optional
  businessContext: BusinessContext  // optional structured context
  actorId: OrganizationRef
  transportUnit: TransportUnitRef   // optional
  parentAggregation: SubjectRef     // optional
  sensorMeasurements: Measurement[] // optional
  confidenceScore: Confidence       // 0.0 to 1.0
  lineagePointer: LineageRef        // chain back to source event(s)
  payloadHash: Sha256Hash           // required, see INV-02

16.3 Contracts

CTR-01 EventIngestion (formal)

contract CTR-01 EventIngestion
  preconditions:
    - partner is certified (see CTR-05)
    - payload is well-formed JSON or valid EPCIS XML
    - payload signature is valid under partner's registered key
  postconditions:
    - on accept: a canonical Event (ENT-13) is persisted with payloadHash set, lineagePointer set, confidenceScore computed
    - on reject: a RejectionRecord is persisted with reason code and retained payload hash
    - the partner receives a synchronous ack with the canonical event ID or the rejection reason
  invariants:
    - INV-01 payload hash retention
    - INV-02 lineage completeness
  error modes:
    - PARTNER_NOT_CERTIFIED, SIGNATURE_INVALID, PAYLOAD_MALFORMED, DUPLICATE_EVENT, SCHEMA_UNKNOWN

16.4 Invariants

16.5 Information policies

1. No externally visible status exists without a retained source evidence pointer (INV-01).
2. Every canonical event retains its original partner payload hash (INV-01).
3. Product, asset, shipment, and facility identifiers are mastered separately and linked through graph relationships (INV-04).
4. Retention policies are jurisdiction-sensitive (INV-05).
5. Personally identifiable information is minimized and regionally controlled (INV-06).

17. Integration Architecture

17.1 Integration patterns

Global Corp. supports multiple partner interaction styles:

• REST / JSON APIs
• webhooks
• AS2 / SFTP batch exchange
• EDI for legacy logistics partners
• GS1 EPCIS capture and query flows
• DCSA-compatible event APIs for ocean tracking
• IoT telemetry ingestion for temperature, shock, and location
• document ingestion for certificates, bills of lading, declarations, and inspection artifacts

17.2 Integration policy

• Standards-compliant integration paths are preferred (P-01).
• Every non-standard integration requires an onboarding exception memo backed by a waiver.
• Every partner integration gets a certification profile (CTR-05).
• Adapters are versioned and region-aware.
• Breaking changes require a customer and partner transition plan.

18. Deployment and Operations Architecture

18.1 Deployment model

Global Corp. runs a global, multi-region cloud deployment with regional control points.

• Primary regions: EU, US, APAC
• Secondary regions: Middle East, Latin America
• Control model: global shared control plane, regional data planes
• Tenant strategy: logical multi-tenancy with tenant-isolated encryption scopes
• Data strategy: operational event stores region-local where required; replicated metadata and aggregate analytics where allowed (INV-05, INV-06)

18.2 Deployment view

flowchart LR
    classDef control fill:#2E6295,stroke:#1A3D5C,color:#fff
    classDef region fill:#438DD5,stroke:#2E6295,color:#fff
    classDef edge fill:#999999,stroke:#6B6B6B,color:#fff

    CP["Global Control Plane"]:::control
    EU["EU Data Plane"]:::region
    US["US Data Plane"]:::region
    APAC["APAC Data Plane"]:::region
    Partners["Partners / Customers"]:::edge

    Partners --> CP
    CP --> EU
    CP --> US
    CP --> APAC

18.3 Component-to-node instance mapping

18.4 Operational posture

• 24x7 follow-the-sun operations (PER-20 SRE lead)
• centralized architecture standards with regional adaptation packs
• platform SRE plus regional incident coordinators
• shared observability, distributed runbooks
• disaster recovery by region and critical service tier

19. Security and Trust Architecture

19.1 Security objectives

• protect customer and partner data
• preserve integrity of event evidence (INV-01, INV-02)
• support tenant isolation
• reduce third-party and supplier cyber risk
• support jurisdiction-specific compliance
• maintain forensic traceability

19.2 Security architecture controls

• zero-trust network assumptions
• centralized identity and policy decision points
• workload identity for service-to-service calls
• encryption in transit and at rest
• immutable evidence logs for externally significant events
• software supply chain controls for internal development
• third-party risk scoring and onboarding reviews
• regional key management
• privileged access segregation
• continuous compliance scanning

19.3 Security rationale

This architecture aligns with the practical need to treat cyber supply chain risk management as a first-class operating capability, not as an afterthought. [R12] It also reflects the broader supply-chain security posture described by ISO 28000. [R13] The security viewpoint (VP-07) in section 28.7 gives the view that visualizes these controls.

20. Dynamic Interactions

Selected runtime sequences that exercise the canonical model.

20.1 DYN-01 Partner submits event batch

sequenceDiagram
    participant P as Partner
    participant G as APP-PC Gateway
    participant A as PartnerAuth
    participant E as APP-EB Backbone
    participant T as APP-TC Traceability
    participant D as APP-DP Data Platform

    P->>G: POST /events (signed batch)
    G->>A: verify partner certificate (CTR-05)
    A-->>G: OK, partner profile
    G->>E: enqueue raw batch (with hash)
    E->>E: validate and deduplicate
    E->>T: emit canonical events (CTR-01)
    T->>T: resolve identity, compute lineage
    T->>D: stream to warehouse
    T-->>G: return canonical event IDs
    G-->>P: 202 Accepted with ID map

20.2 DYN-02 Customer requests ETA

sequenceDiagram
    participant C as Customer Portal
    participant O as APP-OI Operational Intelligence
    participant T as APP-TC Traceability
    participant M as ETA Model

    C->>O: GET /shipments/{id}/eta
    O->>T: read shipment graph and recent events
    T-->>O: graph slice and event window
    O->>M: predict(shipment_slice)
    M-->>O: eta, confidence, contributing signals
    O-->>C: ETA response (CTR-04)

20.3 DYN-03 Compliance evidence export

sequenceDiagram
    participant R as Regulator Portal
    participant C as APP-CC Compliance Core
    participant T as APP-TC Traceability
    participant S as Signing Service

    R->>C: POST /compliance-cases/{id}/export
    C->>T: resolve case scope (products, shipments, events)
    T-->>C: canonical events plus lineage
    C->>C: assemble evidence pack under retention policy (INV-05)
    C->>S: sign pack with regional key
    S-->>C: signed pack
    C-->>R: signed evidence bundle (CTR-03)

20.4 DYN-04 Waiver request and approval

sequenceDiagram
    participant A as Architect
    participant R as Repository
    participant B as EARB
    participant L as Logging

    A->>R: submit Waiver draft (WVR-xx)
    R->>B: notify EARB of pending waiver
    B->>B: review against principle P-08, risk
    B-->>R: approve or reject with rationale
    R->>L: append to Decision Registry
    R-->>A: notify outcome with expiration date

21. Architecturally Significant Requirements

CoDL itemType: ASRCard

Each ASR carries an owner, approver, implementing principle, and verification approach. The ID column in this table maps to the CoDL slug field for each ASRCard concept instance.

22. Architecturally Significant Decisions

CoDL itemType: DecisionRecord

Each ASD uses the full BTABOK decision shape: scope, type, options considered, recommendation, reversibility, linked ASRs, status, approver, and date. The ASD-xx identifiers map to the CoDL slug field for each DecisionRecord concept instance.

The per-decision field-value blocks below (ASD-01 through ASD-08) illustrate the shape of a CoDL DecisionRecord concept. A formal CoDL definition declares these fields (Scope, Type, Options, Recommendation, Reversibility, Method, Linked ASRs, Linked principles, Cascades, Status, Owner, Approver, Decided) as typed sections and metadata rather than free-form rows. A representative CoDL definition looks roughly like:

concept DecisionRecord extends StandardMetadata {
  scope: enum(Enterprise, Solution, Component)
  type: enum(Structural, Constraint, Principle, Tactical)
  options: list<shortText>
  recommendation: shortText
  reversibility: enum(High, Medium, Low, NearImpossible)
  method: enum(Opinion, Scoring, CostBenefit, BudgetedEvaluation, Spike)
  linkedASRs: list<ref<ASRCard>>
  linkedPrinciples: list<ref<PrincipleCard>>
  cascades: list<ref<DecisionRecord | WaiverRecord>>
  status: enum(Proposed, Accepted, Superseded, Rejected)
  owner: PersonRef
  approver: PersonRef
  decided: date
}

22.1 ASD-01 Adopt standards-first canonical model

22.2 ASD-02 Separate ingestion from canonical traceability core

22.3 ASD-03 Use regional data planes

22.4 ASD-04 Treat lineage as a first-class data object

22.5 ASD-05 Keep compliance services separate from general analytics

22.6 ASD-06 Use a curated architecture repository with explicit ownership

22.7 ASD-07 Formalize waiver process

22.8 ASD-08 Use BTABOK-style lightweight deliverables

23. ASR-to-ASD Traceability Matrix

Bidirectional mapping linking each ASR to the ASDs that address it and vice versa.

Each ASR has at least one addressing ASD. Each ASD addresses at least one ASR. No decision is orphaned from the requirement base.

24. Repository and Deliverables

BTABOK describes the repository as being first for architects, and warns that maintained documentation should stay minimal and useful. [R4][R5]

24.1 Repository structure

24.2 Minimum durable deliverable set

Every deliverable has an ID, an owner, an approver, a review cadence, a freshness SLA, and an intended decision audience. The ID column in this table maps to the CoDL slug field for each deliverable concept instance.

25. Governance Model

CoDL itemType: GovernanceBody for section 25.1, GovernanceRule for section 25.2.

25.1 Governance bodies

25.2 Governance rules

1. Every material architecture change requires named sponsor, named architect owner, affected ASRs, decision record, impacted standards statement.
2. Every exception requires waiver ID, justification, risk assessment, expiration date, approver.
3. Every reusable standard must have owner, target audience, effective date, review cadence.
4. Every major delivery initiative must show target capability movement, expected benefit metric, required viewpoints, verification plan.

25.3 Governance posture

Global Corp. uses guided governance, not punitive governance. Validation surfaces warnings by default. Treat-warnings-as-errors is a per-initiative opt-in. This is consistent with BTABOK’s emphasis that governance should remain practical, stakeholder-informed, and enabling. [R6]

25.4 RACI for representative decision types

26. Waiver Register

CoDL itemType: WaiverRecord

Concrete waivers demonstrating the pattern. Every waiver has a rule reference, justification, risk, expiration, and approver. The WVR-xx identifiers map to the CoDL slug field for each WaiverRecord concept instance.

26.1 WVR-01 Non-standard integration for FreightCo

26.2 WVR-02 Cross-region metadata replication for EU DPP index

26.3 WVR-03 Temporary suspension of autonomy check for Legacy-Bridge module

27. Viewpoint Catalog

CoDL itemType: ViewpointCard

Global Corp. uses a reusable viewpoint catalog. Each viewpoint has an ID, audience, concern, required models, and an owner. The View Gallery in section 28 instantiates each viewpoint with at least one concrete view. The ID column in this table maps to the CoDL slug field for each ViewpointCard concept instance.

28. View Gallery

CoDL itemType: CanvasDefinition (CaDL)

One view per viewpoint. Each view (V-01 through V-10) is a CaDL canvas definition over one or more CoDL concepts defined elsewhere in this document. Following the governing CaDL principle that a canvas is a view of a concept and not a separate stored object type, the Mermaid diagrams below are the rendered output; the CaDL definition describes which concepts, sections, and fields are surfaced by the canvas. The V-xx identifiers map to the CoDL slug field for each CanvasDefinition instance.

An illustrative CaDL definition for V-01 (the strategic objective tree) is shown below. The Mermaid rendering that follows remains the canonical human-readable output; the CaDL block is the structural intent.

canvas V-01-strategic-objective-tree {
  renders: viewpoint<VP-01>
  audience: [STK-01, STK-02, STK-12]
  layout: tree
  root: concept<EnterpriseArchitecture>.mission
  branches: list<concept<Objective>> from strategic.objectives
  leaves: list<concept<ASRCard>> from objective.implementedBy
  surfaces: [slug, name, shortDescription]
  rendererHints: { orientation: "top-down", grouping: "by-objective" }
}

28.1 V-01 Strategic view: objective tree (VP-01)

flowchart TB
    Mission["Mission: Trusted global supply-chain visibility"]
    O1["Obj 1: Preferred cross-enterprise platform"]
    O2["Obj 2: Disruption detection in minutes"]
    O3["Obj 3: Low partner onboarding effort"]
    O4["Obj 4: Regulated traceability support"]
    O5["Obj 5: Reusable architecture repository"]

    Mission --> O1
    Mission --> O2
    Mission --> O3
    Mission --> O4
    Mission --> O5

    O2 --> ASR05["ASR-05 actionable exceptions in 5 min"]
    O3 --> ASR04["ASR-04 partner onboarding without rewrites"]
    O4 --> ASR06["ASR-06 compliance export in 4 h"]
    O5 --> ASR09["ASR-09 artifacts owned and current"]

28.2 V-02 Capability heat map view (VP-02)

flowchart LR
    classDef critical fill:#C62828,stroke:#8E0000,color:#fff
    classDef high fill:#EF6C00,stroke:#B53D00,color:#fff
    classDef medium fill:#F9A825,stroke:#C17900,color:#000
    classDef low fill:#9E9E9E,stroke:#616161,color:#fff

    C1["CAP-PAR Partner Interop
baseline:Low-medium target:High"]:::critical
    C2["CAP-TRC Traceability
baseline:Medium target:High"]:::critical
    C3["CAP-TAS Trust & Security
baseline:Medium target:High"]:::critical
    C4["CAP-REP Repository
baseline:Low-medium target:High"]:::critical
    C5["CAP-ENT Enterprise Mgmt
baseline:Medium target:High"]:::critical
    C6["CAP-CPS Compliance
baseline:Low target:Medium-high"]:::high
    C7["CAP-CTR Control Tower
baseline:Medium-low target:Medium-high"]:::high
    C8["CAP-DAI Data & Intel
baseline:Medium target:High"]:::high
    C9["CAP-OUT Outcome Measurement
baseline:Low target:High"]:::high
    C10["CAP-GOV Governance
baseline:Low-medium target:Medium-high"]:::medium
    C11["CAP-CDL Customer Delivery
baseline:Medium target:High"]:::high
    C12["CAP-COM Commercial
baseline:Medium target:Medium-high"]:::medium

28.3 V-03 Stakeholder power-interest grid view (VP-03)

quadrantChart
    title Stakeholder power-interest grid
    x-axis Low Interest --> High Interest
    y-axis Low Power --> High Power
    quadrant-1 Manage closely
    quadrant-2 Keep satisfied
    quadrant-3 Monitor
    quadrant-4 Keep informed
    STK-01 CEO: [0.9, 0.95]
    STK-02 CFO: [0.85, 0.9]
    STK-03 COO: [0.6, 0.85]
    STK-04 CPO: [0.9, 0.88]
    STK-05 Chief Architect: [0.95, 0.85]
    STK-06 CISO: [0.85, 0.9]
    STK-07 Regional Ops APAC: [0.8, 0.55]
    STK-08 Integration Partner: [0.7, 0.45]
    STK-09 Customer SC Director: [0.9, 0.6]
    STK-10 Regulatory Affairs: [0.75, 0.55]
    STK-11 Sustainability: [0.65, 0.5]
    STK-12 EARB: [0.9, 0.85]

28.4 V-04 Information view: canonical event lineage (VP-04)

flowchart LR
    P["Partner Payload (EPCIS XML)"]
    H["Payload Hash (INV-01)"]
    EV["Canonical Event ENT-13"]
    L["LineagePointer (INV-02)"]
    S["Subject (Shipment/Item)"]
    EVI["Evidence Store"]

    P -->|hash| H
    H --> EV
    P -->|store| EVI
    EV -->|references| L
    L --> EVI
    EV --> S

28.5 V-05 Integration view: partner interaction model (VP-05)

flowchart TB
    subgraph Standards
      EPCIS["GS1 EPCIS 2.0"]
      DCSA["DCSA T&T"]
      IoT["IoT Telemetry Profiles"]
    end

    subgraph Patterns
      REST["REST/JSON"]
      WEB["Webhooks"]
      AS2["AS2/SFTP"]
      EDI["EDI"]
    end

    subgraph Onboarding
      CERT["Partner Certification (CTR-05)"]
      MAP["Mapping Pack"]
      SLA["Integration SLA"]
    end

    Standards --> Patterns
    Patterns --> Onboarding
    Onboarding --> APP_PC["APP-PC Partner Gateway"]

28.6 V-06 Operational view: exception management flow (VP-06)

flowchart LR
    IN["Event arrives"] --> RN["Normalized (CTR-01)"]
    RN --> RU["Rule evaluation"]
    RU -->|clean| OK["No action"]
    RU -->|anomaly| AL["Alert raised (ENT-17)"]
    AL --> TR["Triage"]
    TR -->|confirmed| EX["Exception (ENT-18)"]
    EX --> RES["Resolution workflow"]
    EX --> NOT["Customer notification"]
    RES --> CL["Closed with evidence"]

28.7 V-07 Security view: trust boundaries (VP-07)

flowchart TB
    classDef trust fill:#2E6295,stroke:#1A3D5C,color:#fff
    classDef dmz fill:#F9A825,stroke:#C17900,color:#000
    classDef ext fill:#9E9E9E,stroke:#616161,color:#fff

    Partner["Partner (external)"]:::ext
    Customer["Customer (external)"]:::ext
    DMZ["Edge: Partner Gateway + Customer Portal"]:::dmz
    Trusted["Trusted Plane: Event Backbone, Traceability Core, Compliance Core"]:::trust
    KMS["Regional KMS"]:::trust
    SIEM["Security Ops (APP-SO)"]:::trust

    Partner -.mTLS + signed payload.-> DMZ
    Customer -.OAuth2 + mTLS.-> DMZ
    DMZ --> Trusted
    Trusted --> KMS
    DMZ --> SIEM
    Trusted --> SIEM

28.8 V-08 Deployment view: regional failover (VP-08)

flowchart LR
    classDef primary fill:#2E6295,stroke:#1A3D5C,color:#fff
    classDef secondary fill:#438DD5,stroke:#2E6295,color:#fff
    classDef dr fill:#999999,stroke:#6B6B6B,color:#fff

    EU1["EU Primary (Dublin)"]:::primary
    EU2["EU DR (Frankfurt)"]:::dr
    US1["US Primary (Virginia)"]:::primary
    US2["US DR (Oregon)"]:::dr
    APAC1["APAC Primary (Singapore)"]:::primary
    APAC2["APAC DR (Tokyo)"]:::dr
    CP["Global Control Plane (multi-region active-active)"]:::secondary

    CP --> EU1
    CP --> US1
    CP --> APAC1
    EU1 -.failover.-> EU2
    US1 -.failover.-> US2
    APAC1 -.failover.-> APAC2

28.9 V-09 Governance view: approval flow (VP-09)

flowchart TB
    Draft["Draft (author)"] --> DDC["Domain Design Council review"]
    DDC --> RAF["Regional Architecture Forum review (if regional impact)"]
    RAF --> EARB["EARB review"]
    EARB -->|approve| Accepted["Accepted and logged in Decision Registry"]
    EARB -->|waiver needed| Waiver["Waiver drafted (see WVR-xx)"]
    Waiver --> EARBW["EARB waiver decision"]
    EARBW -->|approve| Accepted
    EARB -->|reject| Rejected["Rejected with rationale"]
    Accepted --> Exec["Executed in plan"]
    Exec --> Verified["Verified post-deployment"]

28.10 V-10 Outcome view: scorecard (VP-10)

See section 32 for the full Outcome Scorecard. This view renders the top-line KPI panel referenced by VP-10.

flowchart LR
    OUT["Outcome Scorecard"]
    OUT --> B1["Business Metrics
MET-BZ-01..05"]
    OUT --> A1["Architecture Metrics
MET-AR-01..05"]
    OUT --> O1["Operational Metrics
MET-OP-01..06"]
    B1 --> STK01["STK-01 CEO"]
    B1 --> STK02["STK-02 CFO"]
    A1 --> STK05["STK-05 Chief Architect"]
    A1 --> STK12["STK-12 EARB"]
    O1 --> STK03["STK-03 COO"]
    O1 --> STK07["STK-07 Regional Ops"]

29. Legacy Modernization

CoDL itemType: LegacyModernizationRecord

The LGY-xx identifiers map to the CoDL slug field for each LegacyModernizationRecord concept instance.

29.1 LGY-01 GlobalTrack-APAC v3 decommissioning

29.2 LGY-02 Legacy EDI 214 consolidation handler

30. Roadmap and Transition Architectures

CoDL itemType: TransitionArchitecture for each T1/T2/T3 and target block; RoadmapItem for capability movements within a transition.

Each transition references specific capability movements (baseline to target) and the ASRs/ASDs it advances.

30.1 Baseline architecture

• Fragmented point integrations (CAP-PAR-01 at Low-medium)
• Region-specific visibility tools including LGY-01
• Inconsistent event semantics (no canonical model)
• Weak audit lineage (no INV-01/INV-02 enforcement)
• Inconsistent partner onboarding time (CAP-PAR-01 weak)
• Manual compliance reporting (CAP-CPS-01 at Low)

30.2 Transition T1: Foundation (months 0-9)

• Establish canonical event model (ASD-01, ENT-13)
• Build partner connectivity layer (APP-PC)
• Launch repository and decision registry (ASD-06, CAP-REP-01 move to Medium)
• Deploy first cross-region control plane
• Capability movements: CAP-PAR-01 Low-medium to Medium, CAP-TRC-01 Medium to Medium-high, CAP-REP-01 Low-medium to Medium

30.3 Transition T2: Operational excellence (months 9-18)

• Introduce traceability graph (ASD-04)
• Launch exception management and ETA intelligence (ASR-05)
• Standardize ocean visibility with DCSA-aligned onboarding
• Formalize waiver process (ASD-07)
• Capability movements: CAP-CTR-01 Medium-low to Medium-high, CAP-PAR-01 Medium to High, CAP-GOV-01 Low-medium to Medium-high

30.4 Transition T3: Compliance and sustainability (months 18-30)

• Add DPP support (EXP-02 productization)
• Add food-traceability packs (FSMA 204 alignment)
• Implement evidence exports and regional retention controls (ASR-06)
• Launch executive value dashboard (CAP-OUT-01 to High)
• Capability movements: CAP-CPS-01 Low to Medium-high, CAP-OUT-01 Low to High

30.5 Target architecture (month 30+)

• Global standards-first visibility platform
• Product and shipment traceability unified
• Regionalized compliance and data control
• Governed repository with durable architecture assets
• Measurable business outcomes tied to capability movement

31. Risks and Mitigations

CoDL itemType: RiskCard

The ID column in this table maps to the CoDL slug field for each RiskCard concept instance.

32. Outcome Scorecard

CoDL itemType: ScorecardDefinition (SpecChat extension)

The MET-xx identifiers map to the CoDL slug field for each metric concept instance within the scorecard.

32.1 Business metrics

32.2 Architecture metrics

32.3 Operational metrics

33. Standards Catalog

CoDL itemType: StandardCard

External and internal standards adopted by Global Corp. The STD-xx identifiers map to the CoDL slug field for each StandardCard concept instance.

34. Final Assessment

Global Corp. is intentionally designed as a BTABOK Engagement Model-complete fictional enterprise.

It does not stop at a technical reference architecture. It treats architecture as a practice that spans:

• value and strategy, with a named business case and sponsor
• stakeholders and concerns, with named occupants and engagement strategy
• views and viewpoints, with one view per viewpoint actually instantiated
• ASRs and decisions, with bidirectional traceability and full decision metadata
• repository discipline, with every deliverable carrying ID, owner, approver, cadence, and freshness SLA
• governance and waivers, with concrete waiver examples and a posture of guided governance
• transition planning, with capability-movement targets
• outcome measurement, with baselines and targets per metric
• legacy modernization, with a concrete decommissioning vignette
• experiments, with hypothesis, cost cap, and kill criteria

That is the key point. A supply-chain tracking company is a good vehicle for this exercise because the domain naturally forces the architecture to confront interoperability, traceability, regulation, resilience, and distributed decision-making. The resulting enterprise architecture is therefore a credible testbed for BTABOK, not just a decorative scenario.

This document also serves as the seed for a SpecChat BTABOK profile worked example. Appendix B maps the enterprise architecture into SpecChat artifacts.

Appendix A. Source References

BTABOK / IASA

[R1] Business Technology Architecture Body of Knowledge | IASA - BTABoK. https://iasa-global.github.io/btabok/

[R2] Architecture Lifecycle | IASA - BTABoK. https://iasa-global.github.io/btabok/architecture_lifecycle.html

[R3] Views and Viewpoints | IASA - BTABoK. https://iasa-global.github.io/btabok/views.html

[R4] Deliverables | IASA - BTABoK. https://iasa-global.github.io/btabok/deliverables.html

[R5] Repository | IASA - BTABoK. https://iasa-global.github.io/btabok/repository.html

[R6] Governance Approach | IASA - BTABoK. https://iasa-global.github.io/btabok/governance_em.html

Supply chain and standards realism

[R7] World Bank Releases Logistics Performance Index 2023. https://www.worldbank.org/en/news/press-release/2023/04/21/world-bank-releases-logistics-performance-index-2023

[R8] EPCIS and CBV | GS1. https://www.gs1.org/standards/epcis

[R9] Track and Trace standard | DCSA. https://dcsa.org/standards/track-and-trace

[R10] Digital Product Passport under the Ecodesign for Sustainable Products Regulation | European Commission. https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en

[R11] FSMA Final Rule on Requirements for Additional Traceability Records for Certain Foods (Food Traceability Rule, Section 204) | FDA. https://www.fda.gov/food/food-safety-modernization-act-fsma/fsma-final-rule-requirements-additional-traceability-records-certain-foods

[R12] NIST Cybersecurity Framework 2.0: Quick-Start Guide for Cybersecurity Supply Chain Risk Management (SP 1305) | NIST. https://www.nist.gov/publications/nist-cybersecurity-framework-20-quick-start-guide-cybersecurity-supply-chain-risk

[R13] ISO 28000:2022 Security and resilience, Security management systems, Requirements | ISO. https://www.iso.org/standard/79612.html

Prior workspace learning

[R14] BTABOK and SpecChat Alignment Report, repository source archive/BTA-BOK-integration.md, dated 2026-04-16. The original broad-scope gap analysis, preserved for provenance.

CoDL and CaDL (authoritative)

[R15] Preiss, Paul. Structured Concept Definition Language. BTABoK 3.2, IASA Global Education Portal (2026).

[R16] Repository: docs/design-notes/SpecLang-Design.md. The consolidated design covering Core SpecLang, the BTABOK profile, CoDL and CaDL alignment, and the Engagement Model scope. It records both the Option A decision (CoDL syntax canonical) and the Option X decision (infrastructure absorption into Core SpecLang). It supersedes and incorporates the prior CoDL-CaDL-Integration-Notes.md, Core-SpecLang-Absorption-Design.md, BTABOK-Profile-v0.1-Design.md, and BTABOK-EngagementModel-Mapping.md (all now in archive/).

[R17] Repository: docs/design-notes/Spec-Type-System.md. Consolidated design covering the spec type taxonomy, rationale, and validation architecture.

Appendix B. SpecChat Manifest Scaffolding

This appendix maps the Global Corp. enterprise architecture into a SpecChat spec collection using the BTABOK profile. It is a scaffolding sketch, not a final spec set.

B.1 Proposed spec collection

Every file in the table below carries the Core SpecLang SpecItem metadata (specLangVersion, slug, itemType, name, version, publishStatus, authors, reviewers, committer, tags, createdAt, updatedAt, retentionPolicy, and freshnessSla for indefinite-retention specs) regardless of whether its Profile column shows Core, Core + BTABOK, or BTABOK. The collection manifest additionally declares profileVersion, codlVersion, and cadlVersion when the BTABOK profile is active. Core SpecItem metadata is universal infrastructure after the Option X decision. Profile scope determines only which concept types, concept-specific fields, and CaDL canvases activate on top of the core.

B.2 Execution order (tiered)

• Tier 0 (enterprise foundation): manifest, architecture base, stakeholders, ASRs, viewpoints, standards
• Tier 1 (governance and planning): decisions, governance, roadmap, views
• Tier 2 (platform systems and scorecard): event-backbone, traceability-core, partner-connectivity, waivers, outcome-scorecard
• Tier 3 (dependent systems, modernization, experiments): compliance-core, operational-intelligence, dpp-sustainability, legacy-globaltrack-apac, experiment specs

B.3 Cross-document reference convention

All references use the stable human-readable IDs introduced in this document (ASR-xx, ASD-xx, WVR-xx, STK-xx, VP-xx, V-xx, MET-xx, STD-xx, ENT-xx, CTR-xx, INV-xx, DYN-xx, EXP-xx, LGY-xx, CAP-xx, P-xx, PER-xx, BSVC-xx, APP-xx, DEL-xx, REP-xx, GOV-xx, VS-xx, RSK-xx). Each ID serves as the Core SpecLang slug field. Cross-spec references use the three Core SpecLang reference types (introduced from CoDL via Option X): ref<T> for strong references within the collection, weakRef for references that may resolve outside the collection, and externalRef for references to non-SpecChat systems (Jira, Confluence, Miro). Each ID is globally unique within the Global Corp. collection. Cross-spec references cite the ID with no file-path dependency, so moves and renames do not break the reference graph.

Appendix C. Scope Mapping: BTABOK Engagement Model vs. Out-of-Scope Models

Per the SpecChat BTABOK integration scope decision (see SpecLang-Design.md Section 7), only the Engagement Model is mapped to SpecChat. This appendix declares which sections of this document feed Engagement Model specs and which are enterprise context that would not be expressed as SpecChat artifacts.

Out of scope entirely (mentioned here but not extracted into SpecChat): career paths for personas, competency models for architects, organizational structure, compensation and employment relationships, community and professional development activities. These are People Model and Competency Model concerns.