R-Dash Requirements Freeze (Checkpoint 1)

Decision

Build R-Dash — Runwal’s internal BI platform to replace Tableau. ENTERPRISE scope, single-tenant self-hosted India-only, Snowflake as ONLY data source (consumption-only, zero ingestion), M11 AI Agent Fabric (Project 120) embedded in v1. Vendored Redash query-runner framework + modern stack (React 19 + Vite + TanStack, FastAPI + Pydantic + SQLAlchemy 2.x, Cube.js semantic layer, RQ + Redis, Tailwind + shadcn, Monaco editor). Target: 10 users × 5 functions × 15 dashboards × 30 days × 0 P0 security incidents within 6 months. Non-negotiable: query-layer RLS + column masking + certified content + audit log.

Rationale

Runwal spends significant Tableau license budget and carries operational debt from scattered Excel/Power BI. Owning the platform captures that spend, builds institutional capability, and embeds Project 120 AI agents natively — a combination no incumbent offers at this price + sovereignty + AI-nativeness. Internal-only posture (not a product) strips multi-tenancy / billing / marketing / public-share surfaces, halving the architecture. Snowflake-only consumption keeps the data flow crystal clear: upstream pipelines (Fivetran/n8n/shim) land all data in Snowflake, R-Dash reads Snowflake. ENTERPRISE scope class locks Full Protocol, Pristine Sweep strictness, and gate rigor appropriate to 9-function governance-critical platform at 500→1000 user target. M11 in v1 is the max-differentiation/max-risk bet — justified because the differentiation IS the AI-native angle; deferring it leaves v1 indistinguishable from Metabase. AI-generated content always flagged “unreviewed” until human certifies (risk mitigation).

Alternatives Rejected

Fork Redash wholesale (rejected) — would inherit React 16.14 + Ant 4.4.3 + Bootstrap 3 + SQLAlchemy 1.3 legacy debt; frontend is a full rewrite regardless, and backend benefits more from greenfield FastAPI than Flask-RESTful refactor. Vendor-port the query-runner subsystem only.

Build as external SaaS product with open-core licensing (rejected) — adds multi-tenancy, billing, marketing, SOC2 Type II, go-to-market motion. Not AJ’s v1 goal. Keep option open via R&D→prod transfer pattern.

Defer M11 AI Agent Fabric to v1.5 (Months 7-8) (rejected) — would ship boring-but-solid BI platform first, lower risk. Rejected because M11 is the only differentiation vs Metabase/Redash/Superset; without it v1 is a competent BI clone, not a moat.

Multi-connector v1 (Salesforce-direct, SAP-direct, SharePoint-direct) (rejected) — Fivetran already lands all this in Snowflake; direct connectors would fragment the semantic layer and add security surface. Snowflake-only = one execution path, one semantic model, zero ambiguity.

Option B / C for SharePoint (dual-engine / per-source toggle) (rejected) — user’s “zero ambiguity” directive. All data via Snowflake, period. Upstream pipelines own ingestion.

Drag-drop VizQL canvas in v1 (rejected) — 6-month project alone; SQL + Cube + AI agent beats it for this SQL-literate audience. Deferred to v2+.

Public dashboards + per-query API keys (Redash signature feature, rejected) — Runwal data never goes public. Binding never-build.

Native mobile apps (rejected) — responsive web sufficient for internal function heads. Separate track if ever needed.

LARGE scope class instead of ENTERPRISE (rejected) — 9 functions + governance-critical + AI-native + 3-year horizon + 1000-user target = enterprise-grade rigor required.

Outcome

Pending

Related

• Helix delivery intelligence
• Project 120
• Redash architecture
• Snowflake
• Cube.js
• Tableau replacement
• sharepoint-data-must-flow-through-snowflake-not-vantage-inge
• internal-enterprise-platform-drops-40-percent-of-saas-archit
• r-dash-v1-approved-stack-react19-fastapi-cubejs-rq
• cube-js-chosen-as-semantic-layer-between-snowflake-and-query
• internal-platform-drops-40pct-architecture-surface
• r-dash-frozen-checkpoint-1-requirements
• r-dash-layer2-frozen-stack-modular-monolith
• r-same-snowflake-only-no-direct-source-connectors