ampersand-supabase — ARCHIVED

Archived by decision on 2026-07-30. Archived, not failed — and not yet retired.

Until 2026-08-15 nothing in this directory said so. ARCHITECTURE.md still opens with "Status: Implementation-ready" and a date of 2026-03-28, which was true when it was written and has been wrong for six weeks. This file exists so that opening the directory tells you what opening the directory should tell you.

What it is

One Supabase instance serving the whole [&] Protocol ecosystem, each product in its own PostgreSQL schema. Measured in this tree on 2026-08-15: 40 `.sql` migrations across 10 schemas — agentelic, amp, fleet, geo, govern, kag, orchestrate, rune, temporal, webhost.

Several documents in the portfolio say "35 migrations across 11 schemas." That number came from a JSON example in workbench/docs/spec/README.md and was copied onward without being re-derived. The count above is from ls ampersand-supabase/migrations/*.sql and grep -hoE 'create schema if not exists [a-z_]+'. Re-run those rather than trusting either number.

Why it was abandoned

Postgres stores a row but not why the row is that row, and nothing in the migration layer could refuse a row whose provenance did not check out. The stack's central claim — that a divergence is refusable rather than silent — stopped at the database boundary. It was also a dependency the stack does not control.

The replacement is `studbook` (studbook/docs/spec/README.md), which is a draft spec with no implementation. Its §7 and §10 have not been ruled. Do not build from it yet.

Why it is still here, and still running

Nothing migrates off this until studbook can hold the same data with the same guarantees (studbook §9). Concretely, today:

• fleet.* still serves KILN and FleetPrompt.

• kag.* has been orphaned since the BendScript pivot.

• The migrations still apply and the code written against them still runs.

studbook is blocked on one unruled question — where confidentiality comes from (studbook §10.2). Content addressing is hostile to access control: if the key is the hash of the content, knowing the content is knowing the key. Until that is answered studbook cannot hold anything with a user in it, so it is not yet a replacement for what WebHost.Systems and FleetPrompt use Supabase Auth and RLS for. See CONFIDENTIALITY.md and THREAT_MODEL.md in the repository root.

If you are an agent

• Do not build new products against this. New data-layer work waits on studbook.

• Do not tear it down either. It is load-bearing for two live products.

• A docs/spec/ document specifying Supabase tables, RLS or amp.profiles auth is describing this

route. Several now carry a supersession banner saying so.

• Products that never used it at all: Graphonomous (embedded SQLite), Deliberatic (in-memory),

OpenSentience (ETS).

Provenance