Concepts
The company model
The company model is a lasting, versioned description of how one business works: its objects, how they link, which source is authoritative for each fact, and who may see what.
Why it exists
Connecting a model to a business's systems gives it access, not understanding. A CRM knows a contact and an accounting system knows an invoice. Neither knows they are the same customer, which one is right when they disagree, or that an order is waiting on an inactive supplier. The company model records exactly that, so every session, model and application starts from the same picture.
What it holds
| Part | What it is |
|---|---|
| Entities | Typed objects such as Customer, Order, Supplier, Invoice |
| Facts | Named properties such as Order.status or Supplier.active, each with its declared sources |
| Relations | Typed, directional links such as Order placed_with Supplier |
| Identity | Match keys that resolve records from several systems to one obj_ object |
| Sources | Each system, with an authority level, the facts it may assert and a maximum age |
| Actions | What may be proposed, the rules that decide it, and who may propose and approve |
| Views | What a person may read, and separately what a model may see |
How it is built
- Inspect. Survey what each authorized system holds: tables, columns, a few sample rows.
- Discover. Find the likely customers, invoices and orders, and the links between systems.
- Model. Write the company model down as a contract: the versioned ontology Harness enforces.
- Validate. Check it against fresh data. Ask a person when the data cannot decide.
- Evolve. Revise it as the business changes, keeping its history.
Status Survey, drafting, validation and owner activation run locally. A model-built company model has not yet been approved and applied end to end on a real business.
It outlives the AI model
The company model is independent of any AI model. Switch providers, or run with no model at all, and the entities, rules, approvals and history stay exactly as they were.