Seed data

DemoDataSeeder observes StartupEvent and loads a working set so the platform has content on first run. It is guarded on a single condition:

if (GovFile.count() > 0) {
    return;
}

So it seeds once per database file, and is skipped on every subsequent start. Delete data/ to get it back. In Kubernetes, where no volume is mounted, it re-runs on every pod restart — see Operations.

The seeder writes in four passes: seedFiles(), seedDevices(), seedAuditTrail(), seedSignatures(). All four run inside one @Transactional method.

Pass	Rows
Files and notings	8 GovFile, 20 FileNote
Devices	6 SigningDevice
Audit trail	12 AuditEvent
Signatures	2 Approval

Why the content is what it is

Every file is modelled on a real Andhra Pradesh instrument. The point is that a Section Officer reading the screen should recognise the register they work in, not a placeholder.

• File numbers follow departmental prefixes: ITE&C/RTGS/2026/0247, REV/LRM/2026/1183, FIN/DBT/2026/0912.
• G.O. numbers distinguish G.O.Ms.No. (Manuscript, a substantive order) from G.O.Rt.No. (Routine).
• Heads of Account are real: 2852-80-800-04 for IT industry, 2216-03-104-04-310-312 for housing subsidy.
• Schemes are real: Navaratnalu Pedalandariki Illu, Mana Badi Nadu-Nedu, MGNREGS, NHM.
• Noting language is bureaucratic register — "Submitted for orders", "Examined", "Concurred", "Placed before the Approving Authority for a view".

Timestamps are all relative to startup via days(n), hours(n) and ahead(n) helpers, so the data never looks stale.

The eight files

Statuses break down as five PENDING, two APPROVED, one RETURNED. No file is seeded REJECTED, so the inbox's REJECTED filter is empty until you reject something yourself.

File number	Priority	Status	Category	Amount	Notes
ITE&C/RTGS/2026/0247	MOST_IMMEDIATE	PENDING	Policy directive	—	2
REV/LRM/2026/1183	IMMEDIATE	PENDING	Revenue order	—	3
FIN/DBT/2026/0912	MOST_IMMEDIATE	PENDING	Financial sanction	₹842.7 Cr	2
MAUD/SC2/2026/0071	IMMEDIATE	PENDING	Tender acceptance	₹1,247.0 Cr	2
HFW/PROC/2026/0455	ROUTINE	PENDING	Tender acceptance	₹96.4 Cr	2
ITE&C/SEC/2026/0198	IMMEDIATE	APPROVED	Policy directive	—	3
PR&RD/MGNREGS/2026/2031	ROUTINE	APPROVED	Financial sanction	₹214.8 Cr	3
EDN/INFRA/2026/0663	ROUTINE	RETURNED	Financial sanction	₹1,880.5 Cr	3

The five categories exercise genuinely different approval logic in a real secretariat — a financial sanction needs a Head of Account and a budget check, a tender acceptance is time-boxed by the tender conditions, a revenue order carries statutory backing. The demo does not enforce those differences, but the content shows what would need enforcing.

The pending five

ITE&C/RTGS/2026/0247 — Unified AI Dashboard across 26 districts, initiated by a Joint Secretary 19 hours ago. Two GREEN notes: the proposal, then a Deputy Secretary's "Recommend approval". It is the top of the inbox because it is MOST_IMMEDIATE with the most recent initiation.

REV/LRM/2026/1183 — mandating Class-3 DSC for land mutation. This is the most self-referential file in the set: it justifies token-based signing with a real number, 3,412 mutation entries carrying untraceable manual endorsements. Its third note is YELLOW, so a pending file shows a draft note before any decision is taken.

FIN/DBT/2026/0912 — ₹842.7 Cr second-quarter release under Navaratnalu Pedalandariki Illu, against Head 2216-03-104-04-310-312, 1,42,318 beneficiaries, Aadhaar seeding at 99.4 per cent. Best file to sign during a walkthrough: MOST_IMMEDIATE, a real money figure, and a condition requiring tranche-wise signature.

MAUD/SC2/2026/0071 — Amaravati Smart City Phase-II technical bid, ₹1,247.0 Cr, tender APEPROCURE/2026/SC-II/071. Carries a 48-hour deadline from the TEC recommendation, which is the concrete case for mobile approval.

HFW/PROC/2026/0455 — 12 CT and 34 ultrasound units under NHM, ₹96.4 Cr on the APMSIDC rate contract. ROUTINE, so it sorts to the bottom despite being a real procurement.

The two approved files

Both end in a signedNote() — a GREEN note carrying both signatureHash and signedAt — and both have a matching Approval row, so /verify resolves their digests.

File	Signed	Digest
ITE&C/SEC/2026/0198	6 days ago	4f2a9c1e7b83d604…08b6f317
PR&RD/MGNREGS/2026/2031	4 days ago	9c7e14b0af38265d…46e9d208

Paste either full digest into /verify and you get six PASS checks without signing anything first. Useful for demonstrating verification independently of the signing flow.

These two are also the only input to avgApprovalMinutes: three days and two days from initiation to signature, averaging 3,600 minutes.

The returned file

EDN/INFRA/2026/0663 — Nadu-Nedu Phase-III revised estimates, ₹1,880.5 Cr, an 11.4 per cent enhancement over Phase-II. Its three notes are the clearest illustration of the noting sheet as a conversation:

1. GREEN, Under Secretary — the proposal, attributing the enhancement to SoR 2026 and additional toilet blocks.
2. GREEN, Joint Secretary — "The enhancement over Phase-II appears substantial. Item-wise justification and the third-party quality audit report for Phase-II works are not on record."
3. YELLOW, Approving Authority — returned, asking for a revised BOQ reconciled against SoR 2026 and the Phase-II quality audit certificate.

That third note is YELLOW because a return is a draft instruction, not a disposal. It demonstrates the RETURN outcome without requiring anyone to produce it.

Notings

Twenty in total, distributed 2, 3, 2, 2, 2, 3, 3, 3 across the eight files. Eighteen are GREEN and two are YELLOW — the third note on REV/LRM/2026/1183 and the third on EDN/INFRA/2026/0663. Two of the eighteen GREEN notes are signedNote() entries carrying a digest.

Authors are consistent named officers with plausible designations — K. Sreenivasa Rao (Joint Secretary), R. Anitha (Deputy Secretary, IT), M. Venkateswarlu (Additional Secretary), Dr. A. Padmavathi (Director). The two signed notes and the return are authored by demo.user with designation Approving Authority, matching the constant FileResource writes, so notings you create yourself sit continuously with the seeded history.

Six signing devices

Two IC types, NXP_JCOP4 and INFINEON_SLE78, across four lifecycle states and four CAs.

Serial	IC	Firmware	State	CA	Assigned to
MS-2026-A7F3E291	NXP_JCOP4	1.2.4	ACTIVE	eMudhra	Demo Officer
MS-2026-B2C8D104	INFINEON_SLE78	1.2.4	ACTIVE	NIC-CA	R. Anitha, Deputy Secretary
MS-2026-C9E1F773	NXP_JCOP4	1.2.3	PROVISIONED	eMudhra	—
MS-2026-D4A6B520	INFINEON_SLE78	1.2.4	REGISTERED	—	—
MS-2026-E8B3C947	NXP_JCOP4	1.2.2	REVOKED	Sify	Former Officer
MS-2026-F1D7A386	INFINEON_SLE78	1.2.4	ACTIVE	CDAC	M. Venkateswarlu, Additional Secretary

Three are ACTIVE, which is where the dashboard's totalDevicesActive: 3 comes from.

Details worth noticing, because they are the kind of thing a real inventory surfaces:

• The REGISTERED device has no CA and no certificate — enrolled but not yet issued. It is the row that exercises the nullable provisionedCa and certificate columns.
• The REVOKED device has validTo set to 90 days ago, so it is both revoked and expired, assigned to "Former Officer". The realistic case of an officer who has moved on.
• Firmware spread of 1.2.2, 1.2.3 and 1.2.4 gives a fleet-management screen something to report. Nothing in the platform acts on it.
• The four CAs — eMudhra, NIC-CA, Sify, CDAC — are all genuine CCA-licensed Indian Certifying Authorities.

MS-2026-A7F3E291 is the device whose certSubject and certSerial match what VerifyResource emits: subject CN=Demo Officer, OU=RTGS, O=Government of Andhra Pradesh, C=IN, serial 4F2A9C1E7B83D604 — which is the first 16 characters of the ITE&C/SEC/2026/0198 digest, upper-cased. The device inventory and the verification output were made to agree by hand. Nothing computes that relationship at runtime.

Twelve audit events

Written by a private audit() helper that bypasses AuditEvent.record(), because record() forces occurredAt = Instant.now() and the seed needs historical timestamps.

When	Event type	Actor	Outcome	Target
11d	CREDENTIAL_REGISTERED	demo.user	SUCCESS	MS-2026-A7F3E291
10d	AUTH_SUCCESS	demo.user	SUCCESS	—
9d	FILE_RETURNED	demo.user	SUCCESS	EDN/INFRA/2026/0663
6d	FILE_APPROVED	demo.user	SUCCESS	ITE&C/SEC/2026/0198
6d	SIGNATURE_VERIFIED	audit.officer	SUCCESS	ITE&C/SEC/2026/0198
5d	AUTH_SUCCESS	demo.user	SUCCESS	—
4d	FILE_APPROVED	demo.user	SUCCESS	PR&RD/MGNREGS/2026/2031
3d	AUTH_SUCCESS	audit.officer	FAILURE	—
3d	CREDENTIAL_REGISTERED	M. Venkateswarlu	SUCCESS	MS-2026-F1D7A386
2d	SIGNATURE_VERIFIED	anonymous	SUCCESS	PR&RD/MGNREGS/2026/2031
2d	FILE_REJECTED	demo.user	SUCCESS	REV/LRM/2025/9987
4h	AUTH_SUCCESS	demo.user	SUCCESS	—

Three actors appear: demo.user (Approving Authority), audit.officer (Compliance Auditor) and anonymous (Verifier). The anonymous row is historical: verification is still public, but an anonymous call no longer writes to the ledger, so this row could not be produced today.

The rows are seeded out of chronological order in the source, which does not matter because AuditResource orders by occurredAt desc.

The failure row

audit("AUTH_SUCCESS", "audit.officer", "Compliance Auditor", null, "FAILURE",
        "Assertion rejected — credential counter regression detected. Session denied.", days(3));

A counter regression is the textbook cloned-authenticator signal, and the Quarkus WebAuthn extension really does perform that check against the counter column. Seeding it makes the control visible on a screen it would otherwise never appear on.

Note the inconsistency: eventType is AUTH_SUCCESS while outcome is FAILURE. The event type names the operation, not the result, but reading it as "AUTH_SUCCESS / Failure" in the audit table is confusing, and the type should be AUTH_ATTEMPT. It also means the type filter cannot separate successful logins from rejected ones.

It is also the row that shows outcome doing real work in the UI: the outcome badge renders red while the event-type badge stays neutral, because the two columns are coloured independently.

A reference outside the file set

audit("FILE_REJECTED", "demo.user", "Approving Authority", "REV/LRM/2025/9987", "SUCCESS",
        "Earlier mutation proposal rejected — proposal superseded by REV/LRM/2026/1183.", days(2));

REV/LRM/2025/9987 — note the 2025 — is a prior-year proposal that was rejected and superseded by the 2026 file in the set. It has no gov_file row, which is possible because targetId is free text rather than a foreign key.

Two consequences to expect while reading the screens: the audit trail shows a rejection for a file that cannot be opened, and the inbox's REJECTED filter stays empty because no seeded file carries that status. Both resolve as soon as you reject something yourself.

Two signature records

signature("ITE&C/SEC/2026/0198",
        "4f2a9c1e7b83d6045ae91cf3728b60d95e14a7c206fb3891d4e75c2a08b6f317", days(6));
signature("PR&RD/MGNREGS/2026/2031",
        "9c7e14b0af38265d713ce4b98a02f6d1358be7c4a91d0f62b85a3c1746e9d208", days(4));

Both with username = "demo.user" and assurance = "WebAuthn user verification". The documentHash values match the signatureHash on the corresponding signed notings exactly, which is what keeps the file detail screen and the verification screen consistent.

These digests are literals, not computed from the file bodies. Hashing the seeded body text of ITE&C/SEC/2026/0198 will not produce 4f2a9c1e…. The seeded verification path is therefore self-consistent but not reproducible from the document; only digests produced by an actual signing action satisfy sha256(body) == documentHash. Security model covers what the digest does and does not establish.