Database is source of truth
Pandora will treat its own Supabase Postgres database as durable memory, not ChatGPT built-in memory.
Pandora foundation
A memory operating system shell, not a memory engine yet.
Pandora Memory Engine is being built to manage real-life and AU/story continuity with strict namespace isolation, durable database-backed memory, and auditable changes. The current app is foundation-only.
Current status
The shell is intentionally honest about what exists.
ImplementedFoundation app, documentation, and migration workflow are present.
PlannedMemory storage, search, AU continuity, OpenAI calls, GPT Actions, and MCP are not implemented.
No live data
No memory records are displayed.
This landing page does not show fake counts, fake AU worlds, fake people, fake risks, fake promises, or fake audit activity. Future pages must connect to real implemented services before showing live data.
Operating principles
These rules shape the UI before the backend memory engine exists.
Namespace isolation
Real-life and AU/story memory must remain separated in every future query, write, and UI state.
No fake memory data
Foundation UI must not invent people, worlds, relationships, promises, risks, deals, scenes, metrics, or audit logs.
Append-only memory changes
Memory patch writes go through an internal create-only service and still expose no public routes.
User-owned RLS boundary
The database policy layer now has an owner boundary; service-layer validation remains separate.
Typed table boundaries
Table names and namespace expectations are now represented in reusable TypeScript helpers.
Repository service boundary
Service helpers prepare owner-bound records from authenticated context before future database operations.
Core repository guardrails
Core repositories filter by owner and namespace, and still expose no public memory API surface.
Memory validator guardrails
Memory candidates are checked for namespace, type, source, and patch safety before any future persistence path.
Internal candidate service boundary
Candidate services are internal-only and do not expose public ingest or patch routes.
Internal logging boundary
Logging services are internal-only and write through owner-bound repositories without exposing public routes.
Internal patch boundary
Patch services validate patch candidates and write audit rows without exposing mutation routes.
Internal retrieval boundary
Retrieval services use owner and namespace repository filters and do not expose public search routes.
Transaction and idempotency boundary
Mutation routes must later use real transaction behavior and persistent idempotency before exposure.
Internal mutation safety boundary
Internal mutation wrappers now check idempotency before writes and record outcomes, but no public mutation route exists.
Idempotency RPC boundary
Database function helpers coordinate idempotent claim and finish records, but no memory mutation is public yet.