Subsystem Topology

BluntDashboard should be treated as a system of systems, not as a flat web app. The repo already contains the ingredients for that view:

• Scenarios provide the Operational Analysis (OA) mission threads.
• System Need Analysis defines the boundary, actors, and constraints.
• Logical Architecture defines technology-neutral modules.
• Physical Architecture binds those modules to runtimes and infrastructure.
• Delivery Plan provides the Building Strategy (BS) integration path.

This page turns those Arcadia viewpoints into a stable engineering topology for the repo itself so that features, fixes, maintenance, and migrations can be sliced along subsystem boundaries rather than around whichever files happen to be nearby.

Topology rules

• Operational capability is the first partitioning key. Runtime, framework, and hosting come second.
• Every leaf subsystem should have one dominant mission, one main contract surface, and one obvious verification story.
• Cross-cutting concerns live in dedicated platform subsystems instead of being smeared across domain patches.
• A change should be named and reviewed at the lowest subsystem that fully contains it.
• If a change crosses sibling subsystems, prefer a small patch train over one large mixed PR.

Level 0 decomposition

Plane	Why it exists	Arcadia anchor	Current repo anchors	Target runtime anchors
EXP Staff Experience	Staff-facing navigation, pages, and workflow entry points	OA -> LA	client/src/App.tsx, client/src/pages/**, client/src/components/**	frontend on CF Pages
DOM Operational Domains	Core business behaviors for analytics, taxonomy, combos, assets, and fulfillment	LA	server/routes/**, server/services/**, domain-focused pages and docs	dashboard-api Worker + domain modules
ORCH Workflow & Integration Fabric	Async jobs, external platform mediation, sync/replay, and long-running procedures	LA -> PA	supabase/functions/**, workers/**, scripts/**	ingest Worker, Queues, Workflows, Cron
DATA Data & Knowledge Fabric	Domain tables, marts, artifacts, schemas, and API/job contracts	SA -> LA -> PA	supabase/migrations/**, shared/schema.ts, casestry-api-spec.json, docs/commerce-schema/**	PlanetScale, R2, shared Zod/Drizzle contracts
PLAT Platform Control Plane	Identity, observability, deployment, secrets, and environment wiring	SA -> PA -> BS	server/auth.ts, .wrangler/, vercel.json, worker wrangler.toml, env docs	CF Access, Wrangler bindings, Hyperdrive, Pipelines, alerts
GOV Shared Reference	Architecture memory, ADRs, scenarios, runbooks, and migration guidance	BS + decision capitalization	docs/src/content/docs/**, docs/legacy/**, top-level runbooks	The living architectural reference for all runtime surfaces

Canonical hierarchy

BluntDashboard
|- EXP Staff Experience
|  |- EXP.shell
|  |- EXP.performance-workbench
|  |- EXP.creative-workbench
|  `- EXP.fulfillment-workbench
|- DOM Operational Domains
|  |- DOM.performance-intelligence
|  |- DOM.taxonomy-attribution
|  |- DOM.combo-operations
|  |- DOM.asset-redundancy
|  `- DOM.fulfillment-operations
|- ORCH Workflow & Integration Fabric
|  |- ORCH.shopify-sync
|  |- ORCH.asset-and-export-jobs
|  `- ORCH.casestry-and-release
|- DATA Data & Knowledge Fabric
|  |- DATA.domain-store
|  |- DATA.analytics-store
|  `- DATA.contracts-and-schema
|- PLAT Platform Control Plane
|  |- PLAT.identity-and-access
|  |- PLAT.observability
|  `- PLAT.deployment-and-environment
`- GOV Shared Reference
   |- GOV.scenarios-and-architecture
   `- GOV.runbooks-and-migration

Use these IDs as the canonical coordinate system for PRs, maintenance work, ADRs, and release notes.

EXP: Staff Experience

Subsystem ID	Responsibility	Primary repo loci	Main scenarios
EXP.shell	Routing, auth wrappers, layout, shared dashboard chrome, query client wiring	client/src/App.tsx, client/src/lib/protected-route.tsx, client/src/components/dashboard/**, client/src/hooks/use-auth.tsx	All staff workflows
EXP.performance-workbench	Metrics, tag analytics, tag manager, designer views	client/src/pages/performance-metrics-page.tsx, client/src/pages/tag-analytics-page.tsx, client/src/pages/tag-manager-page.tsx	Performance Metrics, Tag Analytics, Tag Classification, Designer Assignment
EXP.creative-workbench	Combo logs, templates, suggestions, product asset interaction	client/src/pages/combo-logs-page.tsx, client/src/pages/combo-templates-page.tsx, client/src/pages/combo-suggestions-page.tsx, client/src/pages/product-assets-page.tsx	Combo Log CRUD, Combo Templates, Combo Suggestions, Asset Ingest
EXP.fulfillment-workbench	CSV generation, fulfillment monitoring, order reconciliation flows	client/src/pages/csv-generator-page.tsx, client/src/pages/fulfillment-monitoring-page.tsx, client/src/components/order-reconciliation-section.tsx	CSV Export, Fulfillment Monitoring, Order Lookup

DOM: Operational Domains

Subsystem ID	Responsibility	Primary repo loci	Main scenarios
DOM.performance-intelligence	Measurement retrieval, classification specs, performance summaries, tag analytics behavior	server/routes/performance-metrics.ts, server/routes/tag-analytics.ts, docs/src/content/docs/scenarios/performance-metrics.md	Performance Metrics, Tag Analytics
DOM.taxonomy-attribution	Tag classification, tag groups, designer assignment, taxonomy semantics	server/routes/tag-classifications.ts, server/routes/tag-groups.ts, server/routes/designers.ts	Tag Classification, Tag Groups, Designer Assignment
DOM.combo-operations	Combo reports, imports, templates, suggestions, acceptance into logs	server/routes/combo-logs.ts, server/routes/combo-logs-import.ts, combo pages, combo docs	Combo Log CRUD, Combo Templates, Combo Suggestions
DOM.asset-redundancy	Asset catalog, dedupe, product linkage, artifact metadata, design asset lifecycle	server/routes/asset-ingest.ts, server/services/asset-ingest.ts, asset pages, asset migrations	Asset Ingest
DOM.fulfillment-operations	Order lookup, CSV generation semantics, fulfillment monitoring, supplier-facing operations	supabase/functions/generate-casestry-orders-csv/**, supabase/functions/shopify-order-lookup/**, fulfillment pages and docs	CSV Export, Fulfillment Monitoring, Order Lookup

ORCH: Workflow & Integration Fabric

Subsystem ID	Responsibility	Primary repo loci	Main scenarios
ORCH.shopify-sync	Shopify bulk or paginated sync, product tag refresh, mart refresh triggers, replay/backfill sequencing	server/services/shopify-sync.ts, supabase/functions/sync-performance-data/**, supabase/functions/sync-product-tags/**, backfill scripts	Daily Shopify Bulk Sync, Product Tag Sync
ORCH.asset-and-export-jobs	Asset ingest jobs, export generation jobs, retry/cleanup scripts, file movement between external sources and object storage	supabase/functions/ingest-asset/**, supabase/functions/generate-casestry-orders-csv/**, scripts/backfill-assets.ts, scripts/retry-failed-assets.ts	Asset Ingest, CSV Export
ORCH.casestry-and-release	Casestry webhook handling, order hold/release automation, reconciliation, external supplier workflow mediation	workers/shopify-order-webhook/**, workers/order-release-processor/**, workers/shopify-casestry-reconciliation/**	Fulfillment and order release operational flows

DATA: Data & Knowledge Fabric

Subsystem ID	Responsibility	Primary repo loci	Main scenarios
DATA.domain-store	Transactional and operational tables, migrations, warehouse-era raw/core/mart structures, artifact records	supabase/migrations/**, docs/src/content/docs/data-model/schema.md, docs/commerce-schema/**	All domain scenarios
DATA.analytics-store	Performance marts, run history, telemetry, summary/read models, future R2 Iceberg layers	docs/src/content/docs/data-model/pipeline.md, materialized-view migrations, run-history migrations	Performance Metrics, Tag Analytics, sync scenarios
DATA.contracts-and-schema	Shared types, API specs, queue payloads, ontology-backed naming, schema semantics	shared/schema.ts, casestry-api-spec.json, docs/src/content/docs/architecture/api-reference.md, docs/commerce-schema/00-ontology.md	All scenario contracts

PLAT: Platform Control Plane

Subsystem ID	Responsibility	Primary repo loci	Main scenarios
PLAT.identity-and-access	Auth model, session handling, access enforcement, future CF Access cutover	server/auth.ts, client/src/hooks/use-auth.tsx, client/src/contexts/AuthContext.tsx, docs/src/content/docs/operations/authentication.md	All staff workflows
PLAT.observability	Health reporting, run tracking, alerting, telemetry, error visibility	docs/src/content/docs/operations/observability.md, run-history migrations, worker docs, health endpoints	All async and operational scenarios
PLAT.deployment-and-environment	Build/deploy wiring, secrets, Wrangler/Vercel config, environment partitioning, infra bindings	vercel.json, .wrangler/, worker wrangler.toml, shopify.app.toml, setup docs	Deployment, migration, cutover

GOV: Shared Reference

Subsystem ID	Responsibility	Primary repo loci	Main scenarios
GOV.scenarios-and-architecture	Architecture site, scenarios, ADRs, topology, target design, architecture continuity across OA/SA/LA/PA	docs/src/content/docs/**, especially architecture/** and scenarios/**	All scenarios
GOV.runbooks-and-migration	Operational runbooks, migration plans, rollout plans, implementation status, living docs	docs/LIVING_DOCS.md, docs/ROLLOUT_PLAN.md, docs/ORDER_*, docs/legacy/**	Migration and cutover

Binding rules between current and target architecture

The topology intentionally spans both the current repo and the target rewrite architecture.

• EXP is already a coherent plane in the React app, even though it is still coupled to Supabase auth.
• DOM is currently split between Express route modules and direct client-side Supabase access; the target state consolidates these behaviors behind the dashboard-api Worker.
• ORCH is the most fragmented plane today because its responsibilities are split across Supabase Edge Functions, Cloudflare Workers, and ad hoc scripts. The topology treats them as one fabric so they can be retired or migrated in a controlled order.
• DATA is partly real and partly aspirational today: Supabase migrations are the operational truth, while shared/schema.ts and the docs carry target-state contract intent. Both belong in one governed fabric.
• PLAT contains the hardest cutover seams because auth, secrets, deployment, and observability are changing at the same time.
• GOV is not optional overhead. Under Arcadia, it is the shared reference that keeps OA, LA, PA, and BS aligned as the repo evolves.

Review and ownership implications

• Prefer leaf ownership first. A patch that only changes combo suggestion scoring should stay inside DOM.combo-operations or ORCH.asset-and-export-jobs, not a generic “analytics” bucket.
• Use parent-plane ownership only when a change genuinely spans multiple child subsystems under the same plane.
• Treat DATA.*, PLAT.*, and GOV.* changes as higher-leverage than average because they alter shared contracts, platform posture, or the architectural reference itself.
• When a feature crosses planes, the default patch order should be DATA -> ORCH or DOM -> EXP -> PLAT or GOV, not the reverse.

The operational GitOps rules built on this topology live in Change Topology.