OmniOS

Problem

Running social publishing and AI-assisted engagement (replies, DMs) at team scale means either paying recurring per-seat SaaS fees for a scheduling tool (Planable-class), or letting an AI model post and reply unsupervised with no audit trail and no way to prove it's safe before it's trusted with real accounts. Existing scheduling tools don't have an AI-autonomy layer; existing AI agent frameworks don't have a fail-closed publishing gate. The two failure modes that make "just let the AI post" unacceptable in practice: an exception mid-generation that silently falls through to a public account, and a bad reply that goes out with no record of which rule approved it or why. A scheduling tool alone doesn't solve either — it schedules what a human already wrote. An agent framework alone doesn't solve either either — most treat "can it post" as a single credential grant, not a decision that has to be re-earned per account, per platform, and re-checked on every event. The brief was to own both halves under one roof: the publishing mechanics (calendar, approvals, campaign hub) a team already expects from a Planable-class tool, and a gate in front of every AI-originated action that can prove, after the fact, exactly why it did or didn't go out.

What was built

OmniOS is a self-hosted social operating system: a Next.js frontend and FastAPI backend that sit in front of a forked instance of Postiz (an open-source social scheduler) for the actual platform connections, and wrap every piece of AI-generated content or engagement in a six-gate approval pipeline before anything goes out. It reached full parity with a Planable-class scheduling tool - calendar/feed/grid/list views, saved views, multi-level approval chains, comment suggestions and annotations, guest reviewer links, analytics report sharing, a campaign hub, and an omni-campaign generator that turns one prompt into platform-specific drafts. New platform accounts start in a 14-day 'shadow' mode where the AI drafts replies but a human decides whether they would have been sent; only once agreement crosses 90% across 100+ events can an owner manually promote the account to autonomous.

Technical approach

The proprietary core is the gate stack (apps/api/omnios_api/services/gate_stack): six pure functions - platform policy, classifier, risk, draft, brand voice, rate limit - each taking an immutable GateContext and returning a GateOutcome (pass/queue/drop/regenerate), run through one orchestrator for both content generation and engagement replies. The design is fail-closed: any uncaught exception in any gate routes to a human queue rather than publishing, and every gate decision writes an audit row to omnios.gate_decisions regardless of outcome. Data model is Postgres with pgvector for embeddings, 30 tables, 53 Alembic migrations, schema-level fields (origin enums, actor_system flag, a system service-account user) deliberately built ahead of need so later autonomy phases require only code, not migrations. Background work runs on arq workers over Redis for the engagement pipeline, metric polling, and cron jobs. LLM routing prefers a self-hosted Ollama stack (llama3:70b, qwen2.5:9b, nomic-embed-text, whisper-large-v3) with the Anthropic API for tasks that need it, keeping most inference off metered APIs. Postiz (the open-source scheduler this forks) runs as an internal-only Docker service with its own dedicated Postgres, never exposed publicly; OmniOS talks to it over a public API surface (/public/v1/...) that required reverse-engineering because the fork's real endpoints didn't match what the OmniOS integration had assumed, and OAuth account connection turned out to have no API path at all - accounts are connected inside the Postiz UI and then pulled into OmniOS via a sync endpoint. The postiz-evolve fork itself carries exactly one commit ahead of upstream (HMAC-SHA256 signing on outbound webhooks); it is used essentially unmodified as an internal publishing engine, not as a place where custom product work happened.

Creative approach

Craft

Not a design-forward property - OmniOS is an internal backend-and-console tool, and the visible UI work (Next.js frontend) tracks the Planable-parity spec's information architecture (calendar/feed/grid/list, campaign hub tabs, approval builder) rather than an original visual language. Where craft shows up is in interaction completeness rather than visual invention: a Cmd+K command palette with a keyboard-shortcuts overlay, a TipTap-backed caption editor with AI rewrite tone presets (professional/casual/punchy/story/educational/promotional), drag-reorder on both the IG grid planner and the multi-level approval builder, and live per-platform post previews rendered against the actual connected handle rather than a generic mock. The four planning views (calendar, feed, grid, list) are each a distinct component built to match how each platform is actually consumed, not one table with filters styled four ways. Postiz itself - the forked scheduler underneath - was left visually untouched; the fork's one commit ahead of upstream is a webhook-signing change, not a UI change, because the product decision was to spend craft budget on the gate stack and the OmniOS console, not on re-skinning a vendored tool that's never shown to an end user directly.

Reframe

The reframe is treating AI autonomy as a gated pipeline with an audit trail instead of a binary on/off toggle. Rather than asking 'should the AI be allowed to post,' the system asks 'has this specific account, on this specific platform, proven itself over a measured shadow period' - autonomy is earned per-account via a quantified agreement-rate threshold, not granted globally. That reframes AI-driven publishing from a trust decision made once into a metric that's tracked continuously and can be revoked. It also reframes the audit trail from a compliance afterthought into the mechanism that makes autonomy possible at all: because every gate writes its outcome to omnios.gate_decisions even when it passes, the 90%-agreement-over-100-events threshold that promotes an account isn't a self-reported claim, it's a number computed off rows the system had to write regardless of whether a human ever looks at them. The schema commits to this ahead of need - origin enums and an actor_system flag exist in the Phase 0 tables specifically so that later autonomy phases are a code change against data that's already shaped right, not a migration plus a backfill of history that was never captured.

Process and what failed

The build hit a hard wall on the Postiz integration: the original adapter targeted endpoints and an auth header format that never existed in the actual fork, discovered only after building against assumptions instead of the real API surface - the client was rewritten against the verified fork contract and pinned with a dedicated contract test so it couldn't silently drift again. Launch itself stalled on an external dependency outside the codebase entirely: LinkedIn's Community Management API review, which blocked account connection with 'nothing left to build' on the OmniOS side. A cloudflared config split (system launchd config vs a stale user-level config file) caused a silent 404 on the public Postiz hostname for a period, traced back to the daemon reading a config file the docs assumed was the active one.

Outcome

Phase 0 (the full chassis plus Planable-parity feature set) shipped 2026-06-02 with the backlog at zero, backed by 63 passing acceptance and unit tests (29 assertions across 12 phase-0 files, plus 15 gate-stack unit tests) covering row-level-security tenant isolation, Alembic round-trips, SSO domain rejection, JWT revocation, and cross-tenant upload refusal. A follow-up adversarial sweep on 2026-07-19 re-verified all 96 items on the Planable-parity checklist against live routes rather than trusting the original commit log, and surfaced four spec lines the checklist had never enumerated - two were shipped that day, two were logged as deliberate deviations rather than gaps. Cloudflare Tunnel connectivity to the internal Postiz instance, which had been silently 404ing on the public hostname because the running cloudflared daemon was reading a different config file than the one being edited, was traced and confirmed live 2026-07-21. The project is parked pending LinkedIn's Community Management API review before any account can be connected and the autonomous loop exercised end-to-end; per the last session handoff, that review is the only remaining launch gate and there is 'nothing left to build' on the OmniOS side. No later phases (direct publishing UI, engagement inbox, long-form repurposing, analytics dashboards) have started.