Four services, one store, one bus.

A worker definition is a reusable, versioned role in a global catalogue with no customer data in it. A worker instance is one customer's worker: a durable identity bound to a definition version, a contract, a team, a country profile, grants, limits and bindings. Configuration has three scopes: the template (the definition), the customer's adaptation of it, and the bindings to that customer's credentials, systems and telecom routes. A version records which scope each value came from, so an engineer can see what was inherited and what was changed.

The head is the instance's engine: it recognises the situation, chooses from its objective set, selects a procedure, holds the conversation, plans, hands out work, verifies returns and records outcomes. A hand is any recipient that executes one work item under the head's authority: the platform's own hands environment, a person, another worker, an external agent or a system adapter. Only the head may hold contact and commitment actions.

Objectives are a set, not a ladder. An instance holds an objective set with priorities, eligibility, dependencies, deadlines, capacity and conflict rules; an individual objective may carry an ordered fallback path. A durable business objective belongs to the customer's operation and links objective assignments, requests, work items and evidence, so shared goals guide work without a central controller deciding every step.

Verification and reconciliation

A return is not completion. Every return is verified at the declared level before the item completes: a receipt from the system, a read-back of the record, corroboration from a second source, or a person. An unverifiable return is routed to a person. When the outcome of a write is unknown (a timeout, a lost connection), reconciliation looks the operation key up in the system of record and records confirmed, absent or unknown. Absent means the item may be retried under the same key. Unknown is never retried automatically; it stays visible on the work board until a person resolves it. Every external effect is recorded as its own immutable fact, with the item, the key and the system reference.

Conflicts and fan-out

Items that touch the same conflict resource (a quote, an order, a contact's attention) are serialised on that resource. A parent item can fan out to children with a join rule (all, any, quorum); the parent cannot complete while a child is blocked, and nothing is silently dropped.

A stop order is a first-class object with an actor, a reason, a scope (item, subject, worker, objective, campaign, tenant or recipient class), a strength (hold, stop at the next cut point, abort) and a time. It is published on the scope's topics, acknowledged by every recipient holding affected work, and lifted only by a second recorded event. Lifting never resumes work blindly: every affected item re-checks eligibility before it moves.

Ready items in scope are held. Running items stop at the next cut point, or immediately on abort, and then reconcile by operation key. Dependents and join parents are blocked with the stop order as the reason. Obligations to people that depended on the work are not blocked; they are flagged as threatened commitments to their owner, who decides. For recipients the platform does not control, the backstops are grant revocation (adapter writes fail, the next claim is refused), the authority boundary (a later effect is recorded but never credited), and an acknowledgement deadline after which the item is marked stop unconfirmed and routed to a person. Safety stops are immediate and never batched.

Every event is persisted before anything acts on it. The spine does five things in order: persist the envelope (occurred_at, received_at, class, type, subject); deduplicate on the tenant and a natural key, with a unique constraint deciding; order per subject under an advisory lock, applying and flagging late arrivals; apply caps (coalescing, breakers, bulk detection), which stop events bypass; then fan out through the transactional outbox and LISTEN/NOTIFY to subscriptions.

Three classes say where an event came from: observed (a CRM stage change, a signature completed, a payment failed), derived (computed from other events and business state, such as a champion gone quiet or coverage about to fall short) and emitted (produced for others: work ready, meeting booked, stop issued). Every event carries an event identity that survives replay; replay produces no duplicates, and a causal divergence on replay is detected and reported rather than applied.

Delivery is per subscription with a sequence cursor. A consumer checkpoints the cursor it has processed; after a reconnect within the cursor's retention window nothing is skipped. Deliveries that cannot be processed go to a dead letter with the reason and an owner. The absence evaluator, a scheduled job, is the only way "something did not happen" becomes an event.

The schedule catalogue is the complete list of clocked behaviour: timers that produce events (lease expiry, intended-time fire, stop acknowledgement deadline, acceptance window, response deadline), recovery sweeps (readiness and lease, stranded delivery) and jobs (absence evaluator, grading, maintenance). Each entry has an owner and a recovery rule. An interval read of a state table in the work, hand-off, stop or hands modules is a defect the architecture test catches.

Tenant-consistent references. A reference from one tenant-owned row to another is a composite foreign key on (tenant_id, id), so a row of one tenant cannot point at a row of another whatever the application supplies. References into the platform catalogue are the one exception, guarded by a trigger. Version pointers belong to their parent: every active_version_id is a composite key on the parent's own id, so a parent cannot point at another parent's version. There is no archive table. Retention is a policy per table kind; derived records have their own retention separate from the facts they were derived from. Identity merges are journaled as facts, never applied by rewriting history.

People, positions, relationships, initiatives, budgets, customer objectives, observations, commitments, work items, plans and interaction history are held as dated records with provenance and access control, in the same database. Reported information, verified authority and approved knowledge are distinct records with distinct trust. Approved product and policy knowledge, and the worker's long-term memory, live in the Knowledge Substrate, reached through its API with warrants; the platform does not reimplement a knowledge base.

Relationships are stored relationally in PostgreSQL. A graph projection (organisation, person, position, budget, initiative and their edges) can be built from the same tables when multi-hop path queries justify it, isolated from the Knowledge Substrate's stores. It is an option, not a store of its own, and no design decision depends on it.

The platform never speaks a vendor's vocabulary. Field and value mapping is versioned configuration per customer and per connector, because two systems of the same brand differ more than two brands do, and "what changed" must be answerable in seconds.

Connector admission. Every connector meets one common set of requirements: credentials from the tenant's vault prefix, a capability document listing every supported and unsupported capability of its class, health and rate reporting, stable identifiers for every record, idempotent writes on the operation key, receipts with a system reference and version marker for every write, and an authoritative lookup by operation key where the system can offer one. Then it meets the requirements of its class. The inventory class must read stock by item and location with a snapshot time and available-to-promise; reservation, where offered, is a transaction-class write. The quote and order class must create and read quotes with a version, take order intake, acknowledgement and status, and offer cancellation as the compensation path; order submission is two-phase, and status is read-back evidence. The CRM class must accept a suppression change without batching, which is what makes a system eligible to hold contact data at all.

Three integration methods. A native adapter, a scoped API or MCP tool, and an evaluated computer-use path through the hands environment are different methods with different evidence. Read access never establishes write readiness: write capability for a connector and action class is admitted only on recorded evidence from that customer's deployment (a test write, its receipt and its read-back), and the admission is itself a record. Connection readiness has three states: stored, authorised and tested.

Every privileged action class starts at not granted. A grant carries a grantor with standing, a scope, a ceiling, an expiry, a reason and a review interval, and a grantor cannot confer authority they do not hold. Grades per action class are not granted, propose, act with approval, act within limits and act freely; tool grants and prompt-layer edit rights have their own short ladders, and a call resolves all of them with the most restrictive winning. A worker never authors a commitment; it sources one, from a price list, a pricing tool, an approval or a person, and records the source.

The compliance engine evaluates the customer's rule set in the request path before any contact and fails closed on an unanswered dimension. Control paths (a stop, an acknowledgement, a health check) are exempt from business gates so that a gate can never prevent a stop. Consent, suppression and the duty not to misrepresent the worker when asked are floors the platform enforces regardless of configuration. Human access, worker authority, compliance and entitlement are four separate checks with separate records.

Corvair's operating tenant. Corvair's own service operations run as a tenant of kind operations with its own scope and rights: health, cost, pause and release, and only the customer data those need, with every access recorded. It has no commercial authority in a customer's tenant.

A model may propose an outcome candidate. Independent system-of-record receipts or read-backs establish the business event, and the customer contract defines verification, acceptance and the billable unit. The ledger lifecycle is recorded, verified, accepted under the contract, billable, invoiced, with disputes, cancellations and reversals as appended adjustments. The business event is deduplicated across contacts, channels, retries and instances; one owning worker is attributed by a versioned policy and every contributing worker's costs are retained. A definition or skill version change cannot alter a contracted rate. A product's selling price, an internal transfer between a customer's own companies, the customer's budget and Corvair's fee are labelled separately on every record.

Cost. Every model, voice, messaging, email, retrieval, tool, simulation, evaluation, retry and failure cost is recorded against a usage key with an amount state (estimated, reconciled, unreconciled), attributed to tenant, deployment, instance, configuration version, work item, conversation, provider route and trace. Allowances are windows with soft alerts, hard holds and bounded grace for an active conversation; held work keeps its deadline and attribution. Traces may be sampled; cost, outcome and billing records may not.

Scoring covers conversations and non-conversational work alike: tool results, verification failures, waiting time and rework. A finding is classified to one artefact (a business fact, a procedure, a configuration value, a prompt layer, a skill) and becomes a proposal against that artefact's version. Proposals are run against the evaluation cases and the regression suite before a person approves a release. No judged dimension gates a promotion, a grade or a floor without a passed calibration for the rubric version and evaluator binding. A corrected business fact does not change procedure; a changed procedure affects future work only from its release.

The platform runs in a separate Google Cloud project (production and staging as separate projects with the same layout) with its own Cloud SQL instance, backends, buckets, secrets and service accounts. It shares two things with the Corvair estate: the existing load balancer host rules and the Firebase project that issues identity tokens. Cross-project IAM is empty by default; any grant is a documented exception.

Ingress: the application host and the voice host through the load balancer only; jobs and hands have no ingress. Egress: every service through Direct VPC egress and Cloud NAT with reserved static addresses published to customers for allow-lists. Identity: people through Firebase with authorization native in the database and deny by default; six service accounts (api, voice, jobs, hands, tasks, scheduler) plus the CI deployer. Timers run on Cloud Tasks with one queue per priority. Secrets are held in Secret Manager by reference under tenant credential prefixes; a hands environment binds the secrets it is granted and never sees a value it is not. Cloud SQL is regional with a private IP and point-in-time recovery. Observability is Cloud Trace, Logging and Monitoring with billing export to BigQuery.