Codex 0 · Chapter 12 — Dashboards

This chapter specifies dashboard doctrine and the full inventory of every DASH- entry: the audience, the one question it answers, its panels, its source entities and boundaries, its refresh cadence, and its status.

12.0 Purpose

A dashboard is not a data export screen. It exists to answer one question a specific person needs answered, truthfully, at a stated confidence, without letting the presence of a number imply a certainty the underlying data does not support. This chapter fixes that discipline before any dashboard is built or extended.

12.1 Scope and non-scope

In scope. The definition of a dashboard; the doctrine binding every figure, threshold, and drill-down; the full DASH- inventory with its question, panels, sources, cadence, and status.

Not in scope. The engines and boundaries a dashboard reads (Chapters 5, 10), the reporting boundary's own contract (§10.12.10), the annual report and capability indexes as published documents (Chapter 16), and the general surface contract that a dashboard also inherits as a surface (Chapter 11) — this chapter states only what is additional to that contract because the object is a dashboard.

12.2 What a dashboard is

12.2.1 A dashboard is defined by the single question it answers for one audience, restated verbatim from the Registry entry (§157 of the Registry, restated here). A dashboard that cannot state its one question in a sentence is not ready to be built.

12.2.2 A dashboard is a view. It owns no data of its own; every figure traces to a canonical entity (Chapter 07) reached through a declared boundary (Chapter 10), never to a table or query private to the dashboard.

12.2.3 A dashboard is not a report. A report (Chapter 16) is dated, fixed, and archived; a dashboard is live and answers its question as of the moment it is viewed, with its refresh cadence stated plainly to the viewer (§12.3.1).

12.2.4 A dashboard is a surface (Chapter 11) and inherits the surface contract in full: one primary action, progressive disclosure, the five states, metadata, accessibility, and server-side authorisation. This chapter adds obligations specific to figures, aggregation, and explanation; it does not relax anything Chapter 11 requires.

12.3 Dashboard doctrine

12.3.1 Every figure states what it counts and over what period

12.3.1.1 No number appears on a dashboard without an adjacent, plain-language statement of what it counts, over what population, and over what time window. "47 submissions" is not a figure; "47 submissions reviewed in the last 7 days" is.

12.3.1.2 A figure with a stated period that has since elapsed (a "this week" figure shown after the week ends without updating) is treated as an error state (§11.3.3), not left silently stale.

12.3.1.3 Rubric dimension 3 binds dashboards without exception: zero figures without stated meaning is the budget, not a target to approach.

12.3.2 No vanity metrics

12.3.2.1 A metric that exists to make an actor feel active rather than to inform a decision is not shown. Total logins, total clicks, total time on a surface, and any count whose only purpose is to look large are prohibited.

12.3.2.2 A candidate metric is admitted only if it answers, directly, the dashboard's one stated question. A metric that is merely "interesting" but does not answer that question belongs, if anywhere, in a different dashboard whose question it does answer — never bolted onto this one.

12.3.3 No rankings of people against each other

12.3.3.1 No dashboard ranks, orders, or scores one person against another, in leaderboard, percentile, or any other comparative form, at any audience level — including audiences senior to the people being described (§04.4.16, §04.9.4, restated).

12.3.3.2 A dashboard may show a person's own position relative to their own history (was I faster this month than last), and may show aggregate distributions (how many scholars completed this module this term), but never a named or de-anonymized comparison between individuals.

12.3.3.3 This prohibition applies equally to dashboards read by Executives and Stewards; institutional seniority is never a basis for seeing an interpersonal ranking that would otherwise be prohibited (§04.4.16).

12.3.4 Aggregation thresholds that protect individuals

12.3.4.1 Every aggregate figure is computed over a population no smaller than the threshold set by the governing Codex for that data class (§16, restated); a query that would return a figure below threshold instead returns a stated "insufficient population to report" result, never a suppressed-but-inferable near-miss.

12.3.4.2 An Enterprise client or Partner institution dashboard (DASH-07 and its family) enforces this threshold at the boundary (API-10, §10.12.10), never trusts the dashboard's own rendering layer to hide a small number that the underlying query still returned.

12.3.4.3 A drill-down (§12.3.5) may never be used to reconstruct an individual's data by successively narrowing an aggregate below threshold. The boundary enforces the threshold at every level of drill-down, not only at the top.

12.3.5 Drill-down as progressive disclosure

12.3.5.1 A dashboard's surface layer shows the answer to its one question. Depth — the panels behind it, the population behind an aggregate, the history behind a trend — is reached by a labelled affordance, per §11.3.2, never shown all at once on arrival.

12.3.5.2 Drill-down stops at the aggregation threshold (§12.3.4). A dashboard never offers an affordance whose only destination is a number the viewer is not authorised to see; where a boundary would refuse the request, the affordance itself is not shown or is shown disabled with a stated reason (§11.3.3.3).

12.3.6 Explanations accompany machine-generated figures

12.3.6.1 Any figure produced by an engine's inference, a recommendation, a score, or an agent's output (Chapter 13) carries a plain-language explanation of what produced it, reachable from the figure itself, not filed elsewhere.

12.3.6.2 The explanation names the inputs that mattered and, where the underlying model changed over time, states as-of what date the figure was believed true (§10.12.9, the knowledge graph's versioned-edge property, restated as a dashboard obligation).

12.3.6.3 A machine-generated figure is never presented with the same unqualified confidence as a figure counted directly from canonical entities. The distinction between "counted" and "inferred" is visible at the figure, not only in documentation.

12.3.7 Dashboard versus report, restated

12.3.7.1 Where a dashboard and a report (Chapter 16) would show the same underlying figure, the dashboard states the report's most recent dated value alongside its own live value where they differ, so a viewer never mistakes a live number for the fixed, audited one cited elsewhere (e.g. the annual report, SURF-05).

12.3.7.2 A dashboard never substitutes for the report it summarizes. A Steward or Executive citing an institutional figure externally cites the dated report, not a screenshot of a live dashboard (§0.5, status honesty, restated for figures).

12.4 The dashboard inventory

Every entry below carries: audience, the one question it answers, panels, source entities and boundaries, refresh cadence, and status. Status is drawn from the Registry; the single built entry (DASH-02) is grounded in the routes that implement it.

12.4.1 DASH-01 — Personal

• Audience. Member.
• Question. Am I becoming more capable, and what is next?
• Panels. Goal state and progress toward it; recent practice record (habit, without streak framing); financial capability snapshot where the member has opted in; a single recommended next action.
• Sources. ENG-03, ENG-04, ENG-05, ENG-07; boundary API-10 for any cross-engine aggregate.
• Boundaries. No individual data crosses a division boundary here; this dashboard is entirely within the member's own scope.
• Refresh cadence. Real-time on session load; goal and habit panels update on the underlying event, not on a timer.
• Status. reserved.

12.4.2 DASH-02 — Scholar

• Audience. Scholar.
• Question. Where am I in my path and what should I do next?
• Panels. Current position in the enrolled curriculum; the single next recommended unit; recent submissions and their review status.
• Sources. ENT-09 (Curriculum), ENT-10 (Enrolment), ENT-07 (CapabilityAssessment) via API-03/API-04.
• Boundaries. Scoped entirely to the viewing scholar's own Enrolment; no other scholar's data is reachable from this dashboard.
• Refresh cadence. Real-time; reflects the state of Enrolment and progress at the moment of view.
• Status. built — implemented as src/routes/_authenticated/scholar.index.tsx and the SURF-16/17 surfaces (§11.6.3).

12.4.3 DASH-03 — Mentor

• Audience. Mentor.
• Question. Who needs me, and are they progressing?
• Panels. Mentee roster within active mentoring scope; per-mentee progress limited to what the mentee has consented to share; flagged mentees at risk of disengagement, shown without comparative ranking.
• Sources. API-04 scoped to consented data, WF-06 mentoring records.
• Boundaries. No mentee data outside the mentoring scope (§04.4.4); no mentee's financial or engagement record.
• Refresh cadence. Daily; mentoring is not a real-time activity and a daily cadence avoids manufacturing urgency.
• Status. reserved.

12.4.4 DASH-04 — Advisor

• Audience. Advisor.
• Question. What have I committed to, and what is at risk?
• Panels. Active engagements and their commitments; items flagged at-risk (WF-02 stage 4, missed commitment); upcoming delivery milestones.
• Sources. ENT-12 (Engagement) via API-06.
• Boundaries. Scoped to engagements the viewing advisor is staffed to; no other advisor's client material (§04.4.7).
• Refresh cadence. Daily, with an at-risk flag updated on the triggering event.
• Status. reserved.

12.4.5 DASH-05 — Researcher

• Audience. Researcher, Editor.
• Question. What is in flight, and what is blocked?
• Panels. Questions and drafts by stage (WF-03); items awaiting editorial review; publications pending graph linkage.
• Sources. ENT-13 (Publication), ENG-09, via API-07.
• Boundaries. No identifiable member data; research dashboards read derived and anonymized datasets only (§04.4.8, §07).
• Refresh cadence. Real-time on the underlying workflow stage transition.
• Status. reserved.

12.4.6 DASH-06 — Founder

• Audience. Founder.
• Question. Am I hitting milestones, and am I fundable?
• Panels. Milestone cadence and status (WF-04 stage 4); readiness assessment history; funding stage and open capital process where applicable.
• Sources. ENT-15 (Venture), ENT-16 (Investment) via API-08.
• Boundaries. Scoped to the founder's own venture; no other venture's record (§04.4.10).
• Refresh cadence. Weekly, aligned to the milestone review cycle stated in the program; never a countdown to a deadline.
• Status. reserved.

12.4.7 DASH-07 — Investor / Enterprise

• Audience. Investor, Enterprise client.
• Question. Is capability or capital moving as agreed?
• Panels. Portfolio venture status within investment scope, or organizational cohort aggregate capability movement within the agreed reporting scope; agreed report deliverables and their due dates.
• Sources. ENT-15/16 via API-08 (Investor); aggregate cohort data via API-10 (Enterprise).
• Boundaries. No founder personal record; no individual employee's learning record, assessment, or submission absent separate individual consent, and never below the aggregation threshold (§04.4.11, §04.4.12, §12.3.4).
• Refresh cadence. Per the cadence agreed in the investment or enterprise contract; never more frequent than that agreement without renegotiation, so the dashboard does not create a pressure the contract did not.
• Status. reserved.

12.4.8 DASH-08 — Steward

• Audience. Steward.
• Question. Is the institution keeping its commitments?
• Panels. Trust and commitment metrics (Chapter 16); open decision records and their age; audit summary of elevated accesses and the stated reasons; amendment record status.
• Sources. API-10 (aggregates), API-11 (Audit, ENT-19).
• Boundaries. No member content, except through a logged elevation with a stated reason, itself reportable on this same dashboard (§04.4.17).
• Refresh cadence. Daily for audit and commitment panels; on amendment for the decision-record panel.
• Status. reserved.

12.4.9 DASH-09 — Executive

• Audience. Executive.
• Question. Are we on target, and where is capacity constrained?
• Panels. Institutional targets versus results by division; capacity constraints named by division; financial results at the institutional level.
• Sources. API-10, aggregated across all divisions within agreed scope.
• Boundaries. No individual member content by virtue of seniority (§04.4.16); every figure here is an aggregate or a financial result, never a named person's record.
• Refresh cadence. Weekly, aligned to the operating rhythm named in Chapter 03; financial figures follow the closing cadence stated in Chapter 15.
• Status. reserved.

12.4.10 DASH-10 — Administrator

• Audience. Administrator.
• Question. Who has access to what, and why?
• Panels. Current role grants by scope; recent access changes; elevated-access events and their stated reasons.
• Sources. API-01 (Identity & Access), API-11 (Audit).
• Boundaries. No member content; administering access is not authorisation to read what it grants (§04.4.18). This dashboard shows the fact and reason of access, never the accessed content itself.
• Refresh cadence. Real-time for access changes; the record of "why" is fixed at the time of grant and not editable.
• Status. reserved.

12.5 Interfaces

Every DASH- Registry entry (Registry §7) · Chapter 07 for the entities each dashboard reads · Chapter 10, especially API-10 (Reporting & Analytics) and API-11 (Audit), as the boundaries every dashboard is required to read through · Chapter 09 for the workflow stages a dashboard's at-risk and status panels surface · Chapter 11 for the surface contract every dashboard inherits · Chapter 13 for the explainability obligation on any agent-produced figure · Chapter 16 for the distinction between a dashboard (live) and a report (dated and archived).

12.6 Invariants

1. 1Every dashboard states, in one sentence, the single question it answers.
2. 2Every figure states what it counts and over what period, with no exception.
3. 3No dashboard ranks people against each other, at any audience level.
4. 4No aggregate figure is returned below its protective threshold, enforced at the boundary.
5. 5Every machine-generated figure carries a reachable, plain-language explanation.
6. 6A dashboard owns no data; every figure traces to a canonical entity through a declared boundary.

12.7 Prohibitions

1. 1A vanity metric shown because it is available, not because it answers the dashboard's question.
2. 2A leaderboard, percentile rank, or named comparison between individuals, for any audience.
3. 3A drill-down path that reconstructs an individual's data by successive narrowing below threshold.
4. 4A stale figure whose stated period has elapsed, shown without updating or flagging as stale.
5. 5A refresh cadence more frequent than a contracted reporting cadence, imposed to create urgency.
6. 6A machine-generated figure shown with the same unqualified confidence as a directly-counted figure.

12.8 Open questions

1. 1Aggregation threshold value. The specific minimum population size for §12.3.4 is not fixed in this chapter; it is set per data class in Chapter 16 and inherited here, but no dashboard has yet been built against a settled value.
2. 2Dashboard versioning. Whether a dashboard's panel definitions require the same version-and-migration discipline as an API boundary (§10.4) when a panel's meaning changes is undecided.
3. 3Explanation depth for third-party models. Where a machine-generated figure derives from a licensed or third-party model, how much of §12.3.6's explanation obligation can be met without disclosing a vendor's proprietary method is unresolved.
4. 4Cross-division executive rollups. Whether DASH-09 requires a distinct sub-view per division lead audience, or whether §04.4.15's division-lead visibility is served by a filtered instance of the same dashboard, is undecided.

12.9 Governing Codices

Codex 1 (Article VI, individual protection and server-side enforcement), Codex 3 (engines a dashboard is a view over), Codex 4 (audiences and visibility contract), Codex 6 (experience doctrine, the rubric a dashboard inherits as a surface), Codex 9 (amendment procedure), Codex 10 (Institutional Critic review), Chapter 16 (reporting doctrine and the aggregation threshold this chapter inherits).