Summary
- The problem
- Recurring reports are often built by exporting rows and counting them. Revisions, reopened records and late data can change a number without showing why, and a reviewer cannot easily trace a figure to its source.
- Seal’s approach
- Each report runs against a defined population, time window and data cut. Source versions, counting rules and exceptions are retained with the run. Neil drafts the narrative from the selected records, and reviewers approve the interpretation.
- What changes
- A count of deviations counts deviations, not source rows. A signed report stays fixed as later data arrives, and agreed findings become assigned follow-up linked to the issued report.
- Where to start
- A recurring report and one data extract whose numbers your team has to reconcile. Book a demo.
Eleven source rows are not eleven deviations.
The extract includes eight original deviation records and three later revisions. Counting rows would count some deviations twice.
Deviation extract / reporting cut R-009
11 source rows
Original records
R-009-BASE- Identities
- DEV-101–108
- Count rule
- Distinct deviation ID
- Data cut
- 11 September 2026
DEV-101 through DEV-108 are eight distinct deviation identities. The reporting definition counts each identity once, using its selected revision at the data cut.
What follows
Retain the identity set and the inclusion rule with the report run.
Run the work in Seal.
Define the question.
Set the population, time window, source ownership, calculation and treatment of missing or repeated records.
Run against a data cut.
Retain source versions, extraction time, transformations and exceptions. Compare the output against the selected source population.
Review the conclusion.
Use Neil to draft the narrative and proposed actions. Reviewers approve the interpretation and keep follow-up work linked to the issued report.
The eleven source rows represent eight deviation identities. Three rows are later revisions of existing records. I would retain both the deduplication rule and the selected revision for each identity.
R-009 / population reconciliation
DraftCount eight distinct deviations under this report definition. Preserve all eleven source rows for traceability.
Report owner
Confirm that distinct identity, not row count, is the intended metric.
Data owner
Check the revision selection for DEV-102, DEV-104 and DEV-108.
A report your team can reproduce.
Why teams choose Seal for GxP reporting
A GxP report built by exporting rows from several systems into a spreadsheet or BI tool is counted by hand before its charts are pasted into a document for signature. Seal runs the report against a defined population and data cut drawn from records that already share one platform, and keeps the counting rules and exceptions with the run.
A reviewer can trace a figure to the records behind it, Neil drafts the narrative from those records for people to approve, and a signed report stays fixed while later data feeds the next run.
The definition stays with the metric.
A chart should retain its numerator, denominator, time basis and exclusions.
Record whether dates refer to occurrence, opening or closure. Separate event counts from affected-batch counts. Review how late-arriving records and reopened work affect the next report cut.
A signed report stays fixed.
Keep the reviewed data cut and report version unchanged while later information continues to arrive.
New data can feed another run or an amendment, while the previously issued output keeps its calculation basis. A dashboard can move; an issued report is a record of what was reviewed.
A schedule starts a defined workflow.
Configure the report period, source requirements, owners, review and distribution for each recurring output.
Distinguish ready, missing, stale and inaccessible inputs before the run is treated as complete. Retain retries and late-arriving records. Daily dashboards, management reviews and annual product reviews can use related definitions while keeping their purpose and approval requirements distinct.
The review produces a decision and follow-up.
Keep the source references behind the narrative and turn agreed findings into assigned work.
Review calculations, charts, exclusions and interpretation together. Connect actions to the finding, owner, due date and expected evidence. Prepare an inspection or submission source package from the selected records while retaining the separate requirements for that output’s intended use.
Connected to the surrounding work.
Keep specialised systems where they belong. Agree the source of each record, the permitted actions and the reconciliation at each handoff.
Explore integrationsAQuestions and answers
Can we keep our BI and analysis tools?
Yes. Connect the selected data, calculation or script version, output and review record. Seal can coordinate the report workflow without replacing specialist analysis.
Will a schedule publish incomplete data?
Define readiness and exception handling for the scheduled workflow. Preparation, reviewer approval and distribution should remain distinct states.
What does Neil write?
A draft interpretation grounded in the selected records, with source references and unresolved questions. The report owner remains responsible for the conclusion and its intended use.