A conversation. An appointment. A deal. Behind the everyday work, DealerCRM coordinates intelligence, communications, data, and decisions across one connected operating system.
At twelve-point type, our original estimate was about 88,000 letter-size pages. The figures below recalculate from each published release. All that engineering reaches your team through the screens they use every day.
A modern three-story buildingAbout the height of a three-story building. Illustration uses matching heights; actual floor heights vary.
Ten reams. Five thousand sheets. That is one full box. Printing this codebase would fill — boxes, including the partially filled final box.
— reams in total. Each illustrated box represents up to 5,000 sheets.
— books of 300 pages each
— feet from floor to top
Loading the published release measurements…
We count tracked source files in the published release: application code, database SQL, tests, scripts, and retained code versions. We exclude documentation, images, audio, video, and non-code data files. These are repository measurements; they do not mean every line runs in production.
The print estimate uses 12-point monospace type, one-inch margins, approximately 65 characters per line and 45 lines per page, four spaces per tab, and a fresh page for each file. Blank lines and comments count. Stack height assumes paper 0.004 inches thick. Actual pagination and paper thickness vary.
“Code words” means runs of non-whitespace characters, including code and comments. It is a source-size comparison, not a count of English prose. Source size describes the scope of the engineering; it does not measure performance or quality.
Intelligence has different jobs to do: listen to a conversation, understand a request, find relevant evidence, draft a response, evaluate an opportunity, or help a person take the next step.
One connected intelligence system.
Many distinct jobs.
One square. One registered area of intelligence. This map grows with the registry.
— configurable areas
— fixed dependencies
These counts describe the central OliviaAI registry, including operational, experimental, and fixed-dependency areas. They are not separate models, simultaneous processes, or a promise that every area is enabled for every customer.
Help turn calls and messages into useful context: what was discussed, what matters, and what needs attention.
Streaming speech processing, transcription, structured extraction, conversation summarization, and reply-required classification serve distinct inference tasks. Each registered task has its own assignment contract rather than treating all conversation work as one interchangeable prompt.
Bring relevant customer history, inventory, and business context into the work in front of your team.
Permission-scoped retrieval binds context to the authenticated account, store, and operator. Indexed queries, bounded result sets, and governed reporting rollups reduce the amount of data that must be examined for an individual request. A failed read must remain an error rather than masquerading as an empty answer.
Assist with drafting, interpretation, follow-up planning, and turning a request into a useful next step.
Structured outputs and task-specific tool contracts connect language interpretation to application workflows. Model selection does not grant authority: permissions, consent, ownership, and action-specific eligibility remain separate checks. Advisory judgments and draft creation are distinct from authorization to send or change a record.
Keep different kinds of intelligence assigned to the work they are meant to do.
A centralized registry separates task identity, model assignment, fallback policy, and fixed transport dependencies. Signed review and durable mutation records govern assignment changes. This is an orchestration problem: selecting a suitable execution path while retaining the same permissions and workflow boundaries.
A voice conversation cannot wait for an overnight data job. An import should not hold up a salesperson. A delivered message needs a durable history. Different work needs different processing paths.
A conceptual workflow, not a trace of a particular customer interaction.
Streaming transports handle interactive voice and incremental responses. Request-driven services handle foreground application work. Scheduled jobs and durable workers handle synchronization, extraction, enrichment, and maintenance. Separating these paths lets each class of work use an appropriate execution budget.
Provider acknowledgments, webhook events, retries, and customer-visible history can arrive at different times. Idempotency keys and duplicate suppression protect replayable operations; durable records and reconciliation distinguish attempted work from confirmed outcomes. An accepted request and a completed action are different states.
Relationships span customers, conversations, inventory, appointments, employees, stores, and deals. Tenant scope, indexed access paths, pagination, and shared rollup definitions keep those relationships useful without turning every screen into a full-table scan. Store-local presentation sits on top of UTC storage.
Inference consumes context and produces a judgment, response, or proposed tool action. The application must then validate the output, retain attribution, and enforce the exact action contract. Context retrieval, inference, tool execution, media processing, and persistence have different costs and failure modes; orchestrating them is part of the product.
No workload volume, throughput, hardware capacity, or response-time benchmark is claimed here. Those require separately measured runtime evidence.
The scale matters because of what it brings together: conversations, customer context, inventory, deals, and the people who keep work moving.