← DevelopersConnection & Adaptation Layer

Connect external systems without surrendering source-of-record boundaries.

A connector establishes controlled access. An adapter translates provider-native resources and actions into an OMOS common contract. OMOS then applies policy, provenance, Human Gate requirements, least privilege, and audit rules before the capability is used.

EXTERNAL PLATFORM → ADAPTER → OMOS CONNECTION GATEWAY → OMOS RUNTIME → ALGORITHM / O-H-I → DECISION / AUTHORIZATION → ADAPTER → EXTERNAL PLATFORM

Model Connections

OpenAI, Anthropic, Gemini, xAI and future OLLM providers. These define who OMOS can reason with.

Data Connections

GitHub, Google Drive, PostgreSQL/Supabase-compatible data, WordPress, QRV and approved OneGodian APIs. These define what OMOS may read or synchronize.

Action Connections

GitHub, WordPress, Stripe, email, calendar, ACC and deployment actions where separately authorized. Write access is never inferred from read access.

Environment Connections

Local runtimes, development environments, Blender, Unreal, robotics, IoT and XR systems where separately approved and safely scoped.

Developer connections vs. OMOS connections

ChatGPT, Claude, Gemini, Codex, Antigravity, or another developer application may itself be connected to GitHub, Drive, Stripe, Supabase, WordPress, or other services. That helps developers work on OMOS, but it does not give the OMOS runtime the same access. OMOS requires its own explicit connector, credentials or delegated authorization, capability scope, health state, provenance, and audit trail.

Shared state, not shared memory. OMOS should synchronize authoritative records through connectors rather than assuming one model application remembers what happened in another. Each synchronized object retains its source and authority class.

Source-of-record matrix

System	Authoritative role	Initial OMOS posture
GitHub	Code, commits, pull requests, releases, CI evidence	Read/status first; controlled writes through Engineering Council
Google Drive	Documents and approved source material	Read/index first; writes only when explicitly authorized
PostgreSQL / Supabase-compatible infrastructure	OMOS runtime state and Decision Record persistence when configured	Read/write within owner and schema boundaries
WordPress	Published OneGodian site content and distributed bridge surfaces	Controlled two-way sync by site/route scope
Stripe / OneGodian.com	Products, prices, subscriptions and payment state	Read/verify first; commercial writes separately authorized
QRV.Network	Verification / credential records where activated	Controlled verification integration
ACC	Approved execution control plane	Action handoff only after OMOS/human authorization

Required connector record

source · connector_id · authentication_scope · permissions · sync_direction · object_type · external_id · omos_id · source_timestamp · received_at · provenance · conflict_policy · last_sync · health · audit_events

Normalized interface

connect() · authenticate() · capabilities() · health() · read() · search() · sync() · invoke() · write() · subscribe() · cancel() · reconcile() · audit() · disconnect()

Configured capability is not authorization. Synchronization is not verification. Write access and consequential execution remain least-privilege and Human-Gate controlled. Secrets stay server-side.

Model Connectors Control Center Runtime Manifest