Data model and architecture

Technical notes on how the product stores data, links nested records, and validates writes.

This guide explains how Brandow Storage stores and validates data under the hood.

It is useful for technical operators, integration planning, and contributors.

Terminology bridge

These invariants are important for consistency and long-term performance.

Flat Row data keeps core operations predictable:

When data needs hierarchy or relational structure:

Do not put nested user objects inside records.data.

Before writing a Row:

This pattern prevents malformed data from bypassing app rules.

Schema definitions are cached for speed. When a Table structure changes:

Without invalidation, stale validation behavior can occur.

Brandow Storage uses company-scoped access boundaries:

AI routes should be designed with bounded context:

For production reliability:

Core data invariants

Row payloads are stored as flat JSON (records.data).

Nested structures are represented by linked records, not nested JSON blobs.

Row validation runs through the schema layer before writes.

Server/client Supabase usage remains separated by runtime boundary.

These invariants are important for consistency and long-term performance.