← Skills
THE IDEA
Teaches an AI the decision behind adding Arkiv to a web2 app: which records belong on Arkiv (public, verifiable, queryable), which stay in Postgres (private, hot, joined), and how to model the ones you move.
The problem today
- The instinct is to copy whole tables — but Arkiv has no joins and no server ORDER BY, so that produces data you can't query.
- Most data should NOT move: private rows, hot transactional paths, anything heavily joined.
- The only official migration guide is Kaolin→Braga (testnet rotation), not web2→Arkiv.
What it would do
- A decision rule: mirror records that are public + verifiable + queried by attributes; keep the rest in your DB.
- Modeling for the lane: denormalize, foreign keys→attributes, join tables→edge entities, pick a TTL per record type.
- How to wire a simple outbox so the mirror stays in sync without becoming your system of record.
WHY IT’S A BETTER EXPERIENCE
- The agent proposes a queryable, additive design on the first try — not a broken table dump.
- Honest about the boundary: Arkiv complements your database, it doesn't replace it.
FEASIBILITY — AND WHY THIS ISN’T HAND-WAVING
Medium to build
Knowledge skill (no code). Distinct from greenfield data-modeling: this is the mirror-vs-keep decision. The arkiv-migration tool automates the mechanics later.
Grounded in
- Research frame: "sync selected verifiable records, do NOT replace Postgres."
- No-joins / no-ORDER-BY constraints verified against the SDK + PR #70 — they drive every rule here.
- Distinct from the existing data-modeling skill, which covers greenfield entity design.
PAIRS WITH