DASHBOARDS.md — runtime dashboards + the report catalogue
The dashboard is the HOME of the system (PLANNING §27): attention- driven pending queue per role + live tiles; next-step cards drive the work; forms/reports are power shortcuts, not the main path.
The system's second promise (PLATFORM.md §5): runtime picture, not periodic reports. Reports don't disappear — they become two things:
- Exportable reports — the existing paper reports, reproduced (or imported via the BRIDGE contracts) for records, print, and audit.
- Live dashboard tiles — the same underlying data, continuously aggregated and pushed (realtime hub), for decisions.
Rule: a management screen shows the live picture (as-of seconds ago). Any report is a download of that same picture stamped with an as-of time. No separate "after data entry" report run.
1. Dashboard set (top / middle / floor)
Section-by-section board designs follow the BOARDS pattern (main dashboard → component → sub-dashboard → dump + share; exceptions approvals
- reasoning all triggered in-dashboard; users never leave the system).
Section A (Commercial) v1:
docs/BOARDS-A.md— the fine-tuning template for B–F. The four families below are the board set; each section main board is its concrete instance.
| Board | Audience | Live tiles (each tile = events + aggregate) | Decisions enabled |
|---|---|---|---|
| Company board | owner / top mgmt | order book vs capacity (mtrs pledged vs loom-days), yarn stock cover days per yarn + procurement need (demand − free − in-transit), open PO/SO/delivery positions, grade-wise finished stock, dispatch pending, dues snapshot (Tally-fed, later) | buy/sell decisions, price calls, cash allocation |
| Per-setup board | unit head / middle mgmt | beam plan vs actual per loom (planned/actual/remaining/per-day/projected finish), machine efficiency + breakages (IoT), sizing/winding jobs in flight, checking queue + grade mix today, dispatch queue | re-plan looms, chase sizers/weavers, move labour to bottleneck |
| Floor board (TV) | floor staff | today's target vs actual per loom/shift, checkers' grade mix, pending receipts | keep everyone aligned, no paper chasing |
| Commercial board | owner/sales (phase 4) | leads pipeline, pending samples & follow-ups, quotes→order conversion | pursue the right conversations |
2. Tile ↔ source mapping (how each tile is built)
Every tile = aggregates over typed events (event log, PLATFORM.md §4) + realtime deltas. Examples:
| Tile | Events feeding it | Aggregate |
|---|---|---|
| Procurement need | yarn-in, allocations, order requirements (A2) | need = ΣSO(req kgs) − free − in-transit, per yarn |
| Loom progress | production-plan (D1) + loom-telemetry (D4) + fabric-in (D3) | planned vs actual vs remaining vs per-day |
| Efficiency | loom-telemetry (loomgate adapter) | picks/RPM/breaks/stops → eff% per loom+shift |
| Grade mix | checking (E1/E2) | today's mtrs by grade + seconds/lumps → bales |
| Dispatch position | dispatch (F2) + SO (A1) | balance qty per SO by grade |
| Sizing/Winding WIP | warp-to-sizing (C1), sizing-receipt (C2), winding (C3) | sets out vs in, used-kgs |
3. Report catalogue (fed by uploads)
The full working catalogue — with the owner's round-23 rules (no report silo: reports are placed at the workflow step that uses them; a report is the finished product — anything needing further processing is a dump, not a report; exceptions and approvals happen in-system), the decoded uploads, and the step-by-step placement map (Stage A reviewed) — is docs/REPORTS.md. This table is the intake log of uploads.
| Uploaded report | Source(s) | Decision | Notes |
|---|---|---|---|
| Job-work hishob — "In/Out/Consumption Statement" (per contract, PDF 2026-09-02) | beam inwards, yarn in/out, colth outward, engine per-mtr req | RL, placed at the contract (A6) | format decoded in REPORTS.md §2.1; consumption column = standard rate; "inform within a week" → in-system accept/object via confirm-link |
| Actual vs standard yarn consumption (monthly, PDF 2026-09-02) | weft-issue cones (barcoded), production mtrs, engine standard | rebuilt differently — live per-loom/beam consumption tile at D2/D3; period rollup = download of the tile | never a monthly dump; exceptions flagged in-system (REPORTS.md §2.2) |
Decisions made so far in principle: the checking report (grade split, defects/100 m, measured vs computed GSM) is built in-system and placed at the checking screen (Phase 3); "Yarn Hishob" statements map to the yarn ledger queries (kgs + value) — live; the daily efficiency register is a live table (read-only), not a re-entry form (PLANNING.md §3.4). The valuation method (FIFO vs weighted-avg for stock-mode FG P&L) is decided in REPORTS.md §5 — currently a recommendation awaiting the owner.
4. Export formats
- Print: daisyUI print stylesheets → laser/printer via browser (challans, checking report, dispatch slip with customer/office/transport copies).
- Data: CSV/Excel/PDF exports from any live table (the old software's formats mimicked where the BRIDGE contract requires it).
- All exports carry an as-of timestamp; periodic e-mail/WhatsApp pushes of key tiles are a later phase (notifications), not the source of truth.
5. Cross-cutting dashboard standards (round 30 — binding on every board)
5.1 Table standard (every dashboard table)
Every table supports click-to-sort on any column (asc/desc, A→B), per-column search, and filters (date, party, quality/design, status… based on the columns) — for voluminous transactions you sort and search on the go. Same control set as the dump station (DUMPS.md).
5.2 Period control (every dashboard)
Every dashboard states its period on the tile (e.g. "last 30 days", "this FY", "as of today") and has a from–to date selector to widen it — stats are always read against a visible, changeable period; nothing is an unqualified evergreen number ("2 leads lost" is meaningless without its period; the period is shown and editable).
5.3 Status axiom — nobody updates a status manually
Statuses are never a manual field. Three sources only:
- Workflow-derived: the user's actual work event changes state (scan-selected-tap in the forms — the status IS the work, e.g. a beam tapped onto the loading list = dispatched; hishob party accept = accepted).
- Aging-derived (system assumption): no event within a set time → the system assumes a state (e.g. lead or sample with no follow-up in N days → "stale", flagged). The assumption is visible and reversible.
- Prompted status: the system puts a task on the user's dashboard ("Lead L-192 has no update in N days — reply with a reason"); the user's reply IS the status (and the reasoning is logged automatically). Nothing else exists — no manual dropdown statuses anywhere.
5.4 Personal dashboard (every user)
Each role has its own dashboard — a composition of the components relevant to that role from ALL section dashboards, with the todos section on top (approvals pending, chats awaiting reply, OCR confirmations, prompted-status replies, hishob actions). The personal dashboard is what the user sees on login; sections are its drill-downs.
5.5 Record chat (the "Reason" button)
Every record/row has a Chat action → the record's own in-system chat thread (messages, @mentions, attachments, append-only). It is how the team communicates about a record without leaving the system; mentions surface in the mentioned member's personal dashboard.
5.6 Report AI bot (ever-present)
A report bot is present on every screen (floating, one tap): it can query the whole system (events, masters, aggregates, historical data), generate a custom report/analytics on a user request, and save any generated report as a saved template to rerun later. It is the ad-hoc analytics surface; placed reports remain the "finished product" (REPORTS §1.2), the bot is the long-tail generator. (Phase 4/5; the dump loop feeds it what the team needs.)
5.7 Three mindsets — same spine, three tabs
Job-work, SO (against-order trading) and stock-&-sell are different mindsets — the commercial/user-facing dashboards are separate tabs (own context, own KPIs), while function boards stay common where the function doesn't change (procurement, stock, check-dispatch, capacity are the same job in all three flows). The tab separation is only where the decision changes (commercial/pipeline/hishob vs SO delivery vs stock margin).
5.8 Drill-down UX standard (endorsed approach)
Dashboards are common, with a drill-down tree (usually 2–3 layers): bird's-eye tile → section sub-dashboard → row → the form/entry itself (scan/tap/approve/chat/dump). The hierarchy mirrors how a user thinks — start at the overview, go deep in one section, and the deepest level is where the work (data entry / approval / decision) happens. No separate silo dashboards per flow; drill-down IS the navigation.
5.9 Working-capital cycle board (flow-agnostic)
A process-flow (pipeline) chart tracks stock through every stage — full beam on floor → planned → drawn → production → mending → checked → ready for dispatch — with avg days of stock at each stage, total cycle days, vs target duration, and the difference (good/bad) with system-identified candidate reasons for the bad stages (e.g. beams waiting planning > X, no loom assigned, mending queue depth, ready-but- not-dispatched). Management + the team work each stage; employee KPIs can be linked to stage durations. Where it lives: company board; drilled into each section (e.g. Commercial → ready-for-dispatch stock, checking → mending depth).
5.10 Order book must-shows (owner, round 30)
For trading order book: sold mtrs → delivered + pending; ready stock that could be dispatched against an order but is not yet — shown by stage (under mending, checked, packed, ready for dispatch); dead stock with aging; stock with no order. Purpose: expose the working- capital leak (ready stock sitting undispatched). No approval on delivery release (no micromanaging — a release is a workflow action, not an approval). Capacity booked % ("load") is a KEEP (owner confirmed, round 31): mtrs promised ÷ loom-days available, advisory to stop over-committing.
5.11 Data-provenance comments on every component (round 31 — binding)
Every dashboard component carries an inline explainer (shown on hover, and pinned on click of its ⓘ): What it is · Data (source events / masters) · Who enters it or System-calculated. Every mock ships with these — they are the review aid and the future help text, written once per component.
5.12 Dashboard is the entry surface (UX question, round 31)
Recommendation (owner thinking it through): the whole system's UX is one dashboard tree — the deepest drill of every component is the work itself: the form (scan/tap/approve/chat/entry). No separate menus, no screen that is not reachable by drilling from a dashboard. Everyone lands on their own personal dashboard (role composition + todos) and navigates by drilling. Floor actions stay scan-first within the same tree. Awaiting owner confirmation before it becomes binding.
5.13 Anti-overload rule (round 31 — binding, owner: staff must not be overwhelmed)
The system is a change for everyone; nothing may add mental load.
- Default surface is minimal: a component shows 3–4 obvious numbers; everything else sits behind a "Details ▸" expander (tables, exceptions, history, secondary numbers). Never a wall of data on load.
- One number, one meaning: no jargon, no unexplained KPIs — any number that needs a definition is renamed or removed (see round 30: "drift" → "overdue"; "load" kept only because it's now self- explanatory + advisory).
- Explainers are short: the What · Data · Who/System comment (§5.11) is one line on hover; the full text lives behind the ⓘ. Hover help must not itself become noise.
- Progressive disclosure everywhere: details → dump → form; "show all N" only as a deliberate step, never automatic.
- Personal dashboards are minimal by design (todos + few key numbers); the master dashboard is the owner/superuser review view — staff never land on it.