Documentation • Standards • Runtime Evidence
This center separates project operating rules, public explanations, implementation specifications, runtime evidence, engineering governance, commerce rules, and specialized OneGodian research. Repository documents establish what is defined or implemented in source; they do not by themselves prove that the canonical production host is serving that revision.
CANONICAL PROJECT STANDARD
The current project-level authority for architecture boundaries, maturity terminology, Decision Records, persistence, Council behavior, connectors/adapters, MCP, WordPress clients, product strategy, source hierarchy, and engineering priorities.
CAPABILITY
Defines what OMOS may accurately call Conceptual, Prototype, Functional, Verified, or Production and how public capability claims should be bounded.
PRODUCTION
Tracks what has source-level evidence versus what still requires canonical-host deployment verification.
Operating principle
The principal OMOS test is practical: a user submits a difficult question, OMOS processes it through an inspectable governed workflow, the user receives a structured result, consequential authorization remains human-controlled, the Decision Record persists, and the exact record can later be reopened and audited.
Repository ≠ deployment ≠ production proof. Model agreement is comparative evidence, not factual verification.
Terminology, identity rules, interoperability, scope, and policy constraints.
Observe → Distill → Align → Select → Execute → Verify.
Multi-model comparison, critique, contradiction detection, supported dissent, and governed synthesis.
Runtime, orchestration, persistence, APIs, Decision Records, connectors, history, and auditability.
OneGodian model/intelligence provider layer operating inside the OMOS gateway.
Operational command and execution console for agents, approvals, workflows, repositories, and deployments.
Defines the controlled browser journey from Ask OMOS through Layer 1, Alignment, Council, synthesis, Human Gate, Decision Record, restart, and history reopen.
Use public machine-readable interfaces to inspect current route, provider, UI, and persistence state.
Manifest · Health · Providers · Persistence
Decision/Run ID, canonical input, Layer 1, Alignment State, provider provenance, Council review, evidence status, Human Gate disposition, versions, timestamps, hashes, lineage, and ownership belong in the auditable record where applicable.
Issue → classification → assignment → agent work → PR → independent review → CI → OMOS review → human approval → merge → deployment → deployment proof → engineering record.
Agents may implement and test approved-scope work, but they may not commit secrets, bypass protections, self-certify Production, or treat merge as deployment proof.
Current explicit human instruction → production evidence → repository implementation → canonical project documents → project files → earlier decisions → older drafts. Conflicts are surfaced, not silently blended.
OMOS uses provider-neutral connectors and explicit authorization boundaries. Primary model classes include OpenAI, Anthropic, Gemini, xAI, and OLLM/local OneGodian models where available. A configured provider is not automatically a verified live provider.
Model, Data, Action, and Environment connections share common OMOS contracts. Connector = access/transport/authentication. Adapter = translation into OMOS-native objects/actions.
MCP provides interoperability and tool access. It does not become the authoritative database, registry, identity system, financial ledger, or source of record merely because a system exposes MCP.
OLLM is a first-class model/intelligence provider layer within OMOS; OMOS remains the runtime and orchestration authority.
OMOS commercial positioning remains outcome-first: help users turn AI answers, conflicting information, documents, and difficult decisions into structured, reviewable courses of action. Paid access must map to real implemented entitlements.
Commerce chain: Checkout → verified server-side payment → entitlement → authorized run allowance → governed OMOS run → Decision Record → Dashboard History.
Commerce Entitlement Specification ↗ · Pricing · Shop
Core materials include the OneGodian Protocol™, OneGodian Algorithm™, O-H-I architecture, OTS-V5, system-prompt material, GCD synthesis, institutional classification, and specialized OneGodian research. Research/theoretical material remains separately classified and does not displace established scientific evidence unless independently validated.
Protocol · Algorithm · O-H-I · Artifacts & Research
OTS-V5 is the current OneGodian timekeeping standard for derived OneGodian Time representation. UTC remains the canonical machine timestamp and Gregorian/civil dating remains the controlling external civil/legal reference where applicable.