Skip to content

Images, audio, files, and rich output

BailingHub can accept image, audio, and file inputs, then return Markdown, attachment links, and declarative rich content. Upload, model understanding, and frontend rendering are separate responsibilities and must be configured independently.

After upload, media storage creates a controlled asset URL. The route input policy decides what happens next:

  • images may be analyzed or passed to a compatible multimodal model;
  • audio may be transcribed or passed to a compatible model;
  • files may remain attachments, while text extraction depends on configured processing support;
  • missing models or policies should produce an explicit fallback, not a claim that the content was understood.

Formats, size limits, and item counts are versioned HTTP-contract details. Use the fixed release documentation when implementing a client.

Content Official Widget behavior Additional dependency
Markdown and tables Safe built-in display None
Images and file links Rendered from the final reply and attachment structure None
Charts Declarative fenced payload passed to a trusted renderer registered by the host The business page selects and installs the chart library
bailing-form Built-in constrained fields, validation, submission, and receipt No dynamic-form runtime

The model supplies data only. It cannot select or execute JavaScript, HTML, CSS, remote scripts, or component code. Unknown types, invalid JSON, oversized payloads, and renderer errors must fall back to inert code text.

bailing-form collects ordinary information or user selections. The source reply has already reached done; submit or cancel creates a new user turn and a new job in the same thread.

It does not replace:

  • approval for a high-risk tool;
  • login, identity verification, or authorization;
  • payment confirmation or secret collection;
  • final permission checks before a business-side effect.

Form values remain untrusted user input. A later business action still passes through capability scope, approval policy, and backend authorization.

A custom chat UI declares only renderers it actually implements and trusts. Parse fenced payloads only from the complete done.reply, never mount charts or forms from delta, and never interpret model output with eval or innerHTML.