The ontology of how a company is built

A group of companies that share the same primitives. Each industry has its own schema, maintained by the consultant.

Example · Construction, Staffing.

The standard architecture of an industry: its primitives, parameters, connection types, module catalog and interfaces. Schemas are versioned; publishing a new version never changes an existing atlas.

How the schema is grouped: top-level primitives are the parts of the business, and the primitives under them are the standard functions inside each part. The Standard architecture page is the taxonomy of the industry.

Example · Money and obligations → Client billing and invoices.

One of five lenses every primitive belongs to. Layers are how the atlas answers 'who does it, how, with what, on what data, and who decides'.

• people
  Roles, teams, crews and the people outside the company who take part.
• process
  The work itself: steps, hand-offs, approvals and recovery.
• software
  The tools and systems that carry the work.
• data
  The records the company keeps and the facts it relies on.
• decisions
  Rules, authority limits, policies and the places judgement is applied.

A standard business function every company in the industry has in some form. Primitives are the rows of every comparison. What separates companies is how each primitive is configured, not whether it exists.

Example · Estimating, Worker onboarding, Client billing.

A named, typed fact about a primitive that can be filled per company and compared across companies.

Example · Bid win rate (percent), Estimating method (enum: spreadsheet, estimating software, outsourced).

• text
  Free text.
• number
  A number with an optional unit.
• money
  An amount in a currency.
• percent
  A share, 0 to 100.
• boolean
  Yes or no.
• enum
  One of a fixed list of options.
• date
  A calendar date.

A unit of capability under a primitive that does one job and maps to a Business OS module. Modules nest into sub-modules with no depth limit.

Example · Estimating → Estimate builder → Takeoff, Pricing, Bid assembly.

A part of a module. Gaps show up at every level of the breakdown.

A defined input or output where a module connects to another module, a person or an outside tool. Interfaces are the edges of the graph at module level.

Example · Takeoff takes in drawings from the client and sends quantities to Pricing.

• direction
  in or out.
• carries
  The data fields that cross the interface.
• counterparty
  Who or what is on the other side.
• trigger
  event, schedule or manual.
• flow type
  What moves: money, information, material, work, energy or control.

A named kind of link the schema allows between primitives, with its flow type and the layers it usually joins.

Example · Sends estimate (information, process → process); Invoices (money).

One client's private research space: their company, the competitors mapped for them, their people, notes and visibility settings. Workspaces are fully isolated.

The workspace's own company. Everything it provides starts Private.

A company mapped from public sources for comparison. Added once by the consultant and reusable across every client in the same industry.

How a specific company implements a primitive: the thing it actually has. A company can have several components for one primitive, components can nest, and a component with no primitive is a custom component.

Example · For the primitive CRM, Acme's component is 'HubSpot'.

Something a company has that matches no primitive. When several companies share one, it becomes a candidate for a new primitive in the next schema version.

A party outside the company boundary that its components connect to.

• customer
  Who buys.
• supplier
  Who provides materials, labour or services.
• partner
  Who the company delivers with.
• regulator
  Who sets or enforces rules.
• economic_factor
  Interest rates, material prices, the labour market.

A parameter filled in for one component, with its source, confidence, visibility tier and review status.

A connection between two components, with direction and an optional volume. Edges are what the network, flow and money views draw.

• money
  Payments, invoices, margin.
• information
  Documents, messages, records.
• material
  Physical goods.
• work
  Tasks and hand-offs between steps.
• energy
  Power and fuel.
• control
  Approvals, instructions, branching decisions.

A comment on any component or on the whole company. Consultants can pin a recommendation; clients can flag a public value as wrong and give the correct one.

Where a value was found, with the URL, title and the date it was retrieved.

• website
  The company's own site.
• careers
  Careers pages and job descriptions.
• job_post
  Individual job posts, which reveal roles and tools.
• press
  Press and news.
• review
  Customer and employee reviews.
• filing
  Public filings and source repositories.
• registry
  Licence, permit and app-store registries.
• client_document
  A document the client uploaded.
• interview
  What the client told us.
• manual
  Entered by hand by the consultant.

How much a value can be trusted, shown as a small badge wherever the value appears.

• verified
  Confirmed by the client, or read directly from inspected source material.
• self_reported
  Provided by the client, not independently checked.
• inferred_high
  Documented in the company's own public material.
• inferred_low
  Partial or indirect public evidence.

In research-led industries, the parameter that records what the evidence supports for each primitive.

• documented
  Explicit support in the company's first-party material; not operational verification.
• modeled
  Found in inspected source code; capability, not proof of live operations.
• partial
  Some evidence, with the limit recorded in the detail.
• unknown
  Not established by the reviewed sources; never a claim of absence.

Where a value is in the consultant's review queue.

• draft
  Found by research, not yet confirmed.
• confirmed
  Reviewed and kept.
• rejected
  Reviewed and discarded; never shown.

Who can see a value.

• public
  Found by research from public sources. Anyone with access to the profile sees it; the client can flag it as wrong.
• published
  Client data the owner chose to publish. Anyone with access to the profile sees it.
• shared
  Client data shared with named people and the owner.
• private
  Client data, the default. The client workspace and their consultant only.

A preview of a company as a competitor sees it: public and published values only. When a private value differs from the public one, outsiders see the public value and the client sees the difference highlighted.

Every access to private data and every visibility change, visible to the owner.

A company's state for each module and sub-module, with the tool or person that covers it.

• have
  The module exists and all its sub-modules and interfaces work, through a tool or a person.
• partial
  It exists but is missing sub-modules or interfaces.
• manual
  Done by people with no system behind it.
• missing
  Nobody does it.
• not_needed
  Does not apply to this business model.

A company's state for each interface.

• connected
  Data crosses automatically.
• manual_handoff
  Someone copies the data across.
• missing
  Nothing crosses.

A missing or partial module, a broken interface or a compliance gap, ranked by how many other modules depend on it and how many competitors already have it. Each gap links to the Business OS module that fills it.

The share of the schema's primitives that have at least one component mapped for a company.

Completeness per layer, so a thin or overloaded layer is visible at a glance.

The industry median and range for a parameter, computed from public and published values once five or more companies are mapped.

An external rule, recorded with its jurisdiction, authority, status, effective date, scope, the primitives and modules it touches, and a link to the official source.

• regulation
  A law or agency rule with legal force.
• license
  A credential a company must hold to operate.
• permit
  Approval needed per project, site or activity.
• standard
  A voluntary or contract-required standard or certification.
• tax_rule
  Filing, withholding or reporting obligations.
• policy_change
  A proposed rule, bill or ruling not yet in force.
• contract_term
  A requirement that comes from customers or partners.

Where the rule itself stands.

• proposed
  Not yet enacted.
• enacted
  Passed, not yet in force.
• in_force
  Applies now.
• repealed
  No longer applies.

How one company stands against a rule, with an expiry date where there is one.

• holds
  Has the licence or permit, or meets the rule.
• in_progress
  Applied for or working toward it.
• gap
  The rule applies and the company does not meet it.
• not_applicable
  Outside its scope.
• unknown
  Not enough information yet.

A rule a company writes for itself, attached to the primitives, modules, interfaces or decisions it governs. Private by default; for competitors only inferred from what they publish.

• approval_limits
  Who may approve what, up to which amount.
• pricing
  Pricing and discount rules.
• hr
  Hiring, pay bands, leave, conduct.
• safety_quality
  Safety and quality programs.
• sop
  Operating procedures.
• vendor_procurement
  Vendor and procurement rules.
• data_security
  Data, security and IT policies.
• customer_service
  Warranty, response and payment terms.

Components as nodes, connections as edges, zoomable. Best for seeing how everything connects.

Top-down tree from the company through the parts of the business to every component. Best for org structure and chain of command.

Five horizontal bands with the links between them. Best for seeing which layer is thin or overloaded.

One lane per part of the business, flow left to right. Best for hand-offs, bottlenecks and who owns each step.

Every tool by layer with the integrations between them. Best for software overlap, gaps and integration debt.

Primitives by companies, each cell shaded by evidence. Best for spotting differentiators across many competitors.

Any map coloured by have, partial, manual or missing. Best for seeing gaps at a glance.

Every input and output between modules, with manual hand-offs and missing links highlighted.

The company map with each rule's reach highlighted.

What moves through the company, sized by volume: leads, deals, projects, invoices, cash.

Revenue streams in, cost centres out, margin per primitive.

Any output traced upstream to its sources outside the company.

External forces linked to the components they hit.

Select a component and see everything that breaks or slows if it fails.

Layers as stacked planes, connections as beams; two companies as side-by-side towers.

Any view played over time as the architecture changes.

How deep the component tree is unfolded: departments (top-level components) or detail (everything, with hidden children counted on each node).

An encoded unit of intent designed to produce action at its destination: the payload that travels through noise. In the atlas, every edge carries one.

• mode
  How it is perceived: linguistic, visual, auditory, gestural, spatial.
• genre
  The conventional form: SOP, proposal, invoice, change order, daily log.
• type
  What it does: direct, inform, commit, decide, express.
• format
  The container: PDF, spreadsheet, app record, meeting.
• structure
  The internal skeleton that organises the content.

The ratio of useful information to interference. The single objective every viable communication architecture maximises.

The medium a signal travels through. In the atlas, an edge's flow type and the software that carries it.

Any interference between encoding and decoding: re-keying, overload, ambiguity, politics. Manual hand-offs and missing interfaces are noise the atlas can see.

A node is where encoding or decoding happens; the network is the topology of connected nodes. The company atlas is the network; components are its nodes.

Four constraints every viable communication system satisfies. Each failure mode in a company violates one of them.

• channel capacity
  Shannon: reliable communication above a channel's capacity is impossible. Is the channel adequate?
• requisite variety
  Ashby: a controller needs at least as much variety as what it controls. Is the repertoire sufficient?
• recursive viability
  Beer: every subsystem of a viable system is itself viable. Is the architecture complete?
• closed-loop feedback
  Wiener: the destination's response must return to the source. Is the feedback loop closed?

A signal that skips an architectural layer it should pass through: a function bypassing policy, a request ignoring the authority chain. Structurally invalid, and visible in the layer-stack view.

A circular path where the destination's response returns to the source for correction. Feedback edges in the atlas: approvals, reconciliations, retrospectives.

A system organised to survive in a changing environment, with five recursive subsystems: operations, coordination, control, intelligence, policy.

A system that continuously regenerates itself: monitors its own signal complexity, detects degradation and restructures before failure.