Quality assurance
How the registry keeps every DOI and every record right: the controls, the records kept, what is measured, how faults are corrected — version 1.1.
Files: this procedure (Markdown) · the policies · the rules · the DOI System Metadata · the registrant's handbook · the continuity copy
1 October 2026 (evening); approved by Smart Scholars the same day; replaces version 1.0 of the same morning. What Smart Scholars does so that every DOI it holds or registers, and every record behind it, is right — written as a procedure a reviewer can follow, in the shape of a quality-management system (documented process, kept records, measured results, faults corrected and reviewed), without claiming any certificate. It answers the Registration Agency Agreement's "reasonable procedures to assure … that its RA Services meet the standards" (clause 3.c) and the DOI Handbook's "quality assurance measures, so that the integrity of the DOI System as a whole is maintained" (section 9.1.1).
New in 1.1: the DOI System Metadata checked on every record, with its specification published (registry.smartscholars.in/system-metadata.php); every Kernel Metadata Declaration validated against the DOI Foundation's own schema; the registry's names held on its own Handle server, kept in step and watched; the handling of the Handle administrator's key; who issued a name decided by its prefix; the record of the faults of 1 October 2026.
1. Scope and responsibility
The procedure covers the DOI Registry (registry.smartscholars.in — names, records, addresses, the ledger, resolution through the registry's own Handle server, the escrow set), the deposits Smart Scholars makes to Crossref for the journals it serves and their read-back, and the work that carries both. Rahul Raj Akkali is answerable for it. The software prepares the work; a person makes the final check before anything reaches a registry outside ours.
2. Process controls — what is checked, and the evidence kept
| Step | Control | Evidence kept |
|---|---|---|
| A name is taken | the syntax of ISO 26324; a name once given is never given again, in any state | the ledger row of the reservation |
| A record is registered | every rule of the Smart Scholars DOI Metadata Format 1.0, the record's own DOI, and a landing page on the public web (a private or local address is refused) — refused with every reason in words, nothing written | the refusal shown to the registrant; nothing in the ledger |
| A record is registered | one work, one DOI: the same work under another name is refused, naming the older name; a declared IsSameAs relation unifies the two records | the ledger rows of both names |
| A record is registered | the DOI System Metadata (DOI Handbook 10.1; ISO 26324:2025, Annex B): every element present, and the basic metadata the work's sub-type needs (the specification, version 1.0, one row per sub-type). Shown on every record now; refused for a new name from the date the policies set (version 1.1 sets 1 January 2027, with 90 days' notice). A record read in from Crossref is a fact and is held as it is | the record page's System Metadata card ("complete", or what is missing); the count of complete records on the administrator's page and on the published specification |
| A declaration is published | every Kernel Metadata Declaration valid against the DOI Foundation's schema (doi:10.1000/276) and value sets (AVS 2.3, doi:10.1000/282), using the Foundation's own files kept with the software; checked over every record on demand, and over the test records before every release | the date and result of the last check, on the administrator's page and the published specification |
| Who issued a name, and when | taken from the name's prefix, never from what a record says of itself: under a Crossref prefix, Crossref and Crossref's date; under a prefix of this registry, this registry and the day the name was registered here | every name's System Metadata Declaration (registrationAuthorityCode, issueDate) |
| A record changes | a new version only when something changed; the field-level difference recorded; the SHA-256 of every version | the ledger row of the update, with the difference and the snapshot |
| A DOI leaves the record | withdrawal needs a reason; the record stays; the name resolves to a page that says why; restore is possible | the ledger rows; the tombstone page |
| A deposit goes to Crossref | built from the record and checked before sending; after sending, read back from Crossref and compared with what was sent; it stays "sent, not confirmed" until the read-back matches | the deposit log; the journal's activity log |
| A name resolves | every registered name is held on the registry's own Handle server (an independent Handle.Net service at hdl.smartscholars.in, written to only over HTTPS) with the address the registry holds; every change of address is carried to it; a change that cannot be carried stays pending, with its reason, and is tried again every ten minutes | for each name, when it was last carried and the address carried, or the reason; the number pending on the administrator's page |
| The Handle administrator's key | held in two places only — on the Handle server's machine, readable by its administrator alone, and in the registry's settings, encrypted — and never shown on a page, in a log or in a message. A key seen anywhere else is replaced the same day, and the replacement proven: the new key writes, the old one is refused, on the server and through its public address | the date of each replacement and its proofs |
| An address stops answering | every registered address read weekly and slowly (two pages of a site at a time, a pause between rounds); a host that stops answering the reader is left alone for that run, with nothing decided; an address that fails two runs in a row is listed with the day it first failed; after 90 days the name may be pointed at its record page here, by a person's press | the list on the registrant's console; the ledger row of a repoint |
| Anything is released | every test suite green on a clean checkout, the release rehearsed offline, and the server's own check after upload reading every file's hash | the test run; the manifest; the check's output |
3. Records
The ledger: every change to every DOI, numbered per name, only ever added to, never rewritten (the test suite proves it). The escrow set: every DOI, record and ledger row in open files, written nightly and carried into a private repository and the off-site backup. For each name, the Handle server's state: when it was last carried and to which address, or why not. The DOI System Metadata report and the date and result of the last schema check. The activity log of each journal for its deposits. The night log and the runbook. The results of every release's tests and of the check after every install.
4. Monitoring and measurement
Every public property is checked from two servers independently — every five minutes from one, twice an hour from the other — each watching the other, with a mail on every change. From this version the Handle server is checked as well, twice an hour: one name it holds is read through its public address, which must answer with that name's values. Every install ends with the server's own check: files, hashes, database, live pages.
What is measured and read, and where: the records carrying the complete DOI System Metadata (the administrator's page and the published specification — on 1 October 2026, 920 of the 928 records held; the eight are issue records of one journal whose Crossref record carries no title, named from their own record when the prefix is next read in from Crossref); the declarations valid against the DOI Schema (the same two pages, after each check); the names waiting for the Handle server (the administrator's page — none after the run of 18:40 IST on 1 October 2026); the addresses not answering (the registrant's console); the deposits sent but not yet confirmed (each journal's page).
5. Faults, corrections, prevention
A fault found on a live page, in a test, in a client's reply or in a nightly review is recorded with what happened, its cause, the correction, what now prevents it, and the test that proves it; the fix ships with a test that fails on the old behaviour and passes on the new, and the release goes through section 2's last row. A fault that came from a rule being wrong (not a slip) changes the rule's document — the policies, the metadata format or the rules of the registry — by a new numbered version with the date it takes effect.
The faults of 1 October 2026 that touched the registry's service:
| Found | What happened | Cause | Correction and prevention |
|---|---|---|---|
| The first weekly reading of the addresses | 925 live pages of one journal were marked as not answering | the journal's host refused 928 quick requests in a row | the reader slowed (two pages of a site at a time, a pause between rounds); a host that stops answering is left alone for the run with nothing decided; a test reproduces the refusal |
| Putting the names on the Handle server | writes with the administrator's key, sent through the public address, were refused (HTTP 402) | the Handle server accepts a key only over HTTPS, and the web server in front of it passed requests on over plain HTTP | every request now reaches the Handle server over HTTPS; proven through the public address by a write, a removal, and a wrong key refused |
| After the first push to the Handle server | the ten-minute retry of pending names was not running | its schedule line had not been saved | the line saved and its first run read (none pending); every schedule is listed with the log it writes, and a new schedule's first log is read before the work is called done |
6. Review
Every Monday a written review sets the week's work against the Registration Agency goal; every morning a status names what was found overnight, in red first. Once a month the facts the sites state on another body's authority are read again at their source — the statutory registrations and the membership listings. All are kept.
7. Known gaps, honestly
The 90-day repoint of a dead address is one press on the registrant's console, not automatic, so that a page a site merely hid from readers is never repointed by mistake. The Handle server is a test service: doi.org resolves the names through Crossref, as it must until appointment, and the registry's own server is kept in step to show the service working; it runs on one machine, with no mirror yet. The DOI System Metadata is shown on every record but required only from the date the policies set. The schema check runs when pressed and before each release, not yet on a schedule. None of these affects the correctness of a record held today.
Version history
| Version | Date | What changed |
|---|---|---|
| 1.0 | 1 October 2026 (morning) | the first version |
| 1.1 | 1 October 2026 (evening) | the DOI System Metadata check and its published specification; the schema check of every declaration; who issued a name, by its prefix; the landing page on the public web only; the Handle server — its controls, its records, its monitoring; the administrator's key; the record of the day's faults; the monthly reading of the facts stated on another body's authority |
