Skip to main content

Event intake AI platform research (2026-09-25)

Scope: OpenAI API support for turning event posters and freeform text into an editable VRDex event draft. This is platform research, not a tested model choice or an implementation decision. Sources are first-party OpenAI documentation, checked on 2026-09-25. BASIC later clarified that a valid event contributed for another community should publish immediately after preflight, without prior community acceptance. Human review of the extracted fields by the contributor is still required before that publication attempt.

Findings​

  • One multimodal input is feasible. Responses accepts text and input_image content together. Images can arrive as a qualified URL, Base64 data URL, or uploaded file ID; supported formats include PNG, JPEG, WEBP, and non-animated GIF. Images consume input tokens. The model can miss small, rotated, or stylized text, so poster parsing needs a visible source image and editable draft, not an auto-published record. Use detail: high initially and evaluate original for dense flyers on supported models. Images and vision
  • Typed output is available. Responses text.format with a strict JSON schema can constrain the draft's shape. Strict schema support is a subset of JSON Schema: the root must be an object, objects need additionalProperties: false, and every property is required. Nullable fields represent absent event details. Handle API refusal and incomplete output separately from successful schema parsing. Schema adherence cannot make inferred dates, performers, or IDs factually correct. Structured Outputs
  • VRDex can supply bounded tools. Responses function calling can request named functions with strict argument schemas; VRDex executes the functions and returns results by call ID. tool_choice can restrict available tools, and parallel_tool_calls: false permits at most one call per turn. Suitable read-only tools are search_people, search_communities, and resolve_local_time (IANA zone, date, local time, ambiguity information). Keep entity matching and time calculation in VRDex code, with the model choosing among returned candidates or marking unresolved. Do not expose event creation or profile mutation as model tools. Function calling
  • A narrow VRDex-owned agent loop fits this task. OpenAI distinguishes the managed Agents API for long-running tasks, Agents SDK for app-owned workflows, and Responses for direct calls. Intake is a short, deterministic draft flow with VRDex authorization and a shared web/MCP contract. A server-owned Responses loop with a small call budget and fixed read-only tools is the simplest starting point; an SDK becomes useful if handoffs and richer tracing justify it. This is an architectural inference, not a platform requirement. OpenAI is deprecating the visual Agent Builder, with a stated November 30, 2026 shutdown, so it is a poor dependency for new intake work. Agents overview, Agent Builder
  • Latency and cost need measurement on real flyers. Image size/detail affects billable input tokens; model output and extra tool round trips add latency. OpenAI recommends fewer generated tokens and requests. Use a compact draft schema, cap output/tool iterations, record token usage and elapsed time, and compare candidate vision-capable models on a labeled fixture set before choosing one. Pricing varies materially by model and processing tier, so keep model and detail configurable rather than baking a per-poster price into the design. Images and vision, Latency optimization, Pricing, Model selection
  • Treat posters and text as untrusted data. A poster can include instructions to the model. OpenAI recommends adversarial testing, bounded input/output, and human review of outputs. The agent should extract evidence, never act on poster instructions, and return a draft for the contributor to correct and publish through the same preflight as manual entry. Community staff and moderators can correct or remove a published event afterward. Safety best practices
  • Data handling is a design choice. OpenAI states API data is not used for training by default. Responses stores application state for at least 30 days by default or with store: true; use store: false if VRDex does not need that state, while recognizing ordinary abuse-monitoring logs may retain customer content up to 30 days. Uploaded files need explicit expiry/deletion. Image inputs are scanned and may be retained for manual review if flagged. Remote MCP tools are third parties with their own data policies, another reason to run these few lookups inside VRDex rather than send contributor content to a remote MCP server. Data controls

Proposed output boundary​

Return an event draft, not a publish command. A compact root object could contain event (title, description, community candidate, date, start/end, timezone, venue/link), sets[] (performer label, candidate person ID, local start/end), evidence[] (field path, source text/region description), uncertainties[] (field path, reason, alternatives), and lookup_candidates[]. Each field should allow null or an explicit unresolved state where source material is partial. Distinguish directly read facts, calculations, and guesses. Confirm all resolved IDs against current VRDex data and validate the final payload with the ordinary event domain schema before storing a private draft. A separate user action attempts immediate publication through deterministic and, if justified by evaluation, AI-assisted spam checks. This shape is a recommendation based on the structured-output and tool constraints above; it needs agreement with the existing event contract.

Suggested execution: validate input size/type and contributor identity; pass text and/or image to one Responses call; answer at most a small fixed number of read-only lookup/time tool calls; request strict draft output; reject/refine refusal, incomplete or malformed results; present the source and draft for human correction; publish only after explicit contributor action and preflight. A no-AI manual form should produce the same intake type. The moderation endpoint classifies harmful content, not event spam or event authenticity; those are separate product checks and require their own measured classifier if AI is used.

Open questions for product and evaluation​

  1. BASIC now allows almost all fields to remain partial in a private draft and a date-only event to publish with time TBA. The remaining publication minimum recommendation is community, identifying title, and event date. In particular, lineups with names but no matched person IDs should remain useful public labels rather than being discarded.
  2. What is the source-of-truth timezone when a poster omits it, and how should ambiguous DST times or cross-midnight sets appear in contributor review?
  3. Should a draft retain the source poster, source text, and field-level evidence, and for how long? This affects both reviewer trust and storage/privacy policy.
  4. What is the acceptable quality and cost threshold? Build a representative fixture set of clear, dense, ambiguous, and deliberately misleading posters; measure field accuracy, false identity matches, latency, tokens, and cost before picking a model/detail level.
  5. How many lookup attempts should one intake allow, and should community lookup be preselected from the page or performed by the model when the contributor enters from a general event flow?

No paid API calls were made for this research.