Orientation

This page is the entrance hall for readers who want to understand what the system is designed to do and why — product, UX, and business stakeholders — without wading through engineering reference material. It restates almost nothing: it tells you what exists, in what order to read it, and what each stop will give you.

What Arda does

Arda turns kanban on the shop floor into a closed-loop replenishment system that small and mid-size manufacturers can actually run. Physical cards at the point of use signal demand when stock runs down; the system collates those signals, carries them into supplier orders, receives the goods at the dock, and distributes them back to the waiting cards — with a permanent, self-consistent record of every step. The people in that story are few and concrete: a shop-floor worker who scans a card, a purchasing manager who commits an order, a receiving clerk who counts what actually arrived, and the supplier on the other side of the commitment.

Three ideas do most of the design’s work, and you will meet them everywhere:

• Replenishment is a round trip. A card’s signal travels away from the point of use and the goods travel back to it, lap after lap, with no one tracking state by hand. Exceptions — withdrawn cards, failed runs, canceled drafts — reconcile themselves.
• Commitments freeze; reference data versions. A submitted order shows forever exactly what was agreed — supplier, items, terms — because it pins the versions it was agreed under, while the underlying records keep evolving for everyone else. Renaming or retiring a supplier or catalog item never rewrites history and never breaks work in flight; it only gates new commitments.
• Everything is observable, and records are born honest. What the vendor claimed, what was counted, what was accepted, and what was rejected are separate recorded facts; counts are computed from live stock rather than stored; and modules react to each other’s announcements instead of reaching into each other.

How the design is organized

The system decomposes into five business domains, each depending only on the ones below it. Receiving is the capture surface where material arrives and inventory is born. Procurement holds the agreement documents — the orders committed to suppliers. Operations collates shop-floor demand into demand items and tracks production against them. Resources holds the operational assets: kanban cards and their laps, inventory custody, and the network of stations. Reference data is the slowly-changing records everything points at — catalog items, business affiliates, staff.

The reading path

Read in this order; stop when your question is answered.

1. Personas — who the system is for. Eight personas (a ninth, the internal Platform Operator, is catalogued separately on that page): the five who run the replenishment relay, the business principal, Arda’s own support specialist, and the external supplier.
2. Business Flows — what the system does for those people, as eight end-to-end walks ranked by business value, starting with the pull-replenishment round trip. This is the intent-and-capabilities layer; each step links to the reference page that specifies it.
3. The functional overview — the domain map and, beneath it, one page per module with its purpose, lifecycle, operations, and guarantees. This is the reference layer; visit it from a scenario rather than reading it linearly.
4. The glossary — the design’s vocabulary, one definition per term. Keep it open; the documents use these terms precisely.
5. Module status — which parts of the design are live today, in development, or designed and awaiting build. The scenarios describe the design target; this table says where reality is.

Where this documentation comes from

The pages behind this path are exports of a formally verified design record: the behaviors the scenarios walk — state machines, gates, guarantees — are checked in a formal model before they are documented here. When a page says a submitted order’s terms cannot change, that is a verified property, not an aspiration.