Serious engineering.
Simple to use.
A conversation. An appointment. A deal. Behind the everyday work, DealerCRM coordinates intelligence, communications, data, and decisions across one connected operating system.
—lines across the source inventory
—registered OliviaAI areas
—estimated printed pages at 12pt
Imagine printing the entire codebase.
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.
— boxes of paper.
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…
How we measure it
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.
Read the current release measurements (JSON). This public aggregate contains measurements and calculation assumptions, not source code or customer data.
— registered areas of intelligence.
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.
Understand the conversationHelp turn calls and messages into useful context: what was discussed, what matters, and what needs attention.Read the technical layer
From a signal to a usable business fact
A voice stream, a transcript, and a customer message are different inputs. Interactive speech processing has to respond while the conversation is still happening; post-conversation extraction can work on the retained text. The central registry gives transcription, summarization, structured extraction, and reply-required classification distinct task identities and assignment contracts.
This separation matters because the outputs have different meanings. A transcript represents spoken content. A summary compresses that content. A classifier supplies a bounded judgment about whether a response is needed. Combining those jobs into one free-form answer would make it harder to validate, attribute, and use each result in the application.
- Input boundary
- Channel events and conversation content enter the appropriate processing path; transport state and content are separate facts.
- Task boundary
- The registered area selects the interpretation job. A summary does not become a delivery receipt or a completed follow-up.
- History boundary
- Retained conversation evidence supports later work. Historical context is data, never a new instruction or permission.
conversation content
→ transcription / retained text
→ task-specific interpretation
→ summary, extracted fields, or reply-required judgment
→ application context + attributed historyWhy it is compute-intensive
The system must coordinate streaming media, text processing, contextual inference, and durable history. These paths have different timing, retry, and validation requirements. A useful result depends on coordinating the boundaries as well as producing the words.
Find the right evidenceBring relevant customer history, inventory, and business context into the work in front of your team.Read the technical layer
Retrieval starts with authority, not a search box
Context retrieval is a scoped data problem before it is a language problem. The server resolves the authenticated actor and permitted store context before it reads the customer record. Customer identity and store-scoped activity history are related but distinct boundaries; the customer-profile path checks both instead of trusting a store identifier supplied by a browser.
Large histories require bounded access. The customer timeline uses a 200-row page with one additional row to detect continuation, and a timestamp-plus-ID cursor for the next page. Indexed filters and stable ordering let a reader advance through the relevant history without re-reading an ever-growing offset. Reporting uses governed rollup definitions so a conversational answer can agree with the screen’s store, date, and employee scope.
- Scope first
- Authenticated tenant, customer visibility, store permissions, and operator context constrain the reader before context is assembled.
- Bounded evidence
- Page limits, stable cursor ordering, and indexed predicates keep an individual question from becoming an unrestricted scan.
- Failure is explicit
- A denied scope or failed source read cannot be converted into an empty history or a falsely complete answer.
resolve actor + authorized scope
→ verify customer visibility
→ indexed, bounded history / inventory / reporting reads
→ evidence with source context
→ inference within the same authority boundaryWhy it is more than a large prompt
The difficult work is selecting current, relevant, authorized facts. Retrieval must preserve identity, provenance, pagination, and scope while reducing the context to what the request actually needs. More text is not automatically better evidence.
Help people move work forwardAssist with drafting, interpretation, follow-up planning, and turning a request into a useful next step.Read the technical layer
A proposed action is not an authorized action
Language interpretation produces a draft, a judgment, or a proposed tool call. Execution is a separate application contract. The tool must resolve current permissions and validate the action’s arguments, target identity, ownership, consent, and eligibility as applicable. A model assignment does not expand the operator’s authority.
Even a good draft has several distinct milestones. DealerCRM’s compose attribution tracks draft creation separately from a correlated send; a draft is not counted as a delivered message. Message submission, delivery events, and visible history are separate outcomes, so retries and reconciliation must retain the difference between “attempted,” “accepted,” and “confirmed.”
- Typed intent
- Task-specific outputs and tool arguments give the application fields it can validate instead of treating prose as an executable command.
- Independent checks
- Permissions and action eligibility remain application checks. Advisory recommendations do not override ownership or channel policy.
- Durable outcome
- Attributed draft and send records preserve what happened. Retried delivery work must avoid creating duplicate outward actions.
request → proposed intent / draft
→ validate arguments + current scope
→ check action-specific eligibility
→ authorized execution
→ persist receipt + reconcile observed outcomeWhy orchestration is the hard part
Inference, validation, channel execution, and persistence can fail independently. The workflow has to retain enough state to recover safely without confusing generated content with an action that actually happened.
Govern the intelligence itselfKeep different kinds of intelligence assigned to the work they are meant to do.Read the technical layer
A control plane for specialized intelligence
The central registry distinguishes a task’s identity from its execution assignment. Configurable areas and fixed transport dependencies are counted separately. An area can have an allowed assignment set, an API style, and explicit fallback behavior; a fixed dependency is not automatically an interchangeable execution path.
Assignment changes use signed review and a crash-durable mutation journal. The journal anchors the reviewed request and plan with SHA-256 checksums, then compares the current state with the expected prior state and exact intended target. If the state changed after review, automatic reconciliation stops rather than overwriting an unrelated change. Recovery accepts the reviewed prior state or the exact target state, supporting roll-forward after an ambiguous write without inventing a new plan.
- Separate identities
- Task identity, assigned execution path, fallback policy, and fixed dependency type are explicit rather than buried in unrelated prompts.
- Reviewed mutation
- Signed authorization is bound to the proposed plan and expected state. A different current checksum invalidates the automatic change.
- Recoverable control
- Durable journal state and exact-target verification distinguish a queued assignment change from one that actually finished.
registered task + assignment policy
→ reviewed change plan
→ signed authorization + expected-state checksum
→ durable journal + apply / reconcile
→ verify exact target assignmentWhy the registry count matters
It measures the breadth of governed intelligence jobs, not the number of independent models or concurrent processes. The engineering challenge is keeping those jobs individually configurable and recoverable while preserving the same permissions and workflow boundaries.
Many clocks. One connected experience.
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.
- ListenVoice and message events arrive.
- UnderstandContext and intelligence make them useful.
- CheckScope, permissions, and eligibility constrain action.
- CoordinateWorkflows connect the next steps.
- RecordDurable outcomes become history.
A conceptual workflow, not a trace of a particular customer interaction.
Go deep: the systems engineering
Different clocks. Different failure domains. One coordinated result.
Interactive paths
Streaming speech and incremental responses operate on a conversation’s clock. Request-driven services handle foreground work such as opening customer context or preparing a draft. These paths cannot depend on a scheduled maintenance cycle to make an interaction usable.
Context retrieval, inference, media processing, and application execution are separate stages. The end-to-end experience depends on their composition: a quick inference still feels slow if evidence retrieval blocks, and a fluent response is incomplete if the action has no durable receipt.
Background paths
Synchronization, extraction, enrichment, imports, and maintenance run through scheduled jobs and workers. Their execution budgets and recovery strategies differ from those of a live conversation. Background operations carry explicit scope instead of borrowing an interactive browser’s context.
Separating the paths makes it possible to bound foreground reads while coordinating work that takes longer. A background request that is accepted is still pending work; confirmed outcomes and retained operation state determine completion.
INTERACTIVE event → context → inference → validated response
FOREGROUND request → scoped read / action → durable receipt
BACKGROUND scheduled work → bounded batch → checkpoint / retry
RECONCILE observed event → correlate → confirmed historyDelivery is a state machine
Acknowledgments, delivery events, retries, and customer-visible history can arrive at different times. Idempotency and duplicate suppression constrain replayable operations. Correlation links the observed event to the original work; reconciliation distinguishes an attempted action from a confirmed outcome. The application must handle an ambiguous transport result without blindly repeating an outward action.
Data has several coordinate systems
Customers, employees, stores, inventory, conversations, appointments, and deals form a connected graph with distinct ownership and visibility rules. Indexed bounds and continuation cursors keep reads finite. UTC storage and store-local display preserve time interpretation; shared reporting definitions preserve the meaning of a count across screens and conversational answers.
The engineering is in the boundaries.
The system coordinates authorized evidence, task-specific intelligence, channel execution, and persistent history. Each stage needs its own input contract, valid output, failure behavior, and completion evidence. Source size illustrates the breadth of this work; it does not establish runtime throughput, hardware capacity, or a response-time benchmark.
You get the next step.
We handle the engineering behind it.
The scale matters because of what it brings together: conversations, customer context, inventory, deals, and the people who keep work moving.