The hard part
The problems worth being honest about
Letting software act on a real business is genuinely hard, and we'd rather show the seams than hide them. None of these are solved by a bigger model — they're solved by the layer around it, and that layer is the actual work of the lab.
PROBLEM 01 · LIVELiveMoving a live business off Firestore — with zero downtime
The hard part
You can't take a multi-tenant SaaS offline to swap its database. Around 37 collections of live customer data had to move from Firestore to Aurora Postgres while the app kept reading and writing every second — with no moment where a write lands in the old store and a read hits the new one.
Our approach
Migrated wave by wave behind one signed bridge, kept the old listeners only as an on-error fallback during each cutover, then verified row counts and checksums identical across dev, staging, and prod before retiring the old path.
docs/unified-data-spine/full-aws-execution-plan.mdPROBLEM 02 · LIVELiveTenant isolation enforced by the database, not the app
The hard part
In a shared database, one missed org_id filter is a cross-customer leak — and every new query is a fresh chance to forget it. The isolation has to hold even against a bug, and survive a connection reused across tenants.
Our approach
Every tenant-scoped table runs Postgres FORCE ROW LEVEL SECURITY. All access goes through a transaction that sets a transaction-local org id, so the database — not the application code — refuses any row from another tenant.
infra/lambda/shared/db.tsPROBLEM 03 · LIVELiveReal-time updates without a database that pushes
The hard part
Firestore gave live updates for free; Aurora does not push. The naive replacement — write the row, then publish an event — risks the classic dual-write failure: the publish is lost or the transaction rolls back, and one client's screen silently disagrees with the database.
Our approach
The write and a domain-event row commit in the same transaction; a worker drains that transactional outbox to AppSync subscriptions with per-consumer idempotency and retry — so an event lands exactly where it should, even if a step fails mid-flight.
functions/db/migrations/0027_foundation_outbox_messages.sqlPROBLEM 04 · IN PROGRESSIn progressAgents that act on the real system — with receipts
The hard part
An assistant that only talks is safe but limited; one that can start a campaign, move a deal, or send money is dangerous the moment it is wrong or manipulated. The hard part is letting an agent reach the same real action handlers a human clicks, while it can never do something the asking user could not.
Our approach
Agents only re-enter the existing action handlers as the resolved requester — never the database directly — through a gate where reads run inline, low-risk writes follow the workspace autonomy setting, and high-risk actions become a human approval card. Every run leaves an attributable receipt.
infra/lambda/kernel/native-tools.tsPROBLEM 05 · IN PROGRESSIn progressShared AI memory that never leaks need-to-know data
The hard part
A company memory is only safe if a junior's agent can't extract a finance secret a summary happened to absorb. Filtering results after the fact still leaks through ranking and counts; a cross-scope summary can carry a secret its reader can't access the source of.
Our approach
Memory carries no access list of its own — each record inherits its source’s scope, the permission filter runs inside the SQL search rather than after it, and derived memory inherits the strictest of its inputs. A standing red-team probe proves a low-scope requester reaches no high-scope record.
infra/lambda/kernel/scopes.tsPROBLEM 06 · IN PROGRESSIn progressOne platform that fits many trades — without forking
The hard part
A marketing agency's project is a cabinet shop's job is a consultancy's engagement. Hard-code one schema and the product fits one vertical and fights every other one.
Our approach
Every org boots on a base ontology pack, then layers capability and per-industry overlay packs validated at load — so a vertical is data, an overlay over the same engine, not a fork of the platform.
infra/lambda/ontology-packs.tsPROBLEM 07 · LIVELiveA signed gateway that can't be spoofed or replayed
The hard part
Splitting the system across Firebase for auth and AWS for data creates a trust seam: every request crossing it must be provably from the real bridge — not forged, replayed later, or altered in transit.
Our approach
Every call carries an HMAC signature over its timestamp, method, and exact body, verified with a constant-time compare and a five-minute freshness window — so a captured request cannot be replayed.
infra/lambda/shared/bridge-auth.ts 
