docs

Sieve Foundry

Prepare datasets, train private decision adapters and deploy evaluated models.

Sieve Foundry is the workspace for organisation-specific decision models. Prepare labelled examples, upload a dataset, train an adapter against an approved base, then review evaluation before deployment.

Current availability

Supervised decision LoRA is available when your installation has configured storage, an approved compatible Codes checkpoint and a training worker. Deployment additionally requires the private serving engine. An unconfigured installation shows the missing capability and does not simulate training. Generative fine-tuning, DPO and distillation remain unavailable.

Not Microsoft Foundry

Sieve Foundry is ours. It is unrelated to Microsoft Foundry, Azure's model catalogue.

Plan your model

  1. Choose the outcome. Decision labels and rules suggest supervised LoRA. Confidence and escalation suggest a calibration review. Writing style suggests generative SFT, which is planned. Preference optimisation (DPO) and distillation are later research paths.
  2. Define success. Describe the task, current baseline and measurable target. Candidate bases are individual active decision versions; Sieve Auto is a cascade, not an adapter base. Compatibility and capacity require review.
  3. Check a sample locally. Paste JSONL or read a local .jsonl or .ndjson file. The browser checks structure, repeated records, conflicting labels and label distribution. The local check accepts up to 2 MiB, 500 examples, 8,000 characters per text field and 120 per label. This does not upload a dataset or check semantic quality or personal data.
  4. Download a brief. The brief includes the goal and criteria, without example records. Planner state clears on reload and is not saved to the organisation.
  5. Discuss feasibility. Use Discuss a build to open Support. Share the brief summary without customer records, and arrange an approved data-transfer process. Cost and duration require dataset and capacity review.

For example, a shop can prepare reviewed tickets labelled delivery, billing and refund. Hold out unseen tickets to compare the proposed adapter with the base model. Use separate training, validation and test sets, keeping related customers, documents or time periods together to avoid leakage. Changing order status and policy documents should come from connected systems or retrieval.

{"input":"My parcel has not arrived","label":"delivery"}
{"input":"I was charged twice","label":"billing"}

This input/label shape is also accepted by the dataset uploader. Checking a local sample does not upload it or start training.

Upload, train and deploy

Organisation Admins can use the configured dataset and training controls. Members can use the local planner and read their adapter registry.

  1. Upload JSONL. Maximum 25 MiB, 50,000 rows and 64 KiB per row. The original is retained unchanged; choose whether the derived copy removes exact duplicate records. Missing or contradictory labels require review. Structural checks do not prove semantic quality or privacy.
  2. Choose an approved base. Only configured, pinned, compatible decision checkpoints are accepted. A model catalogue listing alone does not make a base trainable.
  3. Create a training job. The worker reserves unseen validation and test examples, trains LoRA weights and the decision head, and compares each split against its own baseline. Related normalised inputs stay together. Business-specific customer/document/time grouping still needs dataset preparation.
  4. Review evaluation. The signed result must satisfy the administrator's configured accuracy and improvement policy. An unfinished, failed, cancelled or stale attempt cannot be published.
  5. Deploy the evaluated model. The private engine verifies the signature and file checksums, loads the adapter and runs a readiness inference. The adapter becomes callable only after the engine acknowledges success.
  6. Revoke or roll back. Revocation blocks new gateway requests immediately and queues engine unload. To roll back, deploy a previous evaluated job under a new deployment identity.
flowchart LR
  A[Upload and validate] --> B[Encrypted dataset]
  B --> C[Train private LoRA]
  C --> D[Held-out evaluation]
  D --> E[Verify and load]
  E --> F[Private adapter API]
  F --> G[Revoke and erase when due]

The implementation limits training admissions and artifact storage. These limits are not a price quote. Production activation also requires reviewed private cloud buckets, key custody, backup policies, approved weights and serving capacity.

Training preset

The step-by-step walkthrough, with the dataset rules, presets, estimate, deploy gate and code samples, is in Fine-tune a model with Foundry.

Supervised LoRA is the only training method the backend accepts today. The console offers three presets: Fast (rank 4, 1 epoch, learning rate 0.0005), Balanced (the default: rank 8, 2 epochs, 0.0002) and Accurate (rank 16, 5 epochs, 0.0001), or Custom values within the limits: 1–10 epochs, a learning rate from 0.00001 to 0.01, rank 4, 8 or 16, and a maximum training time of up to 3,600 seconds (the default). The engine fixes LoRA alpha (twice the rank), dropout (0), the adapted projections, the seed and a 60/20/20 training/validation/test split. Unknown options and generative, DPO or distillation methods are refused rather than silently changed.

Each organisation may have at most four queued/running or previous-24-hour jobs, four live deployment intents, and 1 GiB of artifacts in aggregate. A verified artifact is at most 512 MiB. These are admission limits, not a commercial entitlement.

Reading results

The results panel compares validation and final-test accuracy with their matching base-model baselines. With the default policy, deployment needs validation accuracy of at least 0.80, test accuracy of at least 0.80, and at least 0.01 (one percentage point) improvement over the baseline on both splits. A report can also include per-class errors, a confusion summary and calibration error (ECE); use those to look for classes that are under-represented or over-confident, not only the headline score.

If the gate fails, it names the failed threshold. Add representative labelled examples for the weak class, correct conflicting labels, or try another preset and create a new job. Do not treat a passing structural upload check as a quality result. The panel shows time, cost and adapter details only when the signed training report provides them; a missing field is shown as not reported.

FAQ

Which models can I choose? Only administrator-approved, compatible Codes-family decision bases (Sieve-4B today) appear in the selector. Sieve Auto is a router, not an adapter base. Generative SFT, DPO, QLoRA and distillation are not supported by the current engine.

Can I continue later? Yes. Datasets, estimates and jobs are durable. Return to Foundry and refresh; queued, running and evaluating jobs update there, and you can cancel an active job.

Where do I use a deployed adapter? After the serving engine marks the deployment ready, call it as ft:<deployment name> (or by its adp_... adapter ID) with any API key of your organisation. It also appears in the Playground model picker. Revoking the deployment stops new requests from using it.

Calling a deployed model

Send ft:<name>, where <name> is the deployment name you chose (lowercase letters, digits and hyphens, starting with a letter), or the adp_... adapter ID shown under the deployment:

curl https://api.sieve.one/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "model": "ft:support-router", "state": "My parcel has not arrived", "questions": { "q": { "type": "noul", "instructions": "Is this about a delivery?" } } }'

Python, JavaScript and Go versions are in the fine-tuning guide. Active adapters appear in GET /v1/models (by their adp_... ID) only for keys in your organisation. Another organisation that sends the name gets 404, the same as for a name that does not exist. Routing failures do not silently substitute the base model. The console's Foundry page lists your organisation's adapter records.

Your data

  • Local planner examples remain in browser memory. They are not uploaded or included in the downloaded brief.
  • Stored originals and derived datasets are encrypted and scoped to your organisation. Retention and deletion use durable cleanup obligations; legal holds prevent deletion. Production cloud object versions and backup retention require the installation's reviewed policies. See Data retention.
  • Training work and model artifacts are private to the worker and engine. They require an encrypted persistent volume and are removed after source erasure and confirmed engine unload. Your adapter is private to your organisation.

Commercial terms

Build scope, feasibility and commercial terms are agreed per customer. The planner does not create a quote or charge your organisation. See Invoices and tax.

Next steps

Last updated