Skip to main content

Authority records

Campaign records live below workspaces/{workspaceId}/brands/{brandId}. Every reference contains the workspace, brand, stable ID and immutable revision. Every plan and item pins an exact approved StrategyRef. Independent work has a null campaignRef. A new initiative creates a campaign and its first plan revision. Existing-work placement resolves planId/itemId, or campaignId/planId/itemId, against current authorized records. Completed item revisions remain in plan history.

Planning policy API

GET /api/settings/planning reads the active policy. PUT /api/settings/planning requires an authenticated workspace administrator and this body:
These values are an example, not defaults. Planning requires a stored policy. Initial creation uses expected revision zero; updates require the current revision. A stale revision is rejected. The timezone is an IANA name. Calendar weeks begin on local Monday and observe daylight-saving transitions. Total production capacity counts unfinished work; weekly capacity and channel cadence retain completed commitments. Required assets resolve from the authoritative artifact store. Dependencies pin exact item revisions and must be completed before selection.

Commands and execution

ready_for_planning intake materialization checks the expected draft revision, final message identity and unchanged active strategy. One transaction stores the campaign when applicable, plan, item, receipt and dispatched intake state. An uncertain commit is resolved by reading that exact receipt. Chat advance_plan claims eligible work through the planning command transaction. Chat manage_calendar accepts an exact current item and an ISO timestamp with an explicit offset. Ambiguous requests and changes outside strategy, capacity or approved work create durable proposals. Proposals do not authorize execution. External Google Calendar changes still use the normal effect confirmation. Selection creates the execution job, binds the exact item revision and creates its stage outbox in one transaction. Recovery reuses that binding. Completion permits the next eligible item; failures retain retry or dependency state. Retry admission rechecks current strategy, item binding, policy, concurrency, cadence, dependencies, assets and unresolved effects. An ineligible retry remains pending without a new outbox; completion or recovery can later resume the same job exactly once. A permanent failure requires an administrator’s durable deployed-fix decision. POST /api/jobs/{id}/retry accepts afterFix: true, a stable requestId, a reason, expectedGeneration equal to the displayed job’s controlEpoch, and expectedFailure containing the complete failure object from that job. The record at jobs/{jobId}/permanent_retry_authorizations/{id} pins the tenant, item reference, actor, decision time, exact failure digest and expected generation. It grants retry admission only; all effect approvals still apply. Ordinary transient retries use an empty request body. When capacity is occupied, the authorization remains pending with the failed item and no new outbox. Recovery by the host service or an administrator transactionally rechecks admission and consumes that exact authorization with the next outbox generation on the existing job. Changed failures, stages, item bindings or job generations mark it stale and require a new administrator decision. Exact API and recovery replays read the retained authorization without issuing another decision, outbox or dispatch. A new failure cannot reuse a consumed authorization. Calendar changes before execution create new immutable item and plan revisions and revise unclaimed dependents in the same transaction. Claimed, completed or approved dependents hold the change as an unapplied disposition proposal. Any existing job, outbox, approval, receipt, effect claim or operation protects an item from acquiring a second executable revision. Source-backed editorial inputs live on each item’s immutable production context, so appending an independent deliverable cannot change another item’s sources or execution inputs. GET /api/planning/proposals/{id} returns the exact proposal and its disposition authority digest. An operator can POST requestId, expectedAuthorityDigest and decision: "keep_existing_execution" to decline that calendar change while retaining the existing execution. The transaction rereads job, action, approval, command, claim, receipt and operation authority. Changed authority requires reconciliation and a current proposal. A replay returns the original disposition receipt. This disposition does not authorize an unresolved effect or create replacement work. The calendar feed includes plannedItems and planningPolicy. Workspace chat context and the production panel read those same authority records. Execution-job editorial fields are projections rebuilt from the pinned plan and item.

Source-free production

Source-free work carries operator_context, the exact operator brief and its context digest. It has no evidence IDs, analysis digest or permission to assert factual claims. The host currently permits creative x_post, linkedin_post, caption and compatible content_pack requests. Other output selections remain blocked until source evidence is provided and bound. Source-backed work retains the job-specific source binding and sealed source manifest.

Verification boundary

Local integration tests exercise DynamoDB Local transactions, MinIO artifact readiness, replay/recovery and actual Python-serialized drafting payloads through TypeScript validators. They do not establish live model quality or authenticated cloud/effect execution.
Last modified on September 14, 2026