Skip to main content

​
Purpose

This guide covers the recommended setup for teams moving from build to production on the Affinda platform - how to structure workspaces, manage model memory, and handle changes safely without disrupting live processing.
These are recommendations, not hard requirements. Adapt the structure to fit your team size, governance model, and rollout cadence.
We recommend separating your organization into three workspaces, each with a clear purpose. Keeping them separate makes it easy to control access, isolate change, and keep production predictable.
Workflows Best Practises
1

Training workspace

The source of truth for what the model has learned. All model memory documents live here.
  • All confirmed model memory documents stored here
  • Annotations updated here when fields or behavior change
  • New document variations added here first
  • Access restricted to configuration owners
2

Dev & Test workspace

A staging environment for validating changes before they reach production. Also used for UAT.
  • Document types configured in Training are linked here
  • Integration testing space 
  • No independent model memory; inherits the Model memory that lives in Train config
  • Safe to experiment and break things here
3

Production workspace

Live document processing only. No training activity happens here.
  • Model memory toggle turned off
  • Document types promoted here only after testing
  • All documents processed via API from here
  • No direct schema edits — go through Training first
Access control: keeping workspaces separate lets you control who sees what. Only configuration owners need access to Training. Your operations team works in Production. Dev/Test is for internal QA and integration testing.
Use “Duplicate Document type” to easily set up Test and Production workspaces from your Training workspace.

​
Making changes whilst in production

Once your workflow is live in production, you may still need to update your document types or workflow settings from time to time. Identify the type of change you want to make, then follow the recommended approach below.

​
Scenario A — New document variation

The model hasn’t seen this variation before, or is handling it poorly. Approach: Add to model memory → Training
1

Upload to Training

Upload the new variation to the Training workspace.
2

Annotate and confirm

Annotate all fields correctly and confirm the document as model memory.
3

No deployment needed

Performance improves in production automatically — no deployment step required.

​
Scenario B — Small schema change

Adding or tweaking one or two simple fields. Approach: Edit in place → Training
1

Edit the schema in Training

Edit the schema directly in the Training workspace.
2

Re-predict and reconfirm

Re-predict the new or changed field on the model memory document, then reconfirm it.
3

Takes effect immediately

Changes take effect in production straight away.
Check first: confirm that the change won’t break or affect any downstream integrations before proceeding.

​
Scenario C — Significant schema change

Groups, nesting, structural changes, or anything that requires integration retesting. Approach: Duplicate → Dev/Test → Production
1

Leave production untouched

Leave the existing production document type in place while you build the new version.
2

Duplicate in Training

Duplicate the document type in Training and make all changes on the new duplicate.
3

Rebuild model memory

Re-upload, re-annotate, and confirm all model memory documents on the new duplicate.
4

Test in Dev/Test

Link the duplicate to the Dev/Test workspace to test the integration flow and make adjustments.
5

Validate end-to-end

Validate the full API payload end-to-end against the new schema.
6

Promote to Production

Once sign-off is complete, unlink the old version from production and link the new one.