Shared context is a projection and coordination plane. Proposals, contracts,
identity checks, assessments, Project To-dos, training, messages, payments,
and provider records remain authoritative in their existing APIs.
Start every job-management session here
GET /contextfor the current objective, workflow, readiness, bounded fresh-priority queue, evaluator health, effective-policy summary, Job Operating Guide digest, blockers, action claims, inconsistencies, and revisions.- In a writable session,
POST /sweepwith that revision. Continue with each response’scontextRevisionwhilehasMoreis true, then read context again. Read-only sessions do not sweep. - Claim one coordinated action before working.
- Re-read the affected canonical record and latest authorized conversation immediately before a consequential write.
- Send the expected context or action revision and an idempotency key.
- Verify the canonical result, complete or release the action, then checkpoint or hand off.
Endpoints
Use the machine-readable OpenAPI document for final request and response schemas.
Context response
The response separates each value’s provenance:
Per-person results keep raw gates separate from operative gates. A manual pass can change an operative assessment gate without erasing the failed raw item. Identity and eligible-location gates are non-waivable.
Evidence references contain privacy-safe resource identity, not message bodies, answers, identity documents, fraud telemetry, contact details, or provider secrets.
Automatic synchronization envelopes
Covered Job Operations, messaging-management, and LMS responses add two top-level fields:synccontains the current private-session delivery, conflicts, recommendations, next operations, and whether a full context read is required; andsyncCoverageidentifies the exact operation and reportsnative,bridged, or intentionallynonecoverage.
sync.resyncRequired is true, read context again
before continuing. If syncCoverage.coverage is none, do not claim that the
operation refreshed shared context.
GET /sync/poll provides a bounded real-time wait. It avoids repeated full
scans while another project manager is working, but canonical resources remain
the final authority.
Deterministic attention queue
OpenTrain evaluates supported conditions on the backend and ranks them using a deterministic score. The default actionable queue contains only signals whose condition is active, evaluator result is fresh, and rule is active rather than shadow. Stale or incomplete evaluator runs remain visible in context health and counts, but do not appear as current priorities. Condition, freshness, and triage are independent. Acknowledging, snoozing, or dismissing one occurrence does not clear its underlying condition. Only a successful evaluator run can clear it. Signal claim is the sole path that turns a finding into owned work, and it returns the linked action lease and signed claim receipt. Claim fails closed while a signal is stale, incomplete, live-snoozed, dismissed, or produced by a shadow rule. Refresh context and wait for a complete fresh evaluation instead of creating work from evaluator-health metadata. Priority indicates what may deserve investigation; it does not establish root cause or authorize a canonical mutation. Fetch the evidence-bearing canonical records before acting.Typed policies and generated guide
Job-wide workflow and agent-behavior rules are stored as typed, attributed, append-only policies. A policy update names the exact active decision it supersedes and records the approving user, recording user, recording agent, effective time, enforcement target, and evidence. Supported canonical enforcement changes are applied atomically with the policy record; external enforcement remains pending until separately verified.GUIDE is a publication target. A guide policy marked APPLIED is present in
the shared Job Operating Guide; that status does not claim that another
OpenTrain subsystem enforces the instruction. The
TRAINING_PRODUCTION_GATE v1 payload contains only schemaVersion and
basis. Record a first-production-task stop rule separately as an attributed
OPERATING_RULE.first-production-task-limit guide policy.
GET /guide projects the current objective, workflow, effective policies,
approved exceptions, active claims, and fresh priorities into a structured Job
Operating Guide plus deterministic Markdown. Its version and checksum also
appear in context. The guide is the job’s shared AGENTS.md-equivalent, not a
second authority: canonical records and effective typed policies remain the
source of truth.
Intents, proposals, and overlays
Use an intent before spontaneous work that has no shared action yet. Active intents have bounded leases and deterministic dedupe keys, so overlapping agents receive the current winner instead of performing duplicate work. Use a proposal when a manager wants a different job-wide workflow, policy, priority, goal, exception, or capability action. A proposal is attributed and reviewable but non-enforced. Accepting it records the review and can link a separately authorized decision, action, or brief revision; review never executes the proposal. Use overlays for flexible guidance that should not become policy. TEAM is owner-controlled shared guidance, PERSONAL belongs to one manager, and SESSION belongs to one private agent session. Overlay entries are attributed untrusted content. Typed-reference lint can flag stale or higher-authority references, but overlays never alter readiness, gates, or effective policy.Version and replay safety
- Every context-changing write carries the exact
expectedContextRevisionread by the caller. A mismatch returns409; refresh and re-evaluate instead of blindly retrying. - Action transitions also carry
expectedActionRevision. - Every mutation requires a stable idempotency key. Repeating the same key and payload converges; reusing a key with different intent returns
409. - Signal transitions also carry the exact
expectedSignalRevision. - Claim leases expire. An expired claimant cannot release or complete the action; a later caller can reclaim it through the guarded claim path.
- Action dependencies must be complete before a dependent action can be claimed.
Delta pagination
GET /delta?sinceRevision=<n> returns events strictly after <n>, plus hasMore, nextRevision, and the current context revision. Continue with nextRevision until hasMore is false, then acknowledge that revision with a checkpoint.
Guarded managed messages
When a message is part of claimed job-context work, use:messages:write and messages:manage, plus an
Idempotency-Key of 8–128 characters using letters, numbers, ., _, :, or
-. Its body includes:
expectedLatestMessageId to null only when the authorized conversation
was observed empty. OpenTrain resolves the authorized Job Message or Proposal
Message to its canonical job, validates the guard, and commits the message and
context advance atomically. A teammate or AI trainer reply, context advance,
action transition, expired lease, or mismatched receipt rejects the send before
creating the message or notifications.
POST /api/public/v1/messages remains the generic backward-compatible send
endpoint. Its optional legacy guard is only a stale-message precondition. It
does not attach or advance shared Job Operations context.
Permissions
Reads requirejobs:read; supported coordination and context writes require jobs:write. The authenticated actor must also have canonical access to the exact job—organization membership alone does not bypass folder or direct-job assignment rules.
Shared Job Context is an always-available baseline agent surface. It has no separate environment, account, or UI rollout flag; normal token scopes and job access still apply.