Security & validation

An agent that can move a compression force needs more than a good model.

Six layers sit between a model and a setpoint: the design space, the policy engine, the autonomy level, the QA gate, the audit trail and the fallback. All of them are designed for a GMP plant where the regulator can ask for the record.

Part 11 by designGAMP 5 package in progressValidated on-prem option

run_b2c7e1 · agent graph · scenario 10 nodes · 1 QA approval gate
01 · orchestrator ingest.batch_record ✓ SUCCEEDED 02 · orchestrator twin.rehearse ✓ SUCCEEDED 03 · blend_dispense blend.uniformity ✓ SUCCEEDED 04 · granulate_dry granulate.dry ✓ SUCCEEDED 05 · compress_fill compress.press ✓ SUCCEEDED 06 · coat_dry coat.spray ✓ SUCCEEDED 07 · defect_inspect inspect.tablets ✓ SUCCEEDED 08 · quality_potency spectra.release_evidence ✓ SUCCEEDED 09 · orchestrator approve.qa ◆ APPROVAL 10 · quality_conf release.genealogy ✓ SUCCEEDED

Scenario: Run one immediate-release tablet batch through granulation, compression, coating and inspection inside the approved design space, with QA approval before release. A design walkthrough, not a customer record.

Defence in depth

Six layers between a model and a setpoint

Each layer is independent; a model error has to pass all six to reach the line, and the last one, release, is always a human.

Layer 1

Approved design space

Every tool is bound to the limits the site's validation approved. A move outside is not an exception path; it is a refused call.

Layer 2

Policy engine

Autonomy level, batch state, model version, interlock state and reviewer assignment evaluated before any write.

Layer 3

Autonomy level

Shadow, assist, supervised, bounded. Set per agent and per setpoint by the site. No unattended level exists.

Layer 4

QA gate

Batch release, out-of-space moves and validated-parameter changes always route to a named QA reviewer in the review console.

Layer 5

Audit trail

Append-only, hash-chained, site-owned, with reviewer identity and timestamp. The record a regulator asks for.

Layer 6

Hard fallback

Loss of the node, the network or the model returns the line to the equipment's last known-good recipe.

Tool calls · scenario

Every call, on the record

The scenario run's call log. In production the same stream is written to the site's own storage and exported on request.

tool-call stream · run_b2c7e1
  1. 06:12:04mes.read_batch_record({ line: "L2", product: "IR tablet · family A" })
  2. 06:12:05ok design space loaded · autonomy policy L2 · QA reviewer assigned
  3. 06:12:06twin.simulate({ candidates: 36, horizon: "full batch" })
  4. 06:12:47ok candidate #14 selected · predicted CU inside limit · capping risk under threshold
  5. 06:12:48policy.evaluate({ candidate: 14, autonomy: "L2" })
  6. 06:12:48ok 5 setpoint moves inside design space · release held for QA
  7. 06:12:49nir.score({ probe: "blender-1", model: "cu-famA-v3" })
  8. 06:18:59ok blend end point reached · confidence bounds inside acceptance limit
  9. 06:19:00plc.write_setpoint({ tag: "FBD1.INLET_T", within: "design space" })
  10. 06:22:48ok loss-on-drying in target band · move logged to audit trail
  11. 06:22:49press.write_setpoint({ tag: "TP2.MAIN_FORCE", within: "design space" })
  12. 06:24:51ok weight and hardness on target · capping risk under threshold
  13. 06:24:52vision.stream({ cameras: 6, model: "visqa-defect-v2" })
  14. 06:27:10chip rate rising on camera 4 · attributed to spray rate, not tooling
  15. 06:27:11coater.write_setpoint({ tag: "CT1.SPRAY", within: "design space" })
  16. 06:29:14ok chip rate back to baseline · film window held
  17. 06:29:15nir.evidence_chain({ attributes: ["cu", "moisture"], method: "validated" })
  18. 06:29:53ok evidence chain assembled · citations attached
  19. 06:29:54approval.request({ action: "batch_release", reviewer: "QA" })
  20. 06:33:08ok approved by the named QA reviewer · identity and timestamp logged
  21. 06:33:09audit.write_release_package({ batch: "B-240918", genealogy: "full" })
  22. 06:34:01ok scenario complete · genealogy written · package cited

Reasoning trace

Plan, thought, action, observation, exactly as the orchestrator records it.

GoalRun one immediate-release tablet batch through granulation, co…

Run one immediate-release tablet batch through granulation, compression, coating and inspection inside the approved design space, with QA approval before release.

PlanRehearse on the twin first. Stop blending on NIR evidence rath…

Rehearse on the twin first. Stop blending on NIR evidence rather than on a fixed time. Trim drying, compression and coating only inside the approved design space. Inspect continuously. Hold release for the named QA reviewer, always.

ThoughtThe fixed recipe blends for a set time regardless of what the …

The fixed recipe blends for a set time regardless of what the spectra say. On the twin, the candidate that stops on evidence and trims inlet temperature before compression keeps content uniformity and moisture inside their limits with the lowest predicted capping risk.

Actiontwin.simulate(candidates=36) → candidate #14: evidence-based b…

twin.simulate(candidates=36) → candidate #14: evidence-based blend end point, bounded drying trim, compression force held inside the window, spray rate re-phased to bed temperature.

ObservationEvery candidate that pushed turret speed for takt raised predi…

Every candidate that pushed turret speed for takt raised predicted capping risk above the site threshold and was discarded. Rate is never traded for a quality attribute.

ActionExecute candidate #14 under autonomy level L2: five setpoint m…

Execute candidate #14 under autonomy level L2: five setpoint moves inside the design space, each logged. Batch release routed to QA.

ObservationChip rate rose on camera 4 at 06:27:10. Visqa attributed it to…

Chip rate rose on camera 4 at 06:27:10. Visqa attributed it to coating spray rather than tooling; a bounded spray-rate trim returned it to baseline in about two minutes.

OutcomeScenario complete. Every move inside the approved design space…

Scenario complete. Every move inside the approved design space, the QA approval recorded with identity and timestamp, and the cited release package written by Conforma to the immutable audit trail.

Guardrails

An agent that can move a compression force needs a leash

Pildeon writes to production equipment in a GMP plant. Every capability is scoped to the approved design space, every write is policy-checked, every action is written to an immutable Part 11 audit trail the site owns, and no agent can release a batch.

  • Bounded action space. Each agent can only write to an explicit setpoint allow-list, inside the limits the site's validation approved.
  • Policy engine before every write. Autonomy level, design-space limits, batch state, model version and reviewer assignment are all evaluated before a setpoint moves.
  • Human-in-the-loop gates. Batch release, any move outside the design space and any change to a validated parameter wait for a named QA reviewer.
  • Immutable audit trail. Append-only, hash-chained, exportable, retained on the site's own storage, with reviewer identity and timestamp on every decision.
  • Hard fallback. Loss of the edge node, the network or the model returns the line to the equipment's last known-good recipe.
  • Tenant and IP isolation. Formulations, recipes and models never cross a customer boundary. Validated on-prem deployment is available for regulated producers.

Compliance posture

Compliance and validation status
StandardScopeStatus
21 CFR Part 11Audit trail, e-signatures, records RUNNING Designed in from day one
GAMP 5Validation package for the platform RUNNING In progress, planned for the first design partners
cGMP · ICH Q8 to Q13Design space, QbD, continuous manufacturing RUNNING Design-aligned; site validation decides
SOC 2 Type ICloud control plane QUEUED Planned, first six months
SOC 2 Type IICloud control plane QUEUED Planned, months six to twelve
Data residencyValidated on-prem, air-gapped option SUCCEEDED Available by design

Read the security and validation overview

Autonomy

Four levels, set per agent and per setpoint

A tablet plant does not go from fixed recipes to autonomy in one step, and validated parameters never change without sign-off. Pildeon makes the level explicit, auditable and reversible at any time.

Autonomy levels and the human role at each
LevelWhat the agent doesWhat the human doesTypical time to reach
L0 · ShadowObserves, scores and predicts; writes nothingRuns the line as today; compares predictions to QC resultsWeeks 1 to 6 of a design partnership
L1 · AssistRecommends setpoint moves and explains whyProcess engineer enters the move; QA reviews the logAfter shadow-mode accuracy is shown
L2 · SupervisedProposes a bounded move; it executes on approvalApproves each move in the review consoleAfter assist-mode ROI is shown
L3 · BoundedMoves low-risk compression, coating and inspection setpoints inside the approved design spaceHandles exceptions; approves every releaseAfter validation and change-control review

There is no unattended level. Batch release and any move outside the approved design space always wait for a named QA reviewer, and every model or prompt change runs under GxP change control.

Compliance

Validation and certification status

Honest status, stated as of this writing. Nothing here is a certification claim.

Standards and status
StandardScopePildeon postureStatus
21 CFR Part 11Electronic records and signaturesDesigned in: immutable audit trail, e-signature on approvals, record retention on site storage RUNNING Design complete, validation with partners
GAMP 5Computerised system validationValidation package in progress: URS, FS, risk assessment, IQ, OQ, PQ templates for the platform RUNNING In progress
cGMP · ICH Q8 to Q10, Q13QbD, design space, continuous manufacturingDesign space enforced at call time; change control on models; continuous-manufacturing ready RUNNING Design-aligned
Data integrity (ALCOA+)Attributable, legible, contemporaneous, original, accurateEvery record attributed, timestamped, original and immutable SUCCEEDED By construction
SOC 2 Type ICloud control planePlanned in the first six months QUEUED Planned
SOC 2 Type IICloud control planePlanned in months six to twelve QUEUED Planned
OT safety

Failing safe is a design requirement

Pildeon sits above the equipment's own controls and interlocks, never in place of them.

  • Equipment interlocks and safety PLCs are never bypassed or written to
  • Writes go through constrained connectors with per-setpoint allow-lists and rate limits
  • Read paths and write paths are separately validated; shadow mode is read-only by construction
  • Edge nodes run on isolated OT network segments; the control plane never reaches the equipment directly
  • Kinetos robots operate under their own safety-rated controllers; Pildeon plans and sequences, it does not override safety

Failure modes and responses

Edge node down
Line continues on last known-good recipe; alarm raised; audit trail notes the gap
Model unavailable
Agent degrades to shadow; no writes; reviewer notified
Network lost
Edge continues local inference and logging; sync on recovery; writes hold at current level
Citation check fails
Output withheld; reviewer sees the uncited draft flagged
Arbitration deadlock
Escalated to a human, never resolved by timeout
Data

What leaves the plant, and when

By default, nothing. Everything else is an explicit, logged choice by the site.

Stays on site

Formulations, recipes, spectra, images, genealogy

Tenant-isolated, on site storage, inside the plant. The validated on-prem deployment keeps training there too.

Leaves only if you opt in

Cloud training, benchmark features

Model training in the cloud only when the site chooses; cross-plant benchmarks use privacy-preserving features and require approval.

Never

Another customer's model

Your data is never used to train another tenant's models. Federated learning across tenants is a stated future option, after validation and tenant approval, not a current behaviour.

Multi-agent handoff

Agents negotiate, they do not collide

Two agents will want the same setpoint. The orchestrator arbitrates on the run goal and the quality attributes, not on who asked first, and the handoff is logged like any other step.

Contested move: turret speed on tablet press 2

  1. 01yield_takt.request(turret +4%) SUCCEEDED0.2 s

    Yield-and-Takt wants more turret speed to recover takt lost to an upstream changeover.

  2. 02quality_potency.request(hold) SUCCEEDED0.2 s

    Quality-and-Potency wants turret speed held: the twin's content-uniformity and capping-risk estimates rise with dwell time lost.

  3. 03orchestrator.arbitrate SUCCEEDED0.4 s

    A quality attribute outranks takt under every Pildeon run goal. Quality-and-Potency wins the setpoint; the takt request is declined and the reason recorded.

  4. 04yield_takt.replan(campaign) SUCCEEDED6 s

    Yield-and-Takt recovers the schedule by re-sequencing the next changeover with cuOpt instead of pushing the press.

Arbitration rules

  • Quality attributes first. Content uniformity, potency, dissolution and defect rate outrank yield, energy and takt in every arbitration.
  • The design space is a wall, not a target. No agent can request a move outside the limits the site's validation approved.
  • Time-boxed ownership. An agent holds a contested setpoint for a bounded window, then must re-justify.
  • Everything is logged. The losing request, the score and the reason all appear in the batch genealogy.
  • Deadlocks escalate to a human rather than resolving by timeout.

See the agent roster

Enterprise

Standardise validated autonomy across the group

One policy model, one audit spine, one benchmark across every line in every plant, with formulation and tooling models kept private to each site.

Talk to the team Enterprise details

  • SSO, RBAC and named approvers down to the setpoint level
  • Group autonomy policy with per-site override and approval chains
  • Cross-plant benchmarking on yield, rejects, deviations and energy
  • Validated on-prem and air-gapped plant-edge deployment options
  • Validation packages and change-control records as first-class deliverables
  • Dedicated deployment engineer and quarterly model review per site
FAQ

Security and validation questions

What QA, validation and IT security teams ask first.

Not yet. The platform is designed against 21 CFR Part 11, GAMP 5 and ICH Q8 to Q13 from day one, and a GAMP 5 validation package is in progress for the first design partners. Site validation is always the site's decision and the site's protocol.

Get started

Get the security and validation pack

Architecture, data flows, audit-trail schema, validation approach and the GAMP 5 package status, for your QA and IT security review.