Deterministic rule engine
Rules are explicit and versioned, not a black-box model guessing at risk — you can see exactly what triggered a flag.
Continuous Quality Monitoring
Hear about quality problems as they happen, with the evidence already attached.
PixeSciTM watches the systems you connect, flags the gaps a reviewer or inspector would look for, and recommends what to do next. Every approval, closure, release, and signature stays with a qualified person on your team, and the software enforces that.
How it works
It works behind the systems you already use.
PixeSciTM is not a replacement for your LIMS, QMS, CDS, or instrument software. It connects to what you already run, resolves the execution context around each event — the approved method, the sample, the analyst's authorization, the equipment state — and carries that context, plus the approvals and evidence it generates, through the workflow as it happens.
The result is a record that doesn't need to be reconstructed after the fact, because it was carried through the work in the first place.
- Runs behind your existing CDS, LIMS/ELN, QMS, instruments, and documents
- No new instruments and no rip-and-replace software required
- One governed layer instead of separate point-to-point handoffs
You asked: Does any of our data leave the site?
Data location
Approved local folders
Public internet
Blocked
Controlled actions
Approval required
Credentials
Stored locally
Run records
Audit logging on
Backup policy
Customer managed
Before a run starts
3 / 3 checkedSoftware access follows approved policy
High-risk steps pause for a person
Run records stay with the workflow
Continuous monitoring
Every event gets checked as it happens.
PixeSciTM evaluates a deterministic set of rules against the event history from every system you connect — instrument runs, audit-trail entries, user and account activity, and record completeness — continuously, not on a schedule or a sample.
These rules look for the same patterns a quality reviewer or an inspector would: aborted or repeated runs without a documented reason, activity attributed to a shared or ambiguous account, missing raw-data references, and records that disagree with each other about the same event.
You asked: Which runs were repeated without a reason?
Raw data referenceOK
ReinjectionFlagged
Shared account activityFlagged
Audit-trail reviewOK
Run reconciliationOK
Recommendation
Reinjection has no documented justification. Review before release.
Recommendation only — a qualified reviewer approves, closes, releases, and signs.
Cross-record reconciliation
Compare identity, timing, and outcome fields across records of the same event to catch records that disagree.
Continuous, not periodic
Evaluate events as they happen, instead of waiting for a scheduled review or an audit to surface a gap.
Routed into Quality records
A flagged event becomes a real Quality Management record — a deviation, OOS, or investigation — not a siloed alert.
Governed execution
Anything risky waits for your approval.
Each capability an agent can use is a typed, registered contract with a declared risk level and required permissions — reads run automatically; anything that writes to a record, or that could affect a live instrument, requires human approval first.
Actions that pattern-match to live-instrument control — acquiring, injecting, calibrating, arming, or operating a connected instrument — are always routed to a person, regardless of risk tier.
- Typed capability registry with a declared risk level per action
- Risk-tiered approval gates, not a single blanket permission
- Live-instrument actions always require human approval
- Every execution is checked against role and permission before it runs
You asked: Where is this run right now?
09:42:16.104run.startedrun_01J8Q / trace_7F2
09:42:18.892file.validatedsource/CDS/run-7
09:43:08.220node.completedcds-review
09:44:51.609file.createdrun-summary.csv
09:46:03.017review.requestedqc-directorLatest event
Run summary
Steps3 / 5
3 executed
1 approval required
- events
- 12
- files
- 2
- blocked
- 0
Recommendation only
PixeSciTM recommends. It cannot approve, close, release, or sign.
PixeSciTM's compliance copilot answers questions only from the records, rule results, and evidence it can cite — and it is designed to decline rather than guess when the evidence is missing or contradictory.
Its ability to approve, close, release, invalidate, sign, or write to a source system isn't just discouraged in a prompt — it's absent from what the software will let it do, and an automated evaluation suite tests for exactly this boundary before any change ships.
Cited recommendations
Every answer is grounded in specific records and rule results the copilot can point to, not a general impression.
Enforced authority boundary
Approve, close, release, invalidate, sign, and write-to-source-system are outside what the copilot can do — enforced in the software.
Tested, not just described
An automated evaluation suite checks the copilot resists claiming authority it doesn't have, before any change reaches production.
Verifiable evidence
An audit trail you can check whenever you want.
Every record change and agent action is written into the same hash-chained trail, with each entry linked to the one before it. Run a chain-integrity check at any time and see exactly where it breaks, if it ever does — the check is recomputed live, not served from a cache.
When you need to hand over evidence, export a checksum-manifested bundle for a specific finding — one download, one hash you can verify independently.
FDA guidance calls for records that are complete, consistent, accurate, linked to a person, recorded on time, and ready for review. Teams can use this history to check reviews and prepare records for quality work or inspections. Each organization must still set up and validate those records for its own needs.
- On-demand, live-recomputed audit-chain verification
- Checksum-manifested evidence export per finding
- The same trail records human and agent actions alike
You asked: Who changed this result, and when?
12
events
00
failed
01
review
12
tamper
09:42:16
Workflow execution started
workflowinfowf-flow-review-042
09:43:08
Analysis parameters applied
datainfoanalysis-v3.json
09:44:51
Output checksum recorded
compliancesuccesssha256: 8c7a…9f2e
09:46:03Latest event
Operator review requested
compliancewarningreview / qc-director
Record detail
- Actor
- A. Mensah
- Role
- researcher
- Category
- workflow
- Severity
- info
- Review
- required
- Tamper evident
- yes
- Change reason
- parameter set approved
- Event ID
- evt_01J8QF
Customer review rules determine the final decision.
Attributable
Link each workflow action to the right user, role, session, and item.
Contemporaneous
Record workflow and audit events while the work happens.
Reviewable
Filter records, check their details, and prepare approved exports for review.
Data integrity
Your data, settings, and steps stay together.
Link source files, file details, software versions, settings, scripts, changes, and processing steps. Workflow views make this information easier to inspect without replacing the original records.
Run details
Save times, users, software, file types, settings, and results.
Versioning
Track each workflow version and the software settings used for every run.
Checksums
Use checksums to help reviewers confirm that records and files have not changed.
Built on FDA and EMA good-AI-practice principles
How we built the AI around FDA and EMA guidance.
These ten principles summarize current FDA and EMA guidance on using AI in regulated environments. PixeSciTM's agent architecture was built against them directly, not retrofitted afterward.
- Start with the intended use — every capability is scoped to a specific, declared job
- Assess and manage risk — actions are risk-tiered, with approval gates proportionate to impact
- Use appropriate and trustworthy data — recommendations cite the records and rule results behind them
- Keep training and testing independent — the copilot's authority boundary is checked by an automated evaluation suite, not self-assessed
- Validate the complete system — the model runs inside the same permission, approval, and audit infrastructure as every other action on the platform
- Demonstrate performance for the real-world context — rules evaluate real event data from connected systems, not a synthetic benchmark
- Define limitations and ensure human oversight — the copilot is designed to decline rather than guess, and every regulated decision stays with a person
- Assign accountability — every action, human or agent, is attributed to an identity and a role
- Monitor and manage changes — capability and rule changes go through the same controlled-change process as the rest of the platform
- Maintain transparent and auditable records — every agent action is written into the same hash-chained trail as every human action