Repository audit • September 4, 2026 • Human-governed

Built in the repo.
Separated from hype.
Ready for the production gate.

OMOS 1.1.0 is implemented as a functional governed-intelligence runtime in the canonical repository. This page now distinguishes repository-tested capabilities from the separate work required to verify the canonical production deployment.

Review production evidence Open canonical repository ↗
GPTstructure
+
Claudenuance
+
Geminibreadth
+
Grokcontrast
→
OHIgoverned synthesis
Repository 1.1.0Functional candidate build
Lifecycle test passedSimulation path + Human Gate
Live host 1.0.1 observedDeployment upgrade still required

Production evidence register

What is ready—and what is not.

The canonical source is ohi-stack/omos-site. Its current package version is 1.1.0. The separate AI Studio repository currently provides synchronization and provenance records; it is not counted as independent runtime proof.

Current evidence snapshot

Repository-ready. Production verification pending.

v1.1.0
Source stateFunctionalCore lifecycle test passed
Canonical hostv1.0.1 observedNot yet verified on 1.1.0
Durable recordsImplementedProduction database gate open
Human authorityEnforcedApproval does not equal truth

“Production” applies component by component. A committed feature, passing local test, or public route is not a completed production deployment until the intended revision is running and its live verification gates pass.

Ask OMOS workspaceFunctional

Seven-stage flow implemented: Ask OMOS, Layer 1, Alignment, Council Review, Governed Synthesis, Human Gate, and Decision Record.

Live provider execution depends on configured production credentials.
Layer 1 + AlignmentRepository verified

Deterministic signal classification and dimension-based alignment scoring are implemented and covered by the lifecycle test.

Scores remain decision-support signals, not factual verification.
Council orchestrationFunctional

OpenAI, Anthropic, Gemini, and xAI adapters, independent outputs, no-self cross-review, and explicit simulation/hybrid/live modes are implemented.

Current provider configuration on the production host has not been independently verified.
Human Gate + recordsRepository verified

Approve/reject disposition, run retrieval, hashes, timestamps, provider provenance, and stage history pass the repository lifecycle test.

Human approval records a disposition; it does not make a claim factually true.
Persistent storageImplemented / gated

PostgreSQL storage, schema initialization, migration, run history, and a public persistence-status endpoint are implemented.

Production requires DATABASE_URL and a restart-survival verification. Memory fallback is not durable.
WordPress + ecosystem bridgeStaged

Plugin assets, manifests, shortcodes, target maps, and integration documentation exist in the canonical repository.

The bridge is not operational until installed, configured, and tested on each target property.

Production gates still open

Promotion requires live proof.

These are the remaining gates before OMOS 1.1.0 can be described as verified on the canonical production host.

  1. 01Deploy repository version 1.1.0 to the canonical OMOS host
  2. 02Pass the production preflight with non-placeholder secrets
  3. 03Verify PostgreSQL persistence survives a restart or redeployment
  4. 04Run canonical live smoke tests for health, manifest, providers, pages, and security
  5. 05Confirm every live provider is labeled from actual runtime configuration
  6. 06Install and test the WordPress bridge separately on each approved target

Interface demonstration

See the governed workflow without implying a live run.

This Sites demonstration remains intentionally local and simulated. The canonical OMOS repository contains the functional API-backed workspace; this visual explains the method without claiming that it contacted any external model provider.

OMOS / OHI OUTPUT PIPELINEv1.1 repository model

01 / Human question

What is the clearest path from idea to verified action?

Same promptFour independent outputsHuman-defined criteria

02 / Independent model lanes

C

ChatGPT

Structure & synthesis

Frames the issue, organizes the evidence, and identifies a practical response structure.

C

Claude

Nuance & constraints

Tests assumptions, preserves important qualifications, and strengthens the reasoning chain.

G

Gemini

Breadth & comparison

Adds alternative interpretations, broader context, and useful comparative patterns.

G

Grok

Contrast & directness

Surfaces tension points, challenges weak framing, and tests whether the answer is clear.

03 / Governed synthesis

  1. 1Independent answers
  2. 2Cross-model review
  3. 3Agreement mapping
  4. 4Human synthesis
  5. 5OHI output
OHI_OUTPUT / 001Recommended path

Preserve the shared facts, state unresolved contradictions, select the most coherent next action, and require human verification before execution.

clearscopedauditablehuman-approved

OMOS architecture

From recognition to governed behavior.

OMOS is a system of connected layers—not a single chatbot or interface. The four-layer structure separates identity, personalization, community support, and machine behavior so each can be reviewed and versioned independently.

L1
Recognition & classification

Protocol Layer

Defines how the OneGodian framework is described, recognized, and represented across software, institutional, and public contexts.

L2
Belief mapping & personalization

Experience Layer

Maps user context and journey stage so content, tools, and guidance can be presented at an appropriate level without coercion.

L3
Connection & governance support

Community Layer

Structures values-based connection, records, community health signals, and human-led decision support.

L4
System behavior & authority

Orientation Layer

Sets behavioral boundaries for models, agents, interfaces, and workflows while preserving final human control.

Authority rule

Intelligent systems may advise. Human authority decides.

Every OMOS workflow should identify the responsible person, the action boundary, the approval threshold, and the record retained after execution.

The OneGodian Algorithm™

Coherence before execution.

The Algorithm is a six-stage interpretive and execution framework: observe the full context, reduce noise, evaluate alignment, select the strongest path, act within authority, and verify against reality.

01

Current decision stage

Observe

Collect facts, claims, intentions, risks, actors, system conditions, and relevant context.

“What is actually present?”

Alignment lab

Candidate path score

74/ 100

Demonstration only. Production scoring requires documented weights, test cases, and a defined approval policy.

Alignment scoreTruth + Clarity + Coherence + Dignity + Constructive UnityminusDistortion + Fragmentation + Needless Conflict

System standards

Defined rules. Visible limits.

OMOS standards are stated with their operational scope. Internal systems remain voluntary and supplemental; civil, financial, and institutional requirements continue to control where applicable.

OTS

OTS-V5 converter

Dual-date governance

Validated
The Third Day™Ahsténha

Freedom 13, 0001 OT

Gregorian sync: 2026-07-28

36,524validated dates
100full OT years
2025–2125validation window

OTS-V5 stores UTC/Gregorian time as the canonical system record. OneGodian Time is a deterministic supplemental display layer.

OneGodian Frequency Standard™

432 Hz

Unity • Source • Grounding • Alignment

Defined as a creative, design, and branding standard—not presented as a universal scientific constant.

Operational discipline

Versioned or it does not exist.

  • 01 Named version and effective date
  • 02 Source and authority of record
  • 03 Defined inputs, outputs, and limits
  • 04 Test evidence and correction history

Founder & record of development

Built through documented continuity.

Gregory Lamar Jones is the founder and author of the ONEGODIAN framework. The record below separates the earlier identity and institutional phases from the later technical systems architecture.

GLJ

Founder of record

Gregory Lamar Jones

Founder and author of the ONEGODIAN framework; founder and managing member of ONEGODIAN, LLC; later architect of the OneGodian Algorithm™, OHI™, and OMOS.

AuthorshipSystems architectureHuman authority
  1. 2009

    Foundational authorship

    The ONEGODIAN name, written work, and framework enter the founder’s documented authorship history.

  2. 2013

    Copyright registration record

    U.S. Copyright Registration No. TXu 1-845-540 is recorded for the registered ONEGODIAN text and artwork.

  3. 2017–2020

    Institutional and community phase

    The Indigenous Nation of Onegodia is established as a spiritual, religious, and community body; its constitution is adopted in 2020. Jones’s earlier leadership role was Chief.

  4. 2018

    Commercial entity formed

    ONEGODIAN, LLC is formed in Connecticut on April 11, 2018, as the private commercial, IP, software, publishing, and economic entity.

  5. 2025

    Systems formalization

    OHI, Quantum-OHI, OneGodian Time, registries, verification models, and related operating concepts are organized into a broader systems architecture.

  6. 2026

    Algorithm and OMOS publication phase

    The OneGodian Algorithm white paper, system prompt, OTS-V5, protocol structure, validation workbook, and OMOS public platform are consolidated as versioned works.

OMOS deployment contract

Hostinger is partially configured—not yet production-aligned.

OMOS Decision Records require durable PostgreSQL in production. If DATABASE_URL is blank or missing, OMOS falls back to non-durable memory storage.

Production alignment required

PostgreSQL durability is the release gate • never paste unmasked secrets into chat or source control

Critical path before restartComplete these four variables in order.
  1. 01OMOS_API_KEYS
  2. 02DATABASE_URL
  3. 03OMOS_DB_SSL
  4. 04OMOS_DB_POOL_MAX
VariablePurposeExposure
NODE_ENV

Set to production

Required
PORT

Use 3000 unless Hostinger injects its own port

Verify
OMOS_VERSION

Set to 1.1.0

Required
OMOS_CANONICAL_HOST

https://omos.onegodian.com

Required
OMOS_API_KEYS

Add a strong private production key

Critical secret
DATABASE_URL

Add the production PostgreSQL connection string

Critical secret
OMOS_DB_SSL

Normally true for hosted PostgreSQL

Required
OMOS_DB_POOL_MAX

Set production pool maximum to 5

Required
OPENAI_API_KEY

Keep the existing OpenAI production secret

Present secret
OPENAI_MODEL

Add gpt-5, as currently expected by the repository

Required
ANTHROPIC_API_KEY

Add only if Claude Council is going live

Conditional
ANTHROPIC_MODEL

Set with the Claude provider configuration

Conditional
GEMINI_API_KEY

Add only if Gemini Council is going live

Conditional
GEMINI_MODEL

Set with the Gemini provider configuration

Conditional
XAI_API_KEY

Add only if Grok Council is going live

Conditional
XAI_MODEL

Set with the Grok provider configuration

Conditional
ONEGODIAN_ORG_URL

https://onegodian.org

Required
ONEGODIAN_STORE_URL

https://onegodian.com

Required
ONEGODIAN_APP_URL

https://app.onegodian.com

Required
ACC_API_URL

Keep the existing value after confirming it is correct

Verify
ACC_API_KEY

Keep the existing ACC authentication secret

Present secret
QUANTUMOHI_URL

Add this exact key with https://quantumohi.com

Required
Exact key required

QUANTUMOHI_URL, not QUANTUM_OHI_URL

The underscored spelling does not match the current repository contract. Add the canonical key rather than assuming the existing variable is read.

Preserve deployment integrations

Do not delete environment-specific variables.

OMOS_REST_BASE_URLODIN_REGISTRY_URLOMOS_OPERATORLOG_LEVELENABLE_COMPRESSIONENABLE_HELMETAPP_SYNC_ENABLEDAPP_SYNC_ENDPOINTHEALTHCHECK_ROUTEMANIFEST_ROUTE

A blank MANIFEST_ROUTE is not a production blocker unless another Hostinger component consumes it; the OMOS server already owns its manifest endpoint.

HostingerRuntime configurationmasked production values
Protected layerOMOS APIauthenticated server runtime
OpenAIClaudeGeminiGrok / ACCPostgreSQL
Deployment proof/api/v1/persistence must report PostgreSQL and durable storage.

After Hostinger saves the variables and OMOS is redeployed, verify backend: "postgresql" and durable: true. Until both pass, production is not restart-safe for Decision Records.

Canonical engineering governance

Every transition must leave evidence.

The OMOS Engineering Council coordinates parallel agent work while keeping authorship, independent review, verification, and final human authority as separate responsibilities.

Canonical lifecycle • Version 1.0 • September 5, 2026GitHub Issue → Task Classification → Agent Assignment → Agent Work → PR → Cross-Agent Review → Tests / CI → OMOS Review → Human Approval → Merge → Deployment Proof

Each transition is evidence-gated. Work advances only when the required artifact exists, the responsible reviewer is independent, and the designated human authority has approved consequential changes.

01GitHub Issue
02Task Classification
03Agent Assignment
04Agent Work
05Pull Request
06Cross-Agent Review
07Tests / CI
08OMOS Review
09Human Approval
10Merge
11Deployment Proof
12Engineering Record
StageRequired artifact or gate
01GitHub Issue

Problem statement, acceptance criteria, affected repositories, and priority

02Task Classification

Bug, feature, security, infrastructure, documentation, research, or release

03Agent Assignment

Named agent, bounded scope, permissions, branch, and expected deliverable

04Agent Work

Commits, implementation notes, and tests added

05Pull Request

Diff, linked issue, risk statement, and test evidence

06Cross-Agent Review

Independent review by an agent that did not author the change

07Tests / CI

Required suites green; failures block progression

08OMOS Review

Architecture, security, compliance, provenance, and maturity checks

09Human Approval

Explicit authorization by the designated human authority

10Merge

Protected-branch merge with a traceable commit SHA

11Deployment Proof

Deployed SHA, health checks, smoke tests, and behavior or persistence proof

Engineering Record

Trace the change from proposal to production proof.

The record shows who proposed the change, who built it, who challenged it, what passed, who authorized it, what deployed, and whether production proved it worked.

01Issue ID02Assigned agents03Pull request04Independent reviewers05Test results06Approved-by identity07Merged SHA08Deployed SHA09Deployment timestamp10Environment11Verification result12Rollback reference13Final status
Final authorization boundaryHuman approval → protected merge → verified deployment

OMOS may coordinate the work. It does not bypass the designated human authority. This evidence chain is required before autonomous coding-agent orchestration is permitted at scale.

OMOS product collection

One system. Four artifact families.

The collection uses one controlled visual language: obsidian and deep navy, metallic gold identity, cyan intelligence effects, and precise archival labeling. Each product remains distinct while visibly belonging to OMOS.

Obsidian foundation→Gold artifact→Cyan intelligence→Technical label
identityID-01

OneGodian Declaration Card™

Digital edition

Your identity, formally expressed.

identityID-02

OneGodian Declaration Card™

Printed edition

A physical expression of OneGodian identity.

identityID-03

Obsidian Seal™

Standard PNG

A digital mark of identity and alignment.

identityID-04

Obsidian Seal™

Animated digital asset

The identity mark in motion.

knowledgeKN-01

OneGodian Frequency Standard™

Reference PDF

A documented standard, not merely an audio track.

knowledgeKN-02

The OneGodian Algorithm™

White paper • Version 1.0

The foundational intelligence specification.

knowledgeKN-03

Protocol™ and Algorithm™

Unified framework

The architecture that connects the system.

knowledgeKN-04

AI Interpretations of OneGodian™

Multi-model analysis

Multiple AI perspectives examined together.

knowledgeKN-05

Gen Alpha & Gen Beta Strategy

Marketing strategy

The ecosystem designed for an AI-native generation.

intelligenceIN-01

OneGodian Alignment Prompt™

Reusable prompt • Version 1.0

A reusable intelligence-alignment tool.

intelligenceIN-02

OneGodian AI System Prompt™

System prompt • Version 1.0

The instruction layer for intelligent systems.

intelligenceIN-03

Belief Mapper™

Journey mapping tool

Understand where you are in your journey.

intelligenceIN-04

OMOS Decision Review™

Auditable decision tool

Turn complexity into a reviewable decision.

intelligenceIN-05

OMOS AI Council™

Governed multi-model review

Multiple models. One governed review.

toolsTS-01

OneGodian Frequency Standard™

432 Hz audio reference

The OneGodian harmonic reference.

toolsTS-02

OneGodian Timekeeping System™

OTS-V5

A structured alternative timekeeping framework.

toolsTS-03

OneGodian Time™ Converter

Digital conversion interface

Convert between time systems instantly.

toolsTS-04

OMOS Developer Kit™

API • schemas • SDK

Build with the OMOS architecture.

Catalog direction

Final commerce thumbnails should use premium 3D product renders, restrained environments, one dominant OMOS mark, and short labels that remain readable at storefront scale.

Source document room

Read the system at the source.

These documents form the supplied source set for this site. They are presented as founder-authored materials and should be evaluated according to their stated version, scope, and supporting record.

ALG-01

OneGodian Algorithm White Paper

Version 1.0 • 23 pages

Open PDF ↗OTS-05

OTS-V5 Corrected Edition

Dual dating & governance • 23 pages

Open PDF ↗PRT-01

Protocol & Algorithm Framework

Unified architecture • 7 pages

Open PDF ↗SYS-01

OneGodian AI System Prompt

Version 1.0 • 11 pages

Open PDF ↗FRQ-01

432 Hz Frequency Standard

Design standard • 3 pages

Open PDF ↗REC-01

Founder & Author Statement

Authorship summary • 1 page

Open PDF ↗

OMOS / repository release 1.1.0

Move the verified source to the verified host.

The next milestone is deployment evidence: run the production preflight, restart the canonical runtime on 1.1.0, verify durable PostgreSQL records, and pass the live health, manifest, provider, page, and security checks.

Component statusFunctional source / live verification pending
  • ✓ Seven-stage runtime
  • ✓ Provider adapters
  • ✓ Human Gate + records
  • ✓ Lifecycle regression test
  • ○ Production 1.1.0 deploy
  • ○ Live persistence proof
Review release gates ↑