VI Engine

Social content work loses context between tools: a trend becomes a brief, the brief becomes a draft, an approval happens elsewhere, and publishing results rarely inform the next plan. The product brings that lifecycle into a workspace with brand context, campaigns, posts and review history.

The engineering problem is broader than generating copy. A suggested action must refer to the correct workspace and account, survive a review delay, and produce an understandable outcome. A fluent answer cannot stand in for an authorized publish operation.

The frontend is a Next.js and React application with TypeScript. The agent workbench, composer and calendar share workspace context. A Python FastAPI backend exposes application routes and calls services for campaign planning, agent execution, account readiness and scheduling.

The data layer uses async SQLAlchemy sessions and versioned Alembic migrations. Records and queries carry workspace scope; membership and ownership checks decide which workspace a caller can use. Database migrations also add row-level security policies and restrict direct access to sensitive tables. These controls complement application authorization: an RLS migration alone is not evidence that every application path is isolated.

Scheduled publishing uses durable database state and claims. Optional queue wakeups trigger the existing scheduler rather than becoming a second authority for whether a post should be sent. This separates waking work from authorizing an external side effect.

Trends → Plan → Create → Approve → Publish → Learn describes the product workflow, rather than an unrestricted autonomous loop.

1. Trends: research services gather planning signals; workspace and brand context ground the brief.
2. Plan: the campaign planner persists strategy in content plans and uses campaigns and posts as execution records.
3. Create: the agent and composer prepare drafts for a selected account and platform.
4. Approve: publishing and scheduling proposals become explicit actions for human review.
5. Publish: account readiness, consent, approval and scheduler state govern the call to a platform adapter.
6. Learn: campaign learnings are stored and surfaced in planning and agent context. The broader reusable campaign-memory loop remains incomplete.

The approval unit is a proposed action with its payload and workspace context. Publishing and scheduling require explicit human approval. The server owns the action schema and approval authority; model output is not allowed to declare itself approved.

Approval envelopes bind authorization to action content and expire. Execution checks action state and integrity before proceeding. The MCP implementation similarly returns an exact preview for consequential scheduling and reply operations, then requires confirmation of the same arguments. A changed payload must not inherit permission from an earlier preview.

Durable action identities and idempotency records help separate a repeated request from a new action. An uncertain external outcome needs reconciliation before another attempt: the interface must distinguish a proposal, an approval and a confirmed result. Drafting or asking for a revision does not authorize a send.

The private codebase contains a remote Model Context Protocol connector and a separate OAuth authorization implementation. The public product wording still treats MCP access as planned and unavailable. This case study describes those implementation boundaries without claiming that an external client can connect today.

The connector binds credentials to a workspace, rechecks membership and entitlement, and scopes record lookup to that workspace. Its permission model separates reading, drafting, publishing and inbox replies. The reserved scheduling scope does not itself grant publishing authority.

The OAuth implementation uses authorization-code consent with PKCE, known scopes and workspace binding. Consent grants a subset of requested permissions; refresh can narrow that grant. Credential revocation and replay checks are part of the implementation. OAuth consent and human approval of a specific publish action serve different purposes and neither replaces the other.

Real-client interoperability and the OAuth-to-transport rollout remain release work. Exposing protocol code before those boundaries are verified would turn an implementation milestone into an unsupported availability claim.

A connected account is not proof that a platform has approved every permission. The code and public compliance page support a constrained publishing scope; the product-status ledger does not establish completed platform app review.

• Durable state over conversational memory. Plans, posts and approval records live in the data layer. Conversation helps form a proposal; persisted state decides what can execute. The trade-off is explicit state transitions and reconciliation work.
• Reuse a planning root. The campaign planner extends the existing content-plan record and reuses campaigns and posts. This limits parallel data models, while making versioning and migration of planner state a continuing concern.
• Separate capability from authority. Tools expose bounded operations and permission scopes; consequential actions need their own review. That adds a human step, but keeps a useful agent from becoming implicit permission to publish.
• Treat retries as a state problem. Database claims and durable action identities support recovery across requests. A remote timeout is not enough evidence to repeat a send. This is more involved than a generic retry wrapper.
• Platform-specific adapters. Accounts have different publishing and approval requirements. Shared orchestration can reuse services, while adapters and readiness checks retain those differences.

These trade-offs are an interpretation of the implemented boundaries, not a claim that the lifecycle vision is finished.

Workspace membership, scoped data access and database policies form separate layers of isolation. Agent action schemas prevent model-supplied approval metadata from becoming authority. Action-bound approval, replay checks and durable execution state constrain consequential operations.

The operations subsystem has a durable system-wide emergency stop. Its enforcement reader fails closed when the stop cannot be read, and an observed stop remains engaged through refresh failures. This is a system control; this case study does not claim a separate per-workspace kill switch.

Platform credentials are encrypted at rest, and disconnect revokes publishing access while preserving the audit record. Integration rollout is gated rather than inferred from adapter code. These are implementation controls, not a claim of a completed independent audit or certification.

The private test suite includes negative cases for workspace isolation, MCP authorization and scope handling, OAuth replay, approval integrity, and emergency-stop behavior. Operations invariant tests enumerate related writers and tools, while a mutation harness removes controls to check that the corresponding tests fail.

The useful question is whether an unauthorized action is refused, not whether a happy-path request returns a success response. Stubbed integrations help test deterministic failure and recovery paths; they do not prove a real platform has approved the application or accepted a post.

Pull-request CI classifies changed areas and runs applicable backend, frontend and integration gates. The release process separates CI from deployment: main produces a staging candidate; promotion requires acceptance evidence for that candidate and an owner-triggered release. Workflow code checks source and artifact identity before promotion.

This page reports the testing approach and release design. It does not publish a test count, coverage percentage or operating performance figure.

• Complete and verify platform app approvals before widening publishing access.
• Validate external MCP clients and the OAuth transport boundary before offering public connection steps.
• Extend campaign learning into reusable planning memory while preserving workspace boundaries.
• Continue negative-path testing, reconciliation checks and acceptance evidence as the invite-only Private beta develops.

Those are engineering priorities, not launch dates or commitments. Explore the product at viengine.social.