Iteration Layer
Products
Use Cases
Resources
Pricing
Documentation navigation

Auditability

Iteration Layer gives teams structured outputs, project scoping, and integration patterns that make content-processing workflows easier to review.

What Makes A Workflow Auditable

An auditable workflow keeps enough context to explain what happened without storing more customer content than necessary.

Useful audit context usually includes the API used, request timestamp, project or client scope, input source identifier, output status, confidence values where available, review decision, and delivery destination.

Which Response Fields Help Review Outputs

Structured response fields help reviewers understand what the API produced and how confident the result is.

Document Extraction returns typed values with confidence and source context where supported by the field. Document-to-Markdown returns normalized content that can be reviewed, diffed, stored in your system, or sent into downstream workflows.

How Should Projects Be Used For Audit Boundaries

Use projects to separate clients, environments, or workflow families.

Project boundaries make API keys, usage, budgets, and reporting easier to review. They are useful for agencies and internal platform teams that need to show which workflow belongs to which client, department, or product surface.

How Should Confidence Be Handled

Confidence should be treated as a workflow input, not only as display metadata.

For extraction workflows, route low-confidence fields to human review, store the review decision in your system, and avoid treating uncertain values as final business records without validation.

How Should Webhooks Be Audited

Webhook receivers should record delivery metadata and review status in the system that receives the result.

Iteration Layer retries webhook delivery when your endpoint is unavailable. Your endpoint remains responsible for durable storage, internal access control, and downstream retention after successful delivery.

What Should Not Be Logged

Audit logs should avoid storing full documents, raw personal data, and generated artifacts unless your retention policy requires it.

Prefer narrow metadata, stable identifiers, confidence summaries, status transitions, and review decisions. This gives reviewers enough context without turning audit logs into a second content store.