prd
PRD — caesar
Section titled “PRD — caesar”Status: to be authored. The Phase 1 requirements live in the BRD (the business-requirements source of truth). This product PRD — screen-level specs, personas, user stories and acceptance criteria — gets written as we study the Zoho Books baseline and design Caesar’s flows against it. Until then, treat the BRD as canon and this file as the index.
Problem
Section titled “Problem”See BRD §1–2. Zoho Books breaks not on transaction count but on entity structure; MocX needs an in-house, audit-grade system of record that is OneWorld-shaped from day one.
Goals & non-goals
Section titled “Goals & non-goals”See BRD §3 Design principles and §14 Out of scope.
Audience
Section titled “Audience”Finance and leadership at MocX. Personas and segregation-of-duties roles (requisition / approval / payment / posting) are catalogued in flows/README.md and BRD §12.
User stories
Section titled “User stories”To be authored per persona under ../flows/.
Functional requirements
Section titled “Functional requirements”The Phase 1 functional spec is BRD §8 (ledger core, payables/procurement, revenue posting, banking, fixed assets, inventory→asset, liabilities, intercompany, Nigerian tax), with the command centre in §7 and integrations in §9.
Non-functional requirements
Section titled “Non-functional requirements”Audit-grade primitives are non-negotiable: double-entry integrity, immutable posted journals, period locking, full audit trail. See BRD §3 and §16.
Open questions
Section titled “Open questions”See BRD §15 Assumptions and open decisions — ledger-core build-vs-embed, entities at go-live, single- vs multi-book.
Attachments
Section titled “Attachments”See attachments/ for the original BRD and design exports —
Caesar_BRD_Phase1.docx.