How we know what we publish.
Every guide on this site describes a rule that someone will be fined for getting wrong. This page states where those descriptions come from, who writes them, how often they are re-checked, and what happens when one turns out to be wrong.
Reviewed: 2 September 2026.
Qgentic's guides are written from primary sources only — the regulation, the implementing standard, the supervisor's own handbook — never from other vendors' summaries. They are written by the engineers who build the validators that implement those rules, published without individual bylines, dated on the page, and re-checked when the underlying instrument changes. Validation logic is published as a rule catalogue rather than described in prose, so a claim about what we check can be read rather than trusted. Corrections are made on the page and the date is changed.
Primary Texts, Not Secondary Summaries.
A compliance guide assembled from other people's blog posts inherits their errors and their staleness. Ours are written from the instruments below. Where a guide states a threshold, a deadline or a field definition, it comes from one of these — and the guide links to it so you can check rather than take our word.
| Instrument | What we use it for |
|---|---|
| Regulation (EU) 2022/2554 (DORA) | The Digital Operational Resilience Act itself. |
| Commission Implementing Regulation (EU) 2024/2956 | The implementing technical standards that define the Register of Information templates. |
| EBA validation rules and DPM artefacts | The published validation rules our register checks are built against. |
| FCA Handbook SYSC 15A | Operational resilience requirements for FCA-regulated firms. |
| PRA SS1/21 — Operational resilience | The PRA's supervisory statement on impact tolerances. |
| PRA SS1/23 — Model risk management | The model risk management principles behind the UK model inventory. |
| VAT Notice 700/22: Making Tax Digital for VAT | HMRC's statement of the digital-link and record-keeping rules. |
| HMRC Making Tax Digital for Income Tax | Scope, thresholds and quarterly-update obligations for ITSA. |
| Regulation (EU) 2024/1689 (EU AI Act) | The AI Act, including the Annex IV documentation set. |
| Algorithmic Transparency Recording Standard | The UK government standard for publishing algorithmic transparency records. |
| ISO 17442 / GLEIF | The LEI code structure and check-digit scheme. |
Where a regulator has not yet published a final text, the guide says so and describes the draft as a draft. We would rather leave a question open than answer it with false confidence.
Written by the People Who Build the Validators.
No individual bylines — deliberately
These pages carry no author's name. A named byline on a compliance page reads as a professional opinion offered by that individual, and that is not what this is: our guides are engineering descriptions of rules we have implemented in code, published under the company's name because the company stands behind them. Qgentic Ltd is the author of record, and the registered entity — company number 17341486 — is who you would hold to it.
Not advice, and we will not pretend otherwise
Qgentic is a software company. It is not an accountancy practice, a law firm, or a regulated adviser, and nothing on this site is legal, tax or regulatory advice. Where a rule turns on a judgement about your own business — whether a function is critical or important, where an impact tolerance should sit — the guides explain what the judgement is and who has to make it, and then stop. That boundary is the same one the product enforces: it computes what can be computed and puts a named person in front of everything else.
Claims You Can Check Rather Than Trust.
Rules are published, not described
What the product validates is published as a rule catalogue with identifiers, not as marketing prose. Where a rule mirrors a supervisor's own published validation rule, the catalogue carries both identifiers, so you can trace ours back to theirs.
Coverage is stated honestly
Every pack page states what is complete and what is not, in the same words on the page, in llms.txt and in the structured data. Where a regulator publishes no submission API, the pack prepares the package and says so — it is never described as filing.
The page and the markup agree
Structured data on this site is generated from the rendered page, not maintained beside it — the FAQ markup is parsed out of the FAQ you can see, and prices in the machine-readable catalogue are checked against the prices printed on the page. Markup that contradicts the page is worse than none.
Dated, and Re-checked When the Rulebook Moves.
Every guide carries a publication date and a last-reviewed date, in the page and in its structured data. A guide is re-checked when the instrument behind it changes — a new implementing standard, a policy statement coming into force, a supervisor's updated validation rules — and when it is, the date changes with it. A date that never moves on a page about a moving rulebook is a warning sign, on this site or any other.
Regulatory dates stated on this site are the ones published by the regulator at the review date shown. They move. Where a deadline matters to a decision you are making, check it against the source we link to.
Where AI Is Used, and Where It Is Not.
In the product
Language models read source documents and draft. They do not decide whether a filing is correct. Every field is checked by deterministic code — LEI check digits, VAT registration modulus checks, referential integrity across register tables — so identical inputs always produce an identical filing. A model cannot approve anything: every run halts for a named person, and there is no unattended self-approval mode.
In these pages
Guides are drafted with AI assistance and then checked against the primary sources listed above before publication. The checking is the part that matters and it is not automated: a model that has read a summary of a regulation is a confident source of plausible errors, which is precisely the failure this page exists to guard against.
Tell Us When We Are Wrong.
If something here is wrong, out of date, or misleading, write to privacy@qgentic.co or use the contact form, and say which page and what is wrong with it. We correct the page, change its review date, and — where the error would have changed a reader's decision — say what changed rather than editing silently.
If the error is in what the product validates rather than in what a page says, that is a defect and not a correction: it goes through the same process as any other defect, and the rule catalogue records the change.