← All examples
Existing ecommerce company·Transformation baseline·15 nodes

Northstar Commerce

How can an existing architecture evolve without losing intent or missing consequences?

An established retailer maps the responsibilities affected by marketplace sellers and regional expansion before reorganizing its commerce platform.

What this shows

  • — Starts with an existing commerce estate rather than an invented greenfield platform.
  • — Makes one expansion feature cross responsibilities that teams often plan separately.
  • — Keeps unresolved settlement, returns, and regional-policy questions visible.

What this does not prove

  • — This snapshot is the transformation baseline, not evidence that the migration has happened.
  • — Technologies, data models, rollout sequencing, and migration work are intentionally absent.
  • — Revision comparison will be added only after a genuine successor artifact exists.

Example spec

Published snapshot

Four ways to inspect the same committed specification.

15 nodes · 2 features

Northstar Commerce

Operate and expand an established retail commerce business without breaking existing customer promises.

12 responsibilities in scope2 feature paths0 external dependencies

Responsibilities inside Northstar Commerce

Open questions
  • Which existing responsibilities can support marketplace sellers and which require a deliberate split?
Immutable public snapshot4b4f949e

The snapshot is public content. Your own hosted spec remains tenant-scoped and is authored by your coding agent through authenticated MCP tools.

Set up your agent