Use the Language Model for reasoning. Give it a persistent model of what it is reasoning about.
Proxa pairs a Language Model with a Domain Model to create a persistent environment for professional work.
Six sections, eight examples, and the questions we get asked.
00
Claude paired with a Model of your Essential Data
Language Models are extraordinarily good at reasoning over information. What they lack is anything persistent to reason about. Most AI systems therefore reconstruct the subject every time they work on it — from prompts, documents, search, retrieval, and tool calls — and a larger context window only raises the ceiling on how much can be pushed in.
Our thesis is that professional work needs the other half: an explicit, persistent model of the subject itself. We call it a Domain Model. It can represent a department, project, investment, asset, customer, or any other structured body of information, and it holds the facts, relationships, calculations, assumptions, rules, decisions, and process state that the work depends on.
Underneath it sits Essential Data — the small set of facts every deck, worksheet, and departmental report restates in its own format, held once with a source, an owner, and a date it was last confirmed. As with a spreadsheet, everything downstream depends on those inputs being clean.
Around it sits a harness: the environment that gives Claude and other agents the context, tools, permissions, state, and history to work against the model over time. That is what makes the system process-oriented rather than prompt-oriented.
Put together, silos collapse, the data is governed, inputs and outputs become automated, and the model is computational rather than merely retrieved — all inside an environment the organization controls, with observability, versioning, and rollback.
The rest of these slides are that argument in order: Claude, the Domain Model, Essential Data, what changes when they work together, and the harness that runs it.
01
Built for Claude
A Proxa maxim: just use Claude. We are not building a model, wrapping one behind a house abstraction, or routing between a dozen of them. The frontier model is the reasoning engine, and it gets better without us.
What Claude does not have is a persistent model of the thing it is reasoning about, or an environment built for the way professionals actually work — recurring processes, real sources, permissions, review, and outputs that have to be right.
Most AI systems reconstruct the subject every time they work on it — through prompts, documents, search, retrieval, and tool calls. On each run the model must decide what matters, infer how information relates, identify which sources are authoritative, and rebuild the current state of the work. That is fine for open-ended questions and one-off assistance. It becomes expensive and difficult to reproduce across recurring professional processes.
A larger context window does not remove the problem. It raises the ceiling on how much material can be pushed in, but the structure still has to be re-derived on every run, and the answer still varies with whatever happened to be included.
So Proxa builds the environment: make the important structure explicit and persistent, then let Claude reason against it repeatedly. (Technically, a neuro-symbolic approach — statistical reasoning over explicit symbolic structure.)
The result is Claude working the way professional users already expect it to — with memory of the subject, access to the systems the work lives in, and results they can trace.
02
Domain Models
A Domain Model can represent a department, project, investment, asset, organization, or any other structured body of information. It gives a professional team a shared computational representation of the subject it is working on.
Rather than relying on source documents and retrieved context alone, the model makes the important facts, relationships, calculations, assumptions, rules, decisions, and process state explicit and reusable. The same representation can then support many different questions, analyses, workflows, and outputs over time.
This is what separates a Domain Model from a knowledge base or a context graph. Those systems are designed to retrieve or assemble relevant information. A Domain Model represents the subject itself, in a form that can be reasoned against, updated, calculated against, and operated on.
At its core it combines a semantic graph with a dependency graph. The semantic graph represents what things are and what they mean. The dependency graph represents how they work together: what depends on what, what produces what, who owns a decision, and which calculations rely on which assumptions.
Illustratively: a Domain Model of a portfolio company holds its entities and reporting lines, its operating metrics and how each one is defined, the assumptions behind the current forecast, and who owns them. When Q3 actuals land, the model updates once — and the board deck, the valuation, and the diligence checklist all draw from the same corrected state.
03
Essential Data
Underneath the tools a team uses every day — the slides, the documents, the spreadsheets, the files, the reports run out of departmental systems — there is a much smaller set of facts that all of it depends on. Results and how they are calculated. Terms and obligations. Assumptions and who owns them. Decisions and what they were based on.
Today that layer does not exist as a layer. It is restated in every artifact, in a slightly different form each time, and reconciled by hand. Nobody can say which copy is current, so the same numbers get rebuilt before every meeting.
Essential Data is that layer made explicit: held once, structured, and carrying its provenance — where each fact came from, who owns it, when it was last confirmed, and what depends on it.
The discipline is familiar. A spreadsheet is only as good as the inputs behind it; clean, well-defined data is what makes the formulas trustworthy. The same is true of a Domain Model, at the scale of an organization rather than a workbook.
The objective is not to centralize everything. It is to identify what the work actually depends on, encode that well, and let the documents, decks, and reports draw from it rather than each holding their own version.
04
All working together
Put the Language Model, the Domain Model, and the harness in one environment and the benefits compound.
Data silos collapse. Instead of the same information living differently in a workbook, a deck, a system export, and someone’s head, there is one representation the whole team and its agents work against.
The data is governed. Every fact carries a source, an owner, and a state, so the question is no longer whether the number is right but when it was last confirmed. Proposed changes can be reviewed and validated before they land.
Inputs and outputs become automated. Two loops run continuously around the model: one from sources into the Domain Model, keeping it current as information changes; the other from the model into the work — reports, presentations, forecasts, dashboards, and checklists, produced in the tools teams already use.
You can chat with a living knowledge base rather than a folder of files. The model is current by construction, so a conversation resolves against the present state of the work.
And it is computational, not just reasoning over documents. The model holds calculations, dependencies, and rules, so it can recompute a forecast or trace what an assumption affects — not only summarize what a file says.
The complexity stays in the workspace. The user experience remains simple and conversational.
05
Harness
Claude Code is a harness. The model was always capable of writing software; what changed was giving it the repository, the file system, the tests, the version history, the ability to run something and see what happened, and permissions around all of it. The reasoning did not improve — the environment did.
Proxa is that harness for the business. The material is different: not a codebase but financial models, reports, contracts, source systems, obligations, and decisions. The requirement is the same. Claude needs somewhere to stand, something to act on, and a record of what it did.
Concretely, the harness gives Claude and other agents the context, tools, permissions, state, history, and controls required to work against the Domain Model over time. Agents can monitor sources, maintain the model, perform approved steps, surface exceptions, and involve people when judgment or approval is required.
The difference between the two is the review step. An engineer can run the code and see whether it works. Business work has no compiler, so the harness supplies the equivalent: provenance on every fact, validation before changes land, and a person in the loop where judgment is required.
Every Domain Model begins with source material: operating systems, databases, spreadsheets, presentations, documents, research, third-party data, or direct input from the people responsible for the work. The harness is how that material is interpreted, encoded, and kept current.
The objective is not to ingest everything. It is to build enough of the model to support the work being performed, then expand and maintain it as new information arrives.
Trust is a property of the harness, not a layer added afterwards. All of it operates inside a secure sandbox: the organization controls identity, storage, approved models, permissions, access, and security policies. Activity remains observable, changes can be traced and, where appropriate, rolled back, and proposed changes to the model can be reviewed and validated before they land.
The complexity stays in the harness. The user experience remains simple and conversational.
EXAMPLE
Diligence
A diligence process is a race to build an accurate model of a company under a deadline, from material that arrives in fragments: a data room, management decks, exports, calls, and third-party research.
The Domain Model becomes the working representation of the target — entities and ownership, revenue by segment and how each is defined, contracts and obligations, the assumptions behind management’s forecast and who made them.
Every workstream then draws on the same model. The commercial read, the financial model, the diligence checklist, and the investment memo resolve against one representation, so a correction lands once and propagates rather than being chased across five files.
When new material arrives, the model updates and the open questions narrow. What was verified, by whom, and when, remains visible.
EXAMPLE
Finance
Recurring financial work is the clearest case for a persistent model: the same close, the same reporting pack, the same forecast, month after month, with the reasoning rebuilt by hand every time.
The Domain Model holds the entity and account structure, each metric and its definition, the calculations, and the assumptions the forecast rests on — with an owner and a last-confirmed date on each.
Actuals flow in from the source systems. The model recomputes, exceptions surface, and the board pack, the variance commentary, and the updated forecast pull from the same current state.
Because dependencies are explicit, a changed assumption can be traced to everything it affects before anyone publishes a number.
EXAMPLE
Product
Product knowledge is unusually scattered: specs, roadmaps, research, tickets, analytics, and decisions taken in threads that nobody can find six weeks later.
The Domain Model represents the product itself — surfaces and features, the metrics that describe them, customer segments and their needs, and the decisions made with the reasoning attached.
That makes the roadmap answerable. What depends on this migration, what did we decide about this pricing question and why, which segment does this metric move — all resolve against the model rather than against whoever remembers.
Research and usage data keep it current, and the reports, reviews, and updates teams already produce draw from it.
EXAMPLE
Asset
An asset — a property, a fund position, a piece of infrastructure, a portfolio company — is held for years, and the reasoning about it accumulates in valuation models, reports, contracts, and correspondence that drift apart.
The Domain Model represents the asset itself: its structure and ownership, its cash flows and the drivers behind them, the terms and covenants that constrain it, the current valuation and the assumptions it rests on.
Operating data and third-party inputs keep it current, so a valuation is not a periodic reconstruction but a recomputation against a model that already knows what changed.
Reporting to owners, lenders, and committees then draws from one representation, and a question about performance resolves to structure rather than to whichever spreadsheet was opened last.
EXAMPLE
Sales
Sales information is spread across a CRM, notes, proposals, pricing approvals, and inboxes. The CRM records the shape of the pipeline; it does not hold the reasoning behind any given deal.
The Domain Model represents accounts and opportunities, the people involved and what each of them cares about, pricing and terms and what has been approved, competitive position, and the state of every commitment made.
Because the model is computational, pipeline questions can be answered rather than reported: what does this quarter look like if two renewals slip, which deals depend on a discount nobody has approved, where has the same objection appeared five times.
Forecasts, account plans, QBR material, and handovers to delivery all pull from the same current state.
EXAMPLE
Customer
Three sources hold most of what a company knows about a customer, and none of them agrees with the others. Contracts hold what was actually committed. Salesforce holds the commercial relationship. Customer success holds what is really happening.
Each is authoritative about something and silent about the rest. The contract knows the renewal date and the service levels but not that the account is unhappy. Salesforce knows the owner and the pipeline but not which entitlement was negotiated in an amendment. Success knows the sentiment but not the terms.
The Domain Model encodes all three into one representation of the customer: the entities and people, the commitments and their terms, what was bought and how it is used, open issues, renewal dates, and the decisions taken along the way — each fact carrying its source.
Then the question can be asked once. What did we commit to this account, what are we not delivering, what is at risk at renewal, and who owns it. The renewal conversation, the escalation, and the account review all start from the same facts.
The three sources keep feeding it, so the model is current without anyone reconciling three systems by hand.
EXAMPLE
People
Information about people is sensitive, fragmented, and unusually consequential: an HRIS, contracts, compensation reviews, performance notes, and org charts that are out of date the week they are drawn.
The Domain Model represents the organization as it actually works — roles and reporting lines, skills and responsibilities, compensation structure, and the decisions made about each, with permissions attached at the level of the model rather than the document.
That makes planning computational. What does this reorganization cost, which responsibilities become unowned, who is affected by a change to the leveling framework.
Access controls, observability, and audit matter more here than anywhere else, which is why they sit in the workspace rather than in the individual files.
EXAMPLE
All (an Org Model)
Each of these models is useful alone. Connected, they become an Org Model: a representation of the organization itself rather than of one function inside it.
The connections are where the value compounds. A customer commitment connects to a product dependency; a hiring plan connects to the forecast; an asset’s covenants connect to the finance calendar. Those relationships exist in reality and are usually held only in people’s heads.
Nothing about the approach changes at this scale. Each domain is modelled where the work is, the harness keeps each one current, and the connections are made explicit as they matter — not designed up front in a two-year data programme.
The result is an organization that can be reasoned about: what depends on what, what changed, who owns it, and what a decision here does over there.
FAQ