Reliable Orchestration of an OpenAI-Backed Daily Brief Workflow

Full report

On this page

Executive Recommendation

InternationalIntelligence.org should treat the OpenAI Responses API as a subordinate asynchronous execution service, not as the authority for the Daily Brief’s publication state. The publication system’s own durable supervisor—implemented in its database and advanced through compare-and-swap transitions—must remain the sole authority for process identity, revision, stage, accepted evidence, composition eligibility, and publication readiness.

The supplied project brief correctly reframes the problem from basic API connectivity to distributed-workflow correctness: the essential challenge is whether the site can create, persist, retrieve, validate, reconcile, consume, retry, and clean up provider operations without duplicate jobs, lost results, stale-worker commits, or indefinite stalls.

The recommended architecture has the following defining properties:

The core invariant should be expressed directly in code, database constraints, tests, and operator procedures:

No provider response may publish, advance, overwrite, or invalidate a Daily Brief unless it is attached to the current process ID, expected revision, current stage, live operation generation, and valid fencing token, and its result passes the stage’s local acceptance contract.

Scope and key questions

This report assumes no access to the site’s source code, private prompts, credentials, provider response bodies, account identifiers, or hosting environment. It therefore specifies an implementation-neutral PHP production design based on documented OpenAI behavior and conservative distributed-systems assumptions.

The key questions are:

1. What does the current OpenAI platform officially guarantee for background Responses, retrieval, statuses, web-search evidence, structured outputs, request correlation, cancellation, deletion, webhooks, and retries?
2. Which workflow properties must InternationalIntelligence.org implement locally because the provider does not document them?
3. How should the system handle an API POST that may have succeeded even though the client did not receive the response identifier?
4. How can research, supplemental research, and composition be made independently retryable without losing accepted work?
5. What validation, cost, privacy, and operational controls are required before the workflow can be trusted for unattended publication?

The recommended delivery priority is:

1. Build the local supervisor, immutable contracts, operation reservations, and compare-and-swap transitions.
2. Make ambiguous creation a first-class state.
3. Add deterministic provider fixtures and crash-point testing.
4. Implement evidence-preserving research and composition contracts.
5. Add polling, webhooks, cancellation, and deletion only after the authority model is correct.
6. Run isolated live probes before connecting the orchestrator to publication state.

Official OpenAI Capability Baseline and Recent Developments

Current capability summary

The following findings were checked against current official OpenAI documentation on August 1, 2026. “Documented” means the behavior appears in the official API reference or platform guide. “Engineering consequence” is this report’s recommendation and is not an OpenAI guarantee.

Recent capability timeline

timeline
    title OpenAI capabilities relevant to the Daily Brief workflow
    2024-08-06 : Structured Outputs announced
               : Exact schema adherence introduced for supported strict schemas
    2025-03-11 : Responses API introduced
               : Built-in web search introduced with the new API
    2025-05-21 : Background mode added to Responses
               : Longer-running asynchronous work became directly retrievable
    2026-08-01 : Current documentation baseline verified
               : Retrieve, cancel, delete, webhooks, citations, request IDs, and current status handling reviewed

OpenAI announced Structured Outputs on August 6, 2024, while explicitly noting that schema correctness does not eliminate mistakes within field values. The Responses API and built-in web search were announced on March 11, 2025, and background mode was announced among additional Responses capabilities on May 21, 2025.

Actors and trust boundaries

Documented guarantees versus local obligations

The provider documents mechanisms for creating, retrieving, cancelling, deleting, and receiving completion notifications for responses. It does not thereby guarantee exactly-once job creation, exactly-once webhook delivery, exactly-once local consumption, recovery of an unknown response ID after an ambiguous POST, editorial usefulness, evidence sufficiency, bilingual parity, or preservation of accepted research across retries. Those are application-level obligations.

The appropriate methodology is therefore a combination of:

• immutable command contracts;
• a transactional outbox;
• database-enforced uniqueness;
• leases with fencing tokens;
• compare-and-swap revision transitions;
• explicit ambiguous-outcome states;
• idempotent result consumption;
• source-evidence validation;
• reconciliation instead of blind replay;
• deterministic fault injection;
• bounded operator actions.

Authority Model and Durable Provider Lifecycle

Supervisor state model

A Daily Brief process should have one durable supervisor row, for example:

daily_brief_process
  process_id
  target_date
  locale_set
  revision
  stage
  stage_status
  active_operation_id
  accepted_research_revision
  accepted_evidence_digest
  composition_revision
  publication_status
  health_code
  last_meaningful_progress_at
  next_action_code
  created_at
  updated_at

Recommended process stages are:

RESEARCH_PRIMARY
RESEARCH_ASSESS
RESEARCH_SUPPLEMENTAL
RESEARCH_ACCEPTED
COMPOSITION
COMPOSITION_VALIDATE
READY_FOR_EDITORIAL
READY_TO_PUBLISH
PUBLISHED
DELAYED
QUARANTINED
ABANDONED

DELAYED and QUARANTINED should be overlays or explicit states with a preserved resumable stage. They must not erase accepted research.

A provider operation belongs to one stage attempt:

provider_operation
  operation_id
  process_id
  expected_process_revision
  stage_code
  operation_generation
  request_fingerprint
  contract_version
  request_payload_digest
  provider_response_id_encrypted_or_restricted
  provider_state
  local_state
  create_attempt_count
  poll_attempt_count
  validation_attempt_count
  worker_fence
  lease_owner
  lease_expires_at
  create_started_at
  provider_accepted_at
  last_polled_at
  next_poll_at
  terminal_observed_at
  result_digest
  result_commit_key
  cancel_requested_at
  delete_requested_at
  quarantine_reason
  cost_ceiling
  token_ceiling

The process row answers, “What is the publication doing?” The operation row answers, “What happened to this one external execution?” A provider operation must never answer the first question by itself.

Core invariants

The database should enforce these invariants wherever its engine permits:

Request fingerprint and reservation design

A request fingerprint must identify the semantic and operational contract, not incidental JSON formatting. Compute it from a canonical serialization of:

process_id
target_date
expected_process_revision
stage_code
contract_version
model_policy_version
prompt_template_version or prompt digest
schema_version
canonical evidence-input digest
tool configuration
allowed domains, if any
maximum tool calls
input-token ceiling
maximum output tokens
language requirements
editorial policy version
cost ceiling

Use a construction such as:

request_fingerprint =
    SHA-256(
        "daily-brief-response-v1" ||
        canonical_json(immutable_contract)
    )

The canonicalizer must define UTF-8 normalization, object-key ordering, numeric formatting, array ordering, null treatment, and line-ending normalization. Do not include worker ID, start time, attempt number, transport timeout, or provider request ID in the fingerprint; those describe execution, not the requested result.

operation_generation distinguishes an explicitly authorized replacement from the same logical request. Generation zero is the first creation. Generation one is permitted only after generation zero is conclusively terminal, safely abandoned under policy, or overridden by an audited operator action. The fingerprint stays stable; the generation changes.

Before the network call, durably record:

The X-Client-Request-Id should be derived from a random operation identifier plus generation, not from private text. OpenAI documents it as a correlation aid, including for timeouts, but not as a create-idempotency mechanism.

Suggested bounded provider metadata, where supported by the current request schema, is:

{
  "workflow": "daily_brief",
  "process_suffix": "7F3A91",
  "stage": "research_primary",
  "revision": "12",
  "operation_generation": "0",
  "fingerprint_prefix": "b42a1e5d",
  "contract_version": "research-2026-08"
}

Do not place target article text, private prompts, full process IDs, account identifiers, sensitive URLs, or personal information in metadata. Although metadata may aid interpretation of a response that is later discovered, the current documented Responses endpoint surface does not provide a general lookup-by-metadata operation, so it cannot be the primary ambiguous-creation recovery mechanism.

Complete provider lifecycle

The table below defines the required treatment of every lifecycle step. Codes are illustrative bounded enums.

Normal completion sequence

sequenceDiagram
    participant C as Cron/Scheduler
    participant S as Local Supervisor
    participant D as Database/Outbox
    participant W as Fenced Worker
    participant O as OpenAI Responses
    participant V as Local Validator

    C->>S: Find eligible process
    S->>D: Reserve operation under revision R
    D-->>S: Operation O, fence F
    S->>D: Persist immutable contract and pending-create
    W->>D: Acquire lease for O/F
    W->>O: POST background response
    O-->>W: response_id + queued/in_progress
    W->>D: Attach response_id, set next_poll_at
    loop Only when eligible
        W->>D: Acquire poll lease and verify R/F
        W->>O: GET response_id
        O-->>W: queued/in_progress/completed
        W->>D: Persist observation and next eligibility
    end
    W->>O: GET final response if needed
    O-->>W: output + tool/source evidence
    W->>D: Preserve output and evidence
    W->>V: Validate schema, claims, citations, stage rules
    V-->>W: Accepted
    W->>D: CAS commit under R/F and advance revision
    D-->>W: Exactly-once commit succeeded

Stale-worker rejection

sequenceDiagram
    participant W1 as Old Worker
    participant W2 as New Worker
    participant D as Database
    participant O as OpenAI
    participant S as Supervisor

    W1->>D: Acquire lease with fence 41
    W1->>O: GET response
    Note over W1,O: W1 is delayed
    S->>D: Advance or replace operation
    D-->>S: New fence 42
    W2->>D: Acquire current lease, fence 42
    W1->>D: Attempt to persist or commit with fence 41
    D-->>W1: Rejected as stale
    W1->>D: Record bounded stale-worker event
    W2->>D: Continue current reconciliation

Crash after provider completion

sequenceDiagram
    participant W1 as Worker Before Crash
    participant O as OpenAI
    participant D as Database
    participant W2 as Recovery Worker
    participant V as Validator

    W1->>O: GET response
    O-->>W1: completed + output
    W1->>D: Persist terminal observation and raw-artifact digest
    Note over W1: Process crashes before stage commit
    W2->>D: Acquire new fenced lease
    W2->>D: Read completed, unconsumed operation
    W2->>O: Retrieve again only if required artifacts absent
    W2->>D: Preserve missing evidence
    W2->>V: Run deterministic validation
    V-->>W2: Accepted
    W2->>D: CAS exactly-once result commit

Ambiguity, Polling, Retry, and Reconciliation

Ambiguous create-POST analysis

The most dangerous failure is:

1. the local worker sends POST /v1/responses;
2. OpenAI accepts and creates background work;
3. the client times out or loses the connection before receiving the response ID.

The local system cannot safely conclude either that the operation exists or that it does not exist. Because the current documented Responses API does not expose a general response-list or search-by-metadata endpoint, and because the official request-ID mechanism is documented for correlation rather than create idempotency, the application must not invent an automatic lookup or blindly repeat the POST.

What can be recovered

Required policy

A create attempt should enter one of three outcome classes:

For CREATE_ACCEPTANCE_UNKNOWN:

1. Freeze the active-operation slot.
2. Record the transport phase, elapsed time, cURL error class, client request ID, payload digest, worker fence, and create-start timestamp.
3. Wait through a configurable reconciliation window.
4. Accept a valid signed webhook that identifies a response and can be safely correlated.
5. Permit an operator to request reconciliation, which schedules a fenced local action but does not create work.
6. Escalate to OpenAI support with X-Client-Request-Id when warranted.
7. After the maximum ambiguity age, move to SAFE_ABANDONED_UNKNOWN or retain quarantine.
8. Create generation n+1 only through a separate policy decision that acknowledges possible duplicate cost and prevents generation n from ever committing to the current process.
9. If the old response later appears, preserve the diagnostic event and quarantine or delete it after safe evidence handling; never let it become a second authority.

This policy trades some availability for protection against duplicate cost and conflicting results. That is appropriate for an unattended publication workflow whose source material must remain auditable.

Ambiguous POST sequence

sequenceDiagram
    participant W as Worker
    participant D as Local Database
    participant O as OpenAI
    participant H as Webhook Receiver
    participant R as Reconciler
    participant P as Operator

    W->>D: Persist pending-create, fingerprint, client request ID
    W->>O: POST background response
    O--xW: Connection lost after possible acceptance
    W->>D: Mark CREATE_ACCEPTANCE_UNKNOWN
    D-->>W: Block replacement creation
    alt Signed webhook later arrives
        O-->>H: response.completed with response ID
        H->>D: Deduplicate and store event
        R->>D: Acquire fenced reconciliation lease
        R->>O: GET response ID
        O-->>R: Response object
        R->>D: Correlate or quarantine
    else No response ID becomes discoverable
        P->>D: Request bounded reconciliation
        R->>D: Inspect logs, age, client request ID
        R-->>P: Still ambiguous
        P->>D: Authorize safe abandonment/replacement generation
        D->>D: Fence old generation; reserve generation n+1
    end

Polling policy

OpenAI’s guide demonstrates polling while a response is queued or in_progress. The guide’s example cadence is illustrative; production cadence, ownership, jitter, age limits, and duplicate prevention remain application responsibilities.

Recommended policy:

A response is poll-eligible only when all of the following are true:

provider_response_id is present
provider_state is queued or in_progress
local_state is not quarantined, consumed, deleted, or terminally abandoned
now >= next_poll_at
process_id and expected_revision still match the active supervisor
operation_id is still the supervisor's active operation
cost and age limits have not been exceeded
no valid poll lease is held
no cancellation transition is currently being reconciled

The worker must:

1. atomically acquire a lease and increment the fencing token;
2. re-read process revision and active operation;
3. write a POLL_STARTED event;
4. perform at most one provider GET;
5. write the observation and a durable next eligibility time;
6. release or let the lease expire;
7. never call the provider again in the same cycle merely because the response remains queued.

A browser request must only read a materialized public-status projection. It must not create an outbox command, acquire a workflow lease, issue a provider GET, or invoke reconciliation.

An operator’s “reconcile” action should only create a unique local command such as:

RECONCILE_OPERATION(process_id, revision, operation_id, requested_reason)

The scheduler consumes that command under the ordinary lease and fencing rules. Repeated clicks deduplicate against the command’s unique active key.

Cancellation/completion race

The cancellation endpoint is documented, but asynchronous cancellation can race with ordinary completion. The local system should not decide the stage result solely from the HTTP result of the cancellation call.

sequenceDiagram
    participant P as Operator/Policy
    participant D as Database
    participant W as Worker
    participant O as OpenAI
    participant V as Validator

    P->>D: Persist CANCEL_REQUESTED
    W->>D: Acquire cancellation lease and verify fence
    W->>O: POST cancel response_id
    par Provider may complete
        O->>O: Finish response
    and Cancellation may apply
        O->>O: Process cancellation
    end
    O-->>W: Cancellation-call result
    W->>O: GET response_id for authoritative observed state
    O-->>W: completed or cancelled/other terminal status
    alt completed and operation still locally eligible
        W->>D: Preserve result and evidence
        W->>V: Validate
        V-->>W: Accepted or rejected
        W->>D: CAS commit only if process still allows it
    else cancelled or locally superseded
        W->>D: Record terminal cancellation/quarantine
    end

Retry and reconciliation matrix

The values below are recommended production defaults, not provider guarantees. “Attempt” means a bounded attempt of that specific action, not a new provider response unless explicitly stated.

OpenAI recommends honoring Retry-After, otherwise using bounded exponential backoff with jitter, and warns that failed requests can consume rate-limit capacity. The application should therefore use one durable retry controller rather than stacking SDK retries, PHP wrapper retries, cron retries, and proxy retries.

Stage Contracts and Validation

Why staged work is more recoverable

A single “research the world, choose stories, write both languages, attach citations, and publish” response has one large failure domain. A late composition defect can force expensive research repetition; partial evidence cannot be safely retained; source deficiencies are difficult to distinguish from prose defects; and a retry may select an entirely different event set.

The staged model creates durable checkpoints:

The strongest design does not rely on previous_response_id as the only connection between stages. Instead, the system materializes validated research locally and supplies a bounded evidence package to composition.

Primary-research contract

The primary-research request should satisfy all of the following:

Illustrative schema shape:

{
  "contract_version": "primary-research-2026-08",
  "target_date": "YYYY-MM-DD",
  "candidates": [
    {
      "proposed_event_key": "canonical-short-key",
      "event_date": "YYYY-MM-DD",
      "chronology_precision": "day",
      "headline_fact": "Neutral factual description, not publication prose",
      "regions": ["region-code"],
      "topics": ["topic-code"],
      "claims": [
        {
          "claim_id": "claim-local-within-candidate",
          "claim": "One independently verifiable proposition",
          "source_refs": ["src-1"],
          "support_type": "direct"
        }
      ],
      "sources": [
        {
          "source_ref": "src-1",
          "title": "Source title",
          "publisher": "Publisher",
          "url": "https://example.invalid/",
          "published_at": "YYYY-MM-DD",
          "source_type": "primary"
        }
      ],
      "selection_signals": {
        "international_significance": "high",
        "novelty": "medium",
        "corroboration": "multiple_sources"
      }
    }
  ]
}

The server—not the model—should assign a stable candidate_id after normalization, for example from a process-scoped canonical event key plus collision-safe sequence. A model-provided identifier is input data, not a database authority.

A primary-research response passes only if:

1. at least one usable web_search_call is present;
2. required source details were retrieved through documented source inclusion or citation annotations;
3. each accepted claim maps to at least one retrieved source;
4. candidate and tool-call ceilings were respected;
5. the strict local schema passes;
6. every candidate is independently accept/rejectable;
7. no publication-ready English or Spanish prose appears in fields intended only for neutral evidence.

The OpenAI web-search guide documents both tool-call output and URL-citation annotations, as well as inclusion of a broader source list.

Supplemental-research contract

Supplemental research must be a delta operation, not an implicit restart.

Its input includes:

accepted candidate IDs and evidence digests
rejected candidate IDs and rejection reasons
explicit deficit vector
remaining candidate/source/tool/cost budget
target date and unchanged editorial policy

Recommended deficit codes:

Supplemental output must contain only:

{
  "contract_version": "supplemental-research-2026-08",
  "addressed_deficits": ["CORROBORATION_GAP"],
  "candidate_patches": [],
  "new_candidates": [],
  "unresolved_deficits": []
}

Merging rules:

1. accepted candidate records remain immutable;
2. additions are stored as versioned evidence patches;
3. removing an accepted claim requires an explicit invalidation decision and reason;
4. candidate identity is resolved locally before merge;
5. duplicates merge evidence rather than create new candidate IDs;
6. unresolved deficits remain visible to the supervisor;
7. a second supplemental round receives only remaining deficits;
8. full primary research can be repeated only after a documented contract-level reason, such as a target-date change, broad evidence corruption, or editorial-policy revision.

Safe supplemental-research sequence

sequenceDiagram
    participant A as Research Assessor
    participant D as Local Database
    participant S as Supervisor
    participant O as OpenAI
    participant V as Validator

    A->>D: Read accepted candidates and evidence
    A->>D: Write explicit deficit vector
    S->>D: Reserve supplemental operation under current revision
    S->>O: POST deficit-only research contract
    O-->>S: Background response ID
    S->>D: Attach ID and poll by eligibility
    O-->>S: Completed delta output + source evidence
    S->>D: Preserve delta evidence
    S->>V: Validate patches, new candidates, citations
    V-->>S: Accepted delta and unresolved deficits
    S->>D: Merge additively; retain prior accepted candidates
    D->>D: Advance revision without resetting primary research

Composition contract

Composition receives only locally validated evidence. It should not receive open-ended instructions to “research anything missing.”

Illustrative output:

{
  "contract_version": "composition-2026-08",
  "edition": {
    "target_date": "YYYY-MM-DD",
    "events": [
      {
        "event_id": "evt-...",
        "citation_ids": ["cit-..."],
        "english": {
          "headline": "...",
          "summary": "...",
          "analysis": "..."
        },
        "spanish": {
          "headline": "...",
          "summary": "...",
          "analysis": "..."
        }
      }
    ]
  }
}

Composition acceptance requires:

output_event_ids == approved_event_ids
english_event_ids == spanish_event_ids
output_citation_ids ⊆ supplied_citation_ids
every factual sentence maps to one or more approved claim IDs
no tool-call output exists
no URL appears unless it is in the approved source set
all required language fields are present
dates, amounts, percentages, proper nouns, and qualification levels agree across languages

Composition retry without new research

sequenceDiagram
    participant S as Supervisor
    participant D as Local Evidence Store
    participant O1 as Composition Attempt A
    participant V as Validator
    participant O2 as Composition Attempt B

    S->>D: Freeze validated evidence package E
    S->>O1: Compose from E, tools disabled
    O1-->>S: Structured bilingual composition
    S->>V: Validate schema, claims, citations, parity
    V-->>S: Reject unsupported claim C
    S->>D: Record composition failure; keep E unchanged
    S->>O2: Retry composition from same E with bounded failure codes
    O2-->>S: Corrected structured composition
    S->>V: Revalidate against E
    V-->>S: Accepted
    S->>D: Commit composition exactly once

Structured-output and evidence validation

Structured Outputs improve syntactic reliability but do not remove the need for local validation. OpenAI’s own Structured Outputs materials distinguish schema adherence from truth or semantic correctness, and its examples explicitly handle incomplete responses, refusals, missing messages, and absent parsed output.

Validation should be layered:

Specific detections:

URL normalization must be conservative. It may lowercase the scheme and host, remove a default port, and apply documented redirect mappings captured during retrieval. It should not silently equate unrelated paths, strip semantically meaningful query parameters, or convert a citation to a publisher homepage.

The local validation report should be immutable and machine-readable:

{
  "validation_version": "daily-brief-validation-2026-08",
  "operation_id": "op-...",
  "result_digest": "sha256:...",
  "accepted": false,
  "failures": [
    {
      "code": "CITATION_ORPHAN",
      "path": "/candidates/3/claims/1/source_refs/0",
      "entity_id": "claim-3-1",
      "detail_class": "SOURCE_REF_NOT_RETRIEVED"
    }
  ],
  "counts": {
    "candidates_received": 12,
    "candidates_accepted": 9,
    "sources_retrieved": 22,
    "sources_usable": 16
  }
}

The report should not contain full article text or unrestricted source URLs in ordinary operational logs.

Cost, Cleanup, Observability, and Operational Testing

Cost and denial-of-wallet protections

The system should impose limits before reservation, before POST, after every provider observation, and before replacement generation.

Recommended initial ceilings:

Before submission, use the documented token-counting capability where applicable, or a locally maintained conservative estimator, to reject oversized inputs. The request reference also documents token usage in response objects, which should be persisted as bounded accounting fields.

A process budget can be reserved rather than merely observed:

available_process_budget
    >= reserved_max_cost_for_new_operation

The reservation is released or reconciled when actual usage is known. Unknown-acceptance operations retain their reserved maximum until safely abandoned or discovered; otherwise ambiguity could be exploited to exceed the budget through repeated replacements.

Repeated browser refreshes must not affect provider cost. Repeated cron invocations see either:

not yet eligible
lease already held
operation already reserved
provider job already active
budget exhausted
terminal result awaiting validation

and perform no duplicate external side effect.

When provider or local workflow health degrades, the site may:

• display that the current edition is delayed;
• display the date of the last verified edition;
• keep accepted research and deficits;
• offer one bounded operator command;
• resume from the last durable stage.

It must not relabel yesterday’s edition as today’s, invent a placeholder Daily Brief, omit a delay indicator, or publish unvalidated partial provider output.

Cleanup, cancellation, and deletion rules

Cancellation and deletion have different meanings:

OpenAI documents both cancellation and deletion endpoints. Neither should be used as a substitute for local state transitions.

Deletion eligibility should require all of:

provider_response_id is known
provider state is terminal or local policy expressly permits cleanup
no poll, validation, commit, cancellation, or incident lease is active
required output is preserved locally
required tool/source evidence is preserved locally
citation graph is preserved locally
validation report is preserved locally
usage and request-correlation fields are preserved
result has been committed, rejected, quarantined, or abandoned
minimum operational retention has elapsed
no open incident or operator hold exists

The deletion command should be written before the network call. If deletion succeeds, record provider_deleted_at. If deletion is uncertain, do not assume the object is gone; a subsequent authorized deletion check or delete retry may be appropriate because deleting an identified object is fundamentally different from repeating a create, but the implementation must still interpret documented responses and avoid unbounded retries.

Redacted diagnostics and public status

Public status should be generated from a dedicated projection rather than directly from provider objects.

Illustrative public payload:

{
  "process_suffix": "7F3A91",
  "revision": 12,
  "target_date": "2026-08-01",
  "stage_code": "RESEARCH_SUPPLEMENTAL",
  "provider_state_code": "PROCESSING",
  "health_code": "EVIDENCE_DEFICIT",
  "last_meaningful_progress": "2026-08-01T14:32:10-05:00",
  "next_eligible_cycle": "2026-08-01T14:33:05-05:00",
  "evidence_counts": {
    "candidates_accepted": 7,
    "sources_usable": 14
  },
  "deficit_codes": ["REGION_GAP"],
  "next_action": "WAIT_FOR_SUPPLEMENTAL_RESEARCH"
}

Public values must use bounded enums and counts. They must not disclose whether a specific provider account, project, region, credential, or private endpoint is in use.

Private diagnostic events may include:

full internal process and operation IDs
provider response ID in a restricted field
x-request-id
X-Client-Request-Id
request fingerprint
contract and schema versions
worker identity and fencing token
HTTP status class
cURL error class
attempt and poll sequence
latency
provider status and error code
token usage and estimated cost
result and evidence digests
redacted validation failure paths

They must redact or omit:

API credentials
Authorization headers
private prompts and full provider inputs
raw provider response bodies from ordinary logs
sensitive source URLs
account and project IDs
private filesystem paths
hostnames and IP addresses unless operationally required
personal information
cookies and session identifiers
database credentials
full webhook secrets or signatures

Use field-level allowlisting rather than a best-effort blacklist. Store sensitive artifacts, when operationally necessary, in a separate restricted evidence store with retention, encryption, and access auditing.

Suggested event envelope:

{
  "event_type": "PROVIDER_STATE_OBSERVED",
  "occurred_at": "2026-08-01T19:32:10Z",
  "process_id": "internal-reference",
  "process_revision": 12,
  "operation_id": "internal-reference",
  "operation_generation": 0,
  "worker_fence": 42,
  "stage_code": "RESEARCH_PRIMARY",
  "from_state": "QUEUED",
  "to_state": "IN_PROGRESS",
  "provider_request_id": "restricted",
  "client_request_id": "restricted",
  "fingerprint_prefix": "b42a1e5d",
  "actor_type": "WORKER",
  "diagnostic_code": "POLL_OK"
}

Operator tooling

Operator actions should be commands with explicit eligibility checks:

Every write action should require authentication, authorization, CSRF protection where applicable, an idempotent command key, reason code, actor identity, and audit event.

Deterministic no-network fixtures

A no-network provider adapter should implement the same interface as the live adapter:

interface ResponseProvider
{
    public function create(CreateContract $contract, RequestContext $context): CreateObservation;
    public function retrieve(string $responseId, RequestContext $context): RetrieveObservation;
    public function cancel(string $responseId, RequestContext $context): CancelObservation;
    public function delete(string $responseId, RequestContext $context): DeleteObservation;
}

The fixture adapter should be scriptable by operation and call number:

{
  "create": [
    {"result": "timeout_after_send"},
    {"result": "must_not_be_called"}
  ],
  "webhook": [
    {"after_virtual_seconds": 30, "event": "response.completed", "response_id": "resp-fixture-1"}
  ],
  "retrieve": [
    {"status": "completed", "fixture": "valid_primary_research"}
  ]
}

Required fixtures include:

Property-based or state-machine tests should continuously assert:

active_provider_operations(process, current_revision, current_stage) <= 1
published(process) implies validated_composition_exists(process)
accepted_composition evidence_digest == accepted_research evidence_digest
stale_fence cannot mutate supervisor
result_commit_count(operation) <= 1
provider_create_count(fingerprint, generation) <= 1
replacement_generation > prior_generation
deleted(operation) implies evidence_preserved(operation)
browser_request_provider_call_count == 0

Minimal isolated live-probe strategy

A live probe should exercise real OpenAI behavior without touching publication state.

Recommended design:

A probe sequence is:

reserve probe
create one background response
persist response ID
wait until eligible
retrieve at most once per cycle
validate provider status and schema
preserve minimal evidence
optionally verify webhook correlation
delete after retention condition
record result

A green live probe proves that the selected API path currently works. It does not prove the publication supervisor is correct; deterministic workflow tests and chaos tests must establish that.

Production Acceptance Criteria and Source Record

Production acceptance gates

The workflow should not be enabled for unattended publication until all of the following are demonstrated in a production-like environment.

Recommended launch sequence

Final architectural judgment

The OpenAI platform currently provides the necessary primitives for this workflow: asynchronous Responses, retrieval, explicit statuses, structured schemas, built-in web search with source and citation information, request correlation, webhooks, cancellation, and deletion.

Those primitives are sufficient only when surrounded by a local orchestration system that assumes:

network results can be ambiguous
schedulers and webhooks are at least once
workers can become stale
provider completion is not local success
external creation is not safely repeatable without proof
every result must be reconciled to current authority
every accepted artifact must be committed exactly once
every cleanup operation must follow evidence preservation

The decisive production feature is therefore not another API connectivity test. It is a durable state machine in which the site can explain, for every provider operation:

why it was authorized
which immutable contract it represents
whether creation is known or ambiguous
who currently owns reconciliation
when another call is eligible
which evidence was recovered
why the output was accepted or rejected
whether it advanced the current process revision
what cost was consumed or reserved
when and why it may be cancelled or deleted

When those answers are durable, bounded, and testable, the Daily Brief can recover from timeouts, crashes, duplicate schedules, webhook replays, stale workers, provider delays, malformed output, and composition defects without fabricating content or losing accepted research.

Official sources

• OpenAI API reference, Responses endpoints, request identifiers, compatibility guidance, and response object behavior.
• OpenAI background-mode guide, including asynchronous creation and retrieval-based polling.
• OpenAI web-search guide, including search-call output, citation annotations, and source inclusion.
• OpenAI Structured Outputs guide and launch announcement.
• OpenAI error-code and rate-limit guidance.
• OpenAI webhook guide, including response completion, signature verification, retries, and duplicate-event handling.
• OpenAI cancellation and deletion references.
• OpenAI data-control documentation for Responses retention and background-processing storage considerations.
• OpenAI announcements for the Responses API, web search, and background mode.