Concepts on Slidura

Templates and versions

Mon, 01 Jan 0001 00:00:00 +0000

Templates and versions

⚠️ This page is a stub — full write-up coming soon.

A named handle and the immutable .pptx blobs under it.

The catalog

Mon, 01 Jan 0001 00:00:00 +0000

The catalog

A catalog is Slidura’s machine-readable view of a .pptx: every slide, every fillable field, in reading order. It’s produced once per template version by a background catalog job and stored as JSON.

(TODO: full write-up — full vs compact, what counts as a field, how pptx_field_id differs from the editable field_id, where the JSON lives.)

Annotations as the agent brief

Mon, 01 Jan 0001 00:00:00 +0000

Annotations as the agent brief

⚠️ This page is a stub — full write-up coming soon.

The human-in-the-loop quality step that turns auto-named fields into a clear brief for your agent.

The fill.json schema

Mon, 01 Jan 0001 00:00:00 +0000

The fill.json schema

⚠️ This page is a stub — full write-up coming soon.

The shape your agent produces to fill a template.

Builds and credits

Mon, 01 Jan 0001 00:00:00 +0000

Builds and credits

A build is the act of running the fill engine against a template: it reads a fill.json, resolves every field and variable, and produces a finished .pptx. Each successful build consumes one credit.

What costs a credit

One successful build = one credit. Credits are spent when a build moves to started (i.e., when you press Build deck in the web UI or call POST /builds/{id}/start via the API).
If the build fails, the credit is automatically refunded — you only pay for what you receive.

What is free

Uploading templates, running the catalog scan, annotating fields, editing the working fill, and creating draft builds are all free. You can iterate on a fill as many times as you like before pressing Build deck.

The build lifecycle

Mon, 01 Jan 0001 00:00:00 +0000

The build lifecycle

A build is the durable working object that carries both the fill you are composing and the resulting .pptx. It moves through a defined set of states and is never silently deleted.

States

State	What it means
`created`	The fill is editable. The fill builder (or an API/MCP agent) can read and write the working fill. No credit has been spent.
`started`	The build engine is running. One credit has been reserved. The fill is now read-only.
`built`	The build succeeded. The `.pptx` is available for download.
`failed`	The build engine returned an error. The credit was automatically refunded. The build can be reopened.
`archived`	The build’s output file has been cleaned up; the fill is still kept. An archived build can be reopened or copied.

Transitions

created ──start──► started ──success──► built ──archive──► archived
 │ └──failure──► failed ──►──────►─┘
 └── edit fill (PATCH /builds/{id}) — stays in created

Start: validates the fill, spends the credit, enqueues the job.
Reopen: moves a built, failed, or archived build back to created with its fill intact so you can edit and re-run it.
Copy: creates a new created build pre-seeded with the source build’s fill — useful for branching variations.
Archive: explicit archival any time from built or failed; also triggered automatically by the scheduler after 7 days. The fill is always kept; only the output file is removed.

The `/builds/{id}` view

The build view at /builds/{id} switches its layout based on the current state:

Concepts on Slidura

Templates and versions

Templates and versions

The catalog

The catalog

Annotations as the agent brief

Annotations as the agent brief

The fill.json schema

The fill.json schema

Builds and credits

Builds and credits

What costs a credit

What is free

The build lifecycle

The build lifecycle

States

Transitions

The /builds/{id} view

The `/builds/{id}` view