Company Model
The company model is the picture of a company that Merulan keeps and acts from. It joins four parts: the data a company holds, the judgment it declares, the work it runs, and what that work teaches. This map names the owner of each part and the order in which one part feeds the next.
Topology
The map shows the path from data to judgment to execution, and the evidence that feeds later changes.
Data stores, business logic, and Apps feed the Company Schema. Agents, Dashboards, and machine learning work around it. The Company Schema supports them. Machine learning changes a definition, and the next Workflow Run starts from the changed version.
| Part | What it holds | Owner |
|---|---|---|
| Data | Records, loaded from outside systems into declared kinds | Data Pipelines, Company Schema, Records & Lists |
| Judgment | The definitions and rules a company decides once | Company Schema, Governance & Administration, Agents & Workflows |
| Execution | Runs, approvals, and the Apps that read the model | Agents & Workflows, Apps & Dashboards |
| Learning | Saved Cases, scores, and the Governance log | Labs & Modeling, Governance & Administration |
Data
Data reaches the model through Sources and media, Pipelines, and Runs and lineage. Follow those pages when you need to connect an outside system, define the mapping, or inspect what a Run read and wrote.
A Record is always an instance of a kind the Workspace declared first. Schema model owns what a thing may be, and Records and history owns what exists.
Judgment
Judgment is what a company decides once so that it does not have to decide it again on every call. Schema model holds what the company's things are. Tags, policy, and field access holds who may act, for which purpose, and on which values. Workflows and blocks holds how a piece of work is done.
Each of these is a definition, not an action. Runs and readback explains how a launched workflow is observed.
Execution
Execution is where a definition acts on the company model. Reviews and repair explains the decisions and recovery that can stop work before it proceeds. Use that page when work waits for a decision.
Apps and dashboards sits over the same company model. Use it when a reader needs the experience that shows the result. The map puts both around the model. It does not make either the authority for the other.
Learning
Learning closes the loop. Experiments and evaluations compares saved work, while Models and sandboxes owns the model boundary. Use the first to compare work and the second to set a model boundary.
Access reviews and audit provides the evidence a reviewer uses to inspect access decisions and their actors. These pages describe their own decisions. This map only shows how their results return to the model.
Traversal
Start from the question you have, then follow the part that owns its answer:
| Question | Start at |
|---|---|
| Where did this data come from? | Runs and lineage |
| What may this thing be, and which fields does it carry? | Schema model |
| Who may read or change it? | Tags, policy, and field access |
| What ran, and why did it stop? | Runs and readback |
| Is this definition good enough to trust? | Experiments and evaluations |
Related
- Operation Lifecycle follows one call through the checks every part of this model shares.
- Surfaces names the ways a person, script, or agent reaches the model.
- Security explains what to change when a call into the model is refused.