Architecture
VoyceBook Document OS Architecture & Data Model
Technical overview of how VoyceBook unifies proposals, contracts, invoices, and payments in a single immutable event-driven document graph.
The Core Philosophy: A Document is a Graph, Not a Row
Traditional ERPs store proposals, contracts, and invoices in isolated relational tables. When an invoice is paid or disputed, tracing back to the original proposal requires querying audit logs across disparate services.
VoyceBook models business documents as connected nodes on a directed acyclic graph (DAG). Each document transition—from proposal acceptance to contract signing and invoice dispatch—is recorded as an immutable event with cryptographic provenance.
Document Lifecycle & State Transitions
Every document advances through deterministic states backed by a distributed finite state machine (FSM). State changes trigger automated notifications across WhatsApp and Email and sync to external accounting connectors.
| Document Type | Initial State | Terminal State | Triggering Event |
|---|---|---|---|
| Proposal | DRAFT | ACCEPTED / REJECTED | Client digital approval via portal |
| Contract | DRAFT_SENT | EXECUTED | Dual cryptographic e-signatures sealed |
| Invoice | ISSUED | PAID / WRITTEN_OFF | Bank payment reconciliation or gateway webhook |
| Payment | PENDING | SETTLED | UPI / NEFT / RTGS settlement confirmation |
Event Schema Specification
All mutations emit strongly-typed CloudEvents over our internal messaging fabric. Below is a sample payload emitted when an invoice is settled:
{
"specversion": "1.0",
"type": "com.voycebook.document.invoice.settled",
"source": "/workspaces/ws_01H8X9/invoices/inv_9842",
"id": "evt_01H9A8Z1",
"time": "2026-10-20T10:14:00Z",
"datacontenttype": "application/json",
"data": {
"invoiceId": "inv_9842",
"invoiceNumber": "INV-2026-084",
"clientId": "cust_481",
"amountPaid": 85000.00,
"gstAmount": 15300.00,
"paymentMode": "UPI_AUTO_COLLECT",
"utr": "428910482910",
"timelineDurationDays": 14
}
}