How Writes Work

Writing content in FoxNose is not a single write to a database. Every change runs through a revision pipeline that keeps your records, their embeddings, and their search indexes in sync — so what your agents retrieve always matches what you published.

The Revision Pipeline

When you write content, you are working with a Revision — a versioned change to a single Resource. Each Revision moves through the same ordered stages:

1. Create or update a Revision. You author or edit the content as a draft Revision.
2. Validate. The content is checked against the Collection's current schema.
3. Vectorize. Embeddings are generated for the vectorizable fields.
4. Index. The records and their vectors are written into the search indexes.
5. Publish. The Revision becomes live.

Until you publish, nothing is served. This gives you a safe draft-then-publish workflow: you can prepare and validate changes without affecting what applications and agents see.

Flux Serves Only Published Content

The Flux API — your read and delivery surface — returns only published Revisions. Drafts, in-progress edits, and unpublished changes are never exposed through Flux. Publishing is the single, explicit moment when a change goes live.

Records, Embeddings, and Indexes Stay in Sync

Because vectorization and indexing are stages of the same pipeline, embeddings update on publish automatically. You never generate embeddings yourself, run a separate indexing job, or reconcile a vector store against your records. When a Revision publishes, its records, its embeddings, and its search indexes all advance together.

This is what lets FoxNose combine structured, keyword, and semantic retrieval in a single call without drift: there is no window where the vectors describe an older version of the content than the records do.

Write Operations and Billing

Write operations are volume-weighted. A single request counts as 1 write for content up to roughly 500 embedded tokens; beyond that, it scales in proportion to the amount of content embedded:

write_operations = max(1, ceil(embedded_tokens / 500))

The floor is always 1, so a small write is always exactly one write. A larger write — say around 1,500 embedded tokens — counts as 3. This weighting reflects the real embedding cost of a write and keeps a single large import from being billed the same as a tiny edit.

For current write rates and plan allowances, see Billing & Usage.

Related

• Schema Migrations → How schema changes interact with existing Revisions.
• Management API — Revisions → Create, update, and publish Revisions programmatically.
• Billing & Usage → How writes are metered and priced.