Moonlitic Platform
MOONLITIC
Folder 07 — Marketplace Full Architecture

Moonlitic Marketplace — Full Architecture & Actor Model

Everything a Chief Architect needs to build the production Marketplace

Version: 2.0  ·  Date: April 2026  ·  Classification: Confidential  ·  Companion: Marketplace_Portal_v2.html (working prototype, 4,443 lines)
Audience: Chief Architect, Engineering Leads, Security, Compliance  ·  Purpose: This document + the .html = everything needed to build production

Table of Contents

1 What the Marketplace Is 2 The Actors — Who Does What 3 Actor Interaction Map 4 System Architecture — 8 Engines 5 Lifecycle — Step by Step 6 Data: Entitlements, Categories, Delivery 7 Security Architecture 8 Money — Billing, Suspension, Overage 9 Tile Roster & Platform Economics (Admin) 10 Production Roadmap — What to Build

1. What the Marketplace Is

The Moonlitic Marketplace is the monetization engine of the entire Moonlitic Healthcore Intelligence Platform. Folders 01–05 build a de-identified health data warehouse (patient consent, clinical intelligence, claims processing, reconciliation, payouts). Folder 07 — this system — sells access to that data.

Companies ("Tile Builders") pay a flat $XXX,XXX/year fee to query de-identified cohort data. Every company type gets the same price (OIG Anti-Kickback compliance). What differs is what data they can access — governed by a per-company-type entitlement matrix enforced at every single query.

The Marketplace is NOT a data download portal. It is a zero-trust, compliance-first query platform where:

For the Chief Architect: The companion file Marketplace_Portal_v2.html is a fully working single-file prototype (4,443 lines, all 11 engines inline, 11 demo users). Open it in a browser. Click through every role. That is the functional spec. This document explains the why and the who behind every screen you see.

2. The Actors — Who Does What

There are 10 distinct actors in the platform (Clinician parked for future). They are not theoretical personas — each one maps to a login in the portal prototype, a role in the codebase, and a set of screens they can see.

👤
NEW_REGISTRANT

New Registrant

Who: An external company visiting the portal for the first time. They have no tile, no data access, no credentials. They are a stranger.

Goal: Apply to become a Tile Builder.

What they can see:

  • Login screen (two-step: email+password, then MFA)
  • Onboarding tab ONLY — nothing else
  • 16-step wizard with real-time field validation
  • Lifecycle tracker (shows progress from onboard → active)

What they can do:

  • Fill out the onboarding wizard (fields auto-save to localStorage)
  • Submit application → triggers compliance screening + approval workflow
  • If rejected: see rejection reason, remediate, and resubmit
  • After approval: execute BAA (digital signature)

What they CANNOT do:

  • See approval, billing, dashboard, or ACL tabs (locked with padlock icon)
  • Query any data
  • See other companies' applications

Demo login: newco@acmebio.com / NewCo2026!

💊
TILE_COMPANY

Tile Company — Pharma

Who: An approved, paying company with an active tile. This specific instance is a Pharmaceutical company (PHARMA type).

Goal: Query de-identified health data for drug research, market analysis, clinical trial feasibility.

What they can see:

  • Onboarding (completed, read-only review)
  • Approval (their application status)
  • Billing (their invoices, payment status, suspension warnings)
  • Dashboard — the main workspace:
    • Credit meter (1,000 annual + overage)
    • Data Catalog (7 categories, color-coded by their entitlement)
    • Guided Query Builder (select category → delivery tier → filter → execute)
    • Query History with ACL references
    • Export Job Tracker (for DATASET_EXPORT jobs)
    • Usage Analytics (burn rate chart, projected exhaustion, category breakdown)
  • ACL Audit Log (their own entries)

Entitlement (PHARMA): Claims ✓, Clinical ✓, Rx ✓, Demographics ✓, SDOH ✗, Genomics ⚡IRB+DUA, Device ✗

Demo login: pharma-demo@acmepharma.com / Demo@Marketplace2026

🏥
TILE_COMPANY

Tile Company — Insurance / Payor

Who: An approved, paying insurance company with an active tile. Same TILE_COMPANY role, different company type, different entitlements.

Goal: Actuarial analysis, population health insights, claims benchmarking. NOT individual underwriting (ACA §1182).

What they can see: Same screens as Pharma. Different data access.

Entitlement (INSURANCE_PAYOR): Claims ✓, Clinical ✓, Rx ✓, Demographics ✓, SDOH ⚡DUA, Genomics ✗, Device ✗

Key difference from Pharma: Can access SDOH (with DUA), cannot access Genomics at all. Special rule: no individual underwriting decisions.

Demo login: underwriter@blueanchor.com / Demo@Marketplace2026

💼
APPROVER_BUSINESS

Approver — Business

Who: Jennifer Walsh, Moonlitic internal. Evaluates revenue impact, strategic fit, and customer risk.

Approves FIRST in the 4-step sequence.

What they can see:

  • Approval tab — pending applications, application details, approve/reject buttons
  • ACL Audit Log

What they do:

  • Review application fields (company type, use case, data categories requested)
  • APPROVE (with optional notes, hashed in ACL) — advances to Functional
  • REJECT (20+ char justification required) — terminates workflow, triggers remediation

SLA: 48 hours. Auto-escalates to proxy1 at 48h, proxy2 at 96h, CEO at 120h.

Demo login: jennifer.walsh@moonlitic.com / Approve2026!

⚖️
APPROVER_FUNCTIONAL

Approver — Functional

Who: Dr. Ravi Nair, Moonlitic internal. Evaluates operational readiness and data governance compliance.

Approves SECOND. Only sees the application after Business approves.

Evaluates: Does the requested data match the stated use case? Is the company type appropriate for the categories requested? Are conditional items (IRB/DUA) present?

SLA: 48 hours. Same escalation chain.

Demo login: ravi.nair@moonlitic.com / Approve2026!

🤝
APPROVER_SALES

Approver — Sales

Who: Marcus Thompson, Moonlitic internal. Evaluates commercial terms and account management fit.

Approves THIRD. Only sees the application after Functional approves.

Evaluates: Is the billing contact valid? Are commercial terms understood? Is there a strategic account conflict?

SLA: 48 hours. Same escalation chain.

Demo login: marcus.t@moonlitic.com / Approve2026!

🛡️
APPROVER_TECHNICAL

Approver — Technical

Who: Priya Sethi, Moonlitic internal. Evaluates integration readiness, security posture, and infrastructure requirements.

Approves LAST (4th). The final gate before BAA + invoicing.

Evaluates: Can this company integrate securely? Do they have the technical infrastructure for dataset exports? Any security red flags?

SLA: 48 hours. Escalates to CISO (not CEO).

Demo login: priya.sethi@moonlitic.com / Approve2026!

💰
FINANCE

Finance

Who: Moonlitic Finance team. They do NOT approve applications. They manage money — both incoming (B2B collections) and outgoing (consumer payouts).

What they can see:

  • Finance Operations tab — Collection Status (all tiles), AR Aging Report, AP Consumer Payouts
  • Wire payment confirmation forms
  • ACL Audit Log

What they do:

  • Confirm wire payments: enter wire ref, validate amount against HMAC-sealed invoice
  • Monitor AR aging: who owes what, how long overdue, send reminders / final notices
  • Process consumer payouts: release pending data monetization and clinical trial payments via Velo
  • Track collection rate and outstanding balances across all tiles

What they CANNOT do:

  • Approve/reject applications (separation of duties)
  • Query data or see tile dashboards
  • Modify invoice amounts (HMAC-sealed, tamper-proof)
  • Reinstate suspended tiles (Admin only)

How it differs from Admin Billing: Admin sees the executive summary (how many paid, how much outstanding). Finance sees the operational detail (who specifically owes, aging buckets, action buttons to send reminders, process payouts). Different audience, different granularity.

Demo login: finance@moonlitic.com / Finance2026!

👑
ADMIN

Moonlitic Admin

Who: Moonlitic platform administrator. Has the widest view. Responsible for marketplace health.

What they can see:

  • Revenue Dashboard (exclusive) — ARR, active tiles, pipeline, payment status, credit utilization across the entire marketplace
  • Onboarding — all applications
  • Approval — all workflows
  • Billing — all invoices
  • Dashboard — all tile data
  • ACL Audit Log — full, unfiltered

Unique powers:

  • See Payment Alerts (tiles in GRACE or SUSPENDED state)
  • Reinstate suspended tiles (one-click, logged to ACL)
  • View revenue by company type, pipeline status, credit burn across all tiles

Demo login: admin@moonlitic.com / Admin2026!

🧑‍⚕️
PATIENT

Patient / Consumer

Who: A real person who has completed Clear IAL2 verification (Folder 01) and consented to share health data categories. Their identity is biometrically verified. They are NOT a company — they are the data source.

What they can see:

  • My Data — 12 consent categories with monetization toggles (ON/OFF), estimated value per category, demand indicators, data activity feed (anonymized), provenance trail
  • Clinical Trials — matching trials based on health profile, accept/decline per trial, enrollment history, withdrawal flow
  • Earnings — two income streams (data monetization + trial compensation), payout history via Velo, revocation impact

What they CANNOT see:

  • Other patients' data (ever)
  • Which companies queried their cohort (de-identified)
  • B2B tabs (Revenue & Economics, Approvals & Pipeline, Billing & Payments, Analytics & Credits, ACL)

Key rules: MFA optional (B2C-friendly). 4-hour session. Cannot delete records (immutability). Revocation is forward-looking only.

Demo logins: sarah.patient@gmail.com / Patient2026!  ·  james.patient@outlook.com / Patient2026!

Actor Summary — Quick Reference

ActorInternal / ExternalRole CodeTabs VisiblePrimary Action
New RegistrantExternalNEW_REGISTRANTOnboardFill wizard, submit application
Tile Company (any type)ExternalTILE_COMPANYOnboard, Approval, Billing, Dashboard, ACLQuery data, manage credits
Approver — BusinessInternalAPPROVER_BUSINESSApproval, ACLApprove/reject (1st in sequence)
Approver — FunctionalInternalAPPROVER_FUNCTIONALApproval, ACLApprove/reject (2nd)
Approver — SalesInternalAPPROVER_SALESApproval, ACLApprove/reject (3rd)
Approver — TechnicalInternalAPPROVER_TECHNICALApproval, ACLApprove/reject (4th, final gate)
FinanceInternalFINANCEFinance Operations (Billing), ACLConfirm wire payments, AR aging, AP payouts, collection tracking
AdminInternalADMINRevenue & Economics, Approvals & Pipeline, Billing & Payments, Analytics & Credits, ACLMonitor marketplace, reinstate tiles
Patient / ConsumerExternal (B2C)PATIENTMy Data, Clinical Trials, EarningsView data value, match trials, earn income
Why 4 approvers? Healthcare data access is irreversible reputational and legal risk. A single approver can be pressured, compromised, or simply not qualified to evaluate all dimensions. Business sees revenue risk. Functional sees regulatory risk. Sales sees contract risk. Technical sees security risk. All 4 must agree. One rejection kills the application (with remediation path).

3. Actor Interaction Map — Who Talks to Whom

The Happy Path (Application → Active Tile)

#FromToActionSystem Effect
1RegistrantSystemFills wizard, clicks SubmitApplication created, compliance screening runs (OIG, SAM, OFAC, CMS). If pass → workflow initiated.
2SystemApprover BusinessNotification: "New application pending"HMAC token generated, 48h SLA clock starts
3Approver BusinessSystemReviews, clicks APPROVEDecision + hashed notes logged to ACL. Advances to Functional.
4SystemApprover FunctionalNotification + new HMAC tokenPrevious token invalidated (single-use)
5Approver FunctionalSystemReviews, clicks APPROVEAdvances to Sales
6Approver SalesSystemReviews, clicks APPROVEAdvances to Technical
7Approver TechnicalSystemReviews, clicks APPROVEAll 4 approved. Workflow COMPLETE.
8SystemRegistrantBAA modal presentedMust sign before invoice generates
9RegistrantSystemSigns BAA (E-SIGN Act digital sig)BAA logged to ACL with HMAC checksum. Invoice auto-generated ($125K).
10SystemFinanceInvoice appears in Billing tab (SENT)Wire instructions sent out-of-band
11FinanceSystemEnters wire ref, confirms amountAmount validated against HMAC-sealed invoice. If match → tile ACTIVATED.
12SystemTile CompanyDashboard unlocked, credentials issued1,000 credits loaded. Data Catalog active. 6-month invoice queued.

The Rejection Path

#FromToActionSystem Effect
3RAny ApproverSystemClicks REJECT (20+ char justification)Workflow terminated. All downstream approvals voided.
4RSystemRegistrantRed rejection banner with reasonBilling/Dashboard tabs re-locked
5RRegistrantSystemClicks "Remediate & Resubmit"Wizard reopens with preserved data. Can fix issues. On submit → full approval cycle restarts from step 2.

The Suspension Path

#FromToActionSystem Effect
S1SystemTile CompanyInvoice due date passes, no paymentGrace period starts. Orange banner with countdown.
S2System (day 16)Tile CompanyAuto-suspend firesTILE_SUSPENDED logged. All queries return TILE_SUSPENDED denial. Red banner.
S3AdminSystemSees alert in Revenue Dashboard, clicks ReinstateTILE_REINSTATED logged. Access restored. Suspension cleared.

The Overage Path

#FromToActionSystem Effect
O1Tile CompanySystemSubmits query that exceeds remaining creditsSystem auto-provisions overage block (100 credits / $500). Query executes normally.
O2SystemTile CompanyOrange overage banner on result + notificationCredit bar shows overage badge. Rate limit info shows cumulative overage cost.
O3SystemFinanceOverage cost accumulated for next billing cycleOverage invoice auto-generated at next billing event

4. System Architecture — 8 Engines

The Marketplace is built from 8 independent engines. Each engine has a single responsibility. They communicate through the Payment Orchestrator (engine 8), which wires the lifecycle together. Every engine writes to the ACL before mutating state.

Engine 1: Data Entitlement Engine

data-entitlement-engine.js

THE compliance layer. Called on EVERY query. No caching.

  • 11 company types × 7 data categories = entitlement matrix
  • Returns ALLOWED, CONDITIONAL (needs IRB/DUA), or DENIED
  • Enforces 4 absolute prohibitions (PHI, SUD, Mental Health, Genetic)
  • k-anonymity minimum cohort sizes per category (10–1,000)

Called by: DeliveryEngine.submitQuery()

Engine 2: Auth Wrapper

marketplace-auth-wrapper.js

Two-step authentication for all actors.

  • Step 1: Email + password (constant-time compare)
  • Step 2: TOTP MFA code (mandatory for all B2B logins)
  • 5-attempt lockout → 15-minute cooldown
  • JWT: IP + user-agent bound, 1-hour expiry, HMAC-SHA256
  • Role determines which tabs are visible

Called by: Login screen

Engine 3: Onboarding Bot

marketplace-onboarding-bot.js

16-step wizard that builds the application record.

  • Real-time validation: EIN (XX-XXXXXXX), phone ((XXX) XXX-XXXX), email domain, field lengths
  • Horizontal field pairing (6 pairs for usability)
  • Info tooltips on every field explaining why it's needed
  • Auto-saves draft to localStorage on every keystroke
  • Welcome-back banner for returning registrants
  • Generates application checksum (SHA-256) for tamper detection

Output: Application record handed to Engine 4

Engine 4: Tile Application Engine

tile-application-engine.js

12-state lifecycle manager. Re-validates everything (zero trust).

  • Compliance screening: OIG LEIE, SAM.gov, OFAC SDN, CMS exclusion
  • If any flag → COMPLIANCE_FAILED (terminal, no appeal)
  • If clear → APPROVAL_IN_PROGRESS
  • Manages state transitions: PENDING → SCREENED → APPROVED → INVOICED → ACTIVE
  • Provisions sandbox and issues API credentials only at ACTIVE

Called by: Orchestrator on application submit

Engine 5: Approval Workflow Engine

approval-workflow-engine.js

Sequential 4-role approval with HMAC tokens.

  • Sequence: BUSINESS → FUNCTIONAL → SALES → TECHNICAL
  • Each approval generates new HMAC token for next role
  • Tokens: single-use, 24h expiry, replay detection
  • Rejection requires 20+ char justification
  • Escalation: proxy1 (48h), proxy2 (96h), C-suite/CISO (120h)
  • Notes hashed (SHA-256) in ACL — content not stored

Called by: Orchestrator + Approver UI actions

Engine 6: Invoice & Billing Engine

invoice-billing-engine.js

Generates HMAC-sealed invoices. Cannot be modified after creation.

  • Flat fee: $XXX,XXX/year (OIG Anti-Kickback)
  • Invoice types: APPROVAL ($125K), SIX_MONTH ($125K), ANNUAL ($XXX,XXX)
  • HMAC seal = invoiceId + amount + type + dueDate
  • Wire ref validation (8–50 chars, alphanumeric)
  • Amount mismatch → logged + blocked
  • 15-day grace period, auto-suspend at day 16
  • Admin reinstatement flow

Called by: Orchestrator + Finance UI

Engine 7: Data Delivery Controller

data-delivery-controller.js

Executes queries. 3 delivery tiers. Rate limits. Credit system.

  • Checks suspension → entitlement → rate limit → credits → k-anonymity
  • Aggregate Report: 0 credits, 500/day, bucketed sizes
  • Cohort Query: 1 credit, 100/day, up to 10K records
  • Dataset Export: 50 credits, 5/day, async blob, signed URL
  • Overage: auto-provisions 100-credit blocks at $500/block
  • Export Job Tracker: QUEUED → PROCESSING → READY

Called by: Tile Company Dashboard UI

Engine 8: Payment Orchestrator

marketplace-payment-orchestrator.js

THE glue. Wires all engines into one lifecycle.

  • registerApplication() → calls Engine 4 + Engine 5
  • onApprovalComplete() → calls Engine 6 (invoice)
  • onPaymentConfirmed() → calls Engine 4 (activate) + Engine 6 (6-mo invoice)
  • Manages lifecycle phases: onboard → review → approval → baa → payment → active
  • BAA execution (E-SIGN Act digital signature)

Called by: All UI actions that change lifecycle state

Cross-cutting concern: ACL (Audit Control Ledger) — Not a separate engine, but a shared service used by ALL engines. Every state transition, login, query, approval, rejection, payment, suspension, and overage writes to the ACL before the state mutation occurs. If the ACL write fails, the operation aborts. This is the "fail-closed" guarantee. In production, this maps to Azure Confidential Ledger.

5. Lifecycle — Step by Step

Visual Lifecycle (6 phases tracked in UI)

1OnboardRegistrant
2ReviewSystem (auto)
3Approval4 Approvers
4BAARegistrant
5PaymentFinance
6ActiveTile Company

Detailed Phase Breakdown

PhasePrimary ActorEntry TriggerExit TriggerWhat HappensIf Failure
1. Onboard Registrant User clicks "Begin Onboarding" Clicks "Submit Application" 16-step wizard. Fields validated in real-time. Draft auto-saved. On submit: checksum sealed, application record created. Can save and resume anytime (localStorage)
2. Review System (automated) Application submitted Screening passes Re-validates all fields. Runs OIG LEIE, SAM.gov, OFAC SDN, CMS exclusion checks. Takes <2 seconds. COMPLIANCE_FAILED — terminal, no appeal. Registrant told: "Contact legal."
3. Approval 4 Approvers (sequential) Screening passes All 4 approve OR any 1 rejects BUSINESS → FUNCTIONAL → SALES → TECHNICAL. Each gets HMAC token. 48h SLA each. Sequential — can't skip. Rejection: 20+ char justification. Registrant sees reason + can remediate and resubmit (full cycle restarts).
4. BAA Registrant All 4 approve BAA signed Modal with full BAA text. Requires: (1) checkbox "I have read," (2) typed legal name, (3) title/authority. HMAC checksum logged. Cannot proceed without BAA. No invoice generated until signed.
5. Payment Finance BAA executed Wire confirmed $125K invoice auto-generated (HMAC-sealed). Finance confirms wire ref + amount. Amount validated against seal. Mismatch: logged + blocked. No payment by day 16: auto-suspend.
6. Active Tile Company Payment confirmed Annual renewal or suspension API credentials issued. 1,000 credits loaded. Dashboard + Data Catalog active. 6-month invoice queued. Non-payment: 15-day grace → auto-suspend. Credit exhaustion: overage auto-provision.

6. Data: Entitlements, Categories, Delivery

6.1 Absolute Prohibitions — No Exceptions

These apply to ALL actors, ALL company types, ALL consent states. Federal and state law, not policy.

1. Identifiable PHI — HIPAA 45 CFR §164.502(a)(5)(ii). No sale of identifiable patient data. Ever.
2. SUD Records — 42 CFR Part 2 (ICD-10 F10–F19). Cannot disclose even with consent except QSOA.
3. Mental Health — Texas §611 (ICD-10 F20–F91). Requires specific legal authorization beyond HIPAA.
4. Genetic Data — GINA (ICD-10 Z14–Z84). Minimum 1,000-patient cohort for any genomic query.

6.2 Entitlement Matrix — 11 Company Types × 7 Categories

Company TypeClaimsClinicalRxDemo-graphicsSDOHGenomicsDeviceKey Restriction
Pharma / Biotech⚡IRB+DUANo off-label promotion
Drug Mfgr / PBMApproved indications only
Insurance / Payor⚡DUANo individual underwriting (ACA §1182)
Clinical Trial / CRO⚡IRB⚡IRB⚡IRBIRB required; protocol-limited
Data AggregatorRESALE PROHIBITED
Health IT / EHRInteroperability use only
ACO / Care MgmtCovered entity/BA required
Academic Research⚡IRB⚡IRB⚡IRB⚡IRBIRB required; no commercial gain
Employer PlanOWN MEMBERS ONLY (GINA/ADA)
Government⚡DUAAggregate only; FOIA risk
AI / AnalyticsRe-identification audit required

6.3 Data Categories — Schema Reference

CategoryGrainRecordsDate RangeRefreshMin Cohort
Claims AdjudicatedClaim-level~48M2018-01 to presentWeekly50
Clinical OutcomesPatient-level~12M2019-06 to presentMonthly100
Rx UtilizationFill-level~85M2017-01 to presentWeekly25
Population DemographicsPatient-level~210M2015-01 to presentQuarterly10
Social DeterminantsCensus-tract~35M2020-01 to presentSemi-annual50
Genomics AggregateVariant-level~2M2021-01 to presentQuarterly1,000
Device TelemetryReading-level~15M2022-01 to presentDaily100

6.4 Delivery Tiers

TierCostRate LimitMax RecordsModeInfrastructure
Aggregate Report0 credits (free)500/day, 10K/monthN/A (stats only)SynchronousBucketed cohort sizes — no exact counts
Cohort Query1 credit100/day, 1K/month10,000SynchronousDe-identified record-level data
Dataset Export50 credits5/day, 20/month5,000,000Async blobEncrypted Azure Blob. Signed URL: IP-locked, single-use, 24h expiry, 50 MB/s cap

7. Security Architecture

Zero trust means: every component assumes every other component is compromised. Nothing is cached. Nothing is trusted. Every request is validated from scratch.

Authentication

Two-step: password (constant-time compare) + TOTP MFA. 5-attempt lockout, 15-min cooldown. JWT bound to IP + user-agent hash. 1-hour expiry.

Authorization

Role → tab visibility (hard-coded per role). Entitlement → data access (checked at every query). Suspension → query blocking (checked at every query). No caching. No trust.

Encryption

AES-256-GCM for sensitive fields (EIN, email, phone). HMAC-SHA256 for JWT, approval tokens, invoice seals, BAA checksums, export URL signing. Session keys zeroed on SIGTERM.

Tokens

Approval tokens: HMAC-signed, 24h expiry, single-use (Set-based replay detection). JWT: 1h expiry. Export URLs: IP-locked, single-use, 24h expiry, signed.

ACL (Audit Control Ledger)

Immutable append-only log. Written BEFORE every state change. If write fails → operation aborts (fail-closed). Covers: logins, queries, approvals, rejections, payments, suspensions, overages.

4-Person Rule

No single person can approve a tile. 4 different roles evaluate 4 different risk dimensions. Each has 2 proxies + C-suite escalation. No workflow depends on one person.

Credentials Last

API keys and tile credentials are ONLY created at the ACTIVE state — after approval, BAA, and payment. Never at any earlier stage. If the tile is suspended, credentials are revoked.

k-Anonymity

Every query checks cohort size against the category minimum (10–1,000). If the cohort is too small, the query is denied to prevent re-identification. Aggregate sizes are bucketed, not exact.

Invoice Tamper Protection

HMAC seal = sha256(invoiceId + amount + type + dueDate). On payment confirmation, Finance's amount is validated against the seal. Mismatch → logged + blocked. No human can change an invoice amount.

Auto-Suspend

System auto-suspends at day 16 (no human decision). DeliveryEngine checks suspension status at every query. Suspended tiles get TILE_SUSPENDED denial. Only Admin can reinstate.

Rejection Accountability

Every rejection requires 20+ character justification. Stored in ACL. Cannot silently reject. Remediation path preserves data and resets workflow for resubmission.

Data Delivery Protection

Export URLs: IP-locked (callerIp baked into HMAC), single-use (tracked), 24h expiry (timestamp in seal), 50 MB/s cap. Direct browser download blocked — API pipeline required.

8. Money — Billing, Suspension, Overage

8.1 Pricing (Non-Negotiable)

ItemAmountWhy It's This Way
Annual Fee$XXX,XXX/yearFlat for ALL company types. OIG Anti-Kickback: differential pricing = favoritism risk.
Approval Invoice (50%)$125,000Due on approval. Gets them in the door.
6-Month Invoice (50%)$125,000Auto-generated at month 6. Completes the annual fee.
Annual Renewal$XXX,XXXAuto-generated 30 days before anniversary.
Included Credits1,000/yearCovers typical query volume for most tiles.
Overage Block$500 per 100 creditsAuto-provisioned when credits exhaust. Not punitive — enables continued access.
Payment MethodWire transfer ONLYNo ACH, no credit card. No bank details stored in system. Wire ref validated.

8.2 Grace Period & Auto-Suspension Timeline

DayStatusWhat HappensActor Involved
Due DateCURRENTNormal operations. No warnings.
Day 1–15GRACEOrange banner with countdown. Queries still allowed. Progress bar fills.Tile Company sees warning
Day 16SUSPENDEDAll queries blocked. TILE_SUSPENDED in ACL. Red banner.System (automatic)
After paymentREINSTATEDAdmin clicks Reinstate in Revenue Dashboard. Access restored.Admin

8.3 Overage Credits

TriggerSystem ActionNotification
Query cost > remaining creditsAuto-provision ceil(deficit / 100) blocks × $500Orange banner on query result. Overage badge on credit meter.
Cumulative overage visibleRate limit info shows "Overage: $X (N blocks)"Usage Analytics updated with new total
Next billing cycleOverage costs included in next invoiceFinance sees overage line items

8.4 Admin Tab Architecture (Tab Redistribution)

Admin content is distributed across 5 focused tabs (Onboarding removed from Admin view). Each tab loads its own render function for fast, scrollless UX:

TabLabelContentRender Function
RevenueRevenue & EconomicsPlatform Economics (P&L), Revenue by Company Type, Tile Roster (CRM table)renderAdminRevenue()
ApprovalApprovals & PipelineExisting approval workflows + Application Pipeline (all pending apps)renderAdminApproval()
BillingBilling & PaymentsExisting billing/invoicing + Payment Status Overview + Suspension Alerts with ReinstaterenderAdminBilling()
DashboardAnalytics & CreditsMarketplace-wide credit utilization (per-tile breakdown) + Query AnalyticsrenderAdminDashboard()
ACLACLImmutable audit trail (unchanged)

Implementation: renderRevenueDashboard() is now a master orchestrator that calls all four renderAdmin*() functions. Each function injects Admin-only content into shared screen divs via hidden <div> containers (adminPipelineSection, adminBillingSection, adminDashboardSection). Tab labels and screen headers are dynamically updated when Admin logs in and reset on logout.

9. Tile Roster & Platform Economics — The Admin's Full Picture

9.1 Why This Exists

The Revenue & Economics tab (the Admin's default tab) shows the full financial picture: Platform Economics at the top, then Revenue by Company Type, then the full Tile Roster. Operational details like payment alerts, pipeline, and credit analytics live in their respective tabs (Billing, Approvals, Analytics).

But the CEO, CSO, CTO, or COO needs to answer different questions:

  1. "Who are all our customers?" — A complete roster of every Tile Builder: company name, type, tile ID, join date, payment status, credit usage, data categories they query most. A CRM-like view.
  2. "What is the business doing?" — Total platform revenue, total consumer payouts, platform margin, growth trend, revenue by company type.
  3. "How is the consumer side performing?" — How many patients are active, how many are monetizing, what's the total pool, average patient earnings, trial enrollment funnel.

This is NOT a new role. The ADMIN role already has the widest view. The Admin's content is distributed across 5 focused tabs (Revenue & Economics, Approvals & Pipeline, Billing & Payments, Analytics & Credits, ACL). The Tile Roster (customer table) and Platform Economics (P&L view) live in the Revenue & Economics tab — the Admin's default landing page.

9.2 Tile Roster — Every Customer at a Glance

A sortable, filterable table showing every active, grace, and suspended tile:

ColumnSourceWhy It Matters
Company NameOnboarding wizard (Step 1)Who is this customer?
Company Type11-type entitlement matrixPharma, Insurance, CRO, AI, ACO, etc. Drives entitlement + risk profile
Tile IDSystem-generatedUnique identifier. Links to all ACL entries, invoices, queries
StatusBillingEngine + SuspensionEngineACTIVE / GRACE / SUSPENDED — color-coded badges
JoinedApproval workflow completion dateCustomer tenure. Used for cohort analysis
ARR$XXX,XXX flat (all types)Revenue attribution per customer
CollectedBillingEngine payment recordsHow much has been paid vs. invoiced. Shows collection health
Credits Used / TotalDeliveryEngine credit trackerUsage intensity. High usage = engaged customer. Low usage = churn risk
Top CategoriesQuery history aggregationWhich data categories this tile queries most. Demand signal
OveragesDeliveryEngine overage trackerHow many overage blocks purchased. Upsell signal

Implementation: Built into the Admin's Revenue & Economics tab as a card below Revenue by Company Type. Filter by status (Active/Grace/Suspended), search by company name. All columns sortable.

9.3 Platform Economics — The P&L View

A single card showing the full financial picture of the Moonlitic platform — both sides of the marketplace:

MetricCalculationAudience
Revenue (Money In)
Total B2B Revenue (ARR)Active tiles × $XXX,XXX/yearCEO, CFO
Collected YTDSum of all confirmed wire paymentsCEO, CFO
Outstanding (Receivables)Total ARR − CollectedCFO
Overage RevenueOverage blocks × $500/blockCSO (upsell signal)
Consumer Payouts (Money Out)
Total Patient PayoutsSum of all Velo disbursements (Folder 03)CEO, CFO
Data Monetization PayoutsRevenue share to consented patients from marketplace queriesCEO
Clinical Trial PayoutsCRO compensation passed through to patientsCEO
Avg Patient Monthly EarningsTotal payouts / active patients / monthsCPO (product health)
Platform Margin
Gross Margin(B2B Revenue − Consumer Payouts) / B2B RevenueCEO, Board
Net Platform RevenueB2B Revenue − Consumer Payouts − Operating CostsCFO
Consumer Pool Health
Total Registered PatientsCount of PATIENT role users (Folder 01)CPO
Actively MonetizingPatients with ≥1 category toggled ONCPO
Trial Enrollment FunnelMatched → Invited → Accepted → ActiveCSO (CRO value prop)
Avg Categories per PatientMonetizing categories / active patientsCPO

Implementation: KPI row at the top of the Revenue Dashboard showing Revenue In, Payouts Out, Margin %. Below that, two side-by-side cards: "B2B Revenue" (left) and "Consumer Payouts" (right). All with (i) tooltips.

9.4 What This Is NOT

This is NOT an executive role. We do not create a separate EXECUTIVE login. The ADMIN role already has the widest view. Content is distributed across 5 focused tabs (Revenue, Approvals, Billing, Analytics, ACL) — each short enough to fit on one screen without scrolling. Onboarding was removed from Admin tabs (it's a NEW_REGISTRANT/TILE_COMPANY concern, not Admin's). If in the future the CEO needs a view that an Admin shouldn't see (e.g., employee compensation data), THEN a separate role makes sense. Not yet.
This is NOT a public-facing storefront. The "Choose Your Data Domain" experience (like the Nexus file) is a pre-login marketing page. It belongs outside the authenticated portal entirely. Parked for future.

10. Production Roadmap — What to Build

The prototype demonstrates every workflow end-to-end. The following table distinguishes what's already working from what needs production implementation. Use your judgment on sequencing.

9.1 What Already Works (in the prototype)

CapabilityStatusNotes
16-step onboarding wizard with validationWorkingAll field types, formatting, draft save/resume
Two-step login (password + MFA)WorkingLockout, IP+UA binding, JWT
4-role sequential approval workflowWorkingHMAC tokens, replay detection, notes hashing
Rejection & Remediation flowWorking20-char justification, data preservation, resubmit
BAA execution (E-SIGN Act)WorkingDigital signature, HMAC checksum in ACL
Invoice generation (HMAC-sealed)WorkingTamper-proof, amount validation on payment
Wire payment confirmationWorkingRef validation, amount match, Finance role
Finance Operations (AR + AP)WorkingCollection status, AR aging report with actions, AP consumer payouts with process/batch, info tooltips
Entitlement enforcement (11 × 7 matrix)WorkingChecked at every query, not cached
3 delivery tiers with rate limitsWorkingCredit metering, k-anonymity, bucketed sizes
Export Job TrackerWorkingQUEUED → PROCESSING → READY with timers
Auto-suspension & grace periodWorking15-day grace, query blocking, Admin reinstate
Overage credit provisioningWorkingAuto-provision, notification, cost tracking
Usage Analytics & burn rateWorking14-day chart, projections, category breakdown
Admin Tab Redistribution (5 tabs)WorkingRevenue & Economics, Approvals & Pipeline, Billing & Payments, Analytics & Credits, ACL — no scrolling
ACL audit loggingWorkingEvery action logged, filterable by module
Role-based progressive tab enablementWorkingTabs lock/unlock based on role + lifecycle phase
Interactive data catalog with schema docsWorkingGrain, fields, sample rows, refresh cycle per category
Patient/Consumer portal (My Data tab)Working12 category cards, monetization toggles, value estimates, provenance trail, activity feed
Clinical Trial Matching (two-way)WorkingPatient sees matching trials, accept/decline, enrollment. CRO sees aggregate match counts.
Earnings Dashboard (Patient)WorkingTwo income streams, payout history (simulated Velo), revocation impact tracking
CRO Patient Matching CardWorkingAggregate match counts on CLINICAL_TRIAL tile dashboard. No individual identities.
Approver Queue KPIsWorkingPending count, total in review, coming next, sequence position, SLA per role. Shows on approver login.
Tile Company Welcome-BackWorkingCredits remaining, utilization, payment status, data refreshes since last login, quick action buttons.
Cross-Role NotificationsWorkingContext-aware alerts on login: approver queue size, applicant status updates, Finance overdue/payout alerts, Admin platform health.
Patient Returning ExperienceWorkingNew trial matches, pending payouts, last payout, query activity since last visit. Clickable cards to jump to detail.

9.2 What Needs Production Implementation

ItemPriorityCurrent State (Demo)Production RequirementSuggested Tech
Encryption at Rest P0 Web Crypto API referenced; fields stored in JS objects Server-side AES-256-GCM with managed key rotation Azure Key Vault + Cosmos DB encrypted properties
Government DB Checks P0 Pattern match ("EXCLUDED" / "SANCTIONED") Real API integration to OIG LEIE, SAM.gov, OFAC SDN, CMS Scheduled batch + real-time check on submit. Cache 24h.
ICD-10 Query Filtering P0 Prohibitions displayed; no query-level filtering Delivery Engine must strip/block F10–F19, F20–F91, Z14–Z84 from all results SQL WHERE clause exclusion + post-query audit scan
Identity Provider P0 11 hardcoded demo users in source code (9 B2B + 2 Patient) External IdP with SSO, real MFA, password policy Azure AD B2C / Entra ID + TOTP (Authenticator app)
ACL Backend P0 In-memory array with timestamps Immutable, append-only, auditor-accessible ledger Azure Confidential Ledger or Azure Immutable Blob Storage
Real Data Warehouse P0 Simulated query results with random data De-identified data warehouse from Folders 01–05 Microsoft Fabric / Databricks with row-level security
Export Blob Storage P1 Signed URLs with placeholder domain Encrypted Azure Blob + SAS tokens with IP range + single-use tracking Azure Blob Storage (hot tier) + Redis for URL redemption tracking
Approval Escalation Scheduler P1 Manual escalation function (no time trigger) Auto-escalation at 48h → 96h → 120h per the SLA Azure Durable Functions with timer triggers
Email Notifications P1 Gmail MCP drafts (3 templates created) Transactional email at each lifecycle event SendGrid / Azure Communication Services
Renewal Invoice Scheduler P1 Described in architecture; no cron Auto-generate 6-month + annual invoices on schedule Azure Logic Apps with billing calendar
Wizard Draft Storage P2 localStorage (plaintext on client) Server-side encrypted draft with session key Cosmos DB with client encryption SDK
Employer Membership Filter P2 "OWN MEMBERS ONLY" in special rules text Cross-reference employer_id against member enrollment at query time Query-time JOIN with enrollment table
AI Re-identification Audit P2 "Model re-identification audit required" in special rules Periodic audit of AI/Analytics tile query patterns for re-identification risk Scheduled analysis job + alert threshold

9.3 Recommended Build Sequence

Sprint 1 (Weeks 1–4): Identity Provider + ACL Backend + Encryption at Rest. These are prerequisites for everything else. Stand up Azure AD B2C, Confidential Ledger, and Key Vault. Port auth, ACL, and crypto modules from prototype.

Sprint 2 (Weeks 5–8): Government DB Integration + ICD-10 Filtering + Real Data Warehouse. Connect OIG/SAM/OFAC APIs. Build the query engine against Fabric/Databricks with row-level security and diagnosis code exclusions.

Sprint 3 (Weeks 9–12): Export Blob Storage + Email Notifications + Escalation Scheduler. Complete the async delivery pipeline. Wire up transactional emails. Implement time-based approval escalation.

Sprint 4 (Weeks 13–16): Renewal Scheduler + Employer Filter + AI Audit + Polish. Billing automation. Edge-case compliance. Load testing. Security review.

Total estimate: 16 weeks to production with a team of 4–6 engineers, assuming the prototype as functional spec and this document as architectural spec.