Governance overview · evidence as of 2026-10-09
The local source inventory contains 18 versioned policy definitions, numbered 15.00 through 15.17. This page summarizes their intended purposes in plain language; it does not publish internal policy code and does not claim that every guard is live.
What this inventory establishes
The policy files describe intended responsibilities, evidence expectations and decision boundaries in the CompanyOS source. Source declarations, tests or local artifacts do not by themselves prove current runtime identity, connector activity, customer operation or production acceptance.
Versioned policy areas
The numbers and filenames mirror the local source inventory. The descriptions below are purpose-level summaries for reviewers and ordinary visitors.
15.00-bootstrap-rehearsal-live-mode.yaml
Separate rehearsal, bootstrap and live operating modes so durable state—not model memory or chat context—determines what work may proceed.
15.01-marketing-lead-acquisition.yaml
Set a bounded order for lead-acquisition resources and keep research within approved evidence, terms and operating envelopes.
15.02-real-lead-provenance-no-hallucination.yaml
Require traceable real-world evidence for active leads and business facts, while keeping synthetic rehearsal data out of real queues.
15.03-outreach-message-and-postcard-design.yaml
Keep email, postcard and live demo distinct, with approved channel sequencing and no invented per-lead exceptions.
15.04-human-authenticity-anti-AI-template.yaml
Guide credible, useful and sector-specific commercial material that is reviewed as work for a real local business rather than presented as synthetic perfection.
15.05-owner-entry-attribution-and-conversation.yaml
Attribute owner responses and operate the private owner experience safely while minimizing unnecessary identification of ordinary visitors.
15.06-proportional-autonomy-and-practical-execution.yaml
Use the lightest control sufficient for the risk, escalate material exceptions and avoid turning routine approved work into needless paperwork.
15.07-tenant-scoped-customer-assistant-and-sales-routing.yaml
Keep customer conversations, design handoffs and sales routing within the correct tenant and accountable owner boundaries.
15.08-first-year-bundle-domain-licensing-renewal.yaml
Describe the intended boundaries for a first-year website bundle, hosting use, renewal and publication control without asserting finalized prices or availability.
15.09-executor-capability-and-connector-contracts.yaml
Treat repeatable employee capabilities as versioned tools or skills, with connectors as bounded adapters rather than independent authorities.
15.10-model-routing-quota-and-fallback.yaml
Choose a proportionate model route and protect capacity for customer work, critical fixes and production preparation, with fallback behavior kept bounded.
15.11-live-and-async-customer-escalation.yaml
Provide a path from ambiguous, sensitive or out-of-authority customer requests to a timely human decision and durable follow-up.
15.12-owner-route-token-QR-and-event-contract.yaml
Make owner routes attributable, revocable and privacy-minimal without treating possession of a link as proof of identity.
15.13-operating-cycle-runtime-and-state-integrity.yaml
Protect one authoritative lead state through parallel work, asynchronous waits, restarts, duplicate events and uncertain external-write results.
15.14-autonomous-recovery-loop-guard-and-escalation.yaml
Allow ordinary recoverable failures to be contained while detecting no-progress loops, protecting quota and escalating useful decision evidence.
15.15-codex-hermes-operating-model.yaml
Separate technical construction authority from permission to execute real-world operations and preserve human authority at protected boundaries.
15.16-named-work-queue-and-priority-governance.yaml
Keep company work ordered by business urgency while retaining the named manager, capability, evidence and handoff responsible for each item.
15.17-company-manager-operation-accountability.yaml
Make model-free manager operations attributable to a named capability, applicable rule, connector context and durable host receipt.
Human gates and accountable decisions
Irreversible, economic, external, production and materially sensitive effects require the applicable human approval or escalation path. A worker or model cannot change policy, approve its own critical output or turn a draft into a customer commitment.
Business facts and consequential decisions should carry provenance, scope and a reviewable record. Plausible generated text is not evidence.
Ambiguous customer requests, authority exceptions, sensitive issues and exhausted recovery paths return to the appropriate human decision-maker.
Recovery is intended to be bounded and observable: contain repetition, protect quotas, preserve state and stop when a useful human decision is needed.
Provenance, escalation and recovery
1 · Trace
Identify the source, scope and date for a business fact or artifact.
2 · Review
Validate the result against the applicable policy, role contract and approval envelope.
3 · Escalate or recover
Correct bounded failures; pause and package the evidence when the decision is material or uncertain.
Important boundary: these governance concepts describe the intended source model. They are not a claim that all policy guards, approvals, connectors or recovery loops are currently active in production.
Compare governance with the conceptual architecture and operating workflow.