Purpose: One place that consolidates the Start Here → IPloop HTML pages (diagram, data funnel, Supabase structure, database PRD, data preview) plus what already exists live — so we do not need to re-open those tabs to plan Origin.
Audience: Gil + Origin rebuild of IPloop
As of: 15 September 2026
Primary HTML source: `/Users/cortexaios/PrecisionDataHQ/Management-github/docs/source-backups/reachai-os-system-pages.html` (474 KB, 15 Sep 10:00) — Start here dropdown pages
Also used: `~/Iploop/STATUS.md`, live `iploop` Supabase map, Sep 10 PRD/design HTML set, architecture page (direction only)
Stance for Origin: We are not extending the old GitHub tree. GitHub architecture is direction / vocabulary only. We rebuild in Origin from documentation + the live `iploop` Supabase reel, department by department.
Caveat (Gil): The HTML may be an older or incomplete version — primary framework yes, 100% correct no. Prefer Gil’s spoken department model when it conflicts with Management/Knowledge placement.
---
| Layer | Meaning for Origin |
|---|---|
| **Framework** | Departments, money rules, client types, funnel stages — keep |
| **Evidence / snapshots** | Dated counts (Prime vault, workbook, Totach) — use as seed/test, not as live truth |
| **GitHub / agent OS / Management / Knowledge** | Company-wide or historical — **not** IPloop product DB scope |
| **Live `iploop` Supabase** | Already started clean rebuild (10 Sep) — **extend and contract**, do not invent a second product DB |
---
IPloop is a proxy + SDK monetization company run as its own business:
1. Proxy monetization — companies buy bandwidth through the platform (usage GB / requests / success → client cash).
2. SDK monetization — partners supply devices via SDK (inventory observations + partner revenue → partner money).
3. App monetization (Bravo Apps) — later channel; recorded as a business unit, not the first Origin build slice.
One company can be proxy, SDK, or both. Hard money rule everywhere: client cash and partner earnings never share one total. Missing ≠ zero. Reporting is read-oriented; imports land in staging and are reviewed before they become canonical.
Precision Data builds the operating system / tooling. IPloop is the first company that OS runs — drawn on its own in the HTML. For Origin we treat IPloop as a partner product repo + Supabase project, not as a folder under Management.
---
These are the sections we are structuring the database (and later the Origin tree) around:
| # | Department (Gil) | What it owns for IPloop | HTML diagram closest match |
|---|---|---|---|
| 1 | **Marketing** | Outreach, social, signals / templates used in growth | Marketing |
| 2 | **Activities** | Day-to-day operating activity streams (campaigns, outreach runs, follow-ups as *work*, not company OS tasks) | Split across Marketing outreach + Management Kanban in HTML — **rename/reframe for Origin** |
| 3 | **Sales** | Pipeline to partners/clients, SDK intelligence, partner relationships | Sales & partners |
| 4 | **Accounts · Clients · Leads** | Company cards, proxy/SDK client facts, leads before they are clients | Customers & accounts + PRD Section 1 Clients + future Section 2 Leads |
| 5 | **Finance** | Client cash, partner earnings, expenses, cash accounts, P&L (when sources exist) | Finance |
| 6 | **Design & branding** | Site creatives, banners, content templates, brand packs | Design & branding |
| 7 | **Website & applications** | iploop.io, mini sites, apps/distribution surfaces | Website & web dev (+ Bravo Apps as partner delivery later) |
| 8 | **Operational** | All systems connected: network/system inventory, feeds, monitoring, sync health | Operations & technical + System section + connectors |
| Area | Why out |
|---|---|
| **Management** | Strategy, decisions, priorities, company tasks/scheduling for everyone |
| **Knowledge** | Shared learning, sources, examples for everyone |
The HTML still draws a department “Management & knowledge” under IPloop (Kanban, Command Center, knowledge docs, Slack, mail hub). For Origin: do not put that schema inside the IPloop product database as a peer department. If IPloop needs a work board later, it is a thin *operations* concern or stays in company OS — not a core monetization schema.
---
| System | Role | Origin treatment |
|---|---|---|
| **Prime Owner Data Vault** | Authoritative *read-only* reporting snapshot historically (accounts, plans, payments, usage, inventory, revenue workbook, knowledge) | Upstream / drain source — not write target |
| **cortex-data (old Supabase)** | Legacy R&D holding IPloop tenants + many mixed tables | Drain through staging only |
| **precisiondata (OS Supabase)** | Company OS control plane | Out of IPloop product scope |
| **New management write store** (PRD idea) | Tasks metadata, expenses, approvals, annotations + audit | Split: expenses → Finance when ready; tasks/approvals → **not** IPloop core |
| **primepattern-sync Kanban** | Work board snapshot | Not IPloop product DB |
| **SDK lead-intelligence exports** | Competitors / apps / publishers evidence | Feeds **Sales** (+ later Leads) |
Marketing — Outreach (agent + cowork), Apollo, Instantly, enrichment (later), Vista Social, Buffer (unverified use), Trigify signals (candidate). Gap: templates process (design).
Sales & partners — SDK lead intelligence, partner portals, outreach/contact queue (approval-gated), evidence tiers. Gap: CRM read model.
Customers & accounts — Prime accounts/plans/payments/usage, API key metadata, Telegram (candidate), WhatsApp (gap). Gap: support history / notes.
Finance — Client cash payments, partner earnings workbook, iCount, PayPal; expenses / cash accounts / P&L missing everywhere. Gap: two books to reconcile.
Design & branding — Website redesign, social banners, outreach content templates, Buzz design pack. Gap: no tool / no standard.
Website & web dev — GitHub, Vercel, HTML prototypes, client website as money + entry channel. Gap: site list / publishing.
Operations & technical — Prime sync, Hostinger VPS, Better Stack, live inventory, logs, services. Gap: incidents / maintenance.
Management & knowledge *(exclude from IPloop product scope per Gil)* — Kanban, Command Center, gateway, knowledge vault, Supermemory, Slack, mail hub.
Expenses and recurring costs · cash-account balances · complete P&L · durable support history · incident/maintenance · project/milestone structure · approvals + user-action audit · design tool · WhatsApp path · expense sources still owed.
---
Source → import → staging → review → canonical
| Person / feed | Role |
|---|---|
| **Tony (Totach / Barak Revenue Report)** | Partner revenue source of truth; monthly sheet; many rows `source=tony, verified` |
| **Ultron** | Observed system inventory / proxy-usage money (as named in notes) |
Tony’s automatic finance importer was disabled (8 Sep) when Anchor/Soax sync applied — monthly import into staging is the intended path.
1. Client cash — what proxy clients pay (platform, PayPal, …)
2. Partner earnings — what SDK/proxy partners owe (Tony sheet, portals, workbook)
3. Pass-through (e.g. TRON wallet) — tagged expense/pass-through, not operating revenue
4. Expenses / cash accounts / P&L — do not exist in any system yet
Prime as permanent upstream vs migrate Prime reporting into Supabase once. Funnel works either way; arrows change. Origin default recommendation: keep Prime read-only upstream until Clients+System are trustworthy; migrate tables only with an explicit Gil decision.
Expense spreadsheet · cash accounts & opening balances · accounting basis · receipt/invoice locations · FX policy · approval thresholds · full systems register · consolidated website/app list · tenant/Bravo/WhatsApp/mail channel decisions.
---
The HTML designs the new IPloop database in sections. Plain tables first, confirmed on real data, drawn last.
| Section | Status in HTML | Origin priority |
|---|---|---|
| **1 · Clients** | Drafted (Groups A/B/C) | **P0 — already partially live** |
| **2 · Leads & CRM** | Follows later | P2 (Sales + Accounts/Leads) |
| **3 · Inbox** | Follows later | Parked (not Origin first slice) |
| **4 · System** | Drafted | **P0 — already partially live** |
| **5 · Finance** | Follows later | P1 boundary now; full schema when sources exist |
| **6 · Development** | Drafted | P3 evidence admin — optional |
Group A — Company (shared)
Companies · Contacts · Contracts/documents · Notes/follow-ups
Group B — Proxy
Platform accounts · Proxy terms · Usage per day · Country outcomes (quality, not billing) · Balances · Client payments · Monthly results (calc) · Attention (calc)
Group C — SDK
Reporting profile · SDK terms · Inventory observations (flexible metrics) · Revenue observations · Balance observations · Payouts · Monthly results (calc) · Attention (calc)
Rules: missing≠zero · estimated labelled · exact periods · never mix cash streams · success rates from request totals · never sum overlapping device groups.
Inventory snapshots · breakdowns (country/OS/device-type/SDK version as separate views) · activity summaries · usage report runs · coverage issues · freshness limits.
Clocks are different (inventory ≠ activity ≠ usage report). Stale stays visible. Device-type currently duplicated OS in one snapshot — treat as one breakdown until API fixed.
Work items, tests, deployments, review findings — from real files, not an invented sprint board.
---
| Area | Reality | Design impact |
|---|---|---|
| Proxy accounts | 2,732 non-internal; 3 named paying clients; classification needed | Account key = register; keep recorded vs confirmed company |
| Proxy usage | Only closed days then; must run daily | Monthly results stay “partial” until full month |
| Country | Success-only short windows | **Country outcomes**, not usage-by-country billing |
| Proxy payments ledger | Undated / failed purchases mixed | Cash needs Gil payments file + dated platform txs; bonus → balances not cash |
| SDK | 10 clients; heterogeneous metrics; terms unknown | Observations table confirmed; **reporting profile is first SDK job**; balance-meaning table added |
| Contracts / owners | Nowhere structured | Manual admin entry from day one |
| System snapshot | ~91k devices etc.; device-type = OS copy | Confirms Section 4; flag API flaw |
Argus-style: missing≠zero · proxy≠SDK totals · re-import idempotent · door rights · one proxy card + one SDK card readable end-to-end · first write ships with audit or does not ship.
---
Preview fills PRD tables from the 10 Sep workbook: real values where present, dashes where not. Useful as golden examples for Origin migrations/tests.
Companies (13): Serper, GeoEdge, ProxyScrape (proxy API) + BigMama, CashRaven, EarnFM, EarnFM small, Geonode, HoneyGain, Infatica, Infatica 2, Repocket, Soax (SDK).
No contacts/contracts/notes in preview (correctly empty). Classification and attention signals are rule proposals, not confirmed Gil decisions.
---
Logical company tree (Management, Knowledge-Base, Workflows, Agents, Platform, OS, Partners/IPLoop/…).
For Origin IPloop: take only the idea that Partners/IPLoop owns partner-specific ops config and evidence-backed operations — not that we recreate PrecisionDataHQ repos. Physical repo count/hosting unresolved in that page; Origin is the chosen home for the rebuild.
---
| Project | Role |
|---|---|
| **`iploop`** | Live product home (clean rebuild from 10 Sep) |
| **`cortex-data`** | Legacy drain source |
| **`precisiondata`** | Company OS — out of product scope |
`shared` · `clients` · `system` · `staging` · `audit` · `public` empty by design
Migrations 0001–0013 present in `~/Iploop` (apply history partly via SQL editor).
`~/Iploop` (STATUS, migrations, QA checklist) — reference implementation of the clean model. Origin checkout starts empty/greenfield and should absorb this contract, not the old multi-repo Management tree.
---
Proposed schema / domain split for Origin (names can be schemas or prefixed table groups):
| Gil department | Suggested DB area | Primary tables / feeds | First slice? |
|---|---|---|---|
| Accounts · Clients · Leads | `shared` + `clients` (+ later `leads`) | companies, contacts, docs, notes, platform_accounts, proxy_*, sdk_*, attention | **Yes — Clients now; Leads later** |
| Operational | `system` + staging/feed plumbing | inventory, activity, usage runs, freshness, collection_log, door, health | **Yes** |
| Finance | `finance` (new) or views over payments for v1 | client_payments, sdk_payments, later expenses/cash/P&L | **Boundary now; full later** |
| Sales | later `sales` / leads intelligence | SDK lead-intel, partner evidence, pipeline | After Clients trustworthy |
| Marketing | later `marketing` | outreach runs, Apollo/Instantly artifacts, social | After Clients |
| Activities | thin ops tables or views | activity streams linking marketing/sales/account follow-ups | Define after Clients+Sales |
| Design & branding | mostly files + thin metadata | asset registry optional | Low DB priority |
| Website & applications | config + deploy evidence / later apps | site list, Bravo distribution | Low DB priority until Clients/System stable |
| Management / Knowledge | **exclude** | — | Company OS only |
---
Goal: Origin repo structure mirrors departments + data contract, not PrecisionDataHQ’s historical folders.
iploop/ # Origin product repo ├── README.md # What IPloop is + how to run ├── STATUS.md # Live truth (feeds, counts, open items) ├── docs/ │ ├── product/ # Business narrative, monetization pillars │ ├── database/ # This diagnostic, PRD spine, schema contracts │ ├── departments/ # One short brief per Gil department │ │ ├── marketing.md │ │ ├── activities.md │ │ ├── sales.md │ │ ├── accounts-clients-leads.md │ │ ├── finance.md │ │ ├── design-branding.md │ │ ├── website-applications.md │ │ └── operational.md │ ├── admin/ # UI PRDs / templates (Clients, System, …) │ └── sources/ # Pointers to HTML exports, workbook notes (no secrets) ├── supabase/ │ ├── migrations/ # Numbered only; never edit applied │ ├── seed/ # Non-secret fixtures │ └── functions/ # door, platform-pull, totach-pull, health ├── apps/ │ └── admin/ # Admin UI (Gil template) — later └── tools/ # Import/review scripts, QA checks
Origin owns migrations + functions + docs. Supabase project `iploop` remains the reel. Parallel workstreams:
1. Database structure — finish Clients + System contract; add Finance boundary; park Leads/Marketing.
2. Origin tree — docs by department + migration discipline + admin scaffold when ready.
---
Schemas: `proxy`, `sdk`, `system`, `shared`, `staging`, `audit`, later `finance`.
Pros: Matches monetization pillars. Cons: Company card spans schemas (already true today with shared+clients).
Schemas named marketing/sales/accounts/finance/…
Pros: Matches how Gil speaks. Cons: Cross-cutting companies and money rules get messy; Activities overlaps Marketing/Sales.
Keep live `shared` / `clients` / `system` / `staging` / `audit` (already proven).
Add `finance` when expense/cash sources exist.
Add `leads` (or `sales`) when CRM starts.
Document departments in `/docs/departments/*` so org language stays clear without forcing one schema per department on day one.
Treat Activities as append-only operational events (outreach sent, portal scraped, follow-up due, payment imported) linking to company_id — not as Management Kanban. That separates company OS tasks from IPloop business activity.
---
1. Freeze Gil department list (this doc §2) as the Origin vocabulary.
2. Freeze money + funnel rules (§1, §4, §5.1).
3. Confirm hybrid schema Idea C vs A/B.
4. Phase plan (already aligned with existing database plan):
- Phase 0: contract freeze
- Phase 1: complete Clients + System + matching/profiles/rates + view contract
- Phase 2: Admin UI (Clients → System → thin Finance)
- Phase 3: Sales/Leads, Marketing, Activities stream, full Finance, Website/Apps
5. Parallel Origin tree: create `docs/departments` + absorb STATUS/migrations discipline from `~/Iploop`.
6. Ignore Management/Knowledge/GitHub-as-destination while building the product DB.
---
| Artifact | Path / note |
|---|---|
| Start Here HTML (newest) | `PrecisionDataHQ/Management-github/docs/source-backups/reachai-os-system-pages.html` |
| IPloop copy | `PrecisionDataHQ/Iploop/docs/design/reachai-os-system-pages.html` |
| Store HTML copies | `docs/html/*` in this Agent Store |
| Live STATUS | `~/Iploop/STATUS.md` |
| Existing store docs | `docs/iploop-project-description.md`, `docs/iploop-database-plan.md`, `docs/iploop-supabase-map.md` |
| Sep 10 design set | Downloads: Client Admin Design v2, System API Only, Development Admin PRD; `reachai-os/.../iploop-supabase-prd.html` |
---
The HTML gives us a company-shaped framework: departments, channels, funnel, Clients/System/Finance/Dev sections, and strict money rules. Live Supabase `iploop` already started that framework for Accounts/Clients + Operational/System.
For Origin we: rebuild the product home in Origin, keep `iploop` Supabase as the reel, structure thinking by Gil’s eight departments, keep Management & Knowledge above IPloop, and use GitHub architecture only as directional language — then fine-tune strategy/PRD and build database structure and Origin tree in parallel, starting with Clients + System.