Enablement exits
When the catalog is not the job
Systems map
How the library nests
Four systems layers over the same flat `/docs` URLs — organism, substrate, vertical, and enablement. Categories below keep one nest level of subtopics where the corpus is dense.
Organism
Orientation and day-to-day operating surfaces — what the platform is and how teams run it.
Substrate
Structural model: tenancy, identity, data & ledger — the shared foundation every venture inherits.
Vertical
Per-venture operating loops on the same substrate — fitness, capital, dining, property, construction, counsel.
Enablement
Governed automation and builder contracts — agents, APIs, webhooks, and integration boundaries.
Start here
4 docsNew to the platform: what it is, how a rollout is shaped from first pilot to portfolio, and where daily work happens. Read these first — every other section assumes this orientation.
- Getting startedWelcome to the MCV platform — shared infrastructure built for scale across every brand and business line.
- Venture & brand onboardingHow a new venture plugs into the platform: the consumption contract, the SDK wrapper pattern, identity handoff, isolation rules, and telemetry duty.
- Pilot rollout checklistThe bounded-pilot shape we recommend: one workflow, named owners, explicit proof criteria, and an expansion decision made on evidence.
- Operator consoleInstitutional-grade control room patterns for daily operations — departments, approval gates, live monitoring, and the console boundary.
Platform architecture
6 docsThe structural model underneath every venture: tenant hierarchy, database-level isolation, the layer model, decision logic, and the audit trail. These docs explain why the boundaries exist and how they hold under load.
Tenancy & isolation
3Hierarchy, brand boundary, and how isolation is enforced.
- Multi-tenant architectureThe seven levels of organizational scope on one shared platform — where isolation is enforced, how grants narrow within it, and what is shared versus isolated.
- How per-brand data isolation worksBrand and location boundaries enforced at the database level: blocked by default, explicit by design — and how to think about structuring a new brand.
- Per-brand data isolationPer-brand data stays separate, with isolation enforced at the database level.
Layers & decision logic
2L0–L4 model and the Business OS decision worksheet.
- The L0–L4 layer modelWho owns what in the ecosystem: the substrate, the developer platform, the venture clusters, the convergence hub, and the ventures tier — and why dependencies only flow downward.
- Business OS decision logicOrient shared records, owners, approval gates, and evidence around the decision the workflow must support.
Evidence model
1Audit trail and reconstructable evidence for operators and counsel.
Identity & access
2 docsTriangle secure sign-on, end to end: the public-to-console handoff, session and token mechanics, and how grants resolve per brand. Read these before touching any credentialed surface.
- Triangle: secure sign-onSecure sign-on at the front door — the handoff from public site into the operator console, and how permissions resolve per brand.
- Triangle sessions & tokensThe two-layer session model, the token exchange step by step, lifetimes and rotation, storage discipline, and why invite tokens get their own keys.
Data & ledger
4 docsThe shared record and the shared book: data fabric orientation, isolation mechanics, billing splits, and royalty metering. How operational data and money movement stay separated per brand.
- Data fabric orientationMap authority, identity, lineage, freshness, and failure behavior before connecting an operational source.
- Billing & treasury splitsHow revenue and fees are recorded once on a shared ledger and split across brand, region, and location nodes — with every split reconstructable.
- Royalty metering & the ledgerHow platform usage fees are metered: an append-only, platform-signed, hash-chained ledger with a nightly parity check and a monthly invoicing loop.
- Database isolation mechanicsThe row-level machinery under per-brand isolation: the tenant column, the three standard policies, transaction-scoped context, and the guarded bypass.
Agents
2 docsGoverned automation: the boundaries every agent contract declares and the approval gates in front of irreversible actions. What agents may do unattended — and what always waits for a human.
Boundaries
1What an agent may see, propose, execute, and retain.
Approval gates
1Human gates on irreversible action classes — recorded and scoped per brand.
Operations
2 docsRunning the platform day to day: rosters and constraints, incident readiness, and the support surfaces operators actually use. The operational playbook once the pilot is live.
- Scheduling constraints & the roster engineHow rosters are built from declared constraints — availability, qualifications, hour limits, demand — with conflicts surfaced before publication, not discovered on the floor.
- Support and incident readinessSeparate public orientation from credentialed incident operations while preserving ownership and recovery evidence.
Developers
4 docsBuilding on the platform: the API map, the endpoint reference for the console’s published surfaces, versioning policy, webhooks and events, and the checklist that decides whether an integration is done.
API reference
2Published surfaces, versioning, and compatibility rules.
- API reference overviewService surfaces, SDK contracts, and the endpoint reference for the console’s published BFF surface — what is published, how it is governed, and the shapes to build against.
- API versioning & compatibilityHow platform contracts evolve without breaking consumers: contract-first surfaces, drift as a build failure, additive change only, and the deprecation practice.
Integration
2Webhooks, events, and the boundaries for building against the platform.
- Webhooks & the event substrateReal-time integration on the platform: the transactional outbox, at-least-once delivery, validated event contracts, and signed webhooks with replay protection.
- Integration boundariesConsume published contracts, preserve authority, and stop safely when identity, policy, or source state is uncertain.
Venture lanes
6 docsPer-vertical operating loops — fitness, capital, dining, property, construction, and counsel. Same substrate, tuned workflows, one doc per lane.
- Membership health & retention loopHow engagement telemetry, visit records, and policy-gated outreach form the retention loop on the fitness lane.
- Capital ledger governanceHow splits, gated transfers, and consolidated statements keep the capital record disciplined from location to fund.
- Floor & service operationsFloor balance, phone coverage, kitchen sequencing, and payout math — the operating shape of a service night on the dining lane.
- Tenant record & rollout postureThe tenant lifecycle record, rent ledger, and vendor dispatch model — and the staged-rollout posture the property lane ships under.
- Field record disciplineEnter once in the field, verify before dispatch, sign changes on site — the record discipline and staged-rollout posture of the construction lane.
- Counsel lane design principlesThe design commitments under review for the legal practice lane — stated as direction, with nothing presented as available.
Source · CMS snapshot (seed) — this doc body is served fromcontent/generated/cms-snapshot.json, not the code catalog alone. Staff path: Content Studio (:3030/experience/sites) → Docs tab → publish doc →MCV_CONSOLE_URL=http://localhost:3030 pnpm --filter @mcv-tech/marketing-shell content:seed→ rebuild:3050. Offline:MCV_CMS_SNAPSHOT_FILE=… pnpm content:seed. Category tree / nesting IA stays catalog-authored (L-DOCS); CMS overlays title / excerpt / body / updated only.
Welcome to the MCV platform
The MCV platform is the shared infrastructure institutional-scale, multi-brand operations run on: one secure sign-on, per-brand data isolation enforced at the database, automated royalty and fee tracking, approval gates, and a complete audit trail. Every brand and business line on the platform inherits that foundation — it is never rebuilt per venture.
This page orients you in under ten minutes: what to read first, in which order, and where the boundary between public documentation and the authenticated operator console sits.
The three ideas everything else hangs on
- One shared platform, hard boundaries. All brands run on the same substrate, and every brand's data stays isolated inside it. The boundary is enforced by the database itself, not by application code that can forget a check — read how per-brand data isolation works before anything else.
- One sign-on, every surface. Triangle (secure sign-on) covers the public sites and every operator console. Identity is established once; what you may do is resolved per brand, never assumed from the first brand you belong to. See Triangle: secure sign-on.
- The console is the system of record. Public pages — including this one — are orientation. Live records, approvals, exceptions, and evidence live in the authenticated operator console.
Quick path
Read the isolation model
Start with per-brand data isolation, then the wider multi-tenant architecture for the seven levels of organizational scope. These two pages define the boundary every other feature respects.
Understand the sign-on handoff
Triangle: secure sign-on explains how a request-access submission becomes a credentialed console session, and how permissions resolve per brand. Builders should continue to Triangle sessions & tokens.
Tour the operator console
The operator console page describes the control-room patterns — departments, approval gates, live monitoring — that credentialed operators work in daily.
Plan the rollout
When you are ready to adopt, follow the pilot rollout checklist: one bounded workflow, named owners, explicit proof criteria, and an expansion decision made on evidence. Teams onboarding a whole venture should read venture & brand onboarding.
Where to go next
- Operators: the business OS decision logic worksheet frames every workflow as decision, record, owner, boundary, gate, and evidence.
- Builders: the API reference overview maps the published surfaces, and integration boundaries states the rules for building against them.
- Diligence teams: approval gates and the audit trail & evidence model are the two pages counsel usually asks for first.
How this library is organized
The docs are grouped into eight categories, visible in the sidebar and on the /docs directory: Start here (orientation and rollout), Platform architecture (the structural model), Identity & access (Triangle), Data & ledger (the record and the book), Agents (governed automation), Operations (day-to-day running), Developers (APIs, versioning, webhooks), and Venture lanes (per-vertical operating loops). Every doc cross-links its neighbors, so any page is a valid entry point — but the path above is the one we would hand a new evaluator.
What the docs deliberately do not contain
No production endpoints, credentials, environment URLs, or internal runbooks appear in this library, and no uptime figures or response-time promises — those fail our own honesty bar for public pages. What you will find is the architecture, stated precisely enough to diligence: how isolation is enforced, how sessions and tokens work, how the ledger is signed, how events are delivered, and where every one of those boundaries sits.
Note
Every doc in this library is public architectural orientation. Production schemas, credentials, endpoints, and environment-specific procedures ship with authenticated developer access — never on a marketing page.