The eBR gap most biomanufacturers live with
Most electronic batch record systems were built as document management tools first. The process context — which unit operation, which phase, which step — is added later, by convention, by folder structure, or not at all. The result: records that are compliant on paper but disconnected from the process data that would tell you something is going wrong.
Hercule eBR starts from ISA S88. Every form is positioned in a process hierarchy at design time. Operator instructions travel with the form. A value recorded out of specification does not wait for a batch review meeting — it fires a CPV alarm immediately, while the batch is still running.
That coupling is not an integration between two products. It is one system.
What makes Hercule a different eBR
ISA S88-Structured Forms
Every form is created within Hercule's ISA S88 process hierarchy — procedure, unit procedure, operation, phase. Context is not inferred from a folder name; it is defined at design time. This makes cross-batch and cross-product comparisons meaningful by default.
Real-Time CPV Coupling
An OOS value recorded by an operator in an eBR form triggers a CPV alarm immediately on the running batch. eBR and CPV are the same system — not two modules connected by an export. No other platform in the biomanufacturing space offers this coupling today.
Validator Sign-Off, Separate From Operator
Hercule enforces a dedicated validator role. The operator who fills the form cannot be its validator. Every form submission requires mandatory sign-off. Forms are validated before deployment to routine use — the same rigour at design time that GMP requires at review time.
The eBR–CPV coupling: one system, not two
Most vendors selling both eBR and analytics either bundle separate products or require an export/import workflow between them. Hercule does not.
Because eBR and CPV share the same data layer and the same ISA S88-structured data model, an out-of-specification value recorded in a batch form is immediately visible in CPV — on the running batch, before it is closed.
This matters for two reasons:
Deviations can be responded to during the batch, not discovered at review.
Every CPP and CQA is typed at the moment of capture (in the form definition), not classified retrospectively. CPV charts are meaningful from the first batch.
This architecture is a deliberate product decision, not a roadmap item. Aizon Execute, for example, separates its eBR and analytics modules — the coupling in Hercule is structural.
The batch release report
Hercule generates a custom batch release report at the close of each batch. The report is configurable and can be filtered to show only CQA values, only CPP values, or any combination relevant to your release criteria.
Key elements of the release report:
All operator entries for the batch, in process order, with timestamps and sign-off records
CPV status at time of release — control chart positions, any alarms triggered during the batch
Equipment use and material batch traceability, where process measures include connector-linked equipment validation status
A dedicated sign-off panel for the batch release decision, with mandatory authorisation before the record is closed
The report is not a generic export. It is structured around your process hierarchy and your release criteria, as defined in Hercule.
How to use Hercule as an eBR
1
Define your process structure in Process Builder
Before a single form is created, your ISA S88 process hierarchy is set up in Hercule's Process Builder — products, procedures, unit procedures, operations, phases. This is a self-service step: no spreadsheets, no wait for an IT project. The structure becomes the scaffold for every eBR form you build.
2
Build forms with operator instructions embedded
The form editor lets you design data entry forms directly tied to a phase or operation in your process. Operator instructions — procedural text, reference values, alert thresholds — are embedded in the form itself. The operator sees what to do alongside where to record it. Recipe-driven guidance without a separate SOP document open on a second screen.
3
Version and validate before deployment
Every form version is tracked. A new version of a form must pass a validation step before it becomes available for routine use. The validator role is separate: the person who designs or modifies the form cannot be its own approver. Validated forms are deployed; superseded versions are retained for record integrity.
4
Operators fill forms — with mandatory sign-off
During a batch run, operators access the forms relevant to their current process step. Each form submission requires a mandatory sign-off. Any value recorded outside specification is immediately flagged — both in the eBR record and as a live CPV alarm visible to process and quality teams.
5
Release with a structured batch release report
At the end of the batch, Hercule generates a batch release report that can be filtered by CQA and CPP. The report includes a dedicated sign-off panel for batch release authorisation. The entire record — from raw operator entries to release decision — is traceable in one place.
What Hercule eBR covers — and what it does not
What is in scope today
Hercule as an eBR is production-ready and GMP-validated for:
ISA S88-structured form design and versioning
Operator instruction embedding in forms
Mandatory operator sign-off on each form submission
Separate validator role with pre-deployment form validation
Real-time OOS-to-CPV alarm coupling on running batches
Custom batch release report with CQA/CPP filtering and dedicated sign-off panel
Equipment use and material batch traceability via read-only connectors to external systems
21 CFR Part 11 and GAMP5 V2 compliance framework
On-premise deployment — no cloud dependency, full data sovereignty
Known gaps — we will tell you upfront
Two items are outside the current scope of Hercule eBR. We name them here because QA directors ask, and because honest scoping saves time for both sides.
- ERP write-back for BoM reconciliation: Hercule is read-only by architectural design. It reads from your ERP (SAP, IDOX, others) but does not write back. Bill of materials reconciliation triggered by batch completion — common in some manufacturing execution workflows — is not handled by Hercule. This is a deliberate choice to protect data integrity and simplify validation scope, not a gap we plan to close.
- eSign on the batch release report: Qualified electronic signature (21 CFR Part 11 eSign, distinct from operator sign-off) applied directly to the batch release report PDF is on the product roadmap. Current sign-off is captured within the Hercule application. If your release SOP requires a wet or qualified eSign on the PDF output, raise this in your evaluation call — we will give you the current timeline.
Frequently asked questions
Here are some common questions about Hercule as an eBR.
Yes. Hercule is designed and validated under GAMP5 V2 and 21 CFR Part 11. The system enforces audit trails, mandatory sign-offs, user authentication via Keycloak SSO, and role separation between operators and validators. Trivy-scanned Docker images are part of the standard deployment package. Customers receive full validation documentation to support their own site qualification activities.
In Hercule, you do not create a form and then file it somewhere. You define the process hierarchy first — products, procedures, unit procedures, operations, phases — in Process Builder. Forms are then created within that hierarchy. This means every data point captured has a defined process context from the start: which product, which step, which phase. It makes batch-to-batch comparison and CPV analysis meaningful without post-hoc mapping.
After validation of the encoding, the OOS value is immediately visible in the CPV module as a live alarm on the running batch. This is not a notification sent by an integration — it is the same data layer. The CPV alarm is available to process and quality teams while the batch is still in progress, allowing a response before the batch closes. No other product we are aware of offers this coupling without a separate integration or export step.
Yes. Hercule reads from LIMS, ERP, SCADA, EMS, and historian systems via read-only connectors. Equipment validation status and material batch information from external systems can be surfaced in Hercule as process measures and included in batch records and release reports. Hercule does not write back to any connected system — this is an architectural choice that simplifies validation scope and protects source-of-truth integrity in your existing systems.
Hercule is on-premise only, deployed via Docker Compose on your own Ubuntu/Linux server. There is no cloud-hosted version and no cloud dependency at runtime. All batch data remains on your infrastructure. This is particularly relevant for customers with GDPR obligations, classified manufacturing environments, or contractual restrictions on third-party data processing. No data processing agreement with DNAlytics is required for the software itself.
Implementation timelines depend on the complexity of your process structure and the number of forms to build. Based on customer experience, a focused implementation covering one product and one process stage — including process mapping, form build, validation, and operator training — typically takes weeks, not months. The Process Builder and form editor are self-service tools; your team can build and modify forms without waiting for DNAlytics professional services after the initial onboarding.