Features

Everything a GMP plant needs to trust a system that acts.

Autonomy in a regulated plant is a trust problem before it is a modelling problem. These are the features that make a bounded, auditable, reversible system of action acceptable to a site director, an MSAT engineer and a QA lead at the same time.

Shadow to boundedPart 11 on every actionDesign space enforced at call time

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.

Core

The features that make autonomy safe

From the first release plan: connectors, a constrained agent loop, a review console and a validated audit log from day one.

Connectors

Equipment, PAT, MES and LIMS connectors

Blending, granulation, compression, coating, PAT and NIR, vision and pharma-MES connectors over APIs and OT, built with design partners against their stacks.

Agent loop

Sense, reason, act, bounded

A production-grade agent loop with human-in-the-loop and QA checkpoints, where every action is scored against the approved design space before it is proposed.

Review console

Approve, correct, feed back

Formulators, process engineers and QA approve, correct and annotate recommendations; every correction trains the models under change control.

Audit log

Immutable, validated, Part 11

Append-only, hash-chained, exportable, retained on site storage, with reviewer identity and timestamp on every decision.

Edge runtime

Validated plant-edge inference

Jetson or on-prem GPU per line, TensorRT models behind Triton and NIM, Guardrails enforcing action schemas, fallback to last known good.

Model management

Central, GMP-grade

Versioned model registry, model cards, golden datasets and evaluation gating every model and prompt change in CI under GxP change control.

Run timeline · scenario

One scenario batch, step by step

The same reference run that appears across the site: granulation, compression, coating and inspection inside the design space, QA approval before release.

run_b2c7e1 Line 2 · rotary tablet press · scenario SUCCEEDED
  1. 01 ingest.batch_record SUCCEEDED 1.2 s

    Plant Orchestrator · Pulled the master batch record, the approved design-space limits for this formulation and tooling family, and the site autonomy policy from MES; locked the target envelope for the run.

  2. 02 twin.rehearse SUCCEEDED 41 s

    Plant Orchestrator · Twindra simulated 36 candidate setpoint vectors on the as-made batch twin (granulation DEM, compression and ejection risk, coating CFD, dissolution surrogate) and ranked them on predicted content uniformity, capping risk and takt.

  3. 03 blend.uniformity SUCCEEDED 6 m 10 s

    Blend-and-Dispense · Spectryn scored in-line NIR spectra against the formulation's chemometric model; the blend reached its uniformity end point with confidence bounds inside the site acceptance limit and blending stopped on evidence rather than on a fixed time.

  4. 04 granulate.dry SUCCEEDED 3 m 48 s

    Granulate-and-Dry · Inlet air temperature and drying airflow trimmed inside the approved window to bring loss-on-drying to the target moisture band for compression; the move was bounded, logged and inside the design space.

  5. 05 compress.press SUCCEEDED 2 m 02 s

    Compress-and-Fill · Main compression force and feed-frame speed adjusted inside the approved window to hold tablet weight and hardness on target while the twin's capping-risk estimate stayed under the site threshold.

  6. 06 coat.spray SUCCEEDED 4 m 25 s

    Coat-and-Dry · Spray rate and inlet temperature re-phased against bed temperature and exhaust humidity to hold the film-coat window and avoid twinning and mottling; no excursion from the validated recipe envelope.

  7. 07 inspect.tablets SUCCEEDED continuous

    Defect-and-Inspect · Visqa classified chips, cracks, capping, spots, mottling and print defects on six synchronised cameras, within the sub-100 ms design budget, and linked a rising chip rate to coating spray rather than to tooling.

  8. 08 spectra.release_evidence SUCCEEDED 38 s

    Quality-and-Potency · Spectryn assembled the method-linked evidence chain for content uniformity and moisture with confidence bounds and citations to the validated analytical method, ready for QA review.

  9. 09 approve.qa APPROVAL 3 m 14 s

    Plant Orchestrator · Batch release is above every autonomy level Pildeon offers. The package was held for the named QA reviewer, who approved it in the review console; the decision, the reviewer identity and the timestamp are in the Part 11 audit trail.

  10. 10 release.genealogy SUCCEEDED 52 s

    Quality-and-Conformance · Conforma wrote the time-aligned batch genealogy (every sensor state, recommendation, approved action, equipment response and QC result) and the cited release package to the immutable audit trail.

Tool calls · scenario

The agent shows its work

Every tool invocation, argument and result is written to an immutable, human-readable log, and every reasoning step is expandable. Nothing about a run is hidden from the plant or from QA.

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.

In depth

Three features worth the detail

Latency, evidence and rehearsal are where a quality lead's trust is actually won or lost.

Latency

Line-speed, on the edge

Tablets leave the press by the hundreds of thousands an hour. Design targets: under 100 ms per camera frame group for defect inference, under 500 ms for a fused PAT, NIR and process risk score, under 2 seconds for a validated recommendation. All on the plant edge, none dependent on the cloud.

Evidence

Cited, or not shown

Every recommendation carries a confidence, a rationale and a citation to a validated method, standard, SOP or record. Spectryn's release evidence is method-linked; Conforma's deviation drafts cite cGMP, GAMP 5, Part 11, ICH and USP. Citation checks run on every output.

Rehearsal

Simulated before proposed

Twindra simulates candidate setpoint vectors on the as-made twin and discards any that push a quality attribute past its limit, however much takt it would recover. The chosen candidate is executed step by step and the prediction is logged beside the outcome.

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

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.

How it works

A batch record becomes a plan becomes a run

Nothing about a Pildeon run is implicit. The goal comes from the master batch record, the plan is rehearsed on the twin, each step is typed and bounded by the approved design space, and the outcome is written to the batch genealogy.

Active path

The orchestrator plans, the agents act, QA releases

A run starts as a goal, becomes a plan, and executes as a graph of typed steps. The active path is always visible, always logged, always reversible. Batch release is never on the autonomous path.

RUNNING APPROVAL SUCCEEDED
36 Candidate setpoint vectors rehearsed on the twin in this scenario
5 Setpoint moves, all inside the approved design space
1 QA approval gate, on every batch, at every autonomy level
<100 ms Design target for defect inference per camera frame group
Human in the loop

Autonomy is graduated, and validated parameters never move without sign-off

Shadow, assist, supervised, bounded. Each site sets the level per agent and per setpoint, inside the design space its own validation approved. Anything outside that space, and every batch release, waits for a named QA reviewer, and the decision lands in the 21 CFR Part 11 audit trail.

Design targets

Feature design targets

Pildeon is pre-launch. These are the latency and scale targets the platform is engineered against. None is a shipped result, and each will be measured against a design partner's own QC data.

<100 ms Defect inference per camera frame group, on the plant edge
<500 ms Fused PAT, NIR and process risk score
<2 s Validated recommendation generation
100k+ Synthetic rare-fault scenarios per formulation family

Training corpus targets across design partners: 10M+ tablet and coating images, 50k+ NIR and PAT spectra, 100k+ process time-series windows, 5k+ labelled deviation investigations. Targets, not holdings.

Developers

Define an agent, bound it, run it

The Pildeon SDK is typed Python. Tools are declared with schemas, units and design-space limits; the policy engine enforces them at call time, and every change to a tool or a limit is a change-control event.

What you get

  • Typed tool definitions with unit-aware ranges bound to the approved design space
  • Deterministic replay of any historical batch against a new model version
  • Local twin harness so a setpoint vector is rehearsed before it is shipped
  • Autonomy policy as code, versioned, reviewed and change-controlled like any other GxP change

Read the docs Developer guide

tp2_compression_agent.py
# Bound the compression agent to tablet press 2's approved design space.
from pildeon import Agent, Tool, DesignSpace, Autonomy

force = Tool(
    name="press.write_setpoint",
    tags=["TP2.MAIN_FORCE", "TP2.FEED_FRAME_SPEED"],
    limits=DesignSpace.approved("family-A", "tooling-D"),
)

compress = Agent(
    id="agent.compress_fill",
    goal="weight, hardness on target; capping risk under threshold",
    tools=[force, Tool("press.read_force_curve", read_only=True)],
    # supervised: each move executes on approval
    autonomy=Autonomy.L2,
    # rehearse on the twin before every proposal
    verify="twin",
    # every call lands in the Part 11 audit trail
    audit="part11",
)

run = compress.start(line="L2", batch="B-240918")
for step in run.stream():
    print(step.name, step.status, step.duration)
CLI

Start a run from anywhere

The same run engine, the same policy checks, the same audit trail, from the terminal, the review console or the SDK.

pildeon · cli · scenario
$ pildeon run "batch B-240918 on L2" --autonomy L2

→ plan composed          10 steps · 1 QA approval gate
→ twin.simulate          36 candidates · best #14 · capping risk under threshold
→ policy.evaluate        5 moves inside design space · release held for QA
→ executing              blend.uniformity .... ok   6m10s
→ executing              granulate.dry ...... ok   3m48s
→ executing              compress.press ..... ok   2m02s
→ executing              coat.spray ......... ok   4m25s
! approval required      batch_release · QA reviewer
→ approved               named QA reviewer · identity + timestamp logged
→ run complete           genealogy written · release package cited

$ pildeon runs show run_b2c7e1 --format genealogy
The first meeting

What each stakeholder asks first

Pildeon has no customer quotes to show yet, and will not invent any. These are the questions the three buyers in an OSD plant ask in the first meeting, and the answer each gets.

"What does this do to my reject rate, my deviation count and my release time, and how will you prove it on my line rather than on a slide?"

Site or manufacturing director · economic buyer

Answer: shadow mode first, baseline captured before any autonomous action, a written ROI target before a paid pilot.

"Will it ever move a setpoint outside the design space we validated, and can I see why it recommended every move it made?"

Formulation or process engineer (MSAT) · champion

Answer: no, by construction. Every recommendation carries its reasoning trace and its citation.

"Where is the Part 11 audit trail, who signs the release, and what happens to my validated state when the model changes?"

QA, quality and compliance lead · approver

Answer: an immutable audit spine, a named QA reviewer on every release, and every model change under GxP change control.

Integrations

It speaks tablet plant, not cloud

Pildeon reads and writes through the systems already on the floor: presses, coaters, granulators, PAT probes, MES, LIMS and historians. No rip-and-replace, no parallel historian. Connectors are built with design partners against their stacks; the vendors listed are the ones common in OSD plants.

Blending and granulation

GEA, Glatt, Syntegon, Freund-Vector, L.B. Bohle

Blender, granulator and fluid-bed telemetry; bounded setpoint writes

Tablet presses and fillers

Fette Compacting, Korsch, IMA, Syntegon, MG2

Force curves, fill depth, ejection force; bounded setpoint writes

Coating systems

GEA, Glatt, O'Hara, Thomas, Freund

Spray, inlet, bed temperature, exhaust humidity; bounded writes

PAT and NIR

Bruker, Sartorius, Viavi probes and analysers

Spectra across blend, granulation, drying and compression

Vision

Line cameras and existing inspection systems

Frames, defect maps, reviewed images

Pharma MES and eBR

Körber Werum PAS-X, Rockwell, Siemens Opcenter

Master batch records, campaigns, batch genealogy

LIMS and historians

Site LIMS, OSIsoft PI and equivalent historians

QC results, time-series backfill and replay

Identity and edge

Azure AD, Okta, LDAP · NVIDIA Jetson and on-prem GPU

SSO, RBAC, named approvers · inference at the line

See all integrations

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

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

Straight answers

The questions site directors, MSAT engineers and QA leads actually ask in the first meeting.

Yes, but only inside an explicit setpoint allow-list bounded by the design space your validation approved, and only at the autonomy level your site has set. Level 0 is shadow mode: Pildeon observes and predicts and writes nothing. Most sites spend their first weeks there.

Get started

See these features on your line

A line review maps the features to your equipment, your PAT stack and your validation calendar.