The Design Registry

15 — Reporting, Analytics & Operational Intelligence

Version: 1.0
Prepared: August 2026
Status: Engineering and product source of truth
Primary principle: One governed metric system; different permission-scoped reporting experiences for Registry, Designer Studio and Provider Workspaces.

1. Executive Summary

This specification defines reporting, analytics and operational intelligence for The Design Registry. Reports are not independent spreadsheets or manually maintained dashboard totals. They are permission-scoped projections of canonical Pipelines, Entities, Projects, Tasks, Calendar events, Time Entries, Items, Budgets, Offers, Proposals, Work Orders, Invoices, Payments, Files, Communications and operational evidence.

The reporting product serves three fundamentally different audiences:

Registry operators need network, market, application, Matchmaking, Project, Provider, service-quality, transaction and marketplace intelligence across authorized markets.
Designer Studios need CRM, Project, Client, team, workload, time, budget, procurement, revenue and studio-performance reporting for their own Workspace.
Providers need Offers, conversion, Work Orders, capacity, service-level, exceptions, invoicing, payment and business reporting for their own Workspace and assigned scope.

These experiences share metric definitions, filters, chart and table components, export controls, saved views, scheduling, freshness and lineage. They do not share unrestricted data. The same metric can resolve different permitted records and fields for each audience.

The current product contains only a disabled Reports navigation placeholder with no route or Coming soon label. It must remain unavailable until a working report catalogue, governed metric definitions and permission-safe drilldown exist.

A report explains what happened, why the number is trustworthy, what records support it and what action an authorized user can take next.

2. Product Outcomes

Give each audience a useful reporting home without exposing another Workspace’s private data.
Replace spreadsheet reconciliation with traceable metrics and record drilldown.
Make every number explainable through definition, filters, grain, time zone, currency, freshness and source lineage.
Separate operational attention from historical analytics while linking both to canonical records.
Support saved views, scheduled delivery and controlled exports.
Provide trusted capacity and performance inputs to Matchmaking without exposing private schedules or pricing.
Preserve historical interpretation when Pipeline, Project Template, Category or status labels change.
Allow AI to summarize and investigate authorized metrics without inventing facts or bypassing permissions.

2.1 Success measures

Every published metric has an owner, definition, formula, source, grain, dimensions, freshness target and permission policy.
Dashboard and report totals reconcile to canonical records within the metric’s stated freshness window.
Every aggregate supports permission-safe drilldown or explicitly explains why drilldown is unavailable.
Scheduled reports contain no data the recipient could not access interactively at delivery time.
Export events record actor, Workspace, report, filters, columns, record count and time.
Metric discrepancies can be reproduced and resolved through lineage rather than manual guesswork.

3. Current Product Correction Contract

The August 4, 2026 live review found:

Reports is a disabled # navigation item.
It has no Coming soon label, unlike Messages.
No report route, catalogue, chart, table, metric definition, drilldown, export or scheduled delivery exists.
No audience separation can be verified.

Immediate correction:

Label the disabled entry Coming soon.
Keep it non-interactive until a real route exists.
Do not represent the navigation placeholder as a working feature.
Enable the route only when Registry, Designer Studio and Provider report catalogues are permission-scoped and at least the launch metrics pass reconciliation tests.

4. Core Concepts

4.1 Metric Definition

A versioned definition containing stable key, display name, business meaning, formula, numerator/denominator, source records, grain, dimensions, exclusions, currency behavior, time semantics, freshness target, owner and access policy.

4.2 Report Definition

A versioned configuration that selects metrics, dimensions, filters, visualizations, columns, drilldowns and audience rules.

4.3 Report Run

One evaluated report with exact definition version, Workspace, user, filters, permissions, time zone, currency, as-of time, source watermark and result status.

4.4 Saved View

A named user- or Workspace-owned set of report filters, grouping, columns and presentation. A Saved View never changes the underlying metric definition.

4.5 Snapshot and Live Query

Operational reports may query current authorized read models. Historical and financial metrics use reproducible snapshots or event-derived facts. Every result states its as-of time and freshness.

4.6 Drilldown

A permission-filtered list of canonical records supporting an aggregate. Aggregate access does not automatically grant record or field access.

5. Information Architecture

5.1 Reports home

audience-aware report catalogue;
favourites and recent reports;
saved views;
scheduled deliveries;
data freshness and incidents;
glossary/metric definitions;
permission-safe search.

5.2 Report page

title, purpose, owner and definition version;
date range, time zone and currency;
audience and Workspace scope;
filters and comparison period;
metric cards;
charts and governed tables;
explain-this-metric control;
drilldown;
save view, export and schedule controls;
source/freshness details.

5.3 Global versus contextual reports

Global Reports provides portfolio views. Projects, Pipelines, Entity Profiles and Provider Jobs embed contextual projections from the same metric service. Embedded cards never maintain separate totals.

6. Registry Reporting Catalogue

Registry reports are market- and permission-scoped.

6.1 Network growth and health

Designer Studios and Providers by market, Category and Network Status;
applications, approval rate, time in Stage and verification workload;
Profile Completeness, Credential actions and readiness;
active, paused, suspended and offboarding Entities;
Provider Category coverage, geographic gaps and capacity.

6.2 Demand and Pipeline

Project Opportunities by source, market, budget, Stage and owner;
conversion, loss reasons, aging, velocity and weighted value;
small-lead and target-project segments;
lead distribution and response service levels.

6.3 Matchmaking and assignments

Match Runs, eligibility failures, candidate depth and confidence;
shortlist, Offer response, acceptance and Assignment conversion;
time to match, override reasons and concentration;
Category/market supply-demand gaps.

6.4 Project and operations

active Projects by Phase, health, market and Designer Studio;
schedule, approval, budget, procurement and Provider exceptions;
receiving damage, storage aging, delivery and installation performance;
Provider Job completion and deficiency resolution.

6.5 Commercial and marketplace

Proposal, Work Order, Invoice and Payment volume;
marketplace transaction value and approved fee/take-rate components;
outstanding receivables/payables and payment exceptions;
Provider concentration and category economics;
reconciliation and integration health.

Registry reports must not expose hidden terms to Designers, Providers or Clients merely because their records contribute to an aggregate.

7. Designer Studio Reporting Catalogue

Pipeline: opportunities, source, Stage, aging, conversion and forecast;
Projects: Phase, health, milestones, approvals, risk and completion;
Clients: active relationships, response, decisions and communication workload;
team: Tasks, workload, capacity, overdue work and Time Entries;
design time: planned versus actual hours by Project, Phase, Task and user;
Items and Budgets: planned, approved, committed, actual and forecast by Category;
procurement: approvals, orders, lead time, shipments, receiving, storage, delivery and installation;
commercial: Proposals, revenue, invoices, payments and profitability where permitted;
Providers: assigned work, service performance and exceptions without exposing Registry-private economics.

Workspace Owners may create Saved Views but cannot redefine protected formulas such as paid revenue or approved budget variance.

8. Provider Reporting Catalogue

Offers received, response time, acceptance/decline and win rate;
active Provider Jobs and Work Orders by status, Project and due period;
capacity, crew/resource commitments and utilization;
on-time milestones, service-level performance and blockers;
category-specific operations such as receiving accuracy, damage, storage aging, delivery completion or installation deficiencies;
Proposal value, Invoice status, payment timing and outstanding amounts for the Provider’s Workspace;
Client/Designer communication response where authorized;
Credential/readiness actions and expiry risk.

Providers never see competing Provider data, Registry margin, other Provider pricing or unassigned Project scope.

9. Filters, Dimensions and Comparisons

Shared dimensions include date, market, Workspace, Entity, Provider Category, Project, Project Phase, Pipeline, Stage/system state, owner, team, source, status, currency and service type.

Rules:

display labels use stable internal keys and version context;
historical values do not change when a label is renamed;
date filters identify event date, effective date or snapshot date;
time zone is visible;
multi-currency reports preserve source amount, reporting amount, rate source and conversion date;
comparison periods use equivalent duration and state their boundaries.

10. Metric Governance and Quality

Each metric requires:

business and technical owner;
formula and examples;
canonical source tables/events;
included/excluded States;
grain and allowed dimensions;
null, duplicate and late-event policy;
time zone and currency policy;
freshness service level;
permission classification;
version and change log;
automated reconciliation tests.

Breaking changes create a new metric version. Historical Report Runs preserve the version used. A correction may restate prior data only through an explicit restatement record and visible notice.

11. Permissions, Privacy and Exports

Reports enforce Workspace, Project, record and field permissions server-side.
Aggregate thresholds prevent inference from very small hidden cohorts where required.
Contact, financial, margin, credential and performance fields have independent visibility.
Drilldown rechecks access at request time.
Scheduled delivery rechecks recipient access at send time.
Exports use permitted columns, row limits, watermarking/expiry where appropriate and immutable audit.
Clients do not receive the general Reports module; Client-safe status belongs to the Client Portal.

Users can save private views. Authorized Workspace Owners can publish Workspace views. Registry can publish protected system views.

Scheduled delivery supports in-app and secure email links, not unrestricted attachments by default. Schedules include recipients, cadence, time zone, format, filters and expiration. Revoked access cancels future delivery.

Report links preserve filters but never embed authorization in the URL.

13. Operational Intelligence and Alerts

Operational intelligence identifies actionable exceptions such as overdue approvals, stalled Pipelines, capacity conflict, budget variance, delayed shipment, aging storage, credential expiry, payment failure or communication backlog.

Alerts are domain-event driven and configured through the Notifications Builder. A report threshold does not silently mutate a Project, award work or send external communication.

14. AI Requirements

AI may:

summarize authorized report results;
explain a metric definition and contributing drivers;
propose filters or comparisons;
identify anomalies and likely data-quality issues;
draft an operating review with citations to metrics and drilldowns;
forecast only when the model, horizon, inputs and uncertainty are disclosed.

AI may not:

bypass permissions or minimum-cohort rules;
invent metrics, dates, revenue, Provider performance or causal explanations;
change metric definitions;
treat correlation as causation;
distribute a report without an authorized human/configured schedule.

Every AI statement links to the source Report Run and metric version.

15. Data Model

Minimum tables or equivalent services:

metric_definitions
metric_definition_versions
report_definitions
report_definition_versions
report_runs
report_run_parameters
report_result_artifacts
report_saved_views
report_schedules
report_delivery_attempts
report_exports
metric_snapshots
metric_reconciliation_results
metric_restatements
analytics_events

Operational facts remain in their owning services. Reporting tables store definitions, reproducible runs, snapshots and delivery metadata rather than competing editable business truth.

16. API Design

Representative endpoints:

GET /reports/catalogue
GET /reports/{key}
POST /reports/{key}/runs
GET /report-runs/{id}
GET /report-runs/{id}/drilldown
POST /report-saved-views
POST /report-schedules
POST /report-runs/{id}/exports
GET /metrics/{key}/definition
GET /metrics/{key}/quality

Long-running runs and exports are asynchronous, idempotent and auditable. Query parameters are validated against the report definition and user scope.

17. Supabase and Performance

Row Level Security protects Workspace-scoped definitions, views and results.
Security-definer functions are narrowly scoped and never accept unvalidated Workspace IDs.
Materialized views/read models support expensive aggregates.
Incremental updates use durable domain events and source watermarks.
Large drilldowns paginate or virtualize.
Report Runs enforce query budgets, cancellation and timeouts.
Cached results include permission scope, definition version, filters and source watermark in the cache key.

18. Acceptance Criteria

Reports navigation is labelled Coming soon until a working route exists.
Registry, Designer Studio and Provider users receive separate report catalogues.
Every launch metric has a governed definition, source lineage and automated reconciliation.
Every result shows filters, time zone, currency, as-of time and freshness.
Drilldown and export never reveal inaccessible records or fields.
Saved views cannot redefine protected formulas.
Scheduled reports recheck access at delivery time.
Historical interpretation survives label and Template changes.
AI output cites Report Runs and does not invent unsupported conclusions.
Dashboard, contextual and global reports reconcile to the same metric service.

19. Implementation Phases

Metric registry, permission model and current placeholder correction.
Shared report shell, filters, tables, charts, drilldown and freshness.
Designer Studio launch catalogue.
Provider launch catalogue and category-specific operations.
Registry network, Matchmaking and marketplace catalogue.
Saved views, controlled exports and scheduled delivery.
Reconciliation operations, anomaly detection and AI summaries.

The implementation rule remains: one governed metric system, permission-scoped by audience, always traceable to canonical records.

Current-product review gap closure register

Generated: August 4, 2026
Owning future specification: 15
Mapped current-product profiles: 1
Recorded review gaps: 3

This register is part of the release contract. It maps the current-product reverse review into required future behavior. A gap is not closed because a screen exists; closure requires the corrected canonical data, permissions, states, migration, audit and test evidence described below.

Register rules

Every profile in the Current Product Library must resolve to one owning future specification.
Current limitations are evidence, not optional ideas. If a limitation is intentionally retained, the specification must record the decision, risk, owner and review date.
Shared-component defects are corrected through Spec 16 and then consumed here; feature teams may not create local replacement controls.
Permission, contact, financial and visibility defects also require Spec 08 enforcement, even when the functional feature is owned by another specification.
Legacy Proper Gallery, Lead, Partner and implementation-facing labels are migration inputs only and must not return through new UI, APIs, exports or notifications.
Verification must use realistic fixtures for Admin, Designer, Provider and Client audiences where applicable.

G01 — Reports and operational intelligence

Current-product profile: reports
Observed route: Coming soon — no route
Evidence confidence: Verified

Review gaps

No report implementation exists.
No audience separation is visible.
No metric catalogue, data lineage, freshness, drilldown, export or scheduling can be verified.

Required future closure

Label Reports Coming soon immediately.
Implement Spec 15 and its governed metric catalogue.
Build separate Registry, Designer Studio and Provider report catalogues.
Add permission-safe drilldown, saved filters, exports, scheduled delivery and freshness indicators.

Closure evidence required

The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
Automated tests cover the identified defect or missing journey so it cannot silently regress.
Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

Live features this specification must correct and evolve