A database-first playbook for building auditable, multi-tenant B2B AI

A hackathon project, FarmOps Desk, provides a detailed schema for treating AI governance as a database primitive. The approach moves auditability and tenant safety from the application layer into the schema itself.

Most AI applications are stateless wrappers around a model API, a design that fails for B2B SaaS products where actions must be auditable and tenant data strictly segregated. For a tool writing financial records or medical notes, application-layer safety checks are insufficient. A bug or a hallucination could bypass them, leading to data corruption or cross-tenant leakage.

One founder, writing under the handle 'captjay98', detailed an alternative architecture for a hackathon project called FarmOps Desk. The project's thesis is to treat AI governance as a database primitive. The database schema enforces the rules, making catastrophic failures less likely even if the application code has a bug. This approach is documented in a blog post and a public GitHub repository, providing a clear blueprint for building high-stakes, auditable AI systems.

Governance as a database primitive

The core of the FarmOps Desk architecture is a set of eight tables designed to log every significant AI action and enforce business logic. The founder argues that if the database schema itself prevents unacceptable outcomes, the application becomes a thin, less critical layer. Every table carries a farm_id to enforce tenant boundaries at the row level.

The central tables in the schema include:

• ai_runs: An index of every model invocation, logging the feature, model used, tokens, and latency.
• credit_ledger: An append-only ledger for credit transactions. A database-level CHECK constraint ensures a customer's balance can never go below zero.
• assistant_drafts: A holding area for any record the AI wants to create or modify. These writes are held in a pending state until a user confirms or discards them, creating a human-in-the-loop workflow.
• embeddings: A per-farm RAG index using pgvector for documents and conversation summaries, ensuring retrieval is always scoped to a single tenant.

Other tables track non-mutating recommendations, rule-based evaluations of AI output, user feedback, and durable facts for the AI to remember about a specific farm.

Solving concurrency with atomic credit reservation

The founder identifies a classic race condition common in serverless AI applications. Two concurrent requests for a user with a single credit remaining could both read the balance, both proceed to call the model, and both attempt to deduct a credit, resulting in a negative balance. This is a time-of-check to time-of-use (TOCTOU) bug.

While a simple database lock like SELECT ... FOR UPDATE can solve this, the post suggests a more robust pattern of atomic credit reservation. The goal is to reserve the credit and associate it with a specific AI run in a single, atomic transaction before the expensive model invocation occurs. This prevents the race condition without complex application-level locking, ensuring the credit_ledger remains the single source of financial truth.

What We'd Change

This architecture is presented in the context of a hackathon project, not a production system that has operated at scale. The primary risk is over-engineering for an early-stage product. The complexity of maintaining this eight-table schema, with its relational constraints and append-only ledgers, introduces significant overhead. For many SaaS products, a simpler logging mechanism is sufficient for an MVP.

The playbook is best suited for specific high-stakes verticals like finance, legal tech, or healthcare, where a complete, verifiable audit trail is a core product requirement, not a feature. In these domains, the architectural overhead is justified as a risk mitigation and a competitive differentiator. For a general-purpose AI writing assistant, this level of database-native governance would likely slow down development and increase infrastructure costs for little customer-facing benefit.

Finally, while pgvector is a capable extension, a dedicated vector database might offer better performance and scalability for the RAG component as document volume grows. The trade-off is between the transactional integrity of keeping all data in a single relational database versus the specialized performance of a purpose-built vector store.

Landing

The FarmOps Desk architecture provides a clear playbook for a specific class of AI product. It shifts the design paradigm from treating the AI as an external utility to integrating it as a core, governed process within the database. This approach prioritizes correctness, auditability, and safety over raw development speed. For founders building in regulated or high-trust industries, embedding governance directly into the data layer is not just a technical choice. It is a foundational product decision that builds a defensible moat against competitors who treat safety as an afterthought.

The investor read

This architecture signals a maturing market for B2B AI applications. While first-generation tools competed on features, the next wave will compete on trust, auditability, and enterprise-readiness. This database-centric governance model is precisely what enterprise compliance and security teams look for, de-risking the 'black box' nature of AI. An investor sees this as a technical moat. A generic AI wrapper is a commodity; an AI system with auditable, database-enforced governance for a regulated vertical like fintech or healthtech is defensible. The specific hackathon project, FarmOps Desk, is not investable. However, a founder applying this architectural discipline to a validated market need would be highly credible. The pattern is the asset, not this particular implementation.