Earlier concepts and evidence · preserved for reference. System 2.0 contains the current direction.

Precision Data · ReachAI OS · Shared memory

One shared memory: how every agent is connected to the door, Supabase, Supermemory and GitHub

Every agent, on every platform, reaches the company's memory through one door. Behind it: the Control Room in Supabase (what is true now), shared Recall in Supermemory (what we remember) beside the private-memory boundary per agent identity, and, on a separate connection, the Library on GitHub (what the company has decided). Hover any agent to see what has been proven for it, and what has not.

10 September 2026 · last-known evidence and intended architecture — not full fleet acceptance · source: Shared Memory Connection Report

demonstrated connection intended or not yet verified known blocker GitHub connection (separate from memory) DSPG per agent: Door · Shared Recall · Private memory · GitHub

Idle. Cyan lines are each agent's connection to the door, violet lines its GitHub connection: solid where demonstrated, dashed where not, red where blocked.

The shared system

Six parts, one of them a rule rather than a place

The ReachAI door authenticates the deployment, identifies the agent, and delivers its current briefing and assigned packages. The Supabase Control Room holds the authoritative workstreams, task state, deployment records, permissions and activity records. Shared Recall in Supermemory returns knowledge that has been saved and indexed, within the agent's permissions. The GitHub Library holds the common rules, skills, agent definitions, implementation and evidence, with access that follows the agent's role.

Private memory is the sixth part and the one that is a rule: notes belonging to one agent, available across its authorised sessions and excluded from every other agent's private recall and from shared knowledge. It is an authorisation boundary, not a separate physical database per agent, and it must not be drawn as one without implementation evidence.

Information flow

Interface → door → briefing → state, shared knowledge, private notes

An agent interface talks to an authenticated ReachAI deployment. The door returns the current briefing and the permitted tools. From there the agent reads shared state and shared knowledge, and its own private memory. A material shared checkpoint is recorded in the Control Room and delivered for indexing into shared Recall. Private notes follow a separate private-memory path.

Session continuity uses compact turn records and explicit checkpoints. That does not mean every full conversation is uploaded automatically; it is not.

GitHub is a separate connection

A working Recall proves nothing about the Library

Memory and GitHub run alongside each other. The intended central GitHub App service issues repository- and role-scoped credentials to each deployment; its master credential stays central and is never distributed to an agent. The App is installed for PrecisionDataHQ/reachai-os, but installation alone does not give any agent access: central issuance and agent-level verification were still underway at the last confirmed handoff.

Identity, interfaces, privacy

One agent, several interfaces; one identity, one private memory

One agent can appear in several interfaces. Aurora, for example, can use Hermes, Telegram and OpenMaus. Each conversation needs its own session identifier. Authorised deployments may map to the same canonical agent identity and the same private memory, but that mapping has to be verified; a matching display name is not enough.

Two agents are called Atlas: the Codex Atlas works on Supabase and data architecture, the Hermes Atlas on outreach. They are separate nodes until their canonical identities are reconciled, and their private memories are never merged silently.

Reading the map

Layers are for display, lines are for evidence

Codex and Claude at the top, Hermes in the middle, Grok below: display layers only, not a reporting hierarchy. Cyan lines are memory: a solid line to the door means the door was specifically demonstrated, and it does not imply private-memory or GitHub acceptance. Violet lines are GitHub: each agent's own connection to the central App, solid only where proven, red where a repair is assigned. Hover a card to see its shared and private Recall lines. Names marked with an asterisk keep a provisional spelling. The remaining Hermes profiles and the proposed Grok relay are left off this page.

Team roster and last-known status

Status reflects prior evidence and repair assignments, not a new acceptance run. An assignment means work was requested, not that every repair has started or passed. Facets: Door, Shared Recall, Private memory, GitHub.

Agent	Layer	Role	Facets	Memory connection / remaining work	Lane

Repair ownership

Two Fable sessions were handed the repair work under the same Foundation rules, skills and onboarding checklist, with the instruction to preserve active chats and unrelated work, avoid duplicate implementation, reuse validated adapters, and finish with one meaningful acceptance per deployment.

Active repair · first Fable session · Hermes

Aurora as the reference repair, then Titan, Mason, Iris and Steward. Central GitHub App issuance and a reusable helper.

Active repair · second Fable session · Codex / Claude

Discover and repair the existing Codex and Claude deployments: Anvil, Atlas (Codex), Argus, Cipher.

Remaining rollout · not yet assigned

The other Hermes profiles and the Grok relay still need confirmed repair assignments.

A deployment is complete only when its checks pass

Its own door returns the expected identity, runtime and home; assigned packages and skills are current.
Shared checkpoint save, retry behaviour and fresh-session Recall work.
Private save and fresh-session recall work for the owner; a peer cannot retrieve the note; the note is absent from shared Recall and from activity history.
Ordinary turn recording, session separation, session finish, and denial of later writes work.
GitHub access matches the verified role: builders prove read, branch push and pull-request access; read-only roles prove read and denied write; relay-only roles prove delivery through an authorised builder.

Record actual pass and fail with exact blockers. Configuration, assignments, inferred behaviour and created files are not passing evidence.

Evidence basis: Gill's roster and role corrections, the existing agent definitions, the 8 September runtime-memory audit, the Hermes fleet checklist from the Aurora worktree, and the two Fable task handoffs. Some older records contain roles or blockers superseded by later owner instructions and the GitHub App setup. Consult live Control Room state and current test evidence before any operational change or before upgrading a status to complete. No credentials, keys, tokens or private-note contents appear on this page.

Precision Data · the company · work in progress

Precision Data: one company building its own operating system, and using it to build everything else

Precision Data is the company in scope. ReachAI OS and ReachAI are products being built inside it, alongside website development, mobile development, systems integration and design. Gill directs priorities and reviews results; delivery runs through three working layers. Hover a function to see what exists in the evidence and what the next gap is.

10 September 2026 · initial evidence review — not a fresh production audit · source: Precision Data initial company and work report

working foundation · live test evidence real assets · not yet proven connected, built or adopted you ask, review, assign delivery through the layers (not a management chain)

Idle. Cyan dot: live test evidence. Amber dot: real assets, not yet proven connected, built or adopted.

Company definition

Precision Data is the company; everything else is a product or a function inside it

Following Gill's direction, Precision Data is the company in scope; other companies are separate company contexts. ReachAI OS and ReachAI are products or capabilities being built within Precision Data, alongside website development, mobile development, technology integration and design. Existing software folders and application workspaces do not by themselves establish company ownership or company boundaries.

This page adopts that direction for its structure. It does not change registrations, database boundaries, permissions or the approved Library definitions.

The three working layers

Close collaboration, partly coordinated work, direct assignments

Gill directs priorities and reviews results. Delivery happens through close collaboration with Codex and Claude, partly coordinated work with Hermes agents, and direct assignments to Grok bots. These are working relationships, not proof that one runtime manages another. Named Anvil, Atlas, Argus and Cipher deployments exist, with successful local onboarding recorded for three seats; Hermes acceptance varies by deployment and interface; Forge has prior shared recording and Recall evidence, and the broader tagged contributions through Forge remain a proposed arrangement.

Present state

Working parts exist; one accepted company-wide system does not yet

Precision Data is developing its own AI operating system while using that system to build the products and capabilities the company needs. Working parts already exist in shared memory, agent access, company planning, application interfaces and design. The evidence does not yet establish one fully connected, accepted company-wide system.

Most useful next step

One work register, organised by the six functions

Each entry shows the company, product or function, the accountable person or agent, the working interface, the current deliverable, evidence of completion and one next action. Reconcile existing work into that register before starting duplicate builds. Prioritise the ReachAI OS readiness gaps and the ReachAI interface and data map, because the other functions depend on them.

Work by department

What the reviewed evidence contains for each function, and the present assessment with its next gap.

Department	What exists in the reviewed evidence	Present assessment and next gap

The three working layers

Layer	Role in Gill's operating model	Evidence and limit
Codex and Claude	Direct planning, implementation, review and coordination with Gill.	Named Anvil, Atlas, Argus and Cipher deployments exist. Earlier briefing records successful local onboarding for three seats; cloud and Cowork acceptance still has gaps.
Hermes agents	Specialist work with partial coordination.	The roster includes research, development, web development and systems integration roles. Several agents have recorded door and memory activity, but full acceptance varies by deployment and interface.
Grok bots	Direct tasks from Gill.	Forge has prior shared recording and Recall evidence. Broader tagged contributions through Forge remain a proposed arrangement; tags do not prove distinct authenticated identities or private memories.

Evidence and limits

This review used the successful Anvil briefing of 10 September, accessible Codex task records, current local documents and prior dated evidence. A later start request was rejected by the door with an instance mismatch; no further cross-instance access was attempted, no fresh company-wide Control Room inventory was obtained, and the report has not been recorded there.
The earlier successful briefing explicitly identified the Precision Data instance, so the rejection alone does not establish that Anvil belongs to another company.
Application and deployment information from July is historical, not a claim that the same production services are healthy today. September evidence is newer but bounded to the tests and deployments it names. Some local documents are uncommitted drafts.
No new deployment tests, production probes or code changes were performed. Other companies' delivery work is excluded; shared implementation assets are mentioned only as evidence of reusable capability.

Sources reviewed

Source	What it contributed
ReachAI door briefing, 10 Sep	Identity, work state, completed local-seat checks and recent activity.
Shared Memory Connection Report	Roster, roles, connection limits and assigned repairs (see tab 2). `docs/program/SHARED-MEMORY-TEAM-VISUAL-BRIEF-2026-09-10.md`
Private Memory Acceptance	Deployed save, retry and peer-isolation evidence. `docs/evidence/foundation/private-memory-save-2026-09-09.md`
Existing Data Inventory	Known data systems and outstanding catalog work. `docs/program/data/EXISTING-DATA-INVENTORY.md`
ReachAI Operating Plan (30 Jul)	Historical application, backend, mobile and Command Center boundaries.
Knowledge Library Implementation	Implemented browsing and read-only data boundary.
Mobile Implementation Brief	Intended mobile delivery scope, not completion evidence.
Mobile Design Pack (Buzz kit)	Reusable design assets and their limits.
Precision Data blueprint hub	Five-view planning artifact (Company Structure, Departments & Connectors, OS, Memory, Communication); a planning artifact, not proof of implemented integrations.

IPLoop · a company run on ReachAI OS · operation map

IPLoop: every department a real company has, each with the systems it runs on

IPLoop is its own company, run on the operating system Precision Data builds. It is drawn here on its own: its business units, the agent team dedicated to it, the departments, and under each department the systems and data sources it is built on. The bottom rows show where the data lives today and the three channels clients arrive through, which is what the Supabase design has to serve. Hover any box for its source.

10 September 2026 · starting structure — assembled from the IPLoop Management Admin PRD, the OS baseline, the connectors blueprint and Gill's notes; not a verified integration inventory

documented and in use (verified data or confirmed connection) recorded, use or connection not verified proposed or later missing in every system today H = Hermes agent · G = Grok bot through Forge

Idle. Top to bottom: the company and its business units, the agent team, the departments with their systems, the systems of record, and the client channels.

Why IPLoop is drawn on its own

Precision Data builds the operating system; IPLoop is the first company it runs

Earlier drawings put Precision Data on top, IPLoop below it and other companies below that. This page follows the newer direction: each company is built separately. Precision Data builds the agent technology, processes and operating system; IPLoop is the company those are now being implemented in, with everything a regular company has: finance, marketing, design, website, customers and accounts, operations, task management, data, client performance and email. The IPLoop agent team can be the same agents used today or agents dedicated to IPLoop.

What the documents establish

Three business units, six tenants, one read-only vault

The OS baseline records IPLoop as a client account with three business units: Proxy Monetization, SDK Monetization and App Monetization (Bravo Apps). In the existing cortex-data database IPLoop appears as the tenants iploop, sdk-monetization, bravo-apps and iploop-management. The IPLoop Management Admin PRD (15 August, corrected by its v1.1 addendum) makes the Prime Owner Data Vault the authoritative read-only reporting source and the primepattern-sync Hermes Kanban the authoritative work board, and records the verified Prime snapshot: 2,754 accounts, 2,752 plans, 92 payment transactions, 26,565 usage rollups, 11,120 inventory snapshots, 79,602 revenue workbook cells, 226 knowledge documents.

Why map the departments to systems

The Supabase design follows the channels, not the org chart

Clients reach IPLoop through three channels: SDK partners, proxy companies and, later, apps. Money arrives through several more: the client website and platform, the admin systems, and third-party systems such as iCount, PayPal and the partner portals. Mapping which department depends on which source is what tells the data work what Supabase has to hold, and what it must not mix: the PRD's rules keep client cash and partner earnings separate, treat a missing value as missing rather than zero, and keep reporting read-only.

What is still missing

Red bars are gaps in every system, not just in the drawing

The v1.1 addendum lists what does not exist anywhere yet: expenses and recurring costs, cash-account balances, a complete P&L, durable support history and customer follow-up notes, incident and maintenance records, project and milestone structure, approvals and a user-action audit. Design has no documented tool, and two known gaps remain in the connectors evidence: WhatsApp has no path and the expense sources are still owed.

Departments, agents and systems

One row per department: the verticals inside it, the agents named for it in the roster or by Gill, and the systems and data sources the documents record for it.

Department	Verticals	Agents	Systems and data sources	Gap

Systems of record and client channels

System	Role	Evidence
Prime Owner Data Vault	Authoritative read-only reporting source for accounts, plans, payments, usage, inventory, revenue workbook and logs.	PRD v1.1 addendum §4.1: STATUS.json verified 14 Aug 2026, read-only mode, production-write denial passing.
cortex-data (Supabase)	Existing R&D database holding the IPLoop tenants, SDK partner and revenue tables, iploop_clients, iploop_payments, icount_companies.	Baseline §13 (31 Aug inspection); reachai-is release migrations; Anchor SDK migrations applied 8 Sep.
precisiondata (Supabase)	The ReachAI OS control plane: instances, workstreams, sessions, deployments. Development data only; IPLoop exists as an isolation fixture.	Phase 1 plan §2–4; decision 0008.
Management database (new)	Separate write store for tasks metadata, expenses, approvals, saved views, annotations, with a full audit trail.	PRD §1 and addendum §7: required, not built.
primepattern-sync Kanban	Authoritative work board (99 tasks at audit; no due dates or project fields).	Addendum §4.2.
SDK lead-intelligence exports	Currently authoritative for competitors, apps, publishers and partner evidence.	PRD §14B wiring.
Client channels	SDK partners and proxy companies today; apps later.	Gill, 10 Sep; baseline business units.

Sources: IPLOOP_MANAGEMENT_ADMIN_PRD.md and its v1.1 addendum (Desktop/OS plan); Precision-Data-ReachAI-OS-Baseline-v2026.09.01.md §2.1 and §13; the Departments & Connectors blueprint (Cipher, 9 Sep); the Shared Memory Connection Report roster (10 Sep); Gill's notes of 10 Sep on marketing, design, finance and client channels. Names marked * keep a provisional spelling. Counts are the dated snapshot values, not live figures. No system was queried for this page.

ReachAI OS · the living system · original executive overview

reachai-os-living-system.html (3 September 2026), shown unchanged inside this file · the companies and departments it draws as "next layers" and "instances" are now on tabs 3 and 4; evidence per agent is on tab 2 · it loads its fonts from the internet

IPLoop · the data funnel · every source, how it gets in, where it lives, who uses it

The IPLoop data funnel: everything we do, from every source, into one place we can trust

One row per area of work. Left to right: where the data comes from (people, portals, sites, accounts), how it gets in (pipelines, imports, feeds), where it lives today (Prime, cortex-data, the new management tables, or nowhere), and who uses it (admin pages and agents). Every box is taken from a document; the red ones exist in no system yet. This is the map the Supabase design is built from.

10 September 2026 · assembled from PRD-v2 (3 Sep, re-checked live), the IPLoop Management Admin PRD and its v1.1 addendum, the OS baseline §13, the phase-1 document review, the working instructions and Gill’s notes · counts are dated snapshots, not live

exists and is used (verified data or confirmed connection) exists, partial or not verified planned in the PRD, not built missing everywhere · or still owed by the owner disabled or broken

Idle. Hover a row title to light the whole row; hover a box for its source and status.

The rule of the funnel

Source → import → staging → review → canonical

Nothing becomes a company number by being pasted. PRD-v2's data rules, adopted from the IPLoop PRD: every source is logged as a source before anything is imported from it; imports land in staging and are reviewed row by row; only approval makes a row canonical; verified upstream rows (Tony's) are locked and need an explicit, logged unlock to change. Missing is not zero: stale, partial, estimated and unverified are states, shown as such.

Two feeds from people

Tony and Ultron are sources, not systems

Tony's monthly Google Sheet ("Barak Revenue Report") is the source of truth for partner revenue: 462 of 509 revenue rows carry source=tony, verified, and Tony approves the finance and inventory numbers. Ultron feeds the IPLoop-observed system inventory (iploop_reporting.system_inventory_daily) and, in Gill's words, the proxy-usage money. Tony's automatic finance importer was disabled on 8 September when the Anchor/Soax sync was applied; today Tony's sheet is meant to arrive by monthly import into staging.

Money never mixes

Client cash, partner earnings, pass-through, expenses: four streams

Client cash is what proxy clients pay through the platform (Prime payment transactions, PayPal). Partner earnings are what the SDK and proxy partners owe, from Tony's sheet, the nine partner portals and the revenue workbook. TRON wallet money is pass-through, tagged as expense, never operating revenue. Expenses, cash accounts and the P&L do not exist in any system yet; Finance Overview must read "expense coverage incomplete" until Gill's sources arrive.

The open decision that shapes Supabase

Prime as upstream, or Prime migrated into Supabase

Prime, the Postgres on the Hostinger VPS fed by JSONL drops every five minutes, is verified and rich: accounts, plans, usage, inventory, revenue workbook, logs, 226 knowledge documents. The IPLoop PRD made it the read-only authority; Gill now wants cortex-data shaped as the home. PRD-v2 leaves it as decision one: admin reads Prime and Supabase holds the canonical model, or Prime's reporting data migrates once into Supabase. The funnel above works either way; the arrows from Prime change direction.

Every source, in one table

Department, source, what it feeds, where it lives today, and its status. Owner or login is shown where a document names it.

Area	Source	Feeds	Lives today	Status

What the funnel still needs from the owner

These are the open items PRD-v2 lists as owed; each becomes a source row the moment it is named.

Item	Why the funnel needs it
Expense spreadsheet / CSV and the recurring-cost list	Servers, SaaS, provider bills, payroll and contractor amounts with periods. Without it the expense ledger and the P&L cannot show real totals.
Cash accounts, opening balances, who may view each	Bank, payment processor, crypto and owner-held accounts; reconciliation of client receipts and expenses depends on them.
Historical expense start date · cash or accrual basis	The P&L must state its basis; the ledger needs a first date.
Receipt and invoice locations · currency and FX policy	Document storage and retention for evidence; every expense carries currency, FX rate and source.
Approval thresholds and approvers	Expense transitions (submitted → approved → paid) need named approvers.
Subscriptions and accounts we are signed into	The Systems register today has four rows; the register needs every system with whose login, what it feeds, last sync and health.
The list of websites (Framer, Hostinger, Vercel) and applications built	No document holds a consolidated list; Framer appears in no document at all. Needed for the web, app and design rows.
Tenant list and Bravo status · WhatsApp path · mail channels in scope	PRD-v2 open decisions 2, 3 and 7; they decide which channels the Inbox and CRM rows must cover.

Sources: PRD-v2.md fill plan and open decisions (Desktop/OS plan, 3 Sep, re-checked live); IPLOOP_MANAGEMENT_ADMIN_PRD.md §13–§27 and the v1.1 addendum §4–§7; Baseline §13.3–13.5; phase-1 document review §1–§5 (writers of cortex-data, Anchor/Soax sync, Tony's importer); WORKING-INSTRUCTIONS.md §4 stack and §5 skills; Gill's notes of 10 Sep (Ultron, Tony, bank, PayPal, subscriptions, Framer, Hostinger, applications). No system was queried for this page; every count is the dated value in its source.

IPLoop · the new database · built section by section

The IPLoop database: what we keep about each client, one table at a time

This tab is being rebuilt from scratch. Each section of the database is written here first as plain tables (what we keep, one row per what, where it comes from today, what is still missing), reviewed with Gil against real data, and only then drawn. The illustration comes at the end, when every section is agreed. Sections 1 (Clients), 4 (System) and 6 (Development) are drafted below; 2 (Leads and CRM), 3 (Inbox) and 5 (Finance) follow.

10 September 2026 · design only · nothing created in Supabase yet · no real client figures on this page · basis: the IPLoop Client Admin Design v2, the IPLoop System Data Tables design (API only), the IPLoop Development Admin PRD, the old database (read-only look, 10 Sep), Prime, Gil's notes

source exists today and can be imported partial: exists but incomplete, unmatched or stale calculated from other tables no source anywhere yet · to be entered or decided

Section 1 · Clients

IPLoop has two kinds of client, and they are measured by different things. A proxy client buys bandwidth: what matters is usage (GB, requests, success) and the money it owes. An SDK client supplies devices through our SDK: what matters is inventory (devices, IPs, activity, geography) and the revenue that inventory earns. One company can be both. So the section has three groups of tables: the company itself (shared), the proxy side, and the SDK side.

Group A · the company

One card per company, whatever it buys or supplies

Name, type, status, contacts, contracts, notes and follow-ups live once. The proxy and SDK results sit inside the same card, never in two disconnected lists.

Group B · proxy clients

Usage is the fact, spend is a calculation

Usage arrives per platform account per day. Spend is usage times an approved rate; where no rate is approved it is shown as unpriced, never as zero. Cash received is recorded separately from charges.

Group C · SDK clients

Every client reports inventory its own way

One reports daily active devices by region, another live devices by country, another valid and invalid IPs. One flexible observations table keeps each measurement under its own name, period and geography. Nothing is renamed into a single device total.

The rules the tables obey

Missing is not zero; estimated is labelled; periods are exact

Every figure carries its period and timezone, its source and its status (final, provisional, estimated, not provided). Client cash and partner revenue never mix. Success rates use request totals, not averages of daily percentages. Device counts are never added across overlapping groups.

Group A · Company tables (shared by both client types)

One row per company, contact, document or note. These tables hold the relationship; the results tables below refer to them.

Table	What it holds	One row per	Where it comes from today	Status
Companies	Company name · client type (proxy, SDK, both) · status (trial or testing, active, paused, inactive) · website · country · account owner · working with us since · next follow-up	company	Client register (7 proxy clients) · SDK partner list (9 partners) · iCount counterparties (16)	partial: three lists, not yet one; no owner recorded anywhere
Contacts	Name · role · email · preferred channel · main contact yes/no	person at a company	Client register emails · partner portal logins · mail hub	partial
Contracts and documents	Document name · type (main contract, NDA, amendment, pricing agreement, invoice, other) · service covered (proxy, SDK, both) · status (draft, awaiting signature, signed, expired, replaced) · version and signed copy · parties and signature dates · start and end dates · renewal type and notice deadline · commercial terms summary · exceptions and obligations · responsible person · file	document	nowhere as a table; files sit in mail and drives	to be entered
Notes and follow-ups	Date · subject · note or action · responsible person · due date · status (open, in progress, waiting, done) · related item (contract, invoice, payment, issue)	note or task	Client register notes column only	to be entered

Group B · Proxy client tables (usage and money)

A proxy client is a company that buys bandwidth through the platform. The unit of measurement is the platform account; a company can have more than one. Everything below hangs off the account-to-company mapping, which is the first job.

Table	What it holds	One row per	Where it comes from today	Status
Platform accounts	Account prefix · company · label · status · first seen · last seen · matched by whom and when	platform account	Usage feed: 23 accounts seen since 17 Aug, all unmatched to a company	partial: the mapping has to be made by hand, then kept current
Proxy terms	Price per GB · currency · effective date · billing arrangement (prepaid, postpaid, test credits) · monthly commitment · data allowance · spending limit · payment terms · related agreement	company and effective date (history kept)	Client register: rate and billing model for some clients	partial: rates approved for 2 of 7; the rest are unpriced
Usage per day	Date · account · GB · requests · successes · success rate · source run	account and day	Usage feed (daily rows since 17 Aug) · Prime usage rollups (26,565)	exists; gaps in the daily feed (sampled days, not every day)
Usage by country	Date · account · country · GB · requests · successes	account, day and country	not in the old database; Prime may hold it	to be decided: confirm whether Prime records the country used
Balances	Date · company · money credit · GB remaining · plan name · source	company and day (snapshot)	Prime plans and balances (2,752 plans)	exists in Prime only; import a daily snapshot or read Prime as upstream
Client payments	Date (paid or recorded, labelled) · company · period covered · amount · currency · method (PayPal, purchase, bonus, invoice) · status (due, overdue, partially paid, paid, cancelled, refunded) · due date · invoice or reference · amount outstanding	payment or invoice	Prime payment register (19 rows, stopped 5 Aug) · PayPal feed · iCount invoices	partial: feed stopped; iCount counterparties not linked to companies
Monthly results (calculated)	Month · company · GB · requests · success rate · spend (or unpriced) · payments received · outstanding at month end · status (in progress, closed) · comparison with the same elapsed period last month · estimated month-end spend (labelled)	company and month	calculated from usage, terms and payments	calculated; correct only once accounts are mapped and rates approved
Attention signals (calculated)	Usage dropped · low success rate · unpaid usage · no approved rate · unmatched account · silent while paying · low balance · overdue payment	company and signal	calculated from the tables above	calculated

What the proxy list shows the admin: company, status, usage this month, spend this month, expected monthly spend (estimated), data remaining, account owner, needs attention. All of it comes from the tables above; nothing is typed in twice.

Group C · SDK client tables (inventory and revenue)

An SDK client is a company whose devices run our SDK. Each one reports different things, in different units, over different periods, and money can flow either way. The tables keep each client's own definitions instead of forcing one common number.

Table	What it holds	One row per	Where it comes from today	Status
SDK reporting profile	Company · what this client reports (which measurements, which geography type, which breakdowns) · how it arrives (portal, statement, Tony's sheet, API) · how often · which portal login · what is relevant for us and what is not	company and measurement	nowhere as a table; known from the nine partner portals and Tony's sheet	to be entered with Gil, one line per client
SDK terms	Commercial agreement (payment or revenue share) · whose revenue is shown (ours, the client's earnings, gross) · who pays whom, currency, schedule · revenue calculation (share, deductions, minimum) · forecast calculation or "no basis" · payment terms · related agreement	company and effective date (history kept)	partner list holds some terms; contracts in mail	partial
Inventory observations	Company · measurement (daily active devices, live devices, total agents, valid IPs, invalid IPs, unclassified IPs, other named measure) · count and unit · period type (exact day, rolling 24 hours, live snapshot) · observed at, with timezone · geography type (country, region, overall) · geography as reported · operating system or app (only if reported) · validation rule and check date (for IP validity) · source (portal scrape, partner statement, Tony verified, Ultron observed) · coverage note (what is counted, what is missing, whether groups overlap)	one observation	Partner inventory feed (703 daily rows, self-reported) · balance snapshots · Ultron observed supply (system-level)	partial: exists for some partners, without measurement names, periods or geography kept apart
Revenue observations	Company · period (day or month) · revenue · currency · revenue meaning (ours, client earnings, gross) · status (final, provisional, incomplete, estimated) · source (Tony verified, portal scrape, calculated) · observed at	company and period and source	Partner daily revenue (509 rows; 462 Tony verified) · Tony's monthly sheet · portal scrapers	exists; 24 duplicate day-and-partner groups to resolve
SDK payments	Date (paid or recorded, labelled) · company · period covered · direction (received from, paid to) · amount · currency · status (due, overdue, partially paid, paid, cancelled) · due date · statement or reference · amount outstanding and who owes whom	payment	Payouts table (38) · iCount invoices (SDK side: Soax, Geonode, EarnFM, HoneyGain, Infatica) · TRON wallet pass-through	partial: iCount names not linked to companies; wallet money kept as pass-through
Monthly results (calculated)	Month · company · revenue and its status · expected month-end revenue (current month only, estimated) · comparison with last completed month · inventory summary by named measure (only where it can be computed correctly) · coverage (dates and observations included)	company and month	calculated from revenue and inventory observations	calculated
Attention signals (calculated)	Inventory changed sharply · information old or missing · revenue provisional past its due date · payment needs attention · profile says a measurement should arrive and it has not	company and signal	calculated	calculated

What the SDK list shows the admin: company, status, reported inventory (metric name and count together, several metrics kept separate), inventory period, last month's revenue, expected revenue this month (estimated), last updated (when observed, not when opened), needs attention.

Why the SDK inventory table is one flexible table

Three examples of how a client can report, and how each lands in the same table without losing its meaning.

How the client reports	Measurement	Period type	Geography	What must not happen
Daily active devices by region	daily active devices	exact day (or rolling 24 hours, kept labelled as such)	region, using the client's own region names	a rolling 24-hour count must not be called today's DAU; daily DAU must not be summed into a monthly unique-device count
Live devices by country	live devices	live snapshot, with time and timezone	country	live is a moment, not daily active users, not installed agents, not proof that every connection is usable
IP validity counts	valid IPs · invalid IPs · unclassified IPs, each its own row	validation date or window	overall or country	invalid is never computed as total minus valid unless the same complete population was checked; the groups are not assumed to form a total
Registered or total agents	total agents	snapshot	as reported	never stands in for daily active or live devices

What the old database already gives us for Section 1

Piece	Found (read-only look, 10 Sep)	Goes to
Proxy client register	7 companies with status, billing model, rate for 2, notes	Companies · Proxy terms
Platform usage	23 accounts, daily rows 17 Aug to 7 Sep on sampled days; only 5 accounts carry real traffic, the two largest by far match the two paying clients by volume; 18 are test or one-day accounts	Platform accounts · Usage per day
Closed usage with spend	8 rows for 13 and 14 Aug; spend filled only where a rate exists	Monthly results (as history)
Payments	19 rows, 30 Apr to 5 Aug; bonus credits (GB, no money) mixed with real payments; feed stopped	Client payments · Balances (bonus GB is credit, not cash)
iCount counterparties	16 names: 1 proxy client, 5 SDK partners, 2 internal, 8 occasional; none linked to a company row	Companies (aliases) · Client payments · SDK payments
SDK partners, revenue, inventory, payouts	9 partners · 509 revenue rows · 703 inventory rows · 38 payouts · balance snapshots	Companies · Revenue observations · Inventory observations · SDK payments
Balances and plans	not in the old database; Prime holds 2,752 plans	Balances

Next: real data, one client at a time

Gil shares real data for one proxy client and one SDK client (a usage extract, a portal export or statement, the agreed terms).
We fill the SDK reporting profile line by line: what each client reports, in what unit, how often, and what is relevant.
We match the platform accounts to companies and approve a rate per paying proxy client.
Only then the tables above are confirmed and Section 2, Leads and CRM, starts here.

Decision recorded 10 September: SDK partners are the second type of client, with their own tables in this section. Their money is kept separate from proxy client cash at every step; it is never added into one revenue line.

Section 4 · System (the whole network)

This section is about the network itself, not any client: how many devices are connected, through how many exit addresses, where they are, what they run, and whether those figures can be trusted right now. Everything here comes from one place, the management API, which collects device inventory every 15 minutes and keeps the customer-usage report as a separate daily run. Network figures are never assigned to an SDK client unless a verified mapping exists; that mapping lives in Section 1.

Three different clocks

Inventory, activity and usage are observed at different times

An inventory snapshot has its own observed-at time. Device activity has a check time and a rolling 24-hour window. The customer-usage report has a run time. Every row carries its own clock; nothing is shown as "now".

Counts are identities, not certainties

Devices observed, not devices guaranteed

"Devices observed connected" is the number of different device identities in a snapshot, not physical or usable devices. "Different exit IPs" is a count of addresses, never a list. "Active in the last 24 hours" is never called today's DAU.

Breakdowns overlap

Country, operating system, device type and SDK version are separate views

Each is a breakdown of the same snapshot; the groups can overlap and are never added together to get a total. Unknown or unclassified labels are kept as reported, never guessed.

Freshness is data quality, not server health

Stale, partial and unavailable stay visible

Device data older than 45 minutes and usage data older than 26 hours are flagged stale. A failed collection never replaces a known value with zero. Server and service health (uptime checks, incidents) is a different thing and is not in this section yet.

System tables

Table	What it holds	One row per	Where it comes from today	Status
Inventory snapshots	Observed at · devices observed connected · different exit IPs observed · data status (available, partial, unavailable) · stale flag · collection completed at (empty when the collection failed) · last collection attempt · collected-over-time note (the scan is not atomic)	snapshot (about every 15 minutes)	Management API network overview · Prime inventory snapshots (11,120) · old database daily inventory (11 rows, one per day)	exists in the API; the old database keeps only a daily row
Inventory breakdowns	Snapshot · breakdown (country, operating system, device type, SDK version) · label as reported (unknown kept as unknown) · devices observed · different exit IPs · coverage warning carried from the snapshot	snapshot, breakdown and label	Management API countries, operating systems, device types, SDK versions	exists in the API; nowhere in the old database
Activity summaries	Activity checked at · window start and end (rolling 24 hours) · active in the last 24 hours · first seen today (since the UTC day boundary; not installs) · first seen yesterday · devices in retained records (not all-time installs, not the online fleet)	activity check	Management API device activity	exists in the API
Usage report runs	Run at · reporting window start and end · reported customers (those in the report, not all registered clients) · GB used · requests · recorded success rate (from request totals) · stale flag	report run (daily)	Management API reported customer traffic; the per-account rows of the same report feed Section 1, Usage per day	exists; the old database keeps 14 daily totals and 76 per-account rows
Coverage issues	Snapshot · unreadable records · missing records (not assumed expired or disconnected) · fallback device identifiers (limits claims about unique physical devices) · plain-language warning	snapshot	Management API freshness and coverage	exists in the API
Freshness limits	Data kind (device inventory, activity, usage report) · freshness limit (45 minutes for devices, 26 hours for usage) · who set it and when	data kind	the API's current limits	to be entered once; changed only by decision
Collection log	Attempted at · completed at · outcome (succeeded, partial, failed) · what was collected · error text in plain words	collection attempt	API attempt and completion times · Prime sync runs	partial: attempts are recorded, outcomes not kept as history
Attention signals (calculated)	Device data stale · usage report stale · collection failed twice in a row · snapshot partial · devices observed dropped sharply against the last day · a breakdown label appeared or disappeared	signal	calculated from the tables above	calculated

What the system overview shows the admin: devices observed connected, different exit IPs, active in the last 24 hours, each with its own observed-at time; the reported customer traffic for the last window with its run time; one data-status line with the stale warning. Breakdowns open as their own tables. Counts only: no device identifiers and no exit addresses are ever shown or stored in these tables.

How Section 4 sits beside Section 1

Question	Section 1 · Clients	Section 4 · System
Whose inventory is this?	One SDK client's own reported measures, under that client's names and periods	The whole network as we observe it; overlapping breakdowns, never per client
Whose usage is this?	One platform account per day, mapped to a company	The totals of the same daily report: customers included, GB, requests, success rate
Can the two be joined?	Only through a verified mapping of network devices to an SDK client, which does not exist today. Until it does, no network figure appears on a client card.
What is still outside both?	Server and service health (uptime checks, SSL, ports), incidents and maintenance. Recommendation: add them to Section 4 later as their own tables, fed by the monitoring service, and keep them apart from data freshness.

Section 6 · Development (work, tests, deployments, fixes, documents)

This section shows the development work recorded on Ultron: what changed, what was tested, what was deployed, and the documents behind it. It is built only from existing records and what can be read out of them mechanically. It is not a task tracker: no sprints, workloads, deadlines, owners or "current status" are invented. A work item's latest milestone is derived from the evidence attached to it, and a historical record is always marked historical.

Evidence exists; the feed does not

The records are on Ultron; the export has to be built

The management API used by Section 4 carries no development data. The first deliverable is a sanitised, versioned export of the approved records; until it exists, this section can only be designed and tested on fixtures that are never shown as real.

Claims and proof are kept apart

Implemented is not tested; tested is not deployed; deployed is not healthy

A worker's report says implementation was reported. A test run says what passed. A deployment needs its own record and, separately, a verification readback with its own time. An old successful verification never means the system is fine today.

Every fact points to its source

Source version and location on every displayed value

Dates come from the event, never from the file's modification time; unknown stays unknown. Repeated imports of the same version create nothing new; a changed record creates a new version and keeps the old one.

Protected by default

Sanitised copies, not file paths or raw logs

Secrets, personal contact data, addresses, internal endpoints and command payloads are removed before transfer and again before display. Document text is data, never instructions. Everything is tenant-scoped with row-level access rules.

Development tables

Table	What it holds	One row per	Where it comes from today	Status
Work items	Title · component (only when documented) · safe summary · latest documented milestone (specified, implementation reported, tested, deployment verified), derived from linked evidence · evidence date · recorded-by (only if explicitly recorded) · evidence coverage (which records exist, which links are unverified)	reliably linked piece of work	Ultron report folders (specification, worker result, parent review); a reviewed mapping for older files	no export yet; one real seed item exists (the device-data report API extension)
Test runs	Work item or component · test scope and code revision if recorded · run time (actual, never file time) · result (passed, failed, mixed, incomplete, unknown) · passed, failed, skipped counts when explicit · environment (local, staging, production) when documented · findings summary · evidence link	identifiable test or QA run	Saved test outputs and gate files (machine-readable first)	no export yet; seed: 37 local tests passed, 10 Sep
Deployment events	Work item or component · deployment time if recorded · exact version or revision (empty if absent, never a nearby commit) · target environment as a safe label · outcome (attempted, succeeded, failed, unknown) · verification result and its own time · rollback documented yes/no (existence, not proof it was tested) · evidence link	recorded deployment	Deployment records and the final verification file	no export yet; seed: public endpoint verified 10 Sep, 11:08 UTC (verification time, not deployment time)
Findings (documented fixes)	Sanitised finding · affected component when established · first documented at · correction as recorded · verification specific to the correction · resolution evidence (documented, correction reported, verified correction, resolution not verified) · related work and evidence	documented finding	Review notes and correction records	no export yet; a finding is never closed because a general suite passed
Documents	Title · type (specification, review, test report, deployment proof, guide, other) · related work (explicit identifier or reviewed grouping) · evidence date and import time, kept apart · safe summary · review state (extracted, needs review, verified association) · currency unknown unless evidenced	document	Ultron report folders and integration guides	no export yet
Document versions	Document · version · content fingerprint · source date · imported at · parser version · sanitised copy or excerpt (protected)	version of a document	created by the importer	to be built
Evidence links	Displayed fact or association · source version · field or line location	fact	created by the importer	to be built; every displayed value must have one
Import runs	Started and finished · export version · processed, skipped, rejected, ambiguous counts · outcome · last good import kept when a batch fails	import batch	created by the importer	to be built; one reviewed import first, daily only after approval
Review items	What is ambiguous (ownership, status, date, link, grouping) · proposed label · decision · decided by and when	open question from an import	created by the importer from narrative material	to be built; nothing narrative becomes a fact without review

What the admin shows: three lists (Development work, Tests and QA, Deployments), newest evidence date first, with filters by component, date and evidence state. A work card opens with its summary, tests, deployments, documented fixes and documents. Operational database names stay out of the headings.

The one real work item that can seed Section 6

Record	What it may be read as	What it may not be read as
Specification	Scope and intended implementation of the device-data report API extension	Proof of completion
Implementation report	Implementation reported by the worker	Proof of deployment
Review findings	Documented correction requests	Resolved, unless each has linked evidence
Parent verification	Saved compatibility and security check results	Current health
Production verification	37 local tests passed; public endpoint verified at a recorded time on 10 Sep, with existing behaviour preserved	The deployment time, or today's health
Integration guide	Existing documentation of the usage report API	A development-feed endpoint

Rules Section 6 must pass before it is real

Check	Meaning
Provenance	Every displayed fact has a source version; unsupported fields stay empty, never invented.
Seed reconciles	The device API work item matches its saved specification, test count and exact verification time.
No promotion	An implementation report creates no verified deployment; an old verification implies no current health; a passed suite verifies no specific finding.
Idempotent	Importing the same export twice changes nothing; changing one source version keeps history without duplicating the work item.
Failures explicit	Malformed, stale, partial and conflicting inputs produce named outcomes; the last good import survives a failed one.
Isolation	Cross-tenant reads, links and document access are denied; no tokens or raw source material reach the browser.
Untouched	Client tables, the usage and device API, its token and existing scheduled jobs are not changed by this section.
Approval	Gil approves the exact production scope before any migration, deployment or schedule; rollback disables only the new importer and screens and keeps every record.

Sections still to come

Section	What it will hold	State
1 · Clients	Company card, proxy usage and money, SDK inventory and revenue (above)	drafted above, to confirm with real data
2 · Leads and CRM	Companies and people before they are clients; pipeline stage; outreach targets	not started
3 · Inbox	Email, WhatsApp and Telegram per client: channels, threads, messages, whose turn	not started
4 · System	Network inventory, activity, usage report runs, freshness and coverage (above); service health and incidents to be added	drafted above, to confirm
5 · Finance	Revenue and expenses from every channel: bank, invoices, subscriptions, PayPal, iCount, Tony's sheet, partner portals, Ultron	not started
6 · Development	Work items, test runs, deployments, findings, documents, evidence links, import runs (above)	drafted above; blocked on the sanitised export from Ultron
Illustration	The drawing of the whole database, made only when every section is agreed	last

Basis: IPLoop Client Admin Design v2 (Gil, 10 Sep), the Clients section document (Section 1), the read-only look at the old database of 10 Sep, Prime snapshot counts from the IPLoop Management Admin PRD. No figures on this page are client figures; counts are row counts in the old database. Nothing has been created in Supabase.

IPLoop · the new database · product requirements · version 0.2

PRD: the IPLoop database, Section 1 · Clients, built on the real existing data

What we build first in the new IPLoop Supabase project, why, from which data, in what order, and how we know it is done. Version 0.2 is grounded in the Existing Data Workbook of 10 September (the real account register, closed-day usage, the billing ledger, the SDK observations, the system snapshot and the development records) rather than in the older reading of the old database. The PRD grows one section at a time; Sections 4 (System) and 6 (Development) are added here when they close.

10 September 2026 · v0.2 · requirements and plan, not a build order · nothing created in Supabase yet · no client figures shown, only row counts and dated snapshot totals · basis: Existing Data Workbook (assembled 10 Sep 12:42 UTC), Client Admin Design v2, System Data Tables, Development Admin PRD, Gil's decisions of 10 Sep

1 · Scope

Section 1 holds everything the admin needs about a client company: who they are, what they buy or supply, what they used or reported, what they owe or earn, what was agreed, and what happens next. IPLoop has two kinds of client. A proxy API client buys bandwidth through the platform; it is measured by usage (GB, requests, success) and by the money it owes. An SDK client supplies devices through our SDK; it is measured by the inventory it reports (devices, users, IPs, in its own definitions) and by the revenue that inventory earns. One company can be both. The section therefore has three groups of tables: the company (shared), the proxy side, the SDK side.

Decisions this PRD rests on

Gil, 10 September

One new clean Supabase project for all IPLoop business data; the OS project stays company-neutral; the old project is drained through staging. Plain tables first, confirmed on real data, drawn last. Two client types inside one Clients section; proxy cash and SDK revenue never mixed. No agent holds a database key; access is through the door by role. The platform's own database (Prime) is read as upstream for now.

In scope

Groups A, B, C and their plumbing

Companies, contacts, contracts and documents, notes and follow-ups. Platform accounts and their mapping, proxy terms, usage per day, country outcomes, balances, client payments. SDK reporting profile, SDK terms, inventory observations, revenue observations, SDK balance observations, SDK payouts. Calculated monthly results and attention signals for both types. Staging, review and audit for every import.

Not in Section 1

Left to later sections

Leads before they are clients (Section 2). Email, WhatsApp and Telegram threads (Section 3); the card keeps only a last-message pointer. Network-wide inventory and freshness (Section 4). Expenses, cash accounts and P&L (Section 5). Development records (Section 6). Any write to the old project or to Prime. The illustration.

Who does what

Gil decides; agents build through the door

Gil approves tables against real data, the account mapping, every rate and terms row, and the exact scope of each build step; he supplies the payments file, the SDK real data and the contracts. Atlas owns the data model and writes handoffs. Anvil builds. Cipher reviews and applies. Argus runs acceptance and records pass or fail. Reed and Finch read through the door once the section is live.

2 · What the real data shows (Existing Data Workbook, 10 September)

The workbook fills the accepted designs from existing records and marks every missing field as not available. Read as a whole it changes four things in the plan and confirms the rest.

Area	What exists	What it changes
Proxy accounts	2,732 non-internal accounts from the account register with stable references, plan name and recorded GB balance; 2,264 active, 441 suspended. Three named real clients (Serper, GeoEdge, ProxyScrape) sit on their accounts; two recorded rates (Serper, GeoEdge); ProxyScrape unpriced. Seven accounts carried traffic on the two supplied days; most of the rest are free, test, QA or internal accounts.	The account key is the register, not the 23 anonymous prefixes. The accounts table gets a classification (paying, trial, free, test or internal, unknown) and keeps the recorded company name as "recorded", distinct from the confirmed company.
Proxy usage	Closed-day usage for 8 and 9 September only, per account: GB, requests, successes, failures; usage value calculated where a rate is recorded.	Usage per day is right as designed. The daily report must run every day; two days do not make a month, and monthly results stay "partial" with the days listed until it does.
Country	230 rows of short-window request outcomes by country per account (success rate only, no GB, no share).	"Usage by country" is replaced by "Country outcomes": a quality signal (success by country over a stated window) feeding the attention list, never a usage or billing figure.
Proxy payments	95 ledger rows: 71 purchases (68 failed, 3 completed or refunded) and 24 bonus credits; no payment dates in the ledger; recorded status is not settlement proof.	Client payments cannot be built from this ledger alone. Cash with dates comes from the payments file Gil provides separately and from the platform's dated payment transactions; bonus credits go to Balances as data credit, never as cash.
SDK clients	10 clients (BigMama, CashRaven, EarnFM, EarnFM small, Geonode, HoneyGain, Infatica, Infatica 2, Repocket, Soax). 52 inventory observations with their measurement names kept separate (DAU, qualifying users, devices online, live devices, available devices, total agents, observed IP counts, monthly units); for most the activity definition is "not established", geography is given only once (by region), terms are unknown for all ten, payout direction unknown for all 40 payout rows. 337 revenue records: daily sheet values (Tony), verified month sums for August, and for CashRaven five different September figures (estimates, month-to-date, daily pace) correctly kept apart. 30 balance observations with distinct meanings (awaiting payout, accrued month to date, estimated month, paid to date).	The observations table design is confirmed. Three additions: an SDK balance observations table with a "balance meaning" column; aliases for names that appear only in revenue sources (for example "IPLOOP", "EarnFM BarMic"); and the reporting profile becomes the first SDK job, because without definitions the numbers cannot be compared. Gil's real SDK data, coming soon, fills the profile.
Contracts, follow-ups, owners	No structured records anywhere; the workbook carries availability notices, not invented rows.	Pure manual entry through the admin, from day one; nothing to import.
System snapshot (for Section 4)	One saved API snapshot, 10 Sep 11:04 UTC: 91,111 devices observed, 86,381 exit addresses, 214,587 active in 24 hours, status partial, 14,133 unreadable records; 272 countries, 4 operating systems, 5 SDK versions. The device-type breakdown carries exactly the same four rows and counts as the operating-system breakdown.	Confirms Section 4's tables. One flaw to raise with the API owner: device type is currently a copy of operating system, so it must be shown as one breakdown until the API reports a real device type.
Development (for Section 6)	Four work items (one real: the device-data API extension, 37 tests passed, verified 10 Sep 11:08 UTC; three HTML designs browser-tested), one deployment, eight review findings not individually verified.	Confirms Section 6's tables and its seed item.

The workbook is the approved real-data input for the proxy side and for the shape of the SDK side. Two inputs are still to come from Gil and are planned for: the payments file (dated cash per client) and the real SDK data per client (used to fill the reporting profile and terms). More sources follow after those.

3 · Tables (v0.2)

Changes from v0.1 are marked. Every table also carries the common columns: created and updated by whom and when; source, source id, source version, imported at; a status where a value can be uncertain (final, provisional, estimated, unpriced, not provided). Missing is a state, never zero.

Group A · the company (shared)

Table	Columns	One row per · key	Filled from
Companies	Company name · client type (proxy API, SDK, both) · status (trial or testing, active, paused, inactive) · website · country · account owner · working with us since · next follow-up · aliases (names used in the register, iCount, portals, Tony's sheet) · notes	company · aliases unique	Register names for the 3 real proxy clients; the 10 SDK clients; iCount counterparties as aliases; the rest by hand
Contacts	Company · name · role · email · preferred channel · main contact yes/no	person at a company	By hand (the workbook omits contact details on purpose)
Contracts and documents	Company · document name · type · service covered (proxy, SDK, both) · status (draft, awaiting signature, signed, expired, replaced) · version · signed copy (protected) · parties and signature dates · start and end · renewal type · notice deadline · terms summary · exceptions and obligations · responsible person	document · versions kept	By hand; no records exist
Notes and follow-ups	Company · date · subject · note or action · responsible person · due date · status (open, in progress, waiting, done) · related item	note or task	By hand; no records exist

Group B · proxy API clients

Table	Columns	One row per · key	Filled from
Platform accounts (changed)	Account reference · recorded company name (as in the register, unverified) · confirmed company (link) · classification (paying, trial, free, test or internal, unknown) · account status (active, suspended, inactive, deleted) · recorded plan · registered at · first traffic seen · last traffic seen · matched by · matched at · match confidence (confirmed, proposed, unmatched)	platform account · reference unique	Account register (2,732); classification proposed by rule (internal names, QA names, zero traffic) and confirmed by Gil for anything that carried traffic
Proxy terms	Company · price per GB · currency · effective from and to · billing arrangement (prepaid, postpaid, test credits) · monthly commitment · data allowance · spending limit · payment terms · related agreement · approved by and when	company and effective-from · history kept	Two recorded rates (marked "recorded report rate, not a signed contract") until Gil approves them; the rest by hand
Usage per day	Date · account · GB · requests · successes · failures · success rate (from totals) · source run · imported at	account and day · unique	Closed-day usage (2 days now); the daily report going forward
Country outcomes (changed)	Account · country as reported (unknown kept) · window start and end · successful requests · failed requests · success rate · observed at	account, country and window	Short-window outcome buckets (230 rows); a quality signal only
Balances	Date · company or account · money credit · GB remaining (recorded plan balance) · plan name · credit kind (verified credit, recorded balance, bonus data credit) · source · observed at	account and day (snapshot)	Register GB balances; bonus ledger rows as data credit; platform snapshots going forward
Client payments (changed)	Date · date kind (paid, recorded) · company · period covered · amount · currency · method (PayPal, purchase, invoice, other) · status (due, overdue, partially paid, paid, cancelled, refunded, failed) · due date · invoice or reference · amount outstanding · settlement evidence (yes, no) · source and source id	payment or invoice · source id unique per source	Gil's payments file (separately); the platform's dated payment transactions; PayPal; iCount. The undated ledger is imported only as history with "no date, no settlement proof"
Proxy monthly results (calculated)	Month · company · GB · requests · success rate · spend or unpriced · payments received · outstanding · coverage (the exact days included) · status (partial, in progress, closed) · same elapsed period last month · estimated month-end spend (estimated, with basis)	company and month	Calculated; "partial" with the days listed until a full month of daily usage exists
Proxy attention signals (calculated)	Company · signal (usage dropped, low success rate overall or in a country, unpaid usage, no approved rate, unmatched or unclassified account with traffic, silent while paying, low balance, overdue payment, failed purchases repeating) · since · detail	company and signal	Calculated

Group C · SDK clients

Table	Columns	One row per · key	Filled from
SDK reporting profile	Company · measurement as the client names it · what it means (agreed definition) · unit · period type · geography type · breakdowns available · how it arrives (portal, statement, Tony's sheet, API, manual) · how often · portal login owner (name only) · relevant to us yes/no · note	company and measurement	The 52 observed measurement names as the starting list; definitions from Gil's real SDK data (coming) and the partners
SDK terms	Company · commercial agreement · whose revenue is shown (ours, client earnings, gross) · who pays whom · currency · schedule · revenue calculation · forecast calculation or "no basis" · payment terms · related agreement · effective from and to	company and effective-from · history kept	By hand; unknown for all ten today
Inventory observations	Company · measurement · count · unit · period type (exact day, rolling 24 hours, live snapshot, month) · period start and end · observed at · timezone · geography type · geography as reported · operating system or app · validity rule and check date · source (portal scrape, partner statement, Tony verified, Ultron observed) · source label · source id · coverage note	observation · unique on company, measurement, period, geography, source	52 rows now; the scrapers and statements going forward
Revenue observations	Company · period type (day, month) · period start and end · amount · currency · revenue meaning (ours, client earnings, gross, unknown) · status (final, provisional, incomplete, estimated, unverified zero) · source (Tony verified, sheet value, portal scrape, daily delta verified, calculated) · source id · observed at · locked yes/no	company, period and source · unique	337 rows now; unverified zeros kept as unverified, never summed
SDK balance observations (new)	Company · balance meaning (awaiting payout, accrued month to date, estimated month, paid to date, today so far, daily pace, wallet, other as labelled) · amount · currency · observed at · source label · source id	observation	30 rows now; portal scrapers going forward
SDK payouts	Date · date kind · company · period covered · direction (received from client, paid to client, unknown) · amount · currency · status (due, unpaid, processing, paid, requested, unknown) · due date · statement or reference · amount outstanding · settlement evidence · source and source id	payout · source id unique	40 rows now, direction unknown; direction set from SDK terms once entered
SDK monthly results (calculated)	Month · company · revenue and its status (complete daily source sum, incomplete, estimate) · expected month-end revenue (current month only, estimated, with basis) · compared with last completed month · inventory summary by named measure (only where computable) · coverage	company and month	Calculated; August sums exist for six clients as "complete daily source sum, not reconciled"
SDK attention signals (calculated)	Company · signal (definition not established, inventory changed sharply, information old or missing, revenue provisional past due, payout direction unknown, payment needs attention, expected measurement not received) · since · detail	company and signal	Calculated

Section plumbing, unchanged from v0.1: a canonical area (the tables above), a staging area where every import lands and is reviewed row by row, an audit log for every write (who, when, before, after, why, undo), and a source register. The first write ships with the audit log or it does not ship.

4 · Sources and imports

Source	Feeds	How it gets in	State
Existing Data Workbook (10 Sep)	Platform accounts, Balances, Usage per day, Country outcomes, the undated ledger as history, SDK companies, Inventory observations, Revenue observations, SDK balance observations, SDK payouts	One-time import into staging, sheet by sheet, each row keeping its evidence reference and qualification; reviewed; approved into canonical	approved input
Gil's payments file	Client payments (dated cash per client)	Import into staging when it arrives; reviewed by Gil	to come, separately
Gil's real SDK data per client	SDK reporting profile, SDK terms, and the definitions behind the observations	Worked through with Gil one client at a time; entered by hand or imported	to come, soon
Platform (Prime) through the door	Account register refresh, dated payment transactions, balance snapshots, daily usage	Read as upstream; daily snapshot into staging	access path to be set up in step 0
Daily usage report (the same one Section 4 reads)	Usage per day, Country outcomes	Daily run into staging; approved by rule (exact re-imports only)	runs; must run every day
Partner portals and scrapers	Inventory observations, Revenue observations, SDK balance observations	Existing scrapers repointed to staging, each row tagged with its source label	exist in the old project
Tony's monthly sheet	Revenue observations (verified, locked)	Monthly import into staging; old importer stays disabled	manual
iCount, PayPal	Client payments, SDK payouts, Companies (aliases)	Counterparty mapping reviewed by Gil; then feeds into staging	exist in the old project
Contracts, terms, follow-ups	Groups A and the terms tables	By hand through the admin, signed file attached	nothing exists to import

5 · Rules

Rule	In practice
Missing is not zero	Not provided is stored as a state and shown as Not available; stale stays labelled stale; unverified zeros are never summed.
Estimated is labelled	Estimates live in their own columns with an "as of" and a basis; five different September figures for one client stay five rows, never one number.
Periods are exact	Every figure carries period start, end and timezone; a partial month lists its days.
Charges, cash and outstanding are three things	Spend is calculated; payments received are cash with a date and settlement evidence; outstanding is what is still owed. A ledger status is not settlement proof.
Proxy cash and SDK revenue never mix	No table, view or total adds one to the other; pass-through money is not revenue.
Unpriced is not free	Usage with no approved rate shows unpriced; a recorded report rate is marked recorded until Gil approves it; a free plan is not a rate.
Recorded is not confirmed	A company name in the register is "recorded"; the confirmed company is a separate link set in review.
Success rates from totals	Successes divided by requests over the period; never an average of daily percentages.
Measurements keep their names and definitions	DAU, qualifying users, devices online, live devices, available devices, total agents, IP counts and monthly units are never renamed into one device total; agents are not online devices; usable DAU is not valid IPs.
Network is not client	No network-wide figure appears on a client card without a verified mapping, which does not exist.
One source id, one import	Re-importing the same source version creates nothing; a changed source creates a new version and keeps the old.
No secrets, no keys, no raw identifiers	Portal logins by owner name only; no credential, device identifier or exit address is stored in this section.
Every write is audited	Who, when, what, why, undo; reviewer decisions in staging are writes too.

6 · Initial plan (v0.2)

Seven steps, each approved by Gil before it runs, each producing something he can look at. The proxy steps and the SDK steps can run side by side once step 0 is done. About three working weeks after the project exists, with Gil's review time as the pacing item.

Step	What is done	Output Gil sees	Needs from Gil	Estimate
0 · Ground	Create the empty IPLoop project (paid organisation, us-east-1). Create canonical, staging and audit, the audit log and the source register. Register Section 1's sources. Set the door's rights for the new project. Set up the platform read through the door.	An empty project with staging, audit and a source list; an access table of who can do what	Create the project; approve the access table	1 day
1 · Companies and accounts	Build Group A. Import the workbook's account register into staging; classify accounts by rule; propose company rows with aliases for the three named proxy clients, the ten SDK clients and the iCount counterparties.	A review screen: proposed companies and aliases; every account with a proposed classification; the seven traffic-carrying accounts first	Confirm companies, aliases and the classification of the accounts that carried traffic	2 days
2 · Proxy terms, usage, country	Build Proxy terms, Usage per day, Country outcomes. Import the two closed days and the outcome buckets; switch the daily report to write into staging every day. Enter the two recorded rates as "recorded" pending approval.	Usage per day per account, growing daily; a terms row per paying client; unpriced clients listed	Approve or change the two rates; a rate for ProxyScrape or a decision that it stays unpriced	2 days
3 · Proxy money	Build Balances and Client payments. Import register balances and bonus credits as data credit; import the undated ledger as history only. When Gil's payments file arrives, import it as dated cash; connect the platform's dated payment transactions, PayPal and iCount.	Balance per account with its observed time; dated payment history per client; outstanding per client, or "no dated cash yet"	The payments file; confirm iCount links	3 days once the file exists
4 · SDK profile and terms	Build SDK reporting profile and SDK terms. Load the 52 observed measurement names as the starting list. Work through Gil's real SDK data one client at a time: definition, unit, period, geography, relevance, and the terms.	A profile line per client and measurement, with a definition or "not established"; a terms row per client or "unknown"	The real SDK data per client; the agreed terms; which client first	3 days, paced by the data
5 · SDK observations and money	Build Inventory observations, Revenue observations, SDK balance observations, SDK payouts. Import the workbook's 52, 337, 30 and 40 rows with their source labels and statuses; lock Tony-verified rows; leave payout direction unknown until terms exist. Repoint scrapers to staging.	Per SDK client: inventory history by named measure, revenue by period with status, balances by meaning, payouts	The latest Tony sheet; review decisions on conflicting rows	4 days
6 · Results, signals, the card	Build the calculated tables and the two admin lists and the company card (Company, Commercial terms, Monthly results, Usage or Inventory breakdown, Payments, Contracts and documents, Notes and follow-ups). Contracts and notes entered by hand from then on.	The two client lists and a working company card, read through the door	Walk through one proxy card and one SDK card and approve	4 days
7 · Retire	Repoint each remaining writer of the old client tables to the new staging; mark the old client tables read-only for us; close the section.	A list of writers moved and old tables frozen	Approve freezing each old table	2 days

7 · Acceptance

Check	Passes when
Provenance	Every canonical row has a source, source id, version and import time; re-importing the workbook changes nothing; changing one source row creates a new version and keeps the old.
Audit	Every write in every table has who, when, before, after and why; staging decisions included.
Accounts	All 2,732 accounts are classified; every account that carried traffic is confirmed to a company or listed as unmatched on the attention screen; none is silently dropped.
Pricing	Spend for a client with no approved rate shows unpriced, not zero; a recorded rate shows as recorded until approved; spend for an approved rate equals usage times the rate in force that day.
Cash	Payments received never change spend; outstanding equals charges minus dated cash; bonus credit appears as data credit, never as cash; an undated ledger row never counts as cash.
Country	Country outcomes never feed spend, usage totals or shares; they appear only as a quality signal with their window.
SDK definitions	Every inventory observation carries its measurement name, period type, bounds, timezone and geography type; none was renamed or summed across groups; agents are never counted as online devices.
SDK money	Tony-verified rows are locked; unverified zeros are never summed; each balance observation keeps its meaning; a payout with unknown direction is never shown as received or paid.
Separation	No view or total adds proxy cash to SDK revenue; a test that tries is refused.
Access	The door grants each agent exactly the rights in the access table; a read without rights is denied and recorded; no agent configuration contains a database key.
Screens	The two lists and the company card render for one proxy client and one SDK client from canonical data, at desktop and phone width, with no runtime errors and no identifiers, credentials or addresses on screen.
Untouched	The old client tables and the platform database are unchanged after every step.

Argus records actual pass and fail with exact blockers. Configuration, assignments, inferred behaviour and created files are not passing evidence.

8 · Open items

Item	Recommendation	Why
Platform: upstream or migrated	Upstream through the door for now; revisit after the catalogue	It is verified and read-only today; moving it changes who writes platform data before every writer is known
ProxyScrape's rate	Gil decides: approve a rate or keep it unpriced on purpose	It carried real traffic on both supplied days and has no recorded rate
Which SDK client to profile first	CashRaven or HoneyGain	They report the most measurements with the most ways to misread them (DAU, qualifying users, usable and unusable DAU, devices online)
Device type in the system API	Raise with the API owner; show one breakdown until fixed	The device-type table is a copy of the operating-system table
Reviewer rules	Gil reviews every mapping, classification of traffic-carrying accounts, rate and terms row; agents may auto-approve only exact re-imports of already-approved source ids	Trustworthy first section without Gil reviewing every daily row

Owed by Gil	Needed for
Create the empty IPLoop project	Step 0
The payments file (dated cash per client)	Step 3
The real SDK data per client and the agreed terms	Steps 4 and 5
A rate decision for ProxyScrape; approval of the two recorded rates	Step 2
Signed contracts and current terms, or a note that none exists	Steps 2, 4, 6
Portal login owners (names only); the latest Tony sheet	Steps 4 and 5
The further sources he has mentioned, one at a time	Each becomes a source row when named

9 · Build brief (copy-ready)

A scope and acceptance contract for Atlas, Anvil, Cipher and Argus. Not permission to create or change anything without Gil's approval of the exact step.

Build Section 1 (Clients) of the new IPLoop Supabase project as described in parts 1 to 8, in the seven steps of part 6, each approved by Gil before it runs. Never create or change anything in the old project or in the platform database.
Model: three groups of tables (company, proxy API, SDK) in a canonical area; a staging area where every import lands; an audit log for every write; a source register. Column lists are in part 3; common columns and statuses apply to every table.
Input: the Existing Data Workbook of 10 September is the approved real-data input, imported sheet by sheet with its evidence references and qualifications. Gil's payments file and real SDK data are imported when they arrive; until then the affected fields stay not available.
Rules of part 5 apply to every table and view: missing is not zero, estimated is labelled, periods are exact, recorded is not confirmed, unpriced is not free, measurements keep their names, proxy cash and SDK revenue never mix, nothing reaches canonical without review.
Access through the door only, with the rights table from step 0; no agent holds a database key; every table has access rules from creation.
Imports: register the source first; import by source id and version into staging; review row by row; approve into canonical with an audit record; re-imports of the same version are no-ops; Tony-verified rows are locked.
Acceptance: part 7, every check, recorded by Argus as actual pass or fail with exact blockers. Report blockers plainly; never work around missing access or data with invented values, and never present fixtures as real.

10 · Building it in Supabase (how to start)

Looked at on 10 September: the OS project keeps everything in one named area called reachai, every table protected, reads through views, nothing in the public area. The old project is the opposite: 151 tables in the public area, 36 views, a dozen open to the public key. The IPLoop project copies the OS pattern and adds one area per section, so "IPLoop" is the project and the sections live inside it as named areas.

Area (schema)	Holds	Now or later
shared	Companies, contacts, aliases, contracts and documents, notes and follow-ups; the source register; the reference lists (statuses, client types, measurement names, balance meanings)	now
clients	Section 1: platform accounts, proxy terms, usage per day, country outcomes, balances, client payments, SDK reporting profile, SDK terms, inventory observations, revenue observations, SDK balance observations, SDK payouts; the calculated monthly results and attention signals as views	now
system	Section 4: inventory snapshots, inventory breakdowns, activity summaries, usage report runs, coverage issues, freshness limits, collection log; signals as views	now
staging	One landing table per source sheet or feed, with the evidence columns (source, source id, version, imported at, qualification, evidence reference) and a review decision column; nothing here is ever read by the admin	now
audit	One append-only log for every write in every area: who, when, area, table, row, before, after, why, undo hint; import runs and review decisions	now
dev · crm · inbox · finance	Sections 6, 2, 3, 5 when they close	later
public	Stays empty on purpose; nothing is exposed to the public key	always

Protection from the first table

Every table locked; reads through views; the door holds the only key

Row-level protection is switched on for every table at creation with no open policy, so the public key sees nothing. The admin and the agents read through named views per screen. Writes go through a small set of functions (import, review, approve, enter) that write the audit row in the same step, so the audit log cannot be skipped.

Roles instead of keys

Four database roles, mapped to agent roles in the door

A reader role per area (finance reads clients money, accounts reads clients and shared), a reviewer role (approve staging into canonical), a builder role (create and change tables through migrations only), and the door's service role that carries them. No agent configuration ever contains a key; the door grants a role for a session.

Migrations, not clicks

Every change is a numbered migration file, applied by Cipher

Tables, views, roles and functions are created by migration scripts kept in the repository, reviewed, then applied to the project; the same scripts recreate the project from nothing. Nothing is created by hand in the dashboard, so the audit of the structure is the migration history.

Conventions carried from the OS project

Same shapes, so the agents already know them

Snake-case names, one id per row, created and updated stamps on every table, views prefixed v_ for reads, one named area per system, empty public area. The old project's habits (everything in public, hand-made tables, open policies) are not carried over.

Start here: the first five migrations (step 0 and step 1 of the plan)

Migration	Creates	Proof it worked	Who
0 · Project	The empty IPLoop project on the paid organisation, us-east-1; the public area emptied of defaults; the public key confirmed to see nothing	A read with the public key returns nothing anywhere	Gil creates; Argus checks
1 · Ground	Areas shared, clients, system, staging, audit; the audit log and the write functions that always log; the source register; the reference lists; the four roles	A test write without the function is refused; a test write through it appears in the audit log with who and why	Atlas writes, Cipher applies, Argus checks
2 · Shared tables	Companies, aliases, contacts, contracts and documents, notes and follow-ups, with protection and views	The 13 real companies (3 proxy, 10 SDK) inserted through the function and visible in the companies view; a peer role denied	Anvil builds, Cipher applies
3 · Staging for the workbook	One landing table per workbook sheet used by Sections 1 and 4 (accounts, terms, daily usage, country buckets, ledger, SDK clients, inventory, revenue, balances, payouts, the system sheets), each with the evidence columns and the review decision	Every sheet imported once with its row count matching the workbook; importing it again changes nothing	Anvil builds, Cipher applies, Argus checks counts
4 · Clients and system tables	The Section 1 and Section 4 canonical tables of part 3, their views (the two client lists, the company card tabs, the system overview) and the signals views	The review screen shows the seven traffic-carrying accounts for Gil to confirm; approving one moves it to canonical with an audit row; the proxy list view shows it	Anvil builds, Cipher applies, Gil approves the first rows, Argus checks

Order inside the work: ground first, then shared, then staging with the workbook loaded, then the canonical tables, then the first approvals by Gil. Nothing from the old project is copied directly into canonical; it always passes through staging. The platform read through the door (accounts refresh, dated payments, daily usage) is connected after migration 4, once the landing tables exist for it.

What I checked and did not change: the OS project (20 protected tables in its own area, reads through views) and the old project (151 public tables; in its IPLoop reporting area 11 tables protected with no policies and 5 unprotected). Nothing was written anywhere. The new project does not exist yet; migration 0 is Gil's.

IPLoop database PRD · Section 1 · Clients · v0.2 (part 10 added) · 10 September 2026. Basis: Existing Data Workbook (assembled 10 Sep 12:42 UTC; evidence references A, U, P, S, N, T, R, G, C, D), Client Admin Design v2, System Data Tables (API only), Development Admin PRD, Gil's decisions of 10 September, decisions 0008, 0024, 0025. Supersedes PRD v0.1 (standalone file). Sections 4 and 6 are added to this tab when they close; Sections 2, 3 and 5 after their designs.

IPLoop · the new database · data preview · existing records only

How the tables look with the data we have today

Every table of Sections 1, 4 and 6 from the PRD, filled from the Existing Data Workbook of 10 September. Rows are shown as they would sit in the new database: the same columns as the PRD, real values where a record exists, a dash where nothing exists. Long tables show their first rows and say how many there are. Nothing here is a forecast, and nothing is in Supabase yet.

10 September 2026 · preview from the workbook, no live refresh · no contact details, credentials, device identifiers or exit addresses · classification and attention signals are what the PRD rules would produce from these rows, not confirmed decisions

Group A · the company (shared)

Filled from the register names for the three real proxy clients and the ten SDK clients. Contacts, contracts and notes have no records anywhere; those tables are shown empty on purpose.

Companies

13 rows in the data · showing 13 · the 3 real proxy clients and the 10 SDK clients; owner and follow-up are empty because no record holds them

Company name	Client type	Status	Account owner	Working with us since	Aliases	Next follow-up
Serper	proxy API	active	—	—	ACC-2288 (register)	—
GeoEdge	proxy API	active	—	—	ACC-1233 (register)	—
ProxyScrape	proxy API	active	—	—	ACC-1134 (register)	—
BigMama	SDK	active	—	Not available	SDK-001	—
CashRaven	SDK	active	—	Not available	SDK-002	—
EarnFM	SDK	active	—	Not available	SDK-003	—
EarnFM small	SDK	active	—	Not available	SDK-004	—
Geonode	SDK	active	—	Not available	SDK-005	—
HoneyGain	SDK	active	—	Not available	SDK-006	—
Infatica	SDK	active	—	Not available	SDK-007	—
Infatica 2	SDK	active	—	Not available	SDK-008	—
Repocket	SDK	active	—	Not available	SDK-009	—
Soax	SDK	active	—	Not available	SDK-010	—

Contacts

0 rows · no structured records exist in any collected source; entered by hand from day one

Contracts and documents

0 rows · no structured records exist in any collected source; entered by hand from day one

Notes and follow-ups

0 rows · no structured records exist in any collected source; entered by hand from day one

Group B · proxy API clients

From the account register (2,732 accounts), the two closed usage days, the country outcome buckets and the undated ledger. Classification is proposed by rule and not yet confirmed.

Platform accounts

2,732 rows in the data · showing 14 · sorted: traffic-carrying accounts first · proposed classification counts: test or internal (proposed) 1,426, free (proposed) 1,034, unknown 265, unknown, carried traffic 4, paying 2, trial or unpriced (proposed) 1

Account reference	Recorded company name	Confirmed company	Classification	Account status	Recorded plan	Registered at	Traffic days seen	GB in those days	Match confidence
ACC-2288	Serper	Serper	paying	active	Professional	—	2026-09-08, 2026-09-09	17,275.1	confirmed
ACC-1233	GeoEdge	GeoEdge	paying	active	Free	—	2026-09-08, 2026-09-09	668.02	confirmed
ACC-1134	ProxyScrape	ProxyScrape	trial or unpriced (proposed)	active	Professional	—	2026-09-08, 2026-09-09	566.97	confirmed
ACC-0326	Company not recorded · Account 326	—	unknown, carried traffic	active	Professional	—	2026-09-08, 2026-09-09	11.19	proposed
ACC-0713	Company not recorded · Account 713	—	unknown, carried traffic	active	Professional	—	2026-09-08	0.0002	proposed
ACC-1099	Company not recorded · Account 1099	—	unknown, carried traffic	active	Starter	—	2026-09-08	0	proposed
ACC-1227	Company not recorded · Account 1227	—	unknown, carried traffic	active	Free	—	2026-09-08	0	proposed
ACC-1957	Company not recorded · Account 1957	—	unknown	deleted	Enterprise	—	Not available	Not available	unmatched
ACC-2171	Company not recorded · Account 2171	—	unknown	deleted	Enterprise	—	Not available	Not available	unmatched
ACC-1288	Company not recorded · Account 1288	—	unknown	deleted	Enterprise	—	Not available	Not available	unmatched
ACC-0841	Company not recorded · Account 841	—	unknown	deleted	Enterprise	—	Not available	Not available	unmatched
ACC-1557	Company not recorded · Account 1557	—	unknown	deleted	Enterprise	—	Not available	Not available	unmatched
ACC-0597	Company not recorded · Account 597	—	unknown	deleted	Enterprise	—	Not available	Not available	unmatched
ACC-1191	Company not recorded · Account 1191	—	unknown	deleted	Enterprise	—	Not available	Not available	unmatched

Proxy terms

3 rows in the data · showing 3 · recorded report rates, marked recorded until Gil approves them

Company	Price per GB	Billing arrangement	Commitment and limits	Payment terms	Approved by	Related agreement
GeoEdge	0.2 USD / GB (recorded report rate)	Postpaid (recorded account arrangement)	Not available	Not available	not yet approved (recorded report rate)	Not available
ProxyScrape	Not available	Not available	Not available	Not available	—	Not available
Serper	0.08 USD / GB (recorded report rate)	Not available	Not available	Not available	not yet approved (recorded report rate)	Not available

Usage per day

11 rows in the data · showing 11 · the two closed days supplied, per account

Date	Account	Company	GB	Requests	Successes	Failures	Success rate	Usage value (recorded rate)
2026-09-08	ACC-2288	Serper	5,819.5	11,737,622	10,053,360	1,684,262	85.7%	465.56
2026-09-08	ACC-1233	GeoEdge	240.72	5,847,587	5,556,225	291,362	95.0%	48.14
2026-09-08	ACC-1134	ProxyScrape	201.46	65,148,698	53,406,139	11,742,559	82.0%	Not available
2026-09-08	ACC-0326	Company not recorded · Account 326	0.0094	318	317	1	99.7%	Not available
2026-09-08	ACC-0713	Company not recorded · Account 713	0.0002	258	251	7	97.3%	Not available
2026-09-08	ACC-1099	Company not recorded · Account 1099	0	1	1	0	100.0%	Not available
2026-09-08	ACC-1227	Company not recorded · Account 1227	0	1	0	1	0.0%	Not available
2026-09-09	ACC-2288	Serper	11,455.5	29,990,482	23,756,490	6,233,992	79.2%	916.44
2026-09-09	ACC-1233	GeoEdge	427.30	10,404,940	9,659,808	745,132	92.8%	85.46
2026-09-09	ACC-1134	ProxyScrape	365.51	88,349,153	62,515,003	25,834,150	70.8%	Not available
2026-09-09	ACC-0326	Company not recorded · Account 326	11.18	266,807	252,440	14,367	94.6%	Not available

Country outcomes

230 rows in the data · showing 12 · short-window success by country; a quality signal only, never usage or billing

Account	Company	Country	Window	Successful requests	Failed requests	Success rate
ACC-1134	ProxyScrape	US	2026-09-10 06:10:00+00:00; recorded bucket, not monthly	81,253	64,887	55.6%
ACC-2288	Serper	US	2026-09-10 06:10:00+00:00; recorded bucket, not monthly	71,726	6,811	91.3%
ACC-1134	ProxyScrape	GB	2026-09-10 06:10:00+00:00; recorded bucket, not monthly	17,065	9,353	64.6%
ACC-1134	ProxyScrape	ID	2026-09-10 06:10:00+00:00; recorded bucket, not monthly	12,494	1,299	90.6%
ACC-1134	ProxyScrape	CA	2026-09-10 06:10:00+00:00; recorded bucket, not monthly	11,366	4,591	71.2%
ACC-1134	ProxyScrape	DE	2026-09-10 06:10:00+00:00; recorded bucket, not monthly	4,968	983	83.5%
ACC-1134	ProxyScrape	AU	2026-09-10 06:10:00+00:00; recorded bucket, not monthly	4,248	8,934	32.2%
ACC-1134	ProxyScrape	TT	2026-09-10 06:10:00+00:00; recorded bucket, not monthly	3,992	381	91.3%
ACC-1134	ProxyScrape	BR	2026-09-10 06:10:00+00:00; recorded bucket, not monthly	3,377	693	83.0%
ACC-1134	ProxyScrape	TR	2026-09-10 06:10:00+00:00; recorded bucket, not monthly	3,373	1,005	77.0%
ACC-1134	ProxyScrape	BB	2026-09-10 06:10:00+00:00; recorded bucket, not monthly	3,102	405	88.5%
ACC-1233	GeoEdge	US	2026-09-10 06:10:00+00:00; recorded bucket, not monthly	3,019	155	95.1%

Balances

2,732 rows in the data · showing 10 · recorded plan balances from the register; money credit is not recorded anywhere

Observed	Account	Company	Money credit	GB remaining	Plan	Credit kind
2026-09-10 (register read)	ACC-2288	Serper	—	160,369.8	Professional	recorded plan balance
2026-09-10 (register read)	ACC-1233	GeoEdge	—	24,202.7	Free	postpaid; recorded balance is not verified credit
2026-09-10 (register read)	ACC-1134	ProxyScrape	—	371.24	Professional	recorded plan balance
2026-09-10 (register read)	ACC-0326	Company not recorded · Account 326	—	723.12	Professional	recorded plan balance
2026-09-10 (register read)	ACC-0713	Company not recorded · Account 713	—	7.45	Professional	recorded plan balance
2026-09-10 (register read)	ACC-1099	Company not recorded · Account 1099	—	4.24	Starter	recorded plan balance
2026-09-10 (register read)	ACC-1227	Company not recorded · Account 1227	—	0.4999	Free	recorded plan balance
2026-09-10 (register read)	ACC-1957	Company not recorded · Account 1957	—	100,000	Enterprise	recorded plan balance
2026-09-10 (register read)	ACC-2171	Company not recorded · Account 2171	—	100,000	Enterprise	recorded plan balance
2026-09-10 (register read)	ACC-1288	Company not recorded · Account 1288	—	100,000.0	Enterprise	recorded plan balance

Client payments

95 rows in the data · showing 12 · the undated ledger, imported as history only: no dates, no settlement proof; dated cash comes from Gil’s payments file

Date	Date kind	Account	Company	Amount	Currency	Method	Status	Data credit GB	Settlement evidence
Not available	recorded (no date in ledger)	ACC-1134	ProxyScrape	0	USD	bonus	completed	1,000	no
Not available	recorded (no date in ledger)	ACC-1233	GeoEdge	0	USD	bonus	completed	20,000	no
Not available	recorded (no date in ledger)	ACC-1134	ProxyScrape	0	USD	bonus	completed	100	no
Not available	recorded (no date in ledger)	ACC-2288	Serper	20,000	USD	purchase	completed	250,000	no
Not available	recorded (no date in ledger)	ACC-2288	Serper	0	USD	bonus	completed	5,000	no
Not available	recorded (no date in ledger)	ACC-2288	Serper	0	USD	bonus	completed	5,000	no
Not available	recorded (no date in ledger)	ACC-1233	GeoEdge	0	USD	bonus	completed	10,000	no
Not available	recorded (no date in ledger)	ACC-1233	GeoEdge	0	USD	bonus	completed	10,000.4	no
Not available	recorded (no date in ledger)	ACC-1233	GeoEdge	0	USD	bonus	completed	50	no
Not available	recorded (no date in ledger)	ACC-2288	Serper	9,000	USD	purchase	completed	100,000	no
Not available	recorded (no date in ledger)	ACC-2288	Serper	250	USD	purchase	completed	333	no
Not available	recorded (no date in ledger)	ACC-2288	Serper	250	USD	purchase	failed	333	no

Proxy monthly results (calculated)

7 rows in the data · showing 7 · partial months with the exact days included; spend, cash and forecast stay not available

Month	Account	Company	GB	Requests	Success rate	Spend	Payments received	Outstanding	Coverage
2026-09 (partial)	ACC-2288	Serper	17,275.1	41,728,104	81.0%	Not available	Not available	Not available	2 supplied days: 2026-09-08, 2026-09-09; incomplete month
2026-09 (partial)	ACC-1233	GeoEdge	668.02	16,252,527	93.6%	Not available	Not available	Not available	2 supplied days: 2026-09-08, 2026-09-09; incomplete month
2026-09 (partial)	ACC-1134	ProxyScrape	566.97	153,497,851	75.5%	Not available	Not available	Not available	2 supplied days: 2026-09-08, 2026-09-09; incomplete month
2026-09 (partial)	ACC-0326	Company not recorded · Account 326	11.19	267,125	94.6%	Not available	Not available	Not available	2 supplied days: 2026-09-08, 2026-09-09; incomplete month
2026-09 (partial)	ACC-0713	Company not recorded · Account 713	0.0002	258	97.3%	Not available	Not available	Not available	1 supplied days: 2026-09-08; incomplete month
2026-09 (partial)	ACC-1099	Company not recorded · Account 1099	0	1	100.0%	Not available	Not available	Not available	1 supplied days: 2026-09-08; incomplete month
2026-09 (partial)	ACC-1227	Company not recorded · Account 1227	0	1	0.0%	Not available	Not available	Not available	1 supplied days: 2026-09-08; incomplete month

Proxy attention signals (calculated)

12 rows in the data · showing 12 · what the rules would raise today from the data above

Company	Signal	Since	Detail
Serper	low success rate	2026-09-08	81.0% over the supplied days
ProxyScrape	no approved rate	2026-09-08	usage exists on both supplied days; spend unpriced
ProxyScrape	low success rate	2026-09-08	75.5% over the supplied days
Company not recorded · Account 326	unclassified account with traffic	2026-09-08	11.193 GB on the supplied days; account ACC-0326
Company not recorded · Account 713	unclassified account with traffic	2026-09-08	0.000 GB on the supplied days; account ACC-0713
Company not recorded · Account 1099	unclassified account with traffic	2026-09-08	0.000 GB on the supplied days; account ACC-1099
Company not recorded · Account 1227	unclassified account with traffic	2026-09-08	0.000 GB on the supplied days; account ACC-1227
Serper	no dated cash on record	2026-09-10	ledger rows carry no payment date; outstanding cannot be computed
GeoEdge	no dated cash on record	2026-09-10	ledger rows carry no payment date; outstanding cannot be computed
ProxyScrape	no dated cash on record	2026-09-10	ledger rows carry no payment date; outstanding cannot be computed
Serper	rate recorded, not approved	2026-09-10	recorded report rate awaiting Gil’s approval
GeoEdge	rate recorded, not approved	2026-09-10	recorded report rate awaiting Gil’s approval

Group C · SDK clients

From the SDK observations, revenue records, balances and payouts. Definitions and terms are unknown for all ten clients; that is what Gil’s real SDK data will fill.

SDK reporting profile

23 rows in the data · showing 23 · one line per client and measurement seen so far; “what it means” is filled with Gil

Company	Measurement as the client names it	What it means	Unit	Geography type	How it arrives (source label)	Relevant to us
BigMama	devices	Total agents — NOT online devices	Not available	Not provided / unsegmented	tony	—
CashRaven	dau_qualifying_users	dau qualifying users	users	Not provided / unsegmented	anchor	—
CashRaven	devices_online	devices online	devices	Not provided / unsegmented	anchor	—
CashRaven	live_devices	live devices	count	Not provided / unsegmented	anchor	—
CashRaven	qualifying_users	qualifying users	count	Not provided / unsegmented	anchor	—
CashRaven	dau	dau	count	Not provided / unsegmented	live	—
CashRaven	devices	not established	Not available	Not provided / unsegmented	tony	—
EarnFM	live_dc_devices	live dc devices	count	Not provided / unsegmented	anchor	—
EarnFM	live_devices	live devices	count	Not provided / unsegmented	anchor	—
Geonode	devices	not established	count	Not provided / unsegmented	anchor	—
Geonode	ips	not established	count	Not provided / unsegmented	anchor	—
HoneyGain	dau	dau	count	Not provided / unsegmented	live	—
HoneyGain	udau	udau	count	Not provided / unsegmented	live	—
HoneyGain	unusable_dau	Unusable DAU — not invalid IPs	count	Not provided / unsegmented	live	—
HoneyGain	usable_dau	Usable DAU — not valid IPs	count	Not provided / unsegmented	live	—
HoneyGain	devices	not established	Not available	Not provided / unsegmented	tony	—
Infatica	month_total_units	not established	count	Not provided / unsegmented	anchor	—
Infatica	available_devices	available devices	count	Not provided / unsegmented	live	—
Infatica	devices	not established	Not available	Not provided / unsegmented	tony	—
Infatica 2	month_total_units	not established	count	Not provided / unsegmented	anchor	—
Infatica 2	devices	not established	count	Region	live	—
Soax	available_devices	available devices	devices	Not provided / unsegmented	anchor	—
Soax	devices	not established	Not available	Not provided / unsegmented	tony	—

SDK terms

10 rows in the data · showing 10 · unknown for all ten

Company	Commercial agreement	Whose revenue is shown	Who pays whom	Revenue calculation	Forecast calculation	Payment terms
BigMama	Not available	Partner-reported amounts; ownership/gross-net definition not verified	Not available	Not available	Not available	Not available
CashRaven	Not available	Partner-reported amounts; ownership/gross-net definition not verified	Not available	Not available	Partner-reported estimate; underlying calculation not supplied	Not available
EarnFM	Not available	Partner-reported amounts; ownership/gross-net definition not verified	Not available	Not available	Not available	Not available
EarnFM small	Not available	Partner-reported amounts; ownership/gross-net definition not verified	Not available	Not available	Not available	Not available
Geonode	Not available	Partner-reported amounts; ownership/gross-net definition not verified	Not available	Not available	Not available	Not available
HoneyGain	Not available	Partner-reported amounts; ownership/gross-net definition not verified	Not available	Not available	Not available	Not available
Infatica	Not available	Partner-reported amounts; ownership/gross-net definition not verified	Not available	Not available	Not available	Not available
Infatica 2	Not available	Partner-reported amounts; ownership/gross-net definition not verified	Not available	Not available	Not available	Not available
Repocket	Not available	Partner-reported amounts; ownership/gross-net definition not verified	Not available	Not available	Not available	Not available
Soax	Not available	Partner-reported amounts; ownership/gross-net definition not verified	Not available	Not available	Not available	Not available

Inventory observations

52 rows in the data · showing 20 · each measurement kept under its own name, period and source

Company	Measurement	Count	Unit	Period / observed at	Geography type	Geography	OS / app	Source label	Coverage note
BigMama	Total agents — NOT online devices	978,733	Not available	2026-08-31	Not provided / unsegmented	Not available	other	tony	Alternative reports and overlapping categories retained; do not sum
CashRaven	dau qualifying users	99,707	users	2026-09-08 07:45:00 UTC	Not provided / unsegmented	Not available	android	anchor	Alternative reports and overlapping categories retained; do not sum
CashRaven	devices online	79,294	devices	2026-09-08 07:45:00 UTC	Not provided / unsegmented	Not available	android	anchor	Alternative reports and overlapping categories retained; do not sum
CashRaven	live devices	81,284	count	2026-09-07 12:00:00 UTC	Not provided / unsegmented	Not available	other	anchor	Alternative reports and overlapping categories retained; do not sum
CashRaven	qualifying users	111,923	count	2026-09-07 12:00:00 UTC	Not provided / unsegmented	Not available	other	anchor	Alternative reports and overlapping categories retained; do not sum
CashRaven	live devices	79,290	count	2026-09-08 07:40:00 UTC	Not provided / unsegmented	Not available	Not available	anchor-cdp	Alternative reports and overlapping categories retained; do not sum
CashRaven	qualifying users	99,120	count	2026-09-08 07:40:00 UTC	Not provided / unsegmented	Not available	Not available	anchor-cdp	Alternative reports and overlapping categories retained; do not sum
CashRaven	dau	94,389	count	2026-08-15	Not provided / unsegmented	Not available	android	live	Alternative reports and overlapping categories retained; do not sum
CashRaven	Devices — activity definition not established	96,287	Not available	2026-08-31	Not provided / unsegmented	Not available	android	tony	Alternative reports and overlapping categories retained; do not sum
CashRaven	Devices — activity definition not established	75,902	Not available	2026-08-31	Not provided / unsegmented	Not available	other	tony	Alternative reports and overlapping categories retained; do not sum
CashRaven	Devices — activity definition not established	0	Not available	2026-08-31	Not provided / unsegmented	Not available	windows	tony	Alternative reports and overlapping categories retained; do not sum
EarnFM	live dc devices	1,789	count	2026-09-08 05:11:17 UTC	Not provided / unsegmented	Not available	datacenter	anchor	Alternative reports and overlapping categories retained; do not sum
EarnFM	live devices	22,566	count	2026-09-08 05:11:17 UTC	Not provided / unsegmented	Not available	residential	anchor	Alternative reports and overlapping categories retained; do not sum
Geonode	Devices — activity definition not established	81,589	count	2026-09-08 05:10:06 UTC	Not provided / unsegmented	Not available	all	anchor	Alternative reports and overlapping categories retained; do not sum
Geonode	Observed IP count — validity not classified	73,902	count	2026-09-08 05:10:06 UTC	Not provided / unsegmented	Not available	all	anchor	Alternative reports and overlapping categories retained; do not sum
Geonode	Observed IP count — validity not classified	11,030	count	2026-09-08 05:10:06 UTC	Not provided / unsegmented	Not available	datacenter	anchor	Alternative reports and overlapping categories retained; do not sum
Geonode	Observed IP count — validity not classified	62,872	count	2026-09-08 05:10:06 UTC	Not provided / unsegmented	Not available	residential	anchor	Alternative reports and overlapping categories retained; do not sum
Geonode	Observed IP count — validity not classified	142,865	count	2026-08-15	Not provided / unsegmented	Not available	android	live	Alternative reports and overlapping categories retained; do not sum
Geonode	Observed IP count — validity not classified	154,881	Not available	2026-08-31	Not provided / unsegmented	Not available	other	tony	Alternative reports and overlapping categories retained; do not sum
HoneyGain	dau	91,350	count	2026-08-15	Not provided / unsegmented	Not available	android	live	Alternative reports and overlapping categories retained; do not sum

Revenue observations

337 rows in the data · showing 16 · daily sheet values, verified month sums and scraped figures; unverified zeros are kept as unverified

Company	Period	Amount	Currency	Revenue meaning	Status	Type	Source label
CashRaven	2026-08-09	1,522.2	USD	unknown (partner-reported)	daily_delta_verified	daily_delta	Historical revenue feed
CashRaven	2026-08-10	714.37	USD	unknown (partner-reported)	daily_delta_verified	daily_delta	Historical revenue feed
CashRaven	2026-08-11	692.89	USD	unknown (partner-reported)	daily_delta_verified	daily_delta	Historical revenue feed
CashRaven	2026-08-12	704.56	USD	unknown (partner-reported)	daily_delta_verified	daily_delta	Historical revenue feed
CashRaven	2026-08-13	732.08	USD	unknown (partner-reported)	daily_delta_verified	daily_delta	Historical revenue feed
EarnFM	2026-08-14	517.76	USD	unknown (partner-reported)	verified	Reported daily earnings; not full-month revenue	live-earnfm-api
CashRaven	2026-08-14	739.45	USD	unknown (partner-reported)	daily_delta_verified	daily_delta	Historical revenue feed
BigMama	2026-08-15	472.24	USD	unknown (partner-reported)	verified	Reported daily earnings; not full-month revenue	live-bigmama-api-stat
Geonode	2026-08-15	718.09	USD	unknown (partner-reported)	verified	Reported daily earnings; not full-month revenue	live-geonode-earnings
HoneyGain	2026-08-15	668.72	USD	unknown (partner-reported)	verified	Reported daily earnings; not full-month revenue	live-honeygain-export
Infatica	2026-08-15	63.01	USD	unknown (partner-reported)	verified	Reported daily earnings; not full-month revenue	live-infatica-partner-pages
Infatica 2	2026-08-15	254.56	USD	unknown (partner-reported)	verified	Reported daily earnings; not full-month revenue	live-infatica2-softzeroandroid
Soax	2026-08-15	921.36	USD	unknown (partner-reported)	verified	Reported daily earnings; not full-month revenue	live-redash-9157
CashRaven	2026-08-15	693.60	USD	unknown (partner-reported)	daily_delta_verified	daily_delta	Historical revenue feed
CashRaven	2026-08-17	1,532.4	USD	unknown (partner-reported)	daily_delta_verified	daily_delta	Historical revenue feed
CashRaven	2026-08-18	973.80	USD	unknown (partner-reported)	daily_delta_verified	daily_delta	Historical revenue feed

SDK balance observations

30 rows in the data · showing 16 · each balance keeps its meaning; none are added together

Company	Balance meaning	Amount	Currency	Observed at	Source label
CashRaven	awaiting_payout	7,223.3	USD	2026-09-08 07:45:00 UTC	anchor
CashRaven	daily_pace	947.11	USD	2026-09-07 12:00:00 UTC	anchor
CashRaven	estimated_month	28,146.3	USD	2026-09-07 12:00:00 UTC	anchor
CashRaven	estimated_this_month	28,067.8	USD	2026-09-08 07:45:00 UTC	anchor
CashRaven	mtd_accrued	7,223.3	USD	2026-09-08 07:45:00 UTC	anchor
CashRaven	paid_to_date	0	USD	2026-09-07 12:00:00 UTC	anchor
CashRaven	projected_daily_earnings	947.48	USD	2026-09-08 07:45:00 UTC	anchor
CashRaven	today_so_far	811.20	USD	2026-09-08 07:45:00 UTC	anchor
CashRaven	awaiting_payout	7,218.8	USD	2026-09-08 07:40:00 UTC	anchor-cdp
CashRaven	daily_pace	947.48	USD	2026-09-08 07:40:00 UTC	anchor-cdp
CashRaven	estimated_month	28,063.3	USD	2026-09-08 07:40:00 UTC	anchor-cdp
CashRaven	mtd_accrued	7,218.8	USD	2026-09-08 07:40:00 UTC	anchor-cdp
CashRaven	paid_to_date	0	USD	2026-09-08 07:40:00 UTC	anchor-cdp
CashRaven	today_so_far	807.01	USD	2026-09-08 07:40:00 UTC	anchor-cdp
EarnFM	available_payout	7,708.2	USD	2026-09-08 05:11:17 UTC	anchor
EarnFM	bandwidth_earnings	100,409.6	USD	2026-09-08 05:11:17 UTC	anchor

SDK payouts

40 rows in the data · showing 14 · direction unknown for all 40 until terms are entered

Date	Company	Period covered	Direction	Amount	Currency	Status	Reference	Outstanding
Not available	BigMama	wallet	Not available	0	USD	unknown	Not available	Not available
Not available	CashRaven	2026-08	Not available	0	USD	paid	Not available	Not available
Not available	CashRaven	2026-08 MTD	Not available	5,878.4	USD	unpaid	Not available	Not available
Not available	EarnFM	pending	Not available	11,340.1	USD	unpaid	Not available	Not available
Not available	EarnFM	available	Not available	3,822.6	USD	unpaid	Not available	Not available
Not available	EarnFM	approved	Not available	73,381.8	USD	unknown	Not available	Not available
Not available	Geonode	wallet	Not available	13,174.6	USD	unknown	Not available	Not available
Not available	HoneyGain	2026-07 to 2026-08	Not available	45,536.3	USD	processing	Not available	Not available
Not available	HoneyGain	2026-02 to 2026-05	Not available	45,629.2	USD	paid	Not available	Not available
Not available	HoneyGain	2026-01	Not available	5,899.9	USD	paid	Not available	Not available
Not available	HoneyGain	2025-11 to 2025-12	Not available	7,951.9	USD	paid	Not available	Not available
Not available	HoneyGain	2025-10	Not available	4,134.1	USD	paid	Not available	Not available
Not available	HoneyGain	2025-09	Not available	3,498.9	USD	paid	Not available	Not available
Not available	HoneyGain	2025-05 to 2025-08	Not available	2,709.4	USD	paid	Not available	Not available

SDK monthly results (calculated)

20 rows in the data · showing 20 · August sums where the daily source is complete; September figures kept as separate observations

Company	Month	Revenue	Revenue status	Expected month-end	Compared with last month	Inventory summary	Recorded subtotal
BigMama	2026-08	12,696.8	Complete daily source sum; not independently reconciled	Not available	Not available	Not available	12,696.8
BigMama	2026-09	Not available	Incomplete or unverified month	Not available	Not available	Not available	0
CashRaven	2026-08	Not available	Incomplete or unverified month	Not available	Not available	Not available	19,802.1
CashRaven	2026-09	Not available	Incomplete or unverified month	Not available	Not available	Not available	896.51
EarnFM	2026-08	1,504.8	Complete daily source sum; not independently reconciled	Not available	Not available	Not available	1,504.8
EarnFM	2026-09	Not available	Incomplete or unverified month	Not available	Not available	Not available	0
Geonode	2026-08	22,904.3	Complete daily source sum; not independently reconciled	Not available	Not available	Not available	22,904.3
Geonode	2026-09	Not available	Incomplete or unverified month	Not available	Not available	Not available	0
HoneyGain	2026-08	22,205.1	Complete daily source sum; not independently reconciled	Not available	Not available	Not available	22,205.1
HoneyGain	2026-09	Not available	Incomplete or unverified month	Not available	Not available	Not available	0
Infatica	2026-08	2,577.4	Complete daily source sum; not independently reconciled	Not available	Not available	Not available	2,577.4
Infatica	2026-09	Not available	Incomplete or unverified month	Not available	Not available	Not available	0
Infatica 2	2026-08	8,034.4	Complete daily source sum; not independently reconciled	Not available	Not available	Not available	8,034.4
Infatica 2	2026-09	Not available	Incomplete or unverified month	Not available	Not available	Not available	0
Soax	2026-08	Not available	Incomplete or unverified month	Not available	Not available	Not available	7,817.5
CashRaven	2026-09 (observation)	Not available	Reported estimate	28,146.3	Not available	Not available	28,146.3
CashRaven	2026-09 (observation)	Not available	Reported estimate	28,067.8	Not available	Not available	28,067.8
CashRaven	2026-09 (observation)	7,223.3	Reported month-to-date; incomplete	Not available	Not available	Not available	7,223.3
CashRaven	2026-09 (observation)	Not available	Reported estimate	28,063.3	Not available	Not available	28,063.3
CashRaven	2026-09 (observation)	7,218.8	Reported month-to-date; incomplete	Not available	Not available	Not available	7,218.8

SDK attention signals (calculated)

29 rows in the data · showing 24 · what the rules would raise today

Company	Signal	Since	Detail
BigMama	terms unknown	2026-09-10	whose revenue, who pays whom and the calculation are not recorded
BigMama	definition not established	2026-08-31	Total agents — NOT online devices [other] 978733
CashRaven	terms unknown	2026-09-10	whose revenue, who pays whom and the calculation are not recorded
EarnFM	terms unknown	2026-09-10	whose revenue, who pays whom and the calculation are not recorded
EarnFM small	terms unknown	2026-09-10	whose revenue, who pays whom and the calculation are not recorded
EarnFM small	information missing	2026-09-10	no inventory observation on record
Geonode	terms unknown	2026-09-10	whose revenue, who pays whom and the calculation are not recorded
Geonode	definition not established	2026-09-08	Devices — activity definition not established [all] 81589; Observed IP count — v
HoneyGain	terms unknown	2026-09-10	whose revenue, who pays whom and the calculation are not recorded
HoneyGain	definition not established	2026-08-31	Devices — activity definition not established [android] 94466; Devices — activit
Infatica	terms unknown	2026-09-10	whose revenue, who pays whom and the calculation are not recorded
Infatica	definition not established	2026-09-01	Monthly total units — period definition needs review [mac] 26356; Monthly total
Infatica 2	terms unknown	2026-09-10	whose revenue, who pays whom and the calculation are not recorded
Infatica 2	definition not established	2026-09-01	Monthly total units — period definition needs review [android] 641184
Repocket	terms unknown	2026-09-10	whose revenue, who pays whom and the calculation are not recorded
Repocket	information missing	2026-09-10	no inventory observation on record
Soax	terms unknown	2026-09-10	whose revenue, who pays whom and the calculation are not recorded
CashRaven	payment needs attention	2026-09-10	unpaid · 2026-08 MTD · 5878.39 · direction unknown
EarnFM	payment needs attention	2026-09-10	unpaid · pending · 11340.11 · direction unknown
EarnFM	payment needs attention	2026-09-10	unpaid · available · 3822.61 · direction unknown
HoneyGain	payment needs attention	2026-09-10	processing · 2026-07 to 2026-08 · 45536.31 · direction unknown
HoneyGain	payment needs attention	2026-09-10	unpaid · available · 23331.19 · direction unknown
Infatica	payment needs attention	2026-09-10	unpaid · 2026-07 · 2962.13 · direction unknown
Infatica	payment needs attention	2026-09-10	unpaid · 2026-06 · 3087.38 · direction unknown

Section 4 · System (one saved API snapshot, 10 Sep 11:04 UTC)

The whole network, never a client. Device type is shown once because the API returns the operating-system rows under both names.

Inventory snapshots

1 rows in the data · showing 1

Observed at	Devices observed connected	Different exit IPs	Data status	Stale	Collection completed at	Last collection attempt	Collected over time
2026-09-10 11:04:58 UTC	91,111	86,381	partial	0	2026-09-10 11:06:52 UTC	2026-09-10 11:04:55 UTC	1

Inventory breakdowns

281 rows in the data · showing 17 · top 8 countries of 272, then operating systems and SDK versions; groups overlap and are never summed

Snapshot	Breakdown	Label as reported	Devices observed	Different exit IPs	Coverage warning
2026-09-10 11:04:58 UTC	country	US	52,862	49,542	partial
2026-09-10 11:04:58 UTC	country	GB	9,704	9,455	partial
2026-09-10 11:04:58 UTC	country	UNKNOWN	7,846	7,761	partial
2026-09-10 11:04:58 UTC	country	CA	4,292	4,036	partial
2026-09-10 11:04:58 UTC	country	TT	1,290	1,203	partial
2026-09-10 11:04:58 UTC	country	AU	1,035	1,004	partial
2026-09-10 11:04:58 UTC	country	IN	827	827	partial
2026-09-10 11:04:58 UTC	country	BB	808	737	partial
2026-09-10 11:04:58 UTC	operating system (= device type in the API today)	android	78,916	74,202	partial
2026-09-10 11:04:58 UTC	operating system (= device type in the API today)	docker	1	1	partial
2026-09-10 11:04:58 UTC	operating system (= device type in the API today)	macos	3,991	4,008	partial
2026-09-10 11:04:58 UTC	operating system (= device type in the API today)	windows	8,203	8,192	partial
2026-09-10 11:04:58 UTC	SDK version	2.0	2,375	2,374	partial
2026-09-10 11:04:58 UTC	SDK version	2.0.0	1	1	partial
2026-09-10 11:04:58 UTC	SDK version	2.0.1	5,828	5,825	partial
2026-09-10 11:04:58 UTC	SDK version	2.0.19	78,916	74,202	partial
2026-09-10 11:04:58 UTC	SDK version	2.0.5-macos	3,991	4,008	partial

Activity summaries

1 rows in the data · showing 1

Checked at	Window	Active last 24 h	First seen today	First seen yesterday	Devices in retained records
2026-09-10 11:06:39 UTC	2026-09-09 11:06:39+00:00 — 2026-09-10 11:06:39 UTC	214,587	1,350	3,518	1,100,839

Usage report runs

1 rows in the data · showing 1

Reporting window	Reported customers	GB used	Requests	Success rate	Run at	Stale
2026-09-09 11:00:00+03:00 — 2026-09-10 11:00:00+03:00	5	11,696.4	136,481,008	72.37%	2026-09-10 11:02:34+03:00	0

Coverage issues

1 rows in the data · showing 1

Snapshot	Unreadable records	Missing records	Fallback device identifiers	Collected over time
2026-09-10 11:04:58 UTC	14,133	53	0	1

Freshness limits

2 rows in the data · showing 2 · entered once, changed only by decision

Data kind	Limit	Set by / when
device inventory and activity	45 minutes	API design, 10 Sep
usage report	26 hours	API design, 10 Sep

Section 6 · Development (recorded work only)

Four work items, one of them real; every fact keeps its evidence reference.

Work items

4 rows in the data · showing 4

Title	Component	Latest documented milestone	Evidence date	Evidence coverage
DEV-001 · Device-data API extension	Management reporting / own-device data	Deployment verified at recorded time	2026-09-10 11:08:22.852230 UTC	Specification, implementation report, review, tests and production readback
DEV-002 · Client admin HTML design	Admin design / documentation	Design artifact browser-tested; not production admin deployed	Not available	Existing HTML and browser validation file
DEV-003 · System API-only HTML design	Admin design / documentation	Design artifact browser-tested; not production admin deployed	Not available	Existing HTML and browser validation file
DEV-004 · Development admin PRD	Admin design / documentation	Design artifact browser-tested; not production admin deployed	Not available	Existing HTML and browser validation file

Test runs

9 rows in the data · showing 9

Work item	Scope	Run time	Result	Counts	Environment
DEV-001 · Device-data API extension	Local unit suite, final verified candidate	Not available	Passed (saved evidence)	37 passed; 0 failed; 0 skipped	Local
DEV-001 · Device-data API extension	Independent real-socket compatibility/security gates	Not available	All recorded gates passed	7 gates true of 7	Local
DEV-001 · Device-data API extension	Public readback and automatic snapshot publication	2026-09-10 11:08:22.852230 UTC	Passed (saved evidence)	All recorded checks true	Production
DEV-002 · Client admin HTML design	1440px browser layout and navigation	Not available	Passed (saved validation)	Runtime errors 0; external requests 0	Local browser
DEV-002 · Client admin HTML design	390px browser layout and navigation	Not available	Passed (saved validation)	Runtime errors 0; external requests 0	Local browser
DEV-003 · System API-only HTML design	1440px browser layout and navigation	Not available	Passed (saved validation)	Runtime errors 0; external requests 0	Local browser
DEV-003 · System API-only HTML design	390px browser layout and navigation	Not available	Passed (saved validation)	Runtime errors 0; external requests 0	Local browser
DEV-004 · Development admin PRD	1440px browser layout and navigation	Not available	Passed (saved validation)	Runtime errors 0; external requests 0	Local browser
DEV-004 · Development admin PRD	390px browser layout and navigation	Not available	Passed (saved validation)	Runtime errors 0; external requests 0	Local browser

Deployment events

1 rows in the data · showing 1

Work item	Deployment time	Version	Target	Outcome	Verification	Rollback documented
DEV-001 · Device-data API extension	Not available	Not available	Production reporting service	Deployment verified at recorded readback	Passed · 2026-09-10T11:08:22.852230Z	Scoped rollback procedure and backup existence documented; rollback execution not establis

Findings

8 rows in the data · showing 8

Finding	Component	First documented	Correction	Resolution evidence
Activity query schema	Device snapshot collector / contract	Not available	Requested correction: Use actual recorded device and heartbeat fields; do not substitute r	Review request recorded; individual resolution not verified here
Device and exit counting	Device snapshot collector / contract	Not available	Requested correction: Keep device identity rules and exit-address counts separate from ses	Review request recorded; individual resolution not verified here
Inventory read method	Device snapshot collector / contract	Not available	Requested correction: Use bounded batch reads; missing records are not independently known	Review request recorded; individual resolution not verified here
Collection deadlines	Device snapshot collector / contract	Not available	Requested correction: Bound remote and overall collection time instead of allowing unbound	Review request recorded; individual resolution not verified here
Malformed snapshot containment	Device snapshot collector / contract	Not available	Requested correction: Bound file reads and contain invalid encoding or nested JSON without	Review request recorded; individual resolution not verified here
Strict data types and unknowns	Device snapshot collector / contract	Not available	Requested correction: Reject invalid types and preserve unavailable values as unknown rath	Review request recorded; individual resolution not verified here
Safe labels	Device snapshot collector / contract	Not available	Requested correction: Preserve reported labels safely and exclude private identifiers.	Review request recorded; individual resolution not verified here
Helper compatibility	Device snapshot collector / contract	Not available	Requested correction: Use existing helper functions rather than invented APIs.	Review request recorded; individual resolution not verified here

Documents

8 rows in the data · showing 8

Title and type	Related work	Evidence date / imported	Version	Review state
Device API specification	DEV-001 · Device-data API extension	Evidence date not recorded; workbook assembled 2026-09-10T12:42:25.783207Z	Current saved artifact; formal version not recorded	Existing file; association documented in this workbook
Device API implementation report	DEV-001 · Device-data API extension	Evidence date not recorded; workbook assembled 2026-09-10T12:42:25.783207Z	Current saved artifact; formal version not recorded	Existing file; association documented in this workbook
Review findings	DEV-001 · Device-data API extension	Evidence date not recorded; workbook assembled 2026-09-10T12:42:25.783207Z	Current saved artifact; formal version not recorded	Existing file; association documented in this workbook
Production verification	DEV-001 · Device-data API extension	Evidence date 2026-09-10T11:08:22.852230+00:00; workbook assembled 2026-09-10T12:42:25.783	Current saved artifact; formal version not recorded	Existing file; association documented in this workbook
Consumer integration guide	DEV-001 · Device-data API extension	Evidence date not recorded; workbook assembled 2026-09-10T12:42:25.783207Z	Current saved artifact; formal version not recorded	Existing file; association documented in this workbook
Client admin design	DEV-002	Evidence date not recorded; workbook assembled 2026-09-10T12:42:25.783207Z	Current saved artifact; formal version not recorded	Existing file; association documented in this workbook
System data design	DEV-003	Evidence date not recorded; workbook assembled 2026-09-10T12:42:25.783207Z	Current saved artifact; formal version not recorded	Existing file; association documented in this workbook
Development PRD	DEV-004	Evidence date not recorded; workbook assembled 2026-09-10T12:42:25.783207Z	Current saved artifact; formal version not recorded	Existing file; association documented in this workbook

Source: Existing Data Workbook (assembled 10 Sep 12:42 UTC), sheets P1 to P8, K1 to K8, X1 to X3, Y1 to Y9, D1 to D5. Row counts are the workbook's. Proposed classifications: test or internal by name pattern (IPLoop, QA, Hermes, admin, test), free by recorded plan with no traffic, unknown otherwise; the seven traffic-carrying accounts are the ones to confirm first.

ReachAI OS · Final owner structure

One company structure. Anvil first.

PrecisionDataHQ has seven permanent areas. Each component is developed where it belongs, moves through an explicit lifecycle there, and is shared by reference rather than copied.

13 September 2026 · Approved logical architecture · private area repositories created · Anvil local profile source moved with rollback · broader runtime unchanged

The operating rule

Management sets strategy, decisions, priorities, tasks and scheduling. Knowledge Base supplies ingredients. Workflows define reusable procedures. Agents do the work. Platform provides the interfaces. OS supplies shared data, memory, access, integrations and execution. Partners configure and use those shared capabilities for their own operations.

The seven permanent areas

01 · Direction

Management

Strategy, decisions, priorities, tasks and scheduling. Management directs work; it is not an agent hierarchy.

02 · Ingredients

Knowledge Base

Source material, research, lessons and examples. Ingredients inform work but do not become instructions automatically.

03 · Reusable methods

Workflows

Department procedures and templates for marketing, finance, sales, support, design and later approved functions.

04 · People at work

Agents

Existing agent identities, instructions, skills, routines and governed learning. Anvil is the first complete target.

05 · Interfaces

Platform

Mobile Telegram Management App, Admin Portal and Command Centre. Each product keeps its own evidence and release status.

06 · Shared machinery

OS

Structured records, recall, access, integrations, wiring, execution, monitoring and GitHub integration.

07 · Operations

Partners

IPLoop and Bravo Apps configure shared capabilities for their work without copying the whole company system.

Build in place, prove each state

Status	Meaning
Draft	Defined or being shaped in its permanent area; not accepted for use.
In development	Implementation is underway in a branch or isolated working copy owned by that area.
Tested	Named checks passed against an exact version; this alone is not live activation.
Live	The tested version is activated in its intended environment with current readback and recovery evidence.

No separate Development section or Dev-to-live-home migration exists in this model. Branches and lifecycle status provide safe development inside each permanent area.

First execution objective: complete Anvil

Codex first

Prove the current identity

Anvil's exact profile is now authoritative in Agents for the existing local personal selector. Server execution, native skills, access and checked contribution remain to be tested.

Memory next

Prove continuity

Automatic useful capture, fresh-session recall, correction, privacy, retries and recovery must pass before any working claim.

Claude after

Adapt, then retest

Use the same accepted Anvil definition through a thin adapter and repeat every platform-sensitive test.

The Start here pages remain historical source material. Their earlier central-control, separate-development or deployment claims do not override this final structure and are not current acceptance evidence.

PrecisionDataHQ · Final logical architecture · 13 September 2026

Everything has one permanent place.

The company is organized by responsibility, not by a temporary development destination. Code, definitions and documents live with the component they describe; actual business rows, credentials and private memory stay in their protected systems.

Owner-approved logical structure · private area repositories created 13 September 2026 · content migration, hosting and runtime activation remain incomplete

1 · Final company tree

This tree names permanent logical areas and responsibilities. It is not a claim that these folders or repositories already exist.

PrecisionDataHQ · expand or collapse the final logical tree

PrecisionDataHQ/
├── Management/
│   ├── strategy/                     Company direction and objectives
│   ├── decisions/                    Approved choices and reasons
│   ├── priorities/                   Ordered outcomes
│   ├── tasks/                        Assigned work and status
│   └── scheduling/                   Timing and coordination
├── Knowledge-Base/
│   ├── sources/                      Books, research and source material
│   ├── learning/                     Reviewed lessons and corrections
│   └── examples/                     Reusable examples, not automatic rules
├── Workflows/
│   ├── marketing/                    Reusable procedures and templates
│   ├── finance/
│   ├── sales/
│   ├── support/
│   ├── design/
│   └── other-departments/            Added only when approved and needed
├── Agents/
│   ├── Anvil/                        Existing identity, instructions and setup
│   └── other-existing-agents/        Their own identity, skills and routines
├── Platform/
│   ├── Mobile-Telegram-Management-App/  Already in development
│   ├── Admin-Portal/                 Status must be evidenced
│   └── Command-Centre/               Status must be evidenced
├── OS/
│   ├── supabase/                     Structured data and work records
│   ├── supermemory/                  Relevant recall
│   ├── access-and-auth/              Identity, authorization and boundaries
│   ├── integrations/                 Shared connector implementations
│   ├── agent-workflow-wiring/        Connect agents to approved workflows
│   ├── execution-and-monitoring/     Runs, receipts, health and recovery
│   └── github-integration/           Scoped source access and publication
└── Partners/
    ├── IPLoop/
    │   ├── os-configuration/          Partner-specific settings and references
    │   └── operations/                Finance, sales, marketing, outreach,
    │                                  support, account management and design,
    │                                  live only where evidence supports it
    └── Bravo-Apps/
        ├── website-building/          Partner delivery configuration
        ├── small-app-building/
        └── distribution/              Configured partner operations

Current private repositories: Management · Knowledge Base · Workflows · Agents · Platform · OS · IPLoop · Bravo Apps. The new repositories are private source homes, not evidence that application sources, agents or runtimes have been migrated or activated.

2 · What each area owns

Area	Owns	Does not own	Current status boundary
Management	Strategy, decisions, priorities, tasks and scheduling.	Agent identity, workflow bodies or runtime data.	Private repository created; initial management structure only.
Knowledge Base	Source ingredients, reviewed learning and examples with provenance.	Automatic instructions, live work state or private memory.	Private repository created with safe metadata only; paid/private source bodies remain on the server.
Workflows	Reusable department procedures and templates, each marked draft or tested.	Partner-specific copies or an automatic claim of live use.	Private repository created; individual workflows remain to be reviewed and evidenced.
Agents	Existing identities, instructions, selected skills, routines and governed learning.	Credentials, another agent's private history or copies of shared workflows.	Private repository created; Anvil is the tested source for the local personal profile selector. Server, memory and cloud runtime remain uncertified.
Platform	Owner and team interfaces: mobile Telegram management, Admin Portal and Command Centre.	Canonical business data, secrets or duplicated OS services.	Private repository created with source-empty app placeholders; exact application sources unresolved.
OS	Supabase records, Supermemory recall, access, integrations, wiring, execution, monitoring and GitHub integration.	Agent personality, department procedures or partner business truth.	Logical scope approved; individual components have mixed evidence and require their own tests.
Partners	Partner requirements, configuration, operating records and evidence.	Whole copies of shared agents, workflows, platforms or OS.	IPLoop and Bravo Apps are configured partner areas; live operations are claimed only where evidence exists.

3 · Relationships, in one line each

Management → company

Direction becomes work

Approved strategy and decisions set priorities, tasks and schedules for the permanent areas.

Knowledge → workflows and agents

Ingredients inform, never command

Sources and examples support judgment; only reviewed changes make them part of a workflow or agent instruction.

Workflows ↔ agents

Methods are referenced

Agents invoke the needed reusable procedure at its accepted version; the procedure is not copied into each agent.

Platform → OS

Interfaces use shared services

Mobile, Admin Portal and Command Centre read and act through authorized OS capabilities rather than owning duplicate data or access logic.

Partners → shared company capabilities

Configure, do not clone

IPLoop and Bravo Apps point to approved agents, workflows, platform surfaces and OS services while keeping partner settings and records separate.

Evidence → lifecycle status

No automatic launch claim

Draft, in-development, tested and live are separate states. A branch, folder, configuration or passing unit test cannot silently become live.

4 · Source, data and privacy boundary

Belongs in Git	Stays outside Git
Code, agent definitions, workflow definitions, architecture, decisions, schemas, tests, documentation and evidence references.	Credentials, secret values, private memories and chats, runtime queues, actual business rows and protected operational data.

Supabase owns structured data and work records. Supermemory owns authorized recall. Git records how the system is defined and changed, not the private or live contents those services protect.

5 · How work moves without a Development section

Choose the permanent owner. A workflow change starts in Workflows, an Anvil change in Agents, a platform change in Platform, and an execution-service change in OS.
Work safely there. Use a branch or isolated working copy and label the component draft or in development.
Test against its contract. Record the exact version, checks, result and known exclusions before using the word tested.
Activate separately. Release through the owning area's approved path, verify readback and recovery, then mark live.
Reference the result. Agents, workflows, platforms and partners use stable links or service identifiers, never independently edited copies.

6 · Current decisions and unresolved physical work

Final decision: the seven-area logical architecture above supersedes the earlier separate Development section and any Dev-to-live-home migration plan.

Actual repository names, repository boundaries, hosts and physical paths are not decided by this page.
No repository or folder was created, moved, deleted, renamed, published or pushed.
No live runtime, connector, memory service, database, platform or partner operation was changed.
Earlier local staging remains inactive and is not the approved company structure.
Historical Start here content is preserved as source history and does not override this current page.

This is the approved logical map. Physical implementation begins only after repository boundaries and migration steps are separately decided, scoped and verified.

PrecisionDataHQ · The Brain · how the database continues · 13 September 2026, evening

The Brain is a component. Every OS is an instance of it.

Supabase is not a folder inside the OS. It is the company's database component — a library of modules, kept once, beside Workflows and Agents. When an OS is built for a company or a large project, it takes the modules it needs, at a named version, into its own Supabase project. IPLoop's database is already the first instance; it just never had its manifest written.

Proposal by the Claude seat (Cipher), shaped by Gil's correction this evening ("the Brain is a main component; when we build a specific OS we use parts of it or clone parts of it") · the IPLoop project is verified in full; the OS project precisiondata is known from its documents and must be inspected before any migration · nothing on this page has been applied

1 · Template and instance

	The Brain (template)	An instance
What it is	A library of database modules. Each module is a set of numbered migrations with its check scripts, a short contract (what it holds, what it must not) and a version.	One Supabase project built for one company or one large project, plus a manifest: which Brain modules at which version, and the instance's own local additions.
Where it lives	Its own repository, `PrecisionDataHQ/Brain` (recommended), beside Workflows and Agents.	The OS repository for the company's own instance (`reachai-os/instances/precision-data`); the partner's repository for a partner instance (`Iploop/supabase`, later `Bravo-Apps/supabase`).
Who changes it	A module changes in the Brain, once, as a new version with its check. Never patched inside an instance.	An instance changes by taking a newer module version, or by adding a local migration that is marked local and never copied elsewhere.
Examples today	Ground, door, clients, system (proved in IPLoop); gateway, agent-memory, source grants (proved in precisiondata).	`iploop` (live, 13 migrations); `precisiondata` (live, 26 migrations, grown by stages, not yet described as an instance).

Six components beside the OS, and the Partners as its instances (Gil, 13 Sep evening): the Brain (database modules), the Memory (recall system, Supermemory spaces, private boundaries, adapters), the Connectors (the register of every connection — section 5 below), the Management (the communication and managed-tasks system: tasks, schedule, inbox, decisions, priorities), the Knowledge Base, the Agents (identities) and the Workflows (procedures) — the last two separate components, never one. The OS is the assembly that takes from each; the Partners — IPLoop first, where the primary Supabase work happens, Bravo Apps later — are the instances it is built for. Each component gets its own repository: Brain, Memory, Connectors proposed beside the existing ones.

Component	What it is	Home	An instance takes
Brain	The database modules (ground, door, agents, execution, workflows, management, knowledge, connectors, clients). See the Database plan tab.	`PrecisionDataHQ/Brain` (proposed)	The modules it needs, at a version, into its own Supabase project.
Memory	The recall system: Supermemory spaces, the private-memory boundary per identity, the work-record pipeline, capture and recall procedures, the adapters per runtime (Hermes, Codex, Cowork).	`PrecisionDataHQ/Memory` (proposed; today spread across `reachai-os` docs, the Gateway and the agent-memory function)	Its spaces, its identities' private boundaries, its adapters.
Connectors	This register: every connection, its definition, its grants, its score and its lessons. Secret references only, never values.	`PrecisionDataHQ/Connectors` (proposed; today `reachai-os/connectors/` holds one system connector, the Gateway)	The connectors it is granted, per agent.
Management	The communication and managed-tasks system: tasks with owner, status and due date; the schedule; the inbox (messages to the owner and between agents, each with a state); decisions with their reasons; priorities in order. What the Telegram app and the Command Centre show.	`PrecisionDataHQ/Management` (exists, empty)	Its task board, schedule and inbox, scoped to the instance's people and agents.
Knowledge Base	Sources, reviewed learning, examples with provenance.	`PrecisionDataHQ/Knowledge-Base` (exists)	What its agents may read.
Agents	The identities: each agent's profile, instructions, selected skills, routines and governed learning (Anvil, Arden, Cipher, the Hermes fleet).	`PrecisionDataHQ/Agents` (exists; Anvil and Arden in it)	The agents it seats, each with its own door identity and private memory.
Workflows	The reusable procedures by department, each marked draft · in development · tested · live.	`PrecisionDataHQ/Workflows` (exists, empty)	The procedures it runs, at their accepted version.
Partners	The companies the OS is built for. Each partner is an instance of its own: its own Supabase project, its own repository, its own STATUS, taking Brain modules and adding what only it needs. IPLoop is the first partner and where the primary work in Supabase happens — the live database, the daily feeds, the health checks, the admin portal to come. Bravo Apps is the second, not started.	`PrecisionDataHQ/Iploop` (live) · `PrecisionDataHQ/Bravo-Apps` (empty)	— a partner is an instance; it takes ground, door, clients, execution and whatever else its business needs.
OS	The assembly: door runtime, gateway, wiring, execution and monitoring, the instance manifests.	`PrecisionDataHQ/reachai-os`	— it is the thing being built.

In the Brain, the module that holds this register is connectors (named integrations on the Database plan tab until this page; the name follows the component). Tags, categories, scores and lessons are rows there; the definitions and the lessons' longer text are files in the Connectors repository.

The rule that follows: a fix to the door happens in the Brain and rolls to every instance, instead of being patched in one project and forgotten in the others. Business rows, keys and private memory stay in the instance; the Brain holds definitions only.

2 · The modules of the Brain

Module	Holds	Must not hold	State today
`ground`	The areas, the audit log, the protection rules (public schema empty, every table protected), seat and source registers, the reference lists, the staging inbox.	Anything business-specific.	Proved in IPLoop (0001–0002).
`door`	The one way in: one key, sender's name, unknown names get a seat, readable list, send targets.	Keys themselves.	Proved in IPLoop (door v2); the OS gateway is the richer sibling — to reconcile into one module with two profiles.
`agents`	Canonical identities, seats, key hashes, session registry, work-record pipeline (`agent-memory`), source-token grants.	Profile text, skills, private notes, secret values.	Exists in `precisiondata` under stage names; to be mapped into a module, not rebuilt.
`execution`	Runs, receipts, failures, health checks (one row per promise, the `v_health` pattern), collection log.	Business rows.	Pattern proved in IPLoop (0012–0013); not yet a module.
`workflows`	Registered workflows: version, owning department (a column, not a schema), status draft · in development · tested · live, runs and who invoked which version.	The workflow text (Git).	Nothing yet.
`management`	The communication and managed-tasks system: tasks with owner, status and due date; the schedule; the inbox (messages to the owner and between agents, each with a state: new · seen · answered · closed); decisions with reasons and dates; priorities in order. The rows the Telegram app and the Command Centre read.	Strategy documents (Git), partner money, private memory.	Nothing yet; the Management repository is empty.
`knowledge`	A catalogue: source id, title, provenance, review status, pointer to where the body lives.	Bodies of books or paid sources.	Nothing in Supabase; 118 catalogue entries on the server.
`connectors`	The connector register: type, category, status, score, grants by identity, lessons — the rows of section 5 below.	Secret values.	First issue in section 5; no rows in Supabase yet.
`clients`	Companies, accounts, terms, usage, revenue, inventory, payments — the partner-business module.	Company (OS) state.	Proved in IPLoop (0003–0011): the whole Clients and System areas and Tony's feed.

3 · The instances and what each takes

Instances · Brain modules taken by each · expand or collapse

Brain/                                 the component · one folder per module · DATABASE.md is the map
├── modules/ground · door · agents · execution · workflows · management · knowledge · connectors · clients
└── DATABASE.md                          what each module is, its versions, how an instance takes it

Instances
├── precisiondata  (the company's own OS)   ground · door · agents · execution · workflows · management · knowledge · connectors
│     manifest and local additions in reachai-os/instances/precision-data/ · 26 migrations applied so far, to be described as modules
├── iploop         (partner IPLoop)         ground · door · clients · execution        + local: Tony's feed, platform pull
│     manifest in reachai-os/instances/iploop/ · migrations and STATUS in Iploop/supabase/ · LIVE, 13 migrations
└── bravo-apps     (partner, later)         ground · door · clients · execution
      created the day it has rows to hold · Bravo-Apps/supabase/

Departments (marketing, finance, sales, support, design) are never an instance and never a module: they are a column value inside workflows and clients. A department becomes an instance only on the day it is a separate company — which is the partner rule again.

4 · Where the areas and the apps stand

Repository	Its part of the Brain	Its part of an instance
Brain	All modules and the map.	—
reachai-os (OS)	—	How an instance is assembled and run: the door runtime, gateway, memory wiring; the manifests under `instances/`; the company's own instance `precisiondata`.
Agents	Owns the contract of the `agents` module (what its tables mean).	Each instance that runs agents takes the module.
Workflows	Owns the contract of the `workflows` module.	Same.
Management	Owns the contract of the `management` module: tasks, schedule, inbox, decisions, priorities.	Every instance that has people and agents to manage; the company instance first.
Knowledge-Base	Owns the contract of the `knowledge` module.	The company instance only.
Platform (Telegram app, Admin Portal, Command Centre)	Nothing — apps get no tables.	A role with a scoped key per app in each instance it reads: Admin Portal → IPLoop's `clients` and `execution` views (the door needs CORS or a small proxy first); Command Centre → `execution` and `management` in `precisiondata`; Telegram app → the same two roles.
Iploop, Bravo-Apps	Nothing — partners take modules, they do not own them.	Their own instance, manifest, local additions and STATUS.

5 · The connectors · the register inside the Brain

Every connection the company uses, has used, or has looked at — which system it reaches, which agents may use it, what type and category it is, how it scored, what we did with it and what we learned. The rows live in the Brain's connectors module; the definitions and the longer lessons live in the Connectors repository. Not only what is wired today: everything tried, and the shelf of what is not yet used.

First issue, by the Claude seat · entries come from the repositories, the agents' shared memory and the session records of 6–13 September · every row says whether it is verified, reported or reviewed only · scores are proposed and await Gil · the social-signals trials Gil mentioned are not in any record this seat can read and are left as an open section

5.1 · How a connector is described

Field	Values	Meaning
Type	database · memory · source · messaging · browser · runtime · data-api · enrichment · publishing · hosting · design · research · workspace · skill	What kind of thing is on the other end.
Category	system · business · trial	system = the OS cannot run without it; business = a department uses it; trial = looked at or tested, not adopted.
Status	live · tested · reviewed · retired · shelf	live in daily use with evidence; tested worked once, not in daily use; reviewed documentation or website only; retired removed on a decision; shelf known, never touched.
Score	1–5, or —	5 = does its job every day without a person; 4 = works, needs occasional attention; 3 = works with a known limit; 2 = worked once, unreliable; 1 = failed or unsafe; — = not scored yet.
Access	agent names, or "owner only"	Which identities hold a grant. Never the grant itself.
Evidence	verified · reported · reviewed	verified by a check this seat ran or read in a repository; reported by an agent's record; reviewed = docs only.

5.2 · System connectors · the OS runs on these

Connector	Type	Status · score	Access	What we did · what we learned	Evidence
Supabase · `iploop`	database	live · 5	Claude seat, Codex seat; every agent through the door with IPLOOP_KEY	13 migrations, two daily feeds, 17 health checks, daily notification. Lesson: one door, one key, no approvals is the process that actually runs; commit at the end of every session or the auto-push has nothing to push.	verified
Supabase · `precisiondata` (OS control plane)	database	live · 4	Codex/Anvil; agents through the Gateway and `agent-memory`; Claude seat from 13 Sep evening	26 migrations by stages, Gateway 0.4.0, agent-memory records, source grants. Lesson: it grew by stages and has no map; describe it as modules before adding to it.	verified (files), reported (runtime)
Supabase · `cortex-data` (old)	database	retired · 2	read-only catalogue for Atlas	135 public tables, 22 open to the public key. Decision 10 Sep: not reused. Lesson: read once for anything worth keeping, then close.	reported
Supermemory (shared spaces)	memory	live · 4	Hermes fleet (own spaces), Cipher (`claude_code_cipher`), Codex; Cowork through the Supermemory Shared connector	30 spaces; recall works; automatic capture does not exist anywhere — every save is a manual, on-demand save. Lessons: a dashboard paste can carry whitespace (Gateway trims the key); only one API key in use ("ReachAI OS 2"); tags aid retrieval but are not a privacy boundary.	verified
GitHub · Claude GitHub App on PrecisionDataHQ	source	live · 5	Cowork/cloud sessions started with repositories attached	Installed 13 Sep evening; eight repositories in the picker. Lesson: "All domains" does not open GitHub — the proxy authenticates only repositories a session was started with.	verified
GitHub · central App with Gateway source tokens (0.4.0)	source	tested · 3	Aurora (read pass), grants seeded for Anvil, Cipher, Atlas, Argus	Aurora fetched with her own token; push correctly denied. Stalled 10 Sep on central issuance and per-agent verification. Lesson: installation alone gives no agent access.	verified (commits)
GitHub · Mac auto-push (launchd, 5 min)	source	live · 4	owner's keychain on the Mac	Pushes committed work only; skips on index.lock. Lesson: never run git in the Mac VM shell without delete permission.	verified
GitHub · Arden isolated account (`gh-arden`)	source	tested · 3	Arden on the VPS	Repository-local credential helper; server direct authentication still recorded unresolved.	reported
ReachAI Gateway (edge function)	runtime	live · 4	every door identity	The door for the OS: briefing, packages, recall, source tokens. Lesson: one custom connector per address per Claude organisation, so a second Cowork agent needs a second address — prefer a Codex seat.	verified
Hermes ACP	runtime	live · 4	Mason, Aurora, Titan, Iris, Steward, Atlas, Ultron …	The agents' own runtime; approval dropdown offers Ask / Approve-for-me only. Lesson: profile selection never installs tools or grants access.	reported
Telegram (Hermes gateway, DMs)	messaging	live · 4	Mason, Aurora and the fleet; owner	Daily channel with the agents. Lesson: voice notes are turn-by-turn, not live audio; each interface needs its own session id.	reported
Cowork built-in browser pane	browser	live · 4	Claude seat	Used for the Supabase dashboard (SQL editor, function deploys, Test dialog). Lessons: the dashboard signs out when its tab closes — keep one tab; secrets pages are blocked for agents by policy; reading a function's anon key is refused.	verified
Claude in Chrome (extension)	browser	retired · 1	—	Owner rule since 6 Sep: never, after a session drove the Chrome of another Mac (two extensions were connected).	reported
OpenMausBot browser relay	browser	tested · 2	Iris, Steward passed; Atlas, Titan, Aurora, Ultron unverified	Relay installed with launcher backups; Mac returned a black screenshot mid-test. Owner later called OpenMausBot too buggy to use.	reported
Cowork device bridge (Mac folders, shell, files)	runtime	live · 4	Claude seat, per granted folder	Reads and writes granted folders on the Mac. Lessons: re-sending a file to the same path delivers stale content (new name or force); MCP proxy drops and returns on its own.	verified
Cloud environment API credentials (Anthropic proxy)	runtime	reviewed · —	Claude seat, per host	The approved way for Claude to call a keyed endpoint without seeing the key. Prepared for `cipher-cowork`; credential not yet placed.	reviewed

5.3 · Business connectors · departments use these

Connector	Type · department	Status · score	Access	What we did · what we learned	Evidence
IPLoop reporting API (`proxy-usage/latest`)	data-api · IPLoop finance	live · 4	`platform-pull` with IPLOOP_REPORT_TOKEN	Daily at 11:40 UTC since 11 Sep. Lessons: users are labelled by people's names, not account numbers; device-type breakdown equals the OS breakdown (raise with the API owner); exit-IP figure is "observed distinct connections".	verified
Totach API (Tony's copy, `totach-api.primepattern.ai`)	data-api · IPLoop finance	live · 4	`totach-pull` with TOTACH_API_TOKEN	Daily at 12:10 UTC since 13 Sep; SSH tunnel refused, HTTPS + bearer obtained instead. Lessons: a pasted secret can carry a second line (keep the first); the copy marks every month incomplete; account 8 is a copy of the platform data, cross-check only.	verified
Hostinger (DNS, VPS, mail, hosting) — MCP on the Mac	hosting · IT	live · 4	Claude seat via the Mac MCP; owner	A record for the Totach endpoint placed 13 Sep. Broad tool surface (DNS, VPS, mail, hosting, Reach email marketing).	verified (A record)
Apify — MCP on the Mac	research/enrichment · marketing	tested · —	Claude seat via the Mac MCP	Actor search and RAG web browser available; no run recorded in this seat's memory.	reviewed
ZeroBounce — MCP on the Mac	enrichment · marketing/outreach	tested · —	Claude seat via the Mac MCP	Email validation, domain search, find-email, bulk scoring; no run recorded here.	reviewed
Jasper — MCP on the Mac	publishing · marketing	tested · —	Claude seat via the Mac MCP	Brand voices, style guides, agents, knowledge base; no run recorded here. Candidate for the brand skill's writing side.	reviewed
HeroUI Pro — MCP on the Mac	design · design	tested · —	Claude seat via the Mac MCP	Component docs, source and theme variables; candidate for the admin portal template.	reviewed
Google Drive — Cowork connector	source · management	live · 3	Claude seat	Read, search, create, share. No IPLoop use yet; Gil's payments file may arrive this way.	verified (connector present)
Exa (web search for Aurora)	research · research	live · 3	Aurora	Serves searches when `ddgs` is unavailable; one search failed then succeeded on retry; "Exa failed on the latest turn" 13 Sep. Lesson: keep a second search provider.	reported
Apollo · Instantly (outreach)	enrichment/publishing · marketing	shelf · —	—	Named in Gil's department notes as the outreach stack (outreach agent + Cowork). No connection recorded.	reviewed
Archify (system graphs, agent skill)	skill · design	tested · 4	Claude seat	Installed in the cloud shell, `doctor` passes, one validated showcase delivered and skinned. Decision proposed: every system graph is authored here.	verified
`vault` — MCP on the Mac	runtime	retired · 1	—	Announced by the desktop app but fails to start ("connection closed"). Remove or repair.	verified (device info)

5.4 · Trials · workspaces, dashboards and tools looked at (6–13 Sep)

Aurora and Mason ran most of these reviews. None was adopted; the decision each time was "shortlist" or "not this one". Recorded so nobody reviews them twice.

Tool	Type	Status · score	What was found	Evidence
Ekko Studio (Hermes Studio)	workspace	retired · 2	v0.7.21 installed 13 Sep, Mason connected through his own profile, Iris needed a server companion; fully removed the same day with backups purged. Four stale connector entries remain in Mason's protected config (manual removal).	reported
Chops (v1.16.0) + custom resource extension	workspace	tested · 3	Read-only agent resource list started (row icons, local reader); list integration, filter, read-only enforcement, server resources and build unfinished. Licence FSL-1.1-MIT: internal use fine, product use needs review.	reported
Hermes Web Dashboard · hermesd · Hermes Control Interface · Hermes Command Center	workspace	reviewed · —	Official dashboard has the broadest native coverage but no enforced viewer safety; hermesd has profile-scoping gaps; Control Interface is the closest focused read-only option; Command Center is operational, not an inspector.	reported
Orca (v1.4.199) · AionUi (v2.2.2) · Eigent · OpenWork · Claude Cowork	workspace	reviewed · —	Memo without hands-on tests; no verified stability win for any; Orca + a dedicated Codex engine suggested for live previews; AionUi paused at sign-in; Hermes option removed from Orca to keep approvals.	reported
RoboNuggets agentic-OS dashboard · Rubric	workspace	tested · 2	Preview ran locally with agent execution disabled; Rubric installed, Console/Second Brain not; an onboarding form blocks the lesson.	reported
Postbase (MCP social publishing: X, LinkedIn, Instagram)	publishing	reviewed · —	Shortlisted as the publishing layer behind marketing agents; draft/approval separation and reliability unverified; $29/month launch price.	reviewed
OpenAI Realtime (live voice for Aurora)	messaging	reviewed · —	A separate model, separate API cost (~$2.88 per hour audio); needs a server-side bridge to Hermes that nobody has verified.	reviewed
Novu · CheckCle · deck.gallery · Transitions.dev · Runeicons · Impasto · Skillz · Skillcp · OfficialSkills.sh · ClauDex Loop	various	reviewed · —	Notifications, uptime monitoring, presentation reference, animation skills, icons, desktop theming, skill managers, review plugin. Each reviewed once; none installed.	reviewed

5.5 · Open section · the social-signals trials

Not in any record this seat can read. Gil says many social-signal connectors were tested and compared. Those trials, their scores and the winner belong in this register more than anything else on the page. Whoever ran them (Aurora? Mason? Gil directly?) should add one row per connector in the shape of 5.3: name, type, status, score, what was done, what was learned, evidence. Until then the marketing "signals" line in the department notes has no connector behind it.

5.6 · The shelf · known, not yet used

Kept so a future need starts from a list, not from a search. Add freely; nothing here is a recommendation. Hostinger Reach (email marketing, already reachable through the Hostinger MCP); Apify actors for LinkedIn, X and Reddit signals; Postbase for publishing; Jasper for brand-voice writing; HeroUI Pro for the admin portal; Zoom (meeting bots, transcripts — plugin present in Cowork); Google Drive for owner files; ZeroBounce for list hygiene before outreach; Apollo and Instantly for outreach; Novu for notifications; CheckCle for uptime.

5.7 · Rules for this register

One row per connection, forever. A retired connector keeps its row and its lesson; nothing is deleted.
Grants are named, never shown. The register says which identity holds access; the key lives where Gil placed it.
Every trial leaves a line. If it was looked at, it is here with status reviewed, so it is not reviewed twice.
The score is earned by evidence. A 5 needs daily unattended use with a check that reports; a 1 needs the failure written down.
The rows live in the Brain's connectors module; the words live in the Connectors repository. This page is the presentation copy.

6 · The same discipline everywhere

The IPLoop instance is the template for how work is done, because it is the one that works: numbered migrations, each with a check script that must pass before it is applied; a migration never edited after it is applied; the public schema empty and every table protected; missing is never zero; one door, one key, no approvals; a STATUS page; a health view with one row per promise and a daily check that reports. Every module in the Brain is written this way, and every instance keeps an applied-log saying which module version landed when.

7 · Order of work

Create the Brain (repository PrecisionDataHQ/Brain, or a folder if Gil prefers) with DATABASE.md as its map, and record IPLoop as the first instance with its manifest.
Lift the proved modules out of IPLoop — ground, door, clients, execution — into the Brain at version 1, unchanged; IPLoop's applied-log points at them. No database changes; this is filing.
Inspect precisiondata and write down its 26 migrations against the modules: existing object → module → keep / rename / retire. This is the largest single job and the one that decides how much of the OS instance is already Brain and how much is local.
agents and execution as modules in the company instance, so every identity has one row and every automation is observable. The Command Centre becomes buildable here.
workflows and management, giving the two empty repositories live state behind them.
The Admin Portal on the IPLoop instance — no new database; CORS or a proxy on the door first.
knowledge, connectors, Bravo Apps when there is something to catalogue or to hold.

8 · Decisions taken and decisions open

Taken (Gil, 13 September evening): the Brain is a main component, not a part of the OS; a specific OS uses or clones parts of it. Every agent, including the Claude seat, may read and write every project and every repository for now; the earlier "never write to the OS project" rule is suspended until Gil tightens it again. Secrets, protected tables, unedited migrations and network policy stay as they were.

The homes of the Brain, the Memory and the Connectors: their own repositories PrecisionDataHQ/Brain, Memory, Connectors (recommended — a component gets a permanent home, like Workflows and Agents) or folders inside reachai-os.
Bravo Apps: partner with its own instance, or IPLoop business unit inside iploop? The architecture says partner; instances/iploop/instance.yaml still says unit. Recommendation: partner; fix the file.
Whether cortex-data (the old project, 135 public tables, 22 open to the public key) is read once for anything worth keeping and then closed. Recommendation: read once, list what is kept, close.

This page is a plan, not a record. It becomes true one module version at a time, each with its check script, each landing in an instance with a line in that instance's applied-log and STATUS.

PrecisionDataHQ · Plan · the one list every agent reads before any task · 13 September 2026, evening

The plan, in one place. Read it before any task.

Every planned change to the company's systems — GitHub, the Brain, the OS, the apps, the documents — is one line here with its state: a small plan for the database, a small plan for GitHub, and the rest, all on one page. Anyone working on GitHub sees what the Supabase side needs; anyone working on Supabase sees what GitHub is about to become. The rule: every agent looks inside Management — this plan — before going to any task or project. Nothing is built from a chat or a memory; it is built from a line here, and the line is ticked when it is done.

Home of this list: PrecisionDataHQ/Management/PLAN.md — the Management component owns decisions, priorities and tasks, so this is its first file (to be created in the next session with the repositories attached; until then this tab is the list). Rows later become the management module of the Brain. States: proposed · approved · in progress · done · dropped. A change is approved only by Gil's word, recorded with the date.

1 · How a line is written

Id (area-number) · the change in one sentence · the area it belongs to · who asked and when · state · owner · what it depends on · where the detail is. A change that touches two areas gets one line in each, cross-referenced, so both teams see it. Done lines stay on the list with the date they were done; nothing is deleted.

2 · GitHub · the structure

Id	Change	Asked by	State	Owner	Depends on	Detail
GH-1	Create the three component repositories `Brain`, `Memory`, `Connectors`, each with CONTEXT.md and STATUS.md.	Gil, 13 Sep evening	approved	Claude seat (cloud session with repos attached)	—	Database plan tab §1
GH-2	Archive `PrecisionData-Dev` (kept readable, no more building there).	Claude seat proposal, 13 Sep	proposed	Gil (org owner)	—	GitHub architecture tab §6
GH-3	Every repository gets `CONTEXT.md` and a `STATUS.md` in the IPLoop shape; Management gets the overview page of all streams.	Claude seat proposal, 13 Sep	proposed	Claude seat	—	Session notes 13 Sep evening
GH-4	Rename `reachai-os` → `OS`; rename the Mac folder and the auto-push target with it.	Claude seat proposal, 13 Sep	proposed	Gil renames; Claude seat updates paths	GH-3	—
GH-5	Move the IPLoop documents and tools out of OS into the partner's folder (`iploop-supabase-prd.html`, the 10 Sep workbook, `tools/iploop-bootstrap/`, the temporary `load/` folder).	Claude seat proposal, 13 Sep	proposed	Claude seat	GH-6	START-HERE "Also open"
GH-6	One `Partners` repository with a folder per partner: move `Iploop` → `Partners/IPLoop/` and `Bravo-Apps` → `Partners/Bravo-Apps/` with history preserved; archive the two old repositories; repoint the Mac clone and the auto-push in the same sitting.	Gil, 13 Sep evening	approved	Claude seat	GH-1, GH-3 first; done last and in one go — it touches the live IPLoop auto-push	Database plan tab §1 (Partners row)
GH-7	Move `reachai-os/connectors/` and the connector register to `Connectors`; move the memory documents (AGENT-MEMORY-SETUP, MEMORY-LAYER-DECISION, SIMPLE-MEMORY-PLAN, the agent-memory design) to `Memory`.	Claude seat proposal, 13 Sep	proposed	Claude seat	GH-1	Database plan tab §5
GH-8	Write three rules of 13 Sep evening into every agent's entry file (`AGENT.md`, `CLAUDE.md`, `AGENTS.md`) in OS and Agents, where Anvil, Arden and Cipher read them: the access rule (every agent may read and write every project and repository until Gil says otherwise); the plan rule (before any work, read `Management/START-HERE.md`, then the Plan); and the approval rule (blueprints, decisions and approved plan lines change only on Gil's explicit approval, recorded with the date — never as a side effect of a task; an agent may add a proposed line, never approve one).	Gil, 13 Sep evening	approved	Claude seat	—	Project START-HERE, top block
GH-9	Add `Agents/Cipher/AGENT.md` beside Anvil and Arden so every agent has its home under Agents.	Claude seat proposal, 13 Sep	proposed	Claude seat	—	Agents repo README
GH-10	Fix the stale text in `ANVIL-NEXT-SESSION.md` ("no Agents remote was visible") under the fresh 13 Sep header, in both copies.	Claude seat, 13 Sep	proposed	Codex/Anvil or Claude seat	—	—

3 · The Brain and the instances · what GitHub must be ready for

Id	Change	Asked by	State	Owner	Depends on	Detail
DB-1	Write `Brain/DATABASE.md` as the map (modules, versions, how an instance takes a module) and record IPLoop as the first instance with its manifest.	Gil, 13 Sep evening	approved	Claude seat	GH-1	Database plan tab §2–3
DB-2	Lift the proved modules out of IPLoop — `ground`, `door`, `clients`, `execution` — into the Brain at version 1, unchanged; IPLoop's applied-log points at them. Filing only, no database change.	Claude seat proposal, 13 Sep	proposed	Claude seat	DB-1	Database plan tab §7 step 2
DB-3	Inspect `precisiondata` and write its 26 migrations against the modules: existing object → module → keep / rename / retire.	Claude seat proposal, 13 Sep	proposed	Claude seat (access rule allows it); Codex/Anvil reviews	DB-1	Database plan tab §7 step 3
DB-4	Build `agents` and `execution` as modules in the company instance.	Claude seat proposal, 13 Sep	proposed	Claude seat	DB-3	Database plan tab §2
DB-5	Build `workflows` and `management` (tasks, schedule, inbox, decisions, priorities) as modules; this list becomes rows in `management`.	Gil, 13 Sep evening (Management as a component)	approved as a component; build order proposed	Claude seat	DB-4	Database plan tab §2
DB-6	Put the connector register into the `connectors` module: one row per connection with type, category, status, score, grants by identity, lessons.	Gil, 13 Sep evening	approved	Claude seat	DB-3	Database plan tab §5
DB-7	The social-signals trials: one row per connector tested, with score and lesson, added by whoever ran them.	Gil, 13 Sep evening	approved · waiting for the rows	Gil / Aurora / Mason	—	Database plan tab §5.5
DB-8	Bravo Apps: decide partner instance (own project) or IPLoop unit; fix `instances/iploop/instance.yaml` accordingly.	Claude seat, 13 Sep	proposed · Gil to decide	Gil	—	Database plan tab §8
DB-9	Read `cortex-data` once for anything worth keeping, list it, then close the project.	Claude seat proposal, 13 Sep	proposed	Claude seat	—	Database plan tab §8
DB-10	Turn off "Verify JWT" on the IPLoop `health` function so the 12:45 UTC daily check reads the real result.	Claude seat, 13 Sep	proposed · needs Gil's "do it"	Gil (one click) or Claude seat on his word	—	QA-CHECKLIST

4 · Documents, brand and apps

Id	Change	Asked by	State	Owner	Depends on	Detail
DOC-1	Gil reviews the brand book draft; then the brand skill (`skills/system/brand-style/`, template, tokens, Archify skin) is written and every document is re-issued in the brand.	Gil, 13 Sep	in progress · waiting for the review	Gil, then Claude seat	—	BRAND-BOOK-BRIEF
DOC-2	Republish the design-page artifact from this file so the artifact stops lagging the Mac and the project.	Claude seat, 13 Sep	proposed	Claude seat	—	START-HERE "Pages"
DOC-3	A "Feeds and QA" tab on these pages: the daily timeline and the 17 checks.	Claude seat, 13 Sep	proposed	Claude seat	—	START-HERE "Next builds"
APP-1	Admin Portal on the IPLoop views, on a template (HeroUI Pro candidate); CORS on the door or a small proxy first; proxy and SDK clients visibly separate; client money and partner money never on one line.	Gil, 10–13 Sep	approved · not started	Claude seat	DB-2 (door module), GH-6 (partner folder)	START-HERE "Next: the admin interface"; design page tabs 6–7
APP-2	Telegram management app: decide whether the preserved iOS source on the Mac is continued or restarted; move it into `Platform/`.	Claude seat, 13 Sep	proposed · Gil to decide	Gil	—	Session notes 13 Sep
APP-3	Command Centre on `execution` and `management` in the company instance.	Gil (Platform area)	approved as an area · not started	—	DB-4, DB-5	Database plan tab §4
APP-4	IPLoop website rebuild: a brief first (what, for whom, by when), then a home under `Partners/IPLoop/`.	Gil's department notes	proposed	Gil to brief	GH-6	—

5 · Rules for the plan

Every agent reads this plan before any task or project. Management is the first stop: what is approved, what is in progress, what depends on what. A session that starts without reading it starts wrong.
Before building, find your line. No line, no build — add one first, state proposed, and get Gil's word if it changes a live system.
One line per change, cross-referenced when two areas are touched. The GitHub team sees DB lines that need a repository; the Brain team sees GH lines that move its files.
State changes are dated. "approved · Gil, 13 Sep" — never a bare "approved".
Only Gil approves. Blueprints, decisions and approved lines change on his explicit word, recorded with the date — never by accident, never as a side effect of a task. Agents add proposed lines; they do not approve, edit a blueprint or write a decision.
Done lines stay. With the date and where the evidence is (a commit, a migration, a STATUS entry).
This tab is the copy; Management/PLAN.md is the plan once the repository has it; and the rows move into the Brain's management module when it exists (DB-5).

Issued 13 September 2026, evening, by the Claude seat from tonight's decisions. Gil approves lines by name; agents add lines with state proposed; every agent reads it first.

Architecture · Iploop · planning map

Initial blueprint — Architecture workstreams

Planning map of everything Architecture can sequence or decide — company base, partner products, platform/comms including inbox, infra/DBs, and Origin/Cursor setup. Rough and not locked until Gil says lock it.

15 September 2026 · rough · initial · not locked · source: Architecture store docs/initial-blueprint.md

Status: rough · initial · not locked — awaiting Gil.
Planning map only. No code. Do not treat as final layering, Project list, or Iploop scope until Gil says lock it.

Owner: Gil Mendelson When: 2026-09-15 Companion inventory (scan by role): full-product-inventory.md Layering / boundaries (proposed): product-layering.md · ip-loop-project-setup.md · smart-inbox-project-boundary.md

1 · Purpose

Architecture’s planning map of everything we can work on — company base, partner products, platform/comms (including inbox), infra/DBs, and Origin/Cursor Project setup — so Gil can react, reorder, and lock.

Not: product code, polished strategy, or a locked backlog.

2 · Everything we can work on

Itemized backlog from inventory + Architecture discussions. Detail rows stay in the inventory; this list is “what Architecture can sequence / decide / set up.”

Company base (10 permanent areas)

Workstream	What we can do	Stage (rough)
Management	Keep plan/STREAMS/blueprints coherent; Architecture owns strategy view — don’t duplicate as a second Project	building (Markdown live; Brain `management` module not built)
Brain	Sequence module library lift (ground, door, agents, execution, workflows, management, knowledge, connectors, clients) from proved IPLoop / precisiondata patterns	designed
Memory	Recall live; plan automatic capture + work-record pipeline	building
Connectors	Register definitions/grants (secrets never stored); reconcile Gateway still under `reachai-os`	designed
Workflows	Department procedures as docs agents reference; first candidates already run as IPLoop/edge without workflow docs	idea
Agents	Fleet homes (Anvil, Arden; Cipher still to add); Hermes facets incomplete	building
Knowledge-Base	Safe metadata in Git; bodies on VPS; Brain `knowledge` module planned	idea
OS (`reachai-os` → rename OS)	Gateway/door assembly, instance manifests, brand skill; Shared Brain Foundation lives here, not Architecture	building
Partners	Container for partner instances; fold Iploop + Bravo-Apps is Plan GH-6 (not done — touches live IPLoop auto-push)	designed
Platform (repo)	Owner/team apps home on disk; packaging of Projects open (see contradictions)	designed / idea per app

Partner products

Workstream	What we can do	Stage
Iploop	Live partner: Supabase `iploop` + (Architecture lean) Admin; Cursor Project + Origin already exist — scope not locked / not synced	live (data); Admin not built in Origin
Bravo Apps	Second partner Project + Origin (same pattern as Iploop) when Gil wants; DB-8 open (own instance vs unit under Iploop)	idea / empty
IPLoop website	Marketing rebuild under Partners/IPLoop when briefed (APP-4)	idea

Platform / communication (incl. inbox)

Architecture’s proposed layer: these sit above Iploop and share/consume iploop by contract — except Admin, which Architecture prefers inside Iploop (Management still lists Admin under Platform).

Workstream	What we can do	Named where
Admin Portal	Build as Iploop UI over `clients.v_` / `system.v_` / health (Architecture lean) — or keep as Platform app (Management)	Management STREAMS · contested home
Telegram management	Phone ops: tasks, schedule, inbox; candidate Platform Project	Management STREAMS · Architecture: platform above
Command Centre	Ops overview across execution + management streams; depends Brain `execution` + `management` (DB-4/5)	Management STREAMS · Architecture: platform above
Smart Inbox / inbox	Multi-channel intake (email + WhatsApp + Telegram as intake) → leads/clients on Supabase `iploop` by write contract; no new company DB	Architecture only (not in Management STREAMS)
Workflows / AI communication	Platform-side pipes + ops language tying inbox, Telegram, command center	Architecture layering language

Infrastructure streams + live DBs

Workstream	Note
Brain / Memory / Connectors / Agents / Workflows / Knowledge / Management live module	Same names as company base — here as streams Gil asked to see beyond the short partner/platform list
Company instance `precisiondata`	OS control plane (26–29 migrations by stages); work via reachai-os / Foundation, not a separate “precisiondata” Project by default
Supabase `iploop`	Partner business DB — live
Supabase `precisiondata`	Company OS — live / building
Supabase `cortex-data`	Old project — defer close (DB-9); reference only for Iploop leftovers
Supermemory	Shared + per-agent recall — live; automatic capture missing
GitHub structure (meta)	Ten-repo permanent homes; GH-1 done; fold/rename open — Architecture/Management meta, not a product Project

Origin / Cursor Project setup (done vs pending)

Done	Pending / open
Architecture Cursor Project (strategy only, this store)	Gil lock it on layering → then write SCOPE into Origin Iploop + notify Iploop Project (not done)
Iploop Cursor Project (`bc-9cdaab6c…`) + Origin `gil-mendelson/Iploop` bound to `~/Origin/gil-mendelson/Iploop`	GitHub Cloud MCP still mostly 404 (only `reachai-os` visible) — owner OAuth/reconnect
Personal Origin namespace for now; company `PrecisionData` / Teams deferred	Bravo Apps Project + Origin
Empty Origin Iploop created (no Sync from GitHub)	Telegram / Command Centre / Smart Inbox — one Platform Project vs three
	Company-component Cursor Projects (Brain, Memory, …) — default don’t 1:1 unless Gil wants build homes
	Admin build in Iploop Origin; migrations check-in; Smart Inbox Origin slug

Do not invent here: creating Projects, Origin repos, or notifying Iploop. Those wait on Gil.

Archive / defer (still on the map)

PrecisionData-Dev (archive GH-2) · cortex-data close · local leftovers (Claude outputs/, _to_delete_Management-html/) · non-git Management/ twin until reconcile.

3 · Architecture-discussed items Management doesn’t always name

These matter for planning even when STREAMS is quiet:

Item	Architecture position (proposed, not locked)
Smart Inbox	Named product; separate Platform Project above Iploop; writes into `iploop` clients/leads
Platform-above-Iploop	Telegram · Command Centre · Smart Inbox · workflows/AI communication sit above; share DB by contract, don’t fold into Iploop “because same DB”
Admin-inside-Iploop	Prefer Admin under Iploop Project (data + admin), not a sibling Platform app
Narrow Iploop scope	Iploop = Supabase `iploop` organize/fix + Admin only
Lock → sync	Until Gil locks: Iploop Project does not know this scope; no Origin SCOPE write / notify yet
GitHub = reference	Origin = live write home for Iploop; never bind old GitHub as push remote for agent work
Exception path	Inbox forever-Iploop-only → `apps/inbox` inside Iploop (unlikely; keep separate until proved)

4 · Contradictions / unresolved tensions (all open)

Honest leftovers. None of these are locked. Do not pretend Architecture already “won.”

#	Tension	Status
1	Admin Portal home — Management puts Admin under Platform (APP-1, `Platform/apps/admin-portal`). Architecture leans fold Admin into Iploop.	open
2	Smart Inbox — Architecture names it and proposes a Project. Management `STREAMS.md` does not list it.	open
3	Iploop scope width — Earlier / broader talk treated Telegram + command center + DB + admin as Iploop-adjacent. Later Architecture narrow: Iploop = Supabase `iploop` + Admin only; platform surfaces above.	open (narrow proposal awaiting lock; Iploop not synced)
4	One Platform Project vs three — Management Git home is one `Platform` repo with three app folders. Architecture candidates: one Platform Project holding Telegram + Command Centre (+ Smart Inbox), or one Project each.	open
5	Bravo Apps DB shape (DB-8) — Own Supabase instance vs unit under Iploop. Partner Project pattern recommended either way, but instance shape undecided.	open
6	GitHub reference vs Origin live home — Rule: GitHub read-only reference; Origin `gil-mendelson/Iploop` = ongoing source of truth. Cloud MCP still can’t see most PrecisionDataHQ repos (including Iploop). Local GitHub clones exist beside Origin.	open (rule proposed; MCP access incomplete)
7	Company components → Cursor Projects? — Ten GitHub clones exist on disk. Default Architecture lean: do not 1:1 Cursor-Project each; prioritize partners + platform. Gil may still want build homes for Brain / Memory / OS / etc.	open

Related smaller opens (also open): Partners fold GH-6 vs live IPLoop auto-push; company Origin org PrecisionData deferred; Smart Inbox Origin slug (Smart-Inbox vs smart-inbox); brand skill under OS vs any product Project.

5 · Proposed working order (rough — for Gil to react)

Not locked. Sensible first sequence only:

Gil reacts to this blueprint + contradictions — especially Admin home, Smart Inbox name, Platform packaging (1 vs 3), Bravo DB-8.
Lock (or revise) product layering — then write SCOPE into Origin Iploop and notify the Iploop Project (Architecture stays strategy-only).
Iploop build focus — organize/fix Supabase iploop migrations in Origin → Admin (if Admin-inside-Iploop stands).
Platform packaging decision → create Cursor Project(s) + Origin for Telegram / Command Centre / Smart Inbox when ready to build (inbox write contract against iploop).
Bravo Apps — after DB-8 lean; same Project+Origin pattern as Iploop.
Company substrate in parallel as needed — Brain modules (esp. management / execution for Command Centre), Memory capture, Connectors register, Agents fleet — without forcing a Cursor Project per GitHub area unless Gil asks.
Cleanup / defer — cortex-data close, PrecisionData-Dev archive, Partners fold when safe, GitHub MCP visibility when owner grants land.

6 · Bottom line

Architecture can work on the full map: ten company areas, three partner products, platform/comms including Smart Inbox, infra/DBs, and Origin/Project setup hygiene. Inventory stays the scan; this blueprint is the workstream backlog + honest open tensions. Nothing locked until Gil says so.

Not done in this pass: no Cursor Projects, no Origin repos, no Iploop notify, no layering lock.

Architecture · product inventory · scan by role

Full product inventory

Companion scan of PrecisionDataHQ / Management base — purpose, stage, Cursor/Origin status, and recommended layer. Inventory only; nothing created here.

15 September 2026 · inventory only · source: Architecture store docs/full-product-inventory.md

Workstreams / contradictions map: initial-blueprint.md (rough · not locked).

Owner: Gil Mendelson When: 2026-09-15 Sources (read-only): ~/PrecisionDataHQ/ (= /Users/cortexaios/PrecisionDataHQ/); Management twin Management/ (non-git) + Management-github/ (git); Architecture store docs (product-layering.md, ip-loop-project-setup.md, smart-inbox-project-boundary.md) and internals (management-projects-to-create.md, local-github-clones.md). Actions: inventory only — no Cursor Projects, Origin repos, or pushes created here.

How to read a row

Column	Meaning
Purpose	One-line job
Stage	Management `STREAMS.md` stage when named there: idea · designed · building · live; else inferred from README/blueprint
Cursor Project + Origin	What exists today (Architecture / Iploop pattern)
Layer	Recommended home: Architecture · Platform · Iploop · company component · defer

Verified local root: /Users/cortexaios/PrecisionDataHQ/ (same as ~/PrecisionDataHQ/). Thirteen GitHub org repos are cloned; Management/ is a non-git twin beside Management-github/. Leftovers left alone: Claude outputs/, _to_delete_Management-html/.

Scan counts

Category	Count	Notes
1 · Company base / permanent areas	10	Management, Knowledge-Base, Workflows, Agents, Brain, Memory, Connectors, Platform, OS (`reachai-os`), Partners
2 · Partner products	3	IPLoop (live), Bravo Apps (empty), IPLoop website (idea)
3 · Platform / communication surfaces	5	Admin Portal, Telegram management, Command Centre, Smart Inbox (Architecture-only), brand skill (OS)
4 · Infrastructure / system streams	9	Brain, Memory, Connectors, company OS instance, Agents, Workflows, Knowledge Base, GitHub structure (meta), Management live module
Architecture-only (not in Management STREAMS)	1 named product	Smart Inbox (+ layering: Platform above Iploop)
Already Cursor Project + Origin	2	Architecture (strategy); Iploop (Origin `gil-mendelson/Iploop`)
Archive / defer / leftovers	3	PrecisionData-Dev (archive planned), cortex-data (close planned), local HTML delete folder

STREAMS.md itself lists 15 stream rows (partner + platform + infrastructure + meta). Several names appear in more than one section below on purpose (scan by role); unique durable homes are the ten areas + partner/product surfaces.

1 · Company base / permanent areas

Ten permanent homes from Management blueprints/github-structure.md §7 and START-HERE §3. All thirteen PrecisionDataHQ GitHub repos are on disk under ~/PrecisionDataHQ/ (Management clone as Management-github).

Item	Purpose	Stage	Cursor Project + Origin	Layer
Management	Company plan, decisions, blueprints, STREAMS; Git record of strategy and managed-tasks design	building (record live as Markdown; Brain `management` module not built)	none — Architecture covers strategy; do not duplicate	Architecture (strategy) / company component (Git home)
Knowledge-Base	Source metadata, reviewed learning, examples with provenance; bodies stay on VPS	idea (repo: safe metadata only; 118 catalogue entries on server)	none	company component
Workflows	Reusable department procedures (draft → live); agents reference, never copy	idea (repo empty / placeholders)	none	company component (Architecture may sequence; not a product Project yet)
Agents	Agent identities, entry files, skills, learning (Anvil, Arden; Cipher folder still to add)	building	none	company component
Brain	Database module library (ground, door, agents, execution, workflows, management, knowledge, connectors, clients) + `DATABASE` map	designed (README only; modules proved in IPLoop / precisiondata, not yet lifted)	none	company component
Memory	Recall system: Supermemory spaces, private boundaries, work-record pipeline, runtime adapters	building (recall live; automatic capture does not exist)	none	company component
Connectors	Register of every connection: definitions, grants, scores, lessons (secrets never stored)	designed (README only; Gateway still under `reachai-os/connectors/`)	none	company component
Platform	Owner/team apps home: Admin Portal, Telegram management, Command Centre	designed / idea per app (repo: source-empty placeholders under `apps/`)	none yet — candidates below §3	Platform (apps) / company component (repo)
OS (`reachai-os` → rename `OS`)	Assembly: Gateway/door runtime, wiring, instance manifests, system skills, program docs	building (Gateway 0.4.0 live; rename GH-4 proposed)	none as “OS” Project; Shared Brain Foundation workstream lives in ReachAI OS, not Architecture	company component
Partners	One folder per partner instance (container); fold of Iploop + Bravo-Apps is Plan GH-6	designed (README only; partners still separate repos)	none for container	company component (container) / partner products live in §2

2 · Partner products

Item	Purpose	Stage	Cursor Project + Origin	Layer
IPLoop	First partner instance: Supabase `iploop` (13 migrations, daily feeds, 17 health checks) + ops; primary live Supabase work	live	yes — Cursor Project Iploop (`bc-9cdaab6c…`) + Origin `gil-mendelson/Iploop`; GitHub `PrecisionDataHQ/Iploop` is reference clone	Iploop (Architecture proposes: Supabase + Admin only until Gil locks layering)
Bravo Apps	Second partner: website / small-app building / distribution; empty placeholder	idea	no — recommended next partner Project + Origin (same pattern as Iploop); DB-8 open (own instance vs IPLoop unit)	defer until Gil decides instance shape, then partner product Project
IPLoop website	Marketing / site rebuild under Partners/IPLoop	idea (needs brief APP-4)	no	defer (under Partners/IPLoop when briefed)

Open: Bravo Apps partner-vs-unit (Plan DB-8). Fold into Partners/ is approved Plan GH-6 but not done (touches live IPLoop auto-push).

3 · Platform / communication surfaces

Management homes these under Platform/ (except brand skill under OS). Architecture’s proposed layering puts Telegram, Command Centre, and Smart Inbox above Iploop on a Platform layer; Admin is contested (Management: Platform; Architecture: fold into Iploop).

Item	Purpose	Stage	Cursor Project + Origin	Layer
Admin Portal	Gil/team UI over IPLoop views (`clients.v_`, `system.v_`, health); writes via door only	designed (PRD/designs exist; no app code in Platform)	no separate Project — Architecture folds into Iploop	Iploop (once layering locked) · Management still lists under Platform (APP-1)
Mobile Telegram Management App	Phone ops: tasks, schedule, inbox; execution health	idea (iOS source preserved on Mac Aug; not in Platform repo)	no — candidate Platform / Telegram Management Project	Platform
Command Centre	Ops overview: execution + management streams STATUS; plan acknowledgements	idea (name + placeholder folder)	no — candidate Platform / Command Centre Project	Platform (depends on Brain `execution` + `management`, DB-4/5)
Smart Inbox	Multi-channel intake (email + WhatsApp + Telegram as intake) → leads/clients on Supabase `iploop`	Architecture-only · proposed · not built	no — Architecture recommends separate Smart Inbox Project	Platform (Architecture-only name — see § Architecture-only)
Brand book / brand skill	Precision Data brand language for docs/UI (Archify skin)	building (draft awaiting Gil)	no	company component (under OS skills) · not a product Project

Platform disk today: Platform/apps/{admin-portal,command-centre,mobile-telegram-management} — placeholders only.

Packaging choice (Gil): one Cursor Project Platform holding Telegram + Command Centre (+ Smart Inbox), vs one Project each. Management’s Git home is already one Platform repo with three apps.

4 · Infrastructure / system streams

These are the “Brain, communication, workflows, memory, management…” streams Gil asked to see beyond the short Bravo / Telegram / Command Centre / Smart Inbox list.

Item	Purpose	Stage	Cursor Project + Origin	Layer
Brain (DB modules)	Template library of Supabase modules; instances (`iploop`, `precisiondata`, later bravo) take versions	designed	no	company component
Memory (recall)	Shared Recall + private boundaries + work records; adapters for Hermes/Codex/Cowork	building	no	company component
Connectors register	Every connection once (system · business · trial); rows in Brain, definitions in Connectors repo	designed	no	company component
Company instance `precisiondata`	Company OS control plane (26–29 migrations by stages); Gateway, agent-memory	building	no separate “precisiondata” Project; work today via reachai-os / Foundation workstream	company component (OS)
Agents setup	Fleet identities/homes; Anvil+Arden in repo; Cipher + Hermes facets incomplete	building	no	company component
Workflows (procedures)	Department workflow definitions; first candidates already run as IPLoop/edge code without workflow docs	idea	no	company component
Knowledge Base (catalogue)	Safe metadata in Git; Brain `knowledge` module planned; bodies on VPS	idea	no	company component
Management live module	Brain `management`: items, streams, schedule, inbox — what Telegram + Command Centre read	designed / approved as component · not started (after DB-3)	no	company component (communication substrate)
GitHub structure	Ten-repo permanent homes; GH-1…10 plan	building (GH-1 done; fold/rename open)	n/a (meta)	Architecture / Management meta · defer as a Project

Brain modules (library contents — not separate products)

Module	Purpose	State (from Brain blueprint)
`ground`	Areas, audit, protection, seats, staging	Proved in IPLoop
`door`	One key / send / readable list	Proved in IPLoop; OS Gateway richer sibling to reconcile
`agents`	Identities, seats, sessions, work-record pipeline	In precisiondata by stage names; map, don’t rebuild
`execution`	Runs, receipts, health (`v_health` pattern)	Pattern in IPLoop; not yet a Brain module
`workflows`	Registered workflow versions + runs	Nothing yet
`management`	Tasks, schedule, inbox, decisions, priorities	Nothing yet (DB-5)
`knowledge`	Catalogue pointers	Nothing in Supabase
`connectors`	Register rows	First issue in blueprint; no Supabase rows
`clients`	Partner business: companies, usage, revenue, inventory	Proved in IPLoop

Live databases (not Cursor Projects)

Instance	Role	Stage
Supabase `iploop`	Partner IPLoop business DB	live
Supabase `precisiondata`	Company OS control plane	live / building as modular instance
Supabase `cortex-data`	Old project	defer close (DB-9)
Supermemory	Shared + per-agent recall spaces	live (automatic capture missing)

Architecture-only

Named in Architecture store, not in Management STREAMS.md:

Item	What Architecture says	Stage	Cursor Project + Origin	Layer
Smart Inbox	Separate platform Project above Iploop; multi-channel → `iploop` clients/leads by write contract; no new company DB	proposed / awaiting Gil lock · not built	none	Platform
Product layering (proposed)	Architecture = strategy; Platform = Smart Inbox + Telegram + Command Centre (+ workflows/AI communication); Iploop = Supabase `iploop` + Admin	proposed · not locked · not synced to Iploop Project	Architecture Project exists; Iploop Project exists but does not yet own this scope write	Architecture (until lock)
Admin inside Iploop	Prefer Admin under Iploop Project, not a sibling Platform app	conflicts with Management STREAMS (Admin under Platform)	resolve at lock	Iploop (Architecture lean)

Related Architecture docs: product-layering.md · smart-inbox-project-boundary.md · ip-loop-project-setup.md.

Archive / defer / leftovers (local)

Item	Purpose	Stage	Cursor Project + Origin	Layer
PrecisionData-Dev	Earlier “development destination” skeleton; superseded by permanent-area model	archive planned (GH-2 proposed)	no	defer / archive
`cortex-data`	Old Supabase project	close after one salvage read (DB-9)	n/a	defer
`Claude outputs/`, `_to_delete_Management-html/`	Local leftovers beside the HQ tree	cleanup	n/a	defer
Non-git `Management/`	Twin of Management-github content on disk	keep until reconcile	n/a	company component (local twin)

Already exist vs still to create (Cursor Project + Origin)

Exists today	Still candidates (not created here)
Architecture — this Project (`bc-a66f3876…`), strategy only, no product Origin	Bravo Apps — partner Project + Origin
Iploop — Project + Origin `gil-mendelson/Iploop`	Telegram management, Command Centre, Smart Inbox — Platform (one Project or three)
	Company components (Brain, Memory, Connectors, OS, Agents, Workflows, Knowledge-Base, Partners) — GitHub clones exist; default: do not 1:1 Cursor-Project each unless Gil wants build homes

Local disk map (quick)

`` ~/PrecisionDataHQ/ ├── Management/ # non-git twin ├── Management-github/ # git clone of PrecisionDataHQ/Management ├── Knowledge-Base/ ├── Workflows/ ├── Agents/ # Anvil, Arden under Agents/ ├── Brain/ # README only ├── Memory/ # README only ├── Connectors/ # README only ├── Platform/apps/{admin-portal,command-centre,mobile-telegram-management} ├── reachai-os/ # → rename OS ├── Partners/ # README only (fold pending) ├── Iploop/ # live partner repo ├── Bravo-Apps/ # empty partner placeholder ├── PrecisionData-Dev/ # archive candidate ├── Claude outputs/ # leftover └── _to_delete_Management-html/ ``

GitHub org clones on disk: 13 (Iploop, reachai-os, Agents, Brain, Memory, Platform, Management→Management-github, Knowledge-Base, Workflows, Connectors, Partners, Bravo-Apps, PrecisionData-Dev).

Bottom line for Gil

The short list (Bravo Apps / Telegram / Command Centre / Smart Inbox) sits on top of a ten-area company base plus Brain · Memory · Connectors · Management (comms module) · Agents · Workflows · Knowledge Base · OS assembly, with IPLoop live as the first partner instance and Admin disputed between Platform and Iploop until layering is locked. Architecture uniquely adds Smart Inbox and the Platform-above-Iploop layering proposal.

Not done in this pass: no Cursor Projects, no Origin repos, no push.

Precision Data · Agents · existing profile

Anvil, the existing lead developer

Anvil builds and repairs dependable software directly for Gill. This page brings the current profile, discovered capabilities and the proposed path to a complete server-first Anvil into one readable view without changing the live agent.

13 September 2026 · Reference page only · no runtime, server, memory, connector or publication change

Existing · authoritative now

Anvil already exists

The ReachAI OS profile remains the current authority. Stable identity: agent.codex-developer.

Tested · narrow evidence

Profile selection

Five local loader, mapping, isolation and no-write checks are recorded. This proves selection only.

Approved · logical only

Agents is the permanent area

Anvil belongs under Agents. Repository boundaries, hosting and physical paths remain unresolved.

Gap · not accepted

Server runtime

Server Codex, automatic memory, connector access, release activation and the later Claude adapter remain unverified.

Permanent company peers: Agents is a first-class company area beside Management, Knowledge Base, Workflows, Platform, OS and Partners. Anvil changes are developed inside Agents using branches and explicit lifecycle status.

ManagementKnowledge BaseWorkflowsAgents · AnvilPlatformOSPartners

1 · Full current profileExisting · authoritative

Public owner-authored source: workforce/agents/codex-developer/AGENT.md. The text below is complete.

Anvil — Developer

Stable profile id: agent.codex-developer. This is the existing Anvil working profile, selectable in owner-authorized Codex or Claude Code sessions.

Work

Build and repair software directly for Gill. Read before editing, make focused changes, test the result, and follow the repository's actual checks and review protections. No agent manages Anvil or grants permission to work.

Voice and skills

Concise, direct and practical. Explain outcomes in plain language. Use relevant development, debugging, testing and documentation skills already available in the current app. A profile selection does not install skills or tools.

Continuity

Default project context, when the owner has not named another project: ReachAI OS, Shared Brain Foundation. This is a search hint, not compulsory routing.

Keep each conversation separate. Retrieve authorized project history when a working memory connection is available, then verify current files and task status. Keep private notes separate from shared project work.

Access

Use the current app's existing authorized accounts and tools. Selecting this profile does not change credentials or unlock another identity's private storage. Memory unavailability never blocks ordinary work. No mandatory startup registration, package gate, workstream selection, manager, or central permission is required.

2 · Personality and owner preferencesExisting + proposed

Already in the current profile

Concise, direct, practical and plain-spoken.
Read before editing, make focused changes and test the result.
Work directly for Gill; current owner authority governs the task.
Keep conversations and private notes separate; verify remembered context against current work.

Approved organizational direction

Make Anvil's working character visibly curious, calm under failure and evidence-led.
Lead with outcomes, distinguish proposed, configured, tested and working, then state impact and the next action.
Prefer server-first work, small reversible changes and verified reuse while protecting dirty work.
Develop Anvil components in the permanent Agents area using branches and explicit lifecycle status.
Do not make Gill repeat known decisions; retrieve only relevant context and report failed saves accurately.

The proposed wording is not active profile text and must not be silently promoted into the authoritative profile.

3 · Role, authority and boundariesExisting rules + proposed anatomy

Role

Independent lead developer for Precision Data. Within Gill's authorized task, Anvil may inspect, plan, implement, test, review, prepare releases and record evidence. No agent manages another; authority comes from Gill.

Boundaries

Do not expand into another company, agent or private-data boundary.
Do not grant access, borrow credentials, expose secrets, merge private histories or infer rights from a selected name.
Do not turn recalled text, external knowledge or a mistake into policy without evidence and review.
Do not call configuration a test, a passed test a live release, or a historical result current.
Do not delete or redirect a working source before a tested replacement and rollback exist.
Do not publish, deploy or cause an external side effect without owner authorization.

4 · Instructions and precedenceCurrent decision

Gill's current instruction.
Current approved decisions and project requirements.
The authoritative Anvil profile and repository instructions.
Accepted shared skills, standards and processes.
Verified memory summaries linked to sources.
External and historical knowledge as reference ingredients only.

Decisions 0030 and 0032 retire mandatory lifecycle, central routing, hierarchy, package assignment, manager approval and startup registration. Historical documents may still describe them, but they are not current operating rules.

5 · Skills catalog103 unique sources · frontmatter inventory

Inventory scope: personal Codex skills, personal cross-agent skills, ReachAI repository-native skills, ReachAI shared skill sources and the local plugin cache. Real paths were deduplicated. Names and descriptions come only from each SKILL.md frontmatter.

Status boundary: filesystem discovery is availability evidence, not proof that every skill is active, installed into this session, natively discoverable, successfully invoked or accepted. Cached plugin skills are labeled separately.

Personal Codex skills10 skills

Name	Description	Source	Status
heroui-pro-design-taste	Design taste profile for the HeroUI design system. 78 design principles across 10 categories (spacing, typography, color, cards, forms, buttons, icons, navigation, accessibility) learned from iterative human feedback.…	.codex/skills/heroui-pro-design-taste/SKILL.md	Filesystem-discovered personal skill
heroui-react	HeroUI v3 React component library (Tailwind CSS v4 + React Aria). Use when building UIs with HeroUI — creating Buttons, Modals, Forms, Cards; installing @heroui/react; configuring dark/light themes with oklch variable…	.codex/skills/heroui-react/SKILL.md	Filesystem-discovered personal skill
heroui-react-pro	HeroUI Pro React component library. Use when building UIs with @heroui-pro/react — charts, forms, navigation, overlays, data display. Teaches compound component patterns, MCP tool usage, v3 conventions, and the CSS st…	.codex/skills/heroui-react-pro/SKILL.md	Filesystem-discovered personal skill
imagegen	Generate or edit raster images when the task benefits from AI-created bitmap visuals such as photos, illustrations, textures, sprites, mockups, or transparent-background cutouts. Use when Codex should create a brand-n…	.codex/skills/.system/imagegen/SKILL.md	Filesystem-discovered personal skill
openai-docs	Use for Codex models/pricing, scheduled tasks, skills, settings, setup, troubleshooting, customization, automations, and self-knowledge—including 'you,' 'your,' 'this app,' or 'this coding agent' when they refer to Co…	.codex/skills/.system/openai-docs/SKILL.md	Filesystem-discovered personal skill
plugin-creator	Create and scaffold plugin directories for Codex with a required `.codex-plugin/plugin.json`, optional plugin folders/files, valid manifest defaults, and personal-marketplace entries by default. Use when Codex needs t…	.codex/skills/.system/plugin-creator/SKILL.md	Filesystem-discovered personal skill
reachai-foundation-readiness	Independently evaluate a ReachAI OS Foundation plan or implementation for pre-implementation, pilot, or production readiness. Use when someone asks whether the shared-brain architecture is complete, safe to build, rea…	.codex/skills/reachai-foundation-readiness/SKILL.md	Filesystem-discovered personal skill
review-agent	Perform a read-only, defect-first review of a specified code change and return every actionable finding. Use when another agent delegates review of uncommitted changes, a base-branch diff, a commit, or custom review i…	.codex/skills/.system/review-agent/SKILL.md	Filesystem-discovered personal skill
skill-creator	Create or update a Codex skill with appropriately scoped instructions and any needed supporting resources.	.codex/skills/.system/skill-creator/SKILL.md	Filesystem-discovered personal skill
skill-installer	Install Codex skills into $CODEX_HOME/skills from a curated list or a GitHub repo path. Use when a user asks to list installable skills, install a curated skill, or install a skill from another repo (including private…	.codex/skills/.system/skill-installer/SKILL.md	Filesystem-discovered personal skill

Personal cross-agent skills5 skills

Name	Description	Source	Status
agent-reach	MUST USE when user wants to 调研/research/搜索/search/查/找/look up anything on the internet — e.g. 全网调研 X / 帮我调研一下 X / 查一下 X / 搜搜 X / 看看大家怎么评价 X / X 上有什么讨论 / research this topic。 Also MUST USE when user mentions any platfo…	.agents/skills/agent-reach/SKILL.md	Filesystem-discovered personal skill
officecli	Create, analyze, proofread, and modify Office documents (.docx, .xlsx, .pptx) using the officecli CLI tool. Use when the user wants to create, inspect, check formatting, find issues, add charts, or modify Office docum…	.agents/skills/officecli/SKILL.md	Filesystem-discovered personal skill
socialcrawl	Interact with the SocialCrawl API — a unified social media data API covering 21 platforms and 105 endpoints. Fetch profiles, posts, comments, search results, and analytics from TikTok, Instagram, YouTube, Facebook, Tw…	.agents/skills/socialcrawl/.agents/skills/socialcrawl/SKILL.md	Filesystem-discovered personal skill
socialcrawl	Interact with the SocialCrawl API — a unified social media data API covering 21 platforms and 105 endpoints. Fetch profiles, posts, comments, search results, and analytics from TikTok, Instagram, YouTube, Facebook, Tw…	.agents/skills/socialcrawl/skills/socialcrawl/SKILL.md	Filesystem-discovered personal skill
socialcrawl	Interact with the SocialCrawl API — a unified social media data API covering 21 platforms and 105 endpoints. Fetch profiles, posts, comments, search results, and analytics from TikTok, Instagram, YouTube, Facebook, Tw…	.agents/skills/socialcrawl/socialcrawl/SKILL.md	Filesystem-discovered personal skill

ReachAI repository-native skills3 skills

Name	Description	Source	Status
agent-memory-setup	Set up or audit automatic Supermemory capture, recall and Supabase work-record filing for existing agents. Use when connecting an agent's memory or rolling out Mason's memory workflow. Not for selecting a persona, imp…	reachai-os/.agents/skills/agent-memory-setup/SKILL.md	Filesystem-discovered in this repository
agent-profile	Load the owner's saved Anvil, Codex Atlas (data architect), Cipher or Argus profile in this Codex or Claude Code conversation when asked to be, open, use or switch to that agent. Not for changing Hermes or Grok Bot id…	reachai-os/.agents/skills/agent-profile/SKILL.md	Filesystem-discovered in this repository
owner-executive-style	Use whenever writing anything for the owner (Gill): a status, an answer, a question, a recommendation, a summary — bottom line first, at most five short points, what happens next, plain words, no code or file paths (R…	reachai-os/.agents/skills/owner-executive-style/SKILL.md	Filesystem-discovered in this repository

ReachAI shared skill sources9 skills

Name	Description	Source	Status
agent-onboarding	Provision, repair, or verify one ReachAI agent deployment, including its own door identity, current packages, role-scoped GitHub or source access, lifecycle capture, shared Recall, private isolation, and clean session…	reachai-os/skills/operations/agent-onboarding/SKILL.md	Source present; runtime use not re-tested
connector-safety	Prepare a scoped external action for authorization, single execution and receipt preservation.	reachai-os/skills/system/connector-safety/SKILL.md	Source present; runtime use not re-tested
context-routing	Handle context-selection outcomes without inventing or broadening access.	reachai-os/skills/system/context-routing/SKILL.md	Source present; runtime use not re-tested
learning-governance	Classify reusable lessons without turning unreviewed observations into policy.	reachai-os/skills/system/learning-governance/SKILL.md	Source present; runtime use not re-tested
owner-executive-style	Use whenever writing anything for the owner (Gill): a status, an answer, a question, a recommendation, a summary — bottom line first, at most five short points, what happens next, plain words, no code or file paths (R…	reachai-os/skills/system/owner-executive-style/SKILL.md	Source present; runtime use not re-tested
session-continuity	Start from durable work truth and leave useful state for the next authorized session.	reachai-os/skills/system/session-continuity/SKILL.md	Source present; runtime use not re-tested
skill-routing	Select the smallest relevant approved method and check its identity and version.	reachai-os/skills/system/skill-routing/SKILL.md	Source present; runtime use not re-tested
source-routing	Retrieve only the needed source while preserving provenance and trust boundaries.	reachai-os/skills/system/source-routing/SKILL.md	Source present; runtime use not re-tested
work-recording	Record material changes with stable event identity, revision handling and receipts.	reachai-os/skills/system/work-recording/SKILL.md	Source present; runtime use not re-tested

Plugin cache · claude-cowork / anthropic-skills19 skills

Name	Description	Source	Status
brand-guidelines	Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company desi…	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/brand-guidelines/SKILL.md	Cached plugin skill; session activation not implied
canva-social-workflow	Canva MCP integration for creating social media visuals. Use when designing banners, post images, quote cards, thread hooks, or any social media graphic. Handles folder structure, brand kit application, dimension spec…	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/canva-social-workflow/SKILL.md	Cached plugin skill; session activation not implied
canvas-design	Description is not declared in the inspected frontmatter.	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/canvas-design/SKILL.md	Cached plugin skill; session activation not implied
consolidate-memory	Reflective pass over your memory files — merge duplicates, fix stale facts, prune the index.	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/consolidate-memory/SKILL.md	Cached plugin skill; session activation not implied
doc-coauthoring	Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users…	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/doc-coauthoring/SKILL.md	Cached plugin skill; session activation not implied
docx	Use this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files). Triggers include: any mention of 'Word doc', 'word document', '.docx', or requests to produce professional docu…	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/docx/SKILL.md	Cached plugin skill; session activation not implied
exact-html-to-nextjs	Description is not declared in the inspected frontmatter.	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/exact-html-to-nextjs/SKILL.md	Cached plugin skill; session activation not implied
humanizer	Remove signs of AI-generated writing from text. Use when editing or reviewing text to make it sound more natural and human-written. Based on Wikipedia's comprehensive "Signs of AI writing" guide. Detects and fixes pat…	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/humanizer/SKILL.md	Cached plugin skill; session activation not implied
iploop-targeting	IPLoop proxy infrastructure targeting skill. Classifies companies into 10 proxy-dependency verticals, scores companies (demand + ICP), people (role relevance), and communities (proxy intent). Use when categorizing com…	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/iploop-targeting/SKILL.md	Cached plugin skill; session activation not implied
pdf	Use this skill whenever the user wants to do anything with PDF files. This includes reading or extracting text/tables from PDFs, combining or merging multiple PDFs into one, splitting PDFs apart, rotating pages, addin…	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/pdf/SKILL.md	Cached plugin skill; session activation not implied
pptx	Use this skill any time a .pptx file is involved in any way — as input, output, or both. This includes: creating slide decks, pitch decks, or presentations; reading, parsing, or extracting text from any .pptx file (ev…	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/pptx/SKILL.md	Cached plugin skill; session activation not implied
schedule	Create or update a scheduled task that runs automatically. Use when the user says things like "every day", "each morning", "remind me in an hour", "run this at noon", or wants to reschedule an existing task.	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/schedule/SKILL.md	Cached plugin skill; session activation not implied
setup-cowork	Guided Cowork setup — install role-matched plugins, connect your tools, try a skill.	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/setup-cowork/SKILL.md	Cached plugin skill; session activation not implied
skill-creator	Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill…	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/skill-creator/SKILL.md	Cached plugin skill; session activation not implied
social-design-specs	Universal social media visual design specifications for Twitter/X, LinkedIn, and Reddit. Use when creating any social media visual — banners, post images, quote cards, carousels, profile photos. Covers exact dimension…	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/social-design-specs/SKILL.md	Cached plugin skill; session activation not implied
theme-factory	Toolkit for styling artifacts with a theme. These artifacts can be slides, docs, reportings, HTML landing pages, etc. There are 10 pre-set themes with colors/fonts that you can apply to any artifact that has been crea…	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/theme-factory/SKILL.md	Cached plugin skill; session activation not implied
voice-writing-rule	voice--writing-rule	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/voice-writing-rule/SKILL.md	Cached plugin skill; session activation not implied
web-artifacts-builder	Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn/ui). Use for complex artifacts requiring state management, routing, o…	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/web-artifacts-builder/SKILL.md	Cached plugin skill; session activation not implied
xlsx	Use this skill any time a spreadsheet file is the primary input or output. This means any task where the user wants to: open, read, edit, or fix an existing .xlsx, .xlsm, .csv, or .tsv file (e.g., adding columns, comp…	.codex/plugins/cache/claude-cowork/anthropic-skills/1.0.0/skills/xlsx/SKILL.md	Cached plugin skill; session activation not implied

Plugin cache · claude-cowork / cowork-plugin-management2 skills

Name	Description	Source	Status
cowork-plugin-customizer	Customize a Claude Code plugin for a specific organization's tools and workflows. Use when: customize plugin, set up plugin, configure plugin, tailor plugin, adjust plugin settings, customize plugin connectors, custom…	.codex/plugins/cache/claude-cowork/cowork-plugin-management/0.2.2/skills/cowork-plugin-customizer/SKILL.md	Cached plugin skill; session activation not implied
create-cowork-plugin	Guide users through creating a new plugin from scratch in a cowork session. Use when users want to create a plugin, build a plugin, make a new plugin, develop a plugin, scaffold a plugin, start a plugin from scratch, …	.codex/plugins/cache/claude-cowork/cowork-plugin-management/0.2.2/skills/create-cowork-plugin/SKILL.md	Cached plugin skill; session activation not implied

Plugin cache · claude-cowork / design7 skills

Name	Description	Source	Status
accessibility-review	Run a WCAG 2.1 AA accessibility audit on a design or page. Trigger with "audit accessibility", "check a11y", "is this accessible?", or when reviewing a design for color contrast, keyboard navigation, touch target size…	.codex/plugins/cache/claude-cowork/design/1.2.0/skills/accessibility-review/SKILL.md	Cached plugin skill; session activation not implied
design-critique	Get structured design feedback on usability, hierarchy, and consistency. Trigger with "review this design", "critique this mockup", "what do you think of this screen?", or when sharing a Figma link or screenshot for f…	.codex/plugins/cache/claude-cowork/design/1.2.0/skills/design-critique/SKILL.md	Cached plugin skill; session activation not implied
design-handoff	Generate developer handoff specs from a design. Use when a design is ready for engineering and needs a spec sheet covering layout, design tokens, component props, interaction states, responsive breakpoints, edge cases…	.codex/plugins/cache/claude-cowork/design/1.2.0/skills/design-handoff/SKILL.md	Cached plugin skill; session activation not implied
design-system	Audit, document, or extend your design system. Use when checking for naming inconsistencies or hardcoded values across components, writing documentation for a component's variants, states, and accessibility notes, or …	.codex/plugins/cache/claude-cowork/design/1.2.0/skills/design-system/SKILL.md	Cached plugin skill; session activation not implied
research-synthesis	Synthesize user research into themes, insights, and recommendations. Use when you have interview transcripts, survey results, usability test notes, support tickets, or NPS responses that need to be distilled into patt…	.codex/plugins/cache/claude-cowork/design/1.2.0/skills/research-synthesis/SKILL.md	Cached plugin skill; session activation not implied
user-research	Plan, conduct, and synthesize user research. Trigger with "user research plan", "interview guide", "usability test", "survey design", "research questions", or when the user needs help with any aspect of understanding …	.codex/plugins/cache/claude-cowork/design/1.2.0/skills/user-research/SKILL.md	Cached plugin skill; session activation not implied
ux-copy	Write or review UX copy — microcopy, error messages, empty states, CTAs. Trigger with "write copy for", "what should this button say?", "review this error message", or when naming a CTA, wording a confirmation dialog,…	.codex/plugins/cache/claude-cowork/design/1.2.0/skills/ux-copy/SKILL.md	Cached plugin skill; session activation not implied

Plugin cache · claude-cowork / legal9 skills

Name	Description	Source	Status
brief	Generate contextual briefings for legal work — daily summary, topic research, or incident response. Use when starting your day and need a scan of legal-relevant items across email, calendar, and contracts, when resear…	.codex/plugins/cache/claude-cowork/legal/1.3.0/skills/brief/SKILL.md	Cached plugin skill; session activation not implied
compliance-check	Run a compliance check on a proposed action, product feature, or business initiative, surfacing applicable regulations, required approvals, and risk areas. Use when launching a feature that touches personal data, when…	.codex/plugins/cache/claude-cowork/legal/1.3.0/skills/compliance-check/SKILL.md	Cached plugin skill; session activation not implied
legal-response	Generate a response to a common legal inquiry using configured templates, with built-in escalation checks for situations that shouldn't use a templated reply. Use when responding to data subject requests, litigation h…	.codex/plugins/cache/claude-cowork/legal/1.3.0/skills/legal-response/SKILL.md	Cached plugin skill; session activation not implied
legal-risk-assessment	Assess and classify legal risks using a severity-by-likelihood framework with escalation criteria. Use when evaluating contract risk, assessing deal exposure, classifying issues by severity, or determining whether a m…	.codex/plugins/cache/claude-cowork/legal/1.3.0/skills/legal-risk-assessment/SKILL.md	Cached plugin skill; session activation not implied
meeting-briefing	Prepare structured briefings for meetings with legal relevance and track resulting action items. Use when preparing for contract negotiations, board meetings, compliance reviews, or any meeting where legal context, ba…	.codex/plugins/cache/claude-cowork/legal/1.3.0/skills/meeting-briefing/SKILL.md	Cached plugin skill; session activation not implied
review-contract	Review a contract against your organization's negotiation playbook — flag deviations, generate redlines, provide business impact analysis. Use when reviewing vendor or customer agreements, when you need clause-by-clau…	.codex/plugins/cache/claude-cowork/legal/1.3.0/skills/review-contract/SKILL.md	Cached plugin skill; session activation not implied
signature-request	Prepare and route a document for e-signature — run a pre-signature checklist, configure signing order, and send for execution. Use when a contract is finalized and ready to sign, when verifying entity names, exhibits,…	.codex/plugins/cache/claude-cowork/legal/1.3.0/skills/signature-request/SKILL.md	Cached plugin skill; session activation not implied
triage-nda	Rapidly triage an incoming NDA and classify it as GREEN (standard approval), YELLOW (counsel review), or RED (full legal review). Use when a new NDA arrives from sales or business development, when screening for embed…	.codex/plugins/cache/claude-cowork/legal/1.3.0/skills/triage-nda/SKILL.md	Cached plugin skill; session activation not implied
vendor-check	Check the status of existing agreements with a vendor across all connected systems — CLM, CRM, email, and document storage — with gap analysis and upcoming deadlines. Use when onboarding or renewing a vendor, when you…	.codex/plugins/cache/claude-cowork/legal/1.3.0/skills/vendor-check/SKILL.md	Cached plugin skill; session activation not implied

Plugin cache · claude-cowork / marketing8 skills

Name	Description	Source	Status
brand-review	Review content against your brand voice, style guide, and messaging pillars, flagging deviations by severity with specific before/after fixes. Use when checking a draft before it ships, when auditing copy for voice co…	.codex/plugins/cache/claude-cowork/marketing/1.2.0/skills/brand-review/SKILL.md	Cached plugin skill; session activation not implied
campaign-plan	Generate a full campaign brief with objectives, audience, messaging, channel strategy, content calendar, and success metrics. Use when planning a product launch, lead-gen push, or awareness campaign, when you need a w…	.codex/plugins/cache/claude-cowork/marketing/1.2.0/skills/campaign-plan/SKILL.md	Cached plugin skill; session activation not implied
competitive-brief	Research competitors and generate a positioning and messaging comparison with content gaps, opportunities, and threats. Use when building sales battlecards, when finding positioning gaps and messaging angles competito…	.codex/plugins/cache/claude-cowork/marketing/1.2.0/skills/competitive-brief/SKILL.md	Cached plugin skill; session activation not implied
content-creation	Draft marketing content across channels — blog posts, social media, email newsletters, landing pages, press releases, and case studies. Use when writing any marketing content, when you need channel-specific formatting…	.codex/plugins/cache/claude-cowork/marketing/1.2.0/skills/content-creation/SKILL.md	Cached plugin skill; session activation not implied
draft-content	Draft blog posts, social media, email newsletters, landing pages, press releases, and case studies with channel-specific formatting and SEO recommendations. Use when writing any marketing content, when you need headli…	.codex/plugins/cache/claude-cowork/marketing/1.2.0/skills/draft-content/SKILL.md	Cached plugin skill; session activation not implied
email-sequence	Design and draft multi-email sequences with full copy, timing, branching logic, exit conditions, and performance benchmarks. Use when building onboarding, lead nurture, re-engagement, win-back, or product launch flows…	.codex/plugins/cache/claude-cowork/marketing/1.2.0/skills/email-sequence/SKILL.md	Cached plugin skill; session activation not implied
performance-report	Build a marketing performance report with key metrics, trend analysis, wins and misses, and prioritized optimization recommendations. Use when wrapping a campaign, when preparing weekly, monthly, or quarterly channel …	.codex/plugins/cache/claude-cowork/marketing/1.2.0/skills/performance-report/SKILL.md	Cached plugin skill; session activation not implied
seo-audit	Run a comprehensive SEO audit — keyword research, on-page analysis, content gaps, technical checks, and competitor comparison. Use when assessing a site's SEO health, when finding keyword opportunities and content gap…	.codex/plugins/cache/claude-cowork/marketing/1.2.0/skills/seo-audit/SKILL.md	Cached plugin skill; session activation not implied

Plugin cache · openai-bundled / sites2 skills

Name	Description	Source	Status
sites-building	Use Sites to build websites, including landing pages, portfolios, dashboards, portals, trackers, hubs, and internal tools. Always use Sites when the project contains `.openai/hosting.json`.	.codex/plugins/cache/openai-bundled/sites/0.1.70/skills/sites-building/SKILL.md	Cached plugin skill; session activation not implied
sites-hosting	Host websites with Sites. Use after `sites-building` to privately publish a Site created in this flow or for requested publishing or deployment, and for hosting management or projects containing `.openai/hosting.json`.	.codex/plugins/cache/openai-bundled/sites/0.1.70/skills/sites-hosting/SKILL.md	Cached plugin skill; session activation not implied

Plugin cache · openai-bundled / visualize1 skills

Name	Description	Source	Status
visualize	Create visualizations and interactive tools directly in conversation. Proactively use to show how something works; explore 'what happens when', 'what changes', or 'help me understand'; compare or inspect; create simul…	.codex/plugins/cache/openai-bundled/visualize/1.0.37/skills/visualize/SKILL.md	Cached plugin skill; session activation not implied

Plugin cache · openai-curated-remote / deep-research-work1 skills

Name	Description	Source	Status
deep-research	Use only when the user asks for deep research (or a clear equivalent), invokes $deep-research, or selects Deep Research in Work mode. Produce a comprehensive, cited artifact. Skip ordinary research requests.	.codex/plugins/cache/openai-curated-remote/deep-research-work/0.1.15/skills/deep-research/SKILL.md	Cached plugin skill; session activation not implied

Plugin cache · openai-curated-remote / openai-templates20 skills

Plugin cache · openai-curated-remote / plugin-management1 skills

Name	Description	Source	Status
plugin-management	Discover and suggest relevant plugins, inspect app permissions and dependencies, and manage plugin connections or removal. Use when the user asks about plugins or when a task would materially benefit from an external …	.codex/plugins/cache/openai-curated-remote/plugin-management/0.1.0/skills/plugin-management/SKILL.md	Cached plugin skill; session activation not implied

Plugin cache · openai-primary-runtime / documents1 skills

Name	Description	Source	Status
documents	Create, edit, redline, and comment on `.docx`, Word, and Google Docs-targeted document artifacts inside the container, with a strict render-and-verify workflow. Use `render_docx.py` to generate page PNGs (and optional…	.codex/plugins/cache/openai-primary-runtime/documents/26.909.11809/skills/documents/SKILL.md	Cached plugin skill; session activation not implied

Plugin cache · openai-primary-runtime / pdf1 skills

Name	Description	Source	Status
pdf	Read, create, inspect, render, and verify PDF files where visual layout matters, including fillable AcroForms. Use Poppler rendering plus Python tools such as reportlab, pdfplumber, and pypdf for generation and extrac…	.codex/plugins/cache/openai-primary-runtime/pdf/26.909.11809/skills/pdf/SKILL.md	Cached plugin skill; session activation not implied

Plugin cache · openai-primary-runtime / presentations1 skills

Name	Description	Source	Status
Presentations	Read, create or edit PowerPoint or Google Slides decks. Use for presentation, slide deck, PowerPoint, PPT, PPTX, or Google Slides requests.	.codex/plugins/cache/openai-primary-runtime/presentations/26.909.11809/skills/presentations/SKILL.md	Cached plugin skill; session activation not implied

Plugin cache · openai-primary-runtime / spreadsheets2 skills

Name	Description	Source	Status
excel-live-control	Control an open or active Microsoft Excel workbook through the ChatGPT add-in or connected session. Use when the user tags the Microsoft Excel app in Codex or follows up on an established live Excel task. Do not use f…	.codex/plugins/cache/openai-primary-runtime/spreadsheets/26.909.11809/skills/excel-live-control/SKILL.md	Cached plugin skill; session activation not implied
Spreadsheets	Use skill when user requests to create, modify, analyze, visualize, or work with spreadsheet files (`.xlsx`, `.xls`, `.csv`, `.tsv`) or Google Sheets with formulas, formatting, charts, tables, and recalculation. Do no…	.codex/plugins/cache/openai-primary-runtime/spreadsheets/26.909.11809/skills/spreadsheets/SKILL.md	Cached plugin skill; session activation not implied

Plugin cache · openai-primary-runtime / template-creator1 skills

Name	Description	Source	Status
template-creator	Create or update a reusable personal Codex artifact-template skill. Use when the user invokes $template-creator or asks in natural language to create a reusable template from a reference document, presentation, spread…	.codex/plugins/cache/openai-primary-runtime/template-creator/26.909.11809/skills/template-creator/SKILL.md	Cached plugin skill; session activation not implied

6 · Development and QA choicesExisting discipline + planned methods

The current technical loop is requirement → acceptance test → bounded plan → inspect existing work → isolated change → deterministic checks → risk-based review → authorized publication → separate release → readback and evidence.

Superpowers build loop

Documented choice · not found installed
Brainstorm, plan, test first, review and finish inside a coding session. Verify source, terms and compatibility before adapting it in the owning permanent area.

Osmani review methods

Documented choice · not found installed
Spec-driven development, security hardening, and API/interface design checklists. Planned for adaptation, not installation by this page.

Useful engineering discipline already stands independently: small scoped changes, repository-native checks, new migrations for schema changes, preserved history, proportional review and explicit evidence.

7 · Tools, connectors and accessConfigured is not tested

Capability	Observed state	Evidence boundary
Profile selector	Tested locally	Five loader, mapping, isolation and no-write tests recorded; selection only.
Codex support declaration	Configured	The existing manifest names Codex. It does not prove the intended server execution path.
Current app tools and accounts	Use when authorized	Availability and permissions belong to the current runtime. Profile selection grants nothing.
GitHub contribution	Not accepted for staged server Anvil	A checkout or repository reference is not authenticated read, write and publication evidence.
Supabase work records	Current Anvil path unverified	Shared storage may support work; failed access must not block ordinary development.
Supermemory recall and capture	Current automatic flow unverified	No claim of automatic saving, fresh-session recall or private isolation for the proposed release.
Other connectors	Runtime-specific	Each connector needs a named purpose, authorized scope and separate read/write/deny/revoke evidence.

No credential, secret-store location, private runtime binding or account identifier is shown here.

8 · Knowledge referencesCurrent and historical sources

Current Anvil profile, authoritative identity and behavior.
Existing profile manifest, configuration evidence only.
Profile selection skill, read-only conversation selection.
Decision 0030, independent agents and optional shared notes.
Decision 0032, owner-selected portable profiles.
Repository working rules, current contribution boundary.
How We Build, historical source whose technical loop is reusable but retired control hierarchy is not.
Earlier Anvil organization blueprint, historical proposal where its separate-development model is superseded by the final owner structure.

Knowledge Base material, old plans, books, videos, transcripts, kits and search results are ingredients only. They become active only through a reviewed change to the source that owns the rule or method.

9 · Private memory and continuityExisting boundary · proposed automatic flow

Existing profile rule

Conversations stay separate. Authorized project history may be retrieved when a working connection exists, then checked against current files and task status. Private notes stay separate from shared project work. Memory failure never blocks ordinary work.

Proposed complete flow

Session event → privacy classification and redaction → durable outbox → bounded extraction → canonical upsert → receipt → recall index.

Capture durable decisions, preferences, corrections, verified outcomes and reusable lessons, not full transcripts.
Bind private records to authenticated identity and scope, not a display name.
Use stable idempotency keys, retries, correction/supersession and deletion tombstones.
Keep secrets, credentials, raw private chats and queues outside Git.
Let current project and work records override stale recall; show conflicts instead of blending them.

This automatic flow is proposed and unverified for Anvil on Codex.

10 · Work state and continuityProposed contract

Information	Authority	Rule
Code, decisions and accepted methods	Versioned source	Reviewable history; no secrets or raw chats.
Current task, owner, status, dependencies, result and next action	Durable structured work record	One current record with history, receipts and conflict-safe updates.
Relevant summaries, preferences, corrections and lessons	Shared or Anvil-private recall by classification	Provenance, timestamps, scope and supersession required.

Concurrent sessions keep separate conversation buffers. Revision checks or leases must surface conflicts rather than silently overwrite work.

11 · Learning, feedback and correctionsProposed governed lifecycle

Observation → linked evidence → candidate lesson → proposed change → bounded evaluation → review → accepted canonical update or rejected record → release.

Owner feedback can correct the current task immediately when safe; a durable rule still needs reusable evidence.
Mistakes record cause, impact, correction and a regression test, without blame or irrelevant conversation.
Successful methods need repeatable evidence; one good result is not a standard.
Proposals remain inactive until the one owning source changes, tests pass and a release is made.
Rejected and superseded ideas remain traceable but stay out of startup and default recall.

12 · Platform adaptersCodex first · Claude later

Layer	Responsibility	Status
Portable Anvil source	One identity, role, boundaries, referenced methods and capability schema.	Current profile remains authoritative
Codex adapter	Native startup, skill discovery, tool bindings, memory receipts and acceptance driver.	Proposed server stage · not active
Claude adapter	Thin runtime-specific entry point over the accepted source; no copied editable identity.	Later, after Codex acceptance

Authentication, hooks, tools, capture and model behavior must be tested separately per platform. Codex evidence cannot certify Claude.

13 · Acceptance testsProposed · not run by this page

Server Codex baseline

A01 Natural start	Natural Anvil wording selects the same canonical identity.
A02 Binding	Displayed identity matches authenticated backend scope; forged names grant nothing.
A03 Project	Fresh session selects the correct company, project and current source.
A04 Concurrency	Sessions have separate transient context without silent overwrite.
A05 Skill	A minimum skill is discovered, invoked and its output accepted.
A06 Access	Authorized repository work succeeds; unauthorized scopes are denied.
A07 Development loop	A reversible change passes tests, review and authorized publication with a receipt.

Automatic memory

M01–M03	Automatic capture, fresh-session recall and same-record correction.
M04–M06	Duplicate delivery, outage retry and crash recovery without duplication.
M07–M08	Private-scope denial and seeded-secret rejection.
M09–M11	Current-state precedence, deletion tombstones and concurrent-update conflict handling.

Release and cross-platform

R01 proves rollback to the last good release without identity, work-state or memory loss. Claude repeats every adapter-sensitive baseline, memory and rollback test after Codex is accepted.

14 · Release, activation and open gapsNothing activated here

Superseded · inactive Earlier separate Agents staging does not represent the final company structure. It has no remote or activation, does not replace the current profile, and creates no Dev-to-live-home migration.

Keep the existing Anvil profile authoritative while the permanent Agents component is physically resolved.
Develop each Anvil change in Agents using a branch or isolated working copy and label it draft or in development.
Prove server Codex identity, project selection, native skills, access and checked Git contribution.
Prove automatic memory, privacy, correction, retry and recovery through OS services.
Activate an exact tested version through the Agents release path, then verify readback, monitoring and rollback before marking it live.
Only then adapt and independently test Claude against the same accepted definition.

Current release claim: no new Anvil runtime, server stage, memory system, connector, live-home repository or adapter was created or activated. “Working” is reserved for a tested release activated in its intended environment with current monitoring and recovery evidence.

This page deliberately omits credentials, system or developer prompts, private memory and chats, secrets, protected runtime configuration and live queues. It summarizes public owner-authored profile text, current decisions, bounded filesystem discovery and the final approved logical architecture.

Name	Description	Source	Status
artifact-template-analytics-dashboard	Create a spreadsheet using the Analytics Dashboard template and its retained reference file. Use when the user selects or names Analytics Dashboard. Monitor acquisition, engagement, retention, revenue, and conversion …	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-analytics-dashboard/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-business-review	Create a presentation using the Business Review template and its retained reference file. Use when the user selects or names Business Review. Review business performance, KPIs, segment results, strategic priorities, d…	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-business-review/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-design-report	Create a document using the Design Report template and its retained reference file. Use when the user selects or names Design Report. Produce design reports with an executive summary, key findings, implications, recom…	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-design-report/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-experiment-analysis	Create a document using the Experiment Analysis template and its retained reference file. Use when the user selects or names Experiment Analysis. Analyze experiments with hypotheses, methodology, results, interpretati…	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-experiment-analysis/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-financial-budget	Create a spreadsheet using the Financial Budget template and its retained reference file. Use when the user selects or names Financial Budget. Model actuals, budget and scenario forecasts, variances, cash runway, and …	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-financial-budget/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-investment-committee-memo	Create a document using the Investment Committee Memo template and its retained reference file. Use when the user selects or names Investment Committee Memo. Prepare investment committee memos with the thesis, transac…	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-investment-committee-memo/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-legal-memorandum	Create a document using the Legal Memorandum template and its retained reference file. Use when the user selects or names Legal Memorandum. Draft legal memoranda with the issue, brief answer, relevant facts, analysis,…	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-legal-memorandum/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-market-trends-report	Create a presentation using the Market Trends Report template and its retained reference file. Use when the user selects or names Market Trends Report. Communicate market or industry trends, supporting evidence, impli…	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-market-trends-report/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-minimal-letterhead	Create a document using the Minimal Letterhead template and its retained reference file. Use when the user selects or names Minimal Letterhead. Write professional business letters with sender, recipient, message, and …	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-minimal-letterhead/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-operating-calendar	Create a spreadsheet using the Operating Calendar template and its retained reference file. Use when the user selects or names Operating Calendar. Plan annual and monthly operating milestones, campaigns, launches, dea…	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-operating-calendar/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-operating-review	Create a presentation using the Operating Review template and its retained reference file. Use when the user selects or names Operating Review. Run weekly operating reviews with scorecards, functional updates, risks, …	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-operating-review/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-project-kickoff	Create a presentation using the Project Kickoff template and its retained reference file. Use when the user selects or names Project Kickoff. Align teams on project goals, scope, roles, milestones, risks, and the work…	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-project-kickoff/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-project-tracker	Create a spreadsheet using the Project Tracker template and its retained reference file. Use when the user selects or names Project Tracker. Manage workstreams, tasks, owners, status, priority, dates, launch pulse, an…	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-project-tracker/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-sales-pipeline	Create a spreadsheet using the Sales Pipeline template and its retained reference file. Use when the user selects or names Sales Pipeline. Track opportunities, stages, owners, deal sizes, probabilities, forecasts, nex…	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-sales-pipeline/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-simple-dark-mode	Create a presentation using the Simple Dark Mode template and its retained reference file. Use when the user selects or names Simple Dark Mode. Create clean dark-mode presentations with bold typography, simple section…	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-simple-dark-mode/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-simple-light-mode	Create a presentation using the Simple Light Mode template and its retained reference file. Use when the user selects or names Simple Light Mode. Create clean light-mode presentations with spacious typography, simple …	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-simple-light-mode/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-strategy-memorandum	Create a document using the Strategy Memorandum template and its retained reference file. Use when the user selects or names Strategy Memorandum. Present strategic context, choices, rationale, risks, milestones, and a…	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-strategy-memorandum/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-system-design	Create a document using the System Design template and its retained reference file. Use when the user selects or names System Design. Document system architecture, requirements, components, data flows, APIs, tradeoffs…	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-system-design/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-team-alignment	Create a presentation using the Team Alignment template and its retained reference file. Use when the user selects or names Team Alignment. Facilitate team offsites and planning with context, goals, priorities, decisi…	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-team-alignment/SKILL.md	Cached plugin skill; session activation not implied
artifact-template-three-statement-forecast	Create a spreadsheet using the Three-Statement Forecast template and its retained reference file. Use when the user selects or names Three-Statement Forecast. Build an integrated income statement, balance sheet, and c…	.codex/plugins/cache/openai-curated-remote/openai-templates/0.1.1/skills/artifact-template-three-statement-forecast/SKILL.md	Cached plugin skill; session activation not implied