​
Operating Model

This page defines the narrative boundary between Paperclip product docs and the Tremor operating corpus. Paperclip product docs explain the platform. The operating/* section explains how this specific company is being run on that platform right now, and it points into the underlying companies/tremor/* corpus for the live Tremor record.

​
Boundary

Paperclip is the control plane:
  • it defines the contracts
  • it owns the UI, API, persistence, and adapter model
  • it describes behavior that should hold across instances
Tremor is the operating corpus:
  • it captures current company facts, audits, baselines, and runbooks
  • it documents live verification and recovery discipline
  • it records the present operating state of this company, not the abstract platform

​
What Belongs Where

Put content in Paperclip product docs when it explains:
  • what Paperclip is
  • how the control plane works
  • what a route, schema, adapter, or CLI command does
  • what behavior is expected across deployments
Put content in Tremor operating docs when it explains:
  • current repo strategy
  • live runtime or environment baselines
  • audit snapshots and status pages
  • repo-specific runbooks, handoffs, recovery, and boundary enforcement
  • company-specific artifacts, plans, and operating notes
Within this repo, the operating/* pages are the formal operating surface. They orient the reader and route them to the company corpus under companies/tremor/*.

​
Narrative Rules

  • Product docs should read like a stable manual.
  • Operating docs should read like a dated operating ledger.
  • Product docs should avoid embedding current-only numbers unless they are part of the contract.
  • Operating docs should always make the snapshot date or audit basis visible when facts are time-bound.
  • Product docs should describe the system in general terms.
  • Operating docs should state when the general model has been specialized for Tremor.

​
Operating Page Pattern

Most operating pages should follow this shape:
  1. State the operational purpose.
  2. Identify the current audit date or basis.
  3. Explain the boundary or control surface.
  4. Present the live facts.
  5. Call out the next verification or maintenance step.
That pattern keeps the page usable as a control-plane surface instead of turning it into a generic essay.

​
Boundary Signals

Use these signals to decide whether a fact belongs in the operating corpus:
  • it references the current runtime, repo, DB, or hostname
  • it mentions a current issue ID, audit date, or verified baseline
  • it describes a live operational risk
  • it names a current repo split, migration state, or handoff rule
  • it changes when the company’s operating state changes
If none of those are true, the fact probably belongs in product docs or a more general reference page.

​
Relationship To Product Docs

The two surfaces are complementary:
  • product docs define the platform model
  • operating docs describe the current instance of that model in the Tremor company
That means operating pages can refer back to product docs, but they should not rewrite product contracts in ad hoc language.

Docs style guide

Read the canonical writing conventions for new and revised docs.

System reference

Read the glossary and authoritative boundary map.