Scaffold PIG and model the compute-GTM ontology
PIG is an agent-native CRM for two-sided AI-compute companies: businesses that buy GPU capacity from providers and resell it. Their business is the spread between two pipelines, which is precisely what a generic CRM cannot represent. The load-bearing decision is the `allocations` table, joining a capacity_commitment (what we bought, at a known cost) to a demand_deal (what we sold, at a known price). Margin, utilisation and idle capacity all fall out of that one join. Cost is charged against the full commitment rather than only the hours that sold, because unsold hours are already paid for and any other treatment flatters a block that is losing money. Domain decisions worth noting, each grounded in how this market operates: - Demand stages put `legal` second, not last. Customers do not hand workloads to an infrastructure provider before paper is executed. - Supply qualification splits technical from financial diligence, recorded attributably. Accepting capacity is a two-key decision. - Capacity carries a time SHAPE (intervals + quantities), not a window. Commitments ramp and step down; a rectangle reports availability that does not exist in the month someone wants it. - SLAs model three distinct shapes: none, a reliability tier plus credits policy, and a negotiated agreement. Aggregators generally cannot promise uptime on resold capacity, but negotiate heavyweight paper upstream. Remedies include fee abatement, which is materially better than a capped credit and is not expressible as one. - Export control is a predicate on the allocation edge, evaluated against the ULTIMATE parent's jurisdiction. Country of incorporation is not a valid key, so this cannot live as a flag on an account. - Agent-derived claims land in `facts` with a confidence band and evidence. Only verified claims self-apply; weaker ones await review. - The API never calls the agent. It writes to a leased queue, guarded by a partial unique index on unfinished work. Verified: typechecks clean, migration generates and applies to Postgres 16 (31 tables, 24 enums, 117 indexes). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,179 @@
|
||||
<div align="center">
|
||||
|
||||
# 🐷 PIG — Prime Intellect Growth
|
||||
|
||||
**An open-source, agent-native CRM for two-sided AI-compute companies.**
|
||||
|
||||
[](./LICENSE)
|
||||
|
||||
*Self-hostable. Auditable. Built for teams that buy compute on one side and sell it on the other.*
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## Why this exists
|
||||
|
||||
A company that aggregates GPU capacity and resells it does not run one pipeline.
|
||||
It runs two, and its business is the spread between them.
|
||||
|
||||
Generic CRMs — Salesforce, HubSpot, Attio — model a single pipeline of deals
|
||||
against companies. They have no concept of **inventory**, no concept of a
|
||||
**commitment you already bought and are paying for**, and therefore no way to
|
||||
answer the question the business actually turns on:
|
||||
|
||||
> Which contracted capacity is sold, to whom, at what margin — and what is idle
|
||||
> right now?
|
||||
|
||||
PIG is built around that question. One table, [`allocations`](./packages/db/src/schema/allocations.ts),
|
||||
joins a `capacity_commitment` (what you bought from a provider) to a
|
||||
`demand_deal` (what you sold to a customer). Revenue minus cost is margin per
|
||||
GPU-hour. Committed capacity with no allocation is money burning. Everything
|
||||
else in PIG is ordinary CRM plumbing that exists to keep that ledger honest.
|
||||
|
||||
## Who it's for
|
||||
|
||||
PIG models three teams, because two-sided compute companies have three
|
||||
constituencies competing for the same scarce capacity:
|
||||
|
||||
| Team | Job to be done |
|
||||
|---|---|
|
||||
| **Supply** | Source, qualify, price, and contract GPU capacity from providers |
|
||||
| **Demand** | Sell compute and post-training; renew and expand accounts |
|
||||
| **Research** | Consume capacity internally — real burn, no revenue |
|
||||
|
||||
Research is a first-class tenant rather than an afterthought. Internal research
|
||||
burn competes with revenue for the same GPUs, and margin math that cannot see it
|
||||
is wrong.
|
||||
|
||||
The team set is configurable. PIG ships with these three because they match the
|
||||
structure of the company it was designed for, not because they are universal.
|
||||
|
||||
## Agent-native, not agent-decorated
|
||||
|
||||
PIG is a first-class application for agents *and* for humans, and neither is a
|
||||
degraded view of the other.
|
||||
|
||||
- **An MCP server** ([`apps/mcp`](./apps/mcp)) exposes the CRM over both stdio
|
||||
and Streamable HTTP. Any MCP client connects: **Claude Code**, **Codex**,
|
||||
**[prime-agent](https://github.com/PrimeIntellect-ai/prime-agent)**, or a
|
||||
**[Buzz](https://github.com/block/buzz)** workspace agent via its ACP bridge.
|
||||
Each team member points their own agent at PIG and works from the terminal.
|
||||
- **Piggy**, the in-app agent, drains a leased database queue rather than being
|
||||
called over HTTP — so work survives the agent being down, and every action it
|
||||
takes is recorded with an idempotency key.
|
||||
- **Every agent-derived fact carries evidence.** Enrichment writes to a `facts`
|
||||
table with a confidence score, a band (verified / probable / possible), a
|
||||
source URL, and a status. Strong signals apply automatically; weak ones become
|
||||
proposals a human approves. A CRM that lets an agent write unattributed claims
|
||||
into the record is a hallucination store, not a database.
|
||||
|
||||
### The architectural rule
|
||||
|
||||
> **Intelligence never lives in the API.**
|
||||
|
||||
The API does HTTP, auth, validation, and sync. All research, enrichment,
|
||||
scoring, and identity matching lives in the agent. They communicate through a
|
||||
table, never a direct call. This separation is borrowed from
|
||||
[Comp AI CRM](https://github.com/trycompai/crm) and it is the single most
|
||||
load-bearing decision in the codebase.
|
||||
|
||||
## What makes it compute-native
|
||||
|
||||
- **`inventory_listings`** mirrors the Prime Intellect availability API
|
||||
field-for-field — `gpuType`, `socket`, `interconnectType`, `stockStatus`,
|
||||
`security` (secure vs community cloud), `prices.onDemand`, `provisioningTime`.
|
||||
Sync is a straight mapping, not an ETL project.
|
||||
- **`capacity_commitments`** records what you bought: term, GPU-hours,
|
||||
cost per GPU-hour, floor and ceiling.
|
||||
- **`contracts`** is polymorphic over party and type — MSA, DPA, SLA, order
|
||||
form, capacity commitment — because the supply side negotiates heavyweight
|
||||
paper while the self-serve demand side runs on a reliability tier and a
|
||||
credits policy instead of a signed uptime guarantee.
|
||||
- **Two real pipelines**, with stages taken from how this market actually
|
||||
operates rather than invented:
|
||||
|
||||
```
|
||||
Demand: qualification → legal → scoping → proposal → procurement
|
||||
→ POC → deployment → expansion
|
||||
|
||||
Supply: sourced → qualifying → technical diligence → financial diligence
|
||||
→ pricing → contracting → onboarding → live → renewal
|
||||
```
|
||||
|
||||
Note that **legal sits second** in the demand pipeline. MSA and DPA execution
|
||||
gates the deal rather than closing it. Most CRMs put contracts at the end and
|
||||
are wrong about it for this market.
|
||||
|
||||
## Stack
|
||||
|
||||
| Layer | Choice |
|
||||
|---|---|
|
||||
| Web | React + Vite + TypeScript, Tailwind, shadcn/ui, light + dark |
|
||||
| API | Hono + tRPC on Node 22+ |
|
||||
| Database | PostgreSQL 16, Drizzle ORM |
|
||||
| Auth | Supabase (JWT verification only — PIG stores no passwords) |
|
||||
| Agent | Piggy — a worker draining a leased task queue |
|
||||
| MCP | `@modelcontextprotocol/sdk` — stdio + Streamable HTTP |
|
||||
| Deploy | Docker Compose behind any reverse proxy |
|
||||
|
||||
Authorization comes from PIG's own `users` table, never from the mere existence
|
||||
of an auth account. An identity provider that PIG shares with another
|
||||
application must not grant access here.
|
||||
|
||||
## Quick start
|
||||
|
||||
```bash
|
||||
git clone <this-repo> pig && cd pig
|
||||
npm install
|
||||
cp .env.example .env # then edit it
|
||||
npm run db:migrate
|
||||
npm run db:seed # optional — public, sourced, confidence-graded
|
||||
npm run dev:api # :8920
|
||||
npm run dev:web # :5173
|
||||
```
|
||||
|
||||
Connect an agent:
|
||||
|
||||
```bash
|
||||
claude mcp add pig -- npx -y @pig/mcp # stdio
|
||||
# or point any MCP client at https://<your-host>/mcp
|
||||
```
|
||||
|
||||
## Repository layout
|
||||
|
||||
```
|
||||
apps/
|
||||
web/ React + Vite front end
|
||||
api/ Hono + tRPC API, Supabase JWT verification
|
||||
mcp/ MCP server — stdio and Streamable HTTP
|
||||
packages/
|
||||
db/ Drizzle schema, migrations, seed
|
||||
core/ Shared domain types and the ontology
|
||||
prime/ Typed client for the Prime Intellect compute API
|
||||
docs/ Ontology, deployment, seed-data provenance
|
||||
deploy/ Compose files and reverse-proxy snippets
|
||||
```
|
||||
|
||||
## Documentation
|
||||
|
||||
- [Ontology](./docs/ontology.md) — the domain model, and why it is shaped this way
|
||||
- [Seed data provenance](./docs/seed-data.md) — every claim, graded and cited
|
||||
- [Agent integration](./docs/agents.md) — Claude Code, Codex, prime-agent, Buzz
|
||||
- [Deployment](./docs/deploy.md) — self-hosting
|
||||
|
||||
## A note on seed data
|
||||
|
||||
PIG ships with a roster of publicly documented people so the application is
|
||||
legible on first run. Every record carries a confidence grade and a source URL.
|
||||
**No email addresses are included or inferred.** Records that could not be
|
||||
independently sourced are marked as such rather than quietly presented as fact,
|
||||
and people who are demonstrably *not* staff — alumni, residency participants —
|
||||
are labelled accordingly. See [docs/seed-data.md](./docs/seed-data.md).
|
||||
|
||||
If you are seeded here and would rather not be, open an issue and it will be
|
||||
removed.
|
||||
|
||||
## Licence
|
||||
|
||||
Apache License 2.0 — see [LICENSE](./LICENSE) and [NOTICE](./NOTICE).
|
||||
Reference in New Issue
Block a user