Expand description
The turn’s files, on their way to a model.
§The half that was missing
Attachments already travel end to end at the plan level: a turn carries
them, the interpretation schema offers attachment_extraction as evidence
pinned to the identifiers the turn actually has, and an act can name a file
so an application’s own extractor fetches the bytes and rewrites the command.
That is how a document’s numbers reach a record without passing through a
model at all, and it needs nothing from here.
What was missing is the model seeing the file. Nothing built a
ContentPart from an attachment, so a turn carrying a photograph reached
the model as a sentence mentioning one. An adopter whose extraction is a
vision call behind a domain prompt has no fallback when it returns nothing —
a receipt photographed at an angle, a scan of a scan, a document that is not
what the prompt asks for — except “I cannot read this”, on the turn where the
user has just done the work of taking the picture.
§What is not decided here
Which providers can accept what. A part carrying an image makes the request require vision and one carrying a document makes it require documents, both derived from the part itself, so the router picks a candidate that has them and falls back through the chain like any other requirement. A file one vendor refuses and another accepts is therefore already handled, and handled in the one place that knows the vendors.
Structs§
- Attachment
Copy - What a user is told about a file the model was not shown.
- Omitted
Attachment - One file the turn carried and the model was not shown.
- Turn
Attachments - The turn’s files as a model can be given them, and the ones it cannot.
Enums§
- NotShown
- Why a file the turn carried was not put in front of the model.