So the product is legible before anyone has entered real data, and so Piggy
has something to reason about while it is being built.
Kept separate from the base seed because that one is publicly-sourced and cited
while this is invented. Two rules, both deliberate:
Every record is prefixed "DEMO — ", so a screenshot can never be mistaken for
real business. And demand-side customers are fictional. Suppliers are real
companies — they are public, and naming the actual market is the point — but
inventing customers with invented contract values against real named businesses
would be fabricating commercial records about them, which is a different thing
and not worth the extra realism.
The numbers are tuned to teach rather than to flatter. The book clears +5.4% at
79% utilisation, which is thin and about right for this industry once capacity
cost is charged honestly. Underneath, the blocks disagree: the large H200 block
carries it, the EU H100 block is underwater at 55% sold because a 46% markup
needs ~69% sold to break even, and the community pool holds a large unconverted
hold — so the difference between "sold" and "held" is visible rather than
theoretical.
An earlier tuning left the whole book at -26%. Honest, but it reads as a broken
product rather than an under-utilised book, so the totals now open healthy and
the problems appear on drill-down.
Also exercises parts of the schema nothing had touched yet: ramped capacity
shapes, negotiated SLAs with fee abatement and spare-pool scope, renewal
obligations with one deliberately near-term, EU data-residency constraints on a
capacity request, and internal research burn.
Two bugs found while testing it, both the same trap as before: the research
allocation duplicated on every run because onConflictDoNothing() is a no-op
without a matching unique constraint, and notes were double-prefixed. Verified
idempotent over three consecutive runs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
karti