The system manifest, in brief

The promise

Your investment philosophy. A portfolio management desk built around it. Conversation and direct editing let a person research, construct, refine, compare, personalize, monitor, review and explain portfolios. The synthetic desk underneath coordinates specialist analysis and application-owned financial tools. The database, not the conversation, is the source of state.

The experience scales through scope, not through separate products: one exploratory portfolio, one account, one advisor’s book, a multi-advisor firm. The same engine serves each; institutional controls and language stay hidden until the scope needs them.

The complete investment loop

Describe intent, inspect the interpretation, propose an allocation, calculate and compare, accept a version, assign and personalize, monitor actual observations, review a case, document a decision, report; and, later and separately gated, authorize and reconcile implementation.

“Vibe code” describes the interaction. It does not mean running arbitrary generated code, guaranteeing returns, inferring suitability from age, or trading through a chat completion. Responsiveness is an interface property; real-time market data is a separate licensed capability.

Reading map

Start with 00 for the operating instructions and 16 for the release map. Sections 01–15 define the system. Phases P00–P11 give the ordered build steps. Sections 17–21 cover acceptance, traceability, change control and sources.

1. 00Authority and coding-agent operating instructionsWhat the document governs, how MUST, SHOULD and LATER read, and the global definition of done.
2. 01Product mandate, users and release boundariesThe promise, the complete investment loop, the initial supported product and each release definition.
3. 02Experience systemFive destinations, one investment workspace; the scope bar, the assistant drawer, the Using strip and the required states.
4. 03Signature journeys and product invariantsExplore and refine, personalize against an account, manage the book, adapt through research, review and explain.
5. 04Technical stack and deployment boundariesOne monorepo, a modular Python backend, Vercel, Railway, Supabase and Inngest, and what is deliberately not used.
6. 05Repository, contract ownership and service interfacesThe repository baseline and the interface groups every module builds against.
7. 06Canonical domain and lifecycle modelPortfolios, versions, assignments and the rules that keep publication and assignment separate.
8. 06AMinimum typed contract fieldsThe fields every typed proposal, run and result must carry.
9. 07Durable work, streaming, concurrency and cachingRequest-to-result sequence, resumable progress, revision fencing and reuse.
10. 08Market data and deterministic portfolio analyticsThe numerical contract for weights, returns, risk and coverage.
11. 09Policy compiler and asset-class preferencesHow a philosophy, a policy and an implementation list compose into a typed proposal.
12. 10Memory, research and evidence governanceThe memory taxonomy, the research workspace and how sources are retrieved and cited.
13. 11Synthetic analyst desk and model gatewayThree separate authorities, routing levels and the one gateway all model calls pass through.
14. 12Clients, positions, lots and transition planningThe account-data pipeline, gain/loss and the nonexecuting plan.
15. 13Monitoring, compliance notes, performance and reportingPrioritized cases instead of notification noise, review notes and three separate result types.
16. 14Integration contracts and future controlled executionRead-only integration first; execution as an architecture, not an initial action.
17. 15Security, reliability and firm-scale operating modelAccess and trust, operations, and the capacity fixtures used for testing.
18. 16Phase map, dependency graph and release ownershipThe order of the phases and who owns each gate.
19. P00–P11Ordered build phasesNinety-six ordered steps from inventory through the Studio, the adaptive desk, the CRM, firm scale, read-only integration, paper execution and limited live implementation.
20. 17Acceptance program and golden demonstrationsThe demonstrations a release must pass on controlled fixtures.
21. 18Requirement traceability and deferred boundariesWhere each requirement lands and which deferrals are intentional.
22. 19Decisions, rollout checklist and build-status contractSafe defaults, gated decisions and the evidence ledger.
23. 20–21Sources and consolidation provenanceThe primary source register and the validation boundary of the consolidation.

Release boundaries

Each release is a gate with evidence, not a date. No capability is enabled because its schema or button exists, and a coding agent cannot approve its own production access, financial methodology, legal operating model or live execution gate.