Certifying green hydrogen for the whole country, from a blank page
India had no process for certifying green hydrogen. The process was defined with the ministry first, then the portal was built around it, security-audited, and launched by the Minister on 1 July 2026.
- Client
- Ministry of New and Renewable EnergyDelivered through NeGD, MeitY
- Role
- Project ManagerBDO India
- Team
- 10 peopleBusiness analysts, developers, QA, design, DevOps
- Timeline
- Jan to Jul 2026Public launch on 1 July 2026
The challenge
India aims to produce 5 million tonnes of green hydrogen a year by 2030. For hydrogen to count as green, it must be made from renewable energy and stay under a set carbon limit, and someone has to check and certify that. The Ministry of New and Renewable Energy issued the scheme rules in April 2025. What did not exist was a way to apply, audit, approve and issue certificates online.
There was no existing process to copy, so the process had to be defined before anything could be built. The launch date was fixed, the cloud environment arrived only two and a half weeks before the first testing target, and an external security audit stood between the build and going live.
What was done
1. Define the process with the ministry first.
The team started from the scheme rules, mapped every user journey, studied similar portals and presented the process flow to the client. Nothing went to development until the client accepted it. The requirements, about 250 features across 11 modules, were signed off before the first sprint, and every later change went through a formal change request.
2. Never overwrite a certificate.
A certificate is a legal record. When one is amended, the system keeps the original and adds a new version, for all four certificate types. It costs more storage and makes the screens more complex. It means the full history can be shown years later if anyone challenges a certification.
3. Test security before the auditors arrive.
The team reviewed its own code first and closed 48 of 51 findings before the external audit by a CERT-In empanelled agency began. The audit then needed one short round of fixes, and clearance came on 30 June, the day before launch.
4. Launch without AI, and add it later.
The people who verify and approve certificates had never used this digital process. They needed to understand it first, so Phase 1 launched with no AI. It was planned for Phase 2.
My role
What I owned
The process definition and requirements baseline, the change-control routine, delivery governance and escalation, the UAT and security-remediation plan, and the Phase 2 scope and request for quotation.
What the team delivered
Design, build and testing of 11 modules, and the fixes that came out of the security review. A team of ten, including me.
What the client decided
The scheme rules, sign-off of the baseline and of each change, acceptance after UAT, security clearance, and the decision to launch.
The result
The Minister launched the portal on 1 July 2026. 8 producers, 3 verification agencies and 4 committee members are on it. More than 20 applications have come in and 8 certificates have been issued so far. Signing with Aadhaar eSign and a digital signature certificate, notifications and the document locker all work.
After launch, the first change request touched the workflow itself. It was analysed, approved by the client and ready in about three days.
Where AI fits
Phase 2 · approved, in procurement
Phase 2 adds AI to help check submissions, spot unusual emissions data and support verifiers. Two rules apply. AI advises, and a named officer approves every important decision. Every claim it makes must point to the document behind it. It will be accepted against cases that people have already answered by hand.
The lesson
When a process is new, the people who must judge the result have to understand it first. Holding AI back by one phase means Phase 2 can be accepted on evidence.
When a project has to define its own process, the time spent agreeing it with the client before development is what makes the launch date possible.
View the numbers as a table
| When (2026) | What |
|---|---|
| Jan | Mandate received; process defined; BRD signed before sprint 1 |
| Feb | Build starts |
| 27 Mar | UAT release; 66 fixes and enhancements closed before submission |
| May | Internal security review: 48 of 51 findings closed |
| 30 Jun | External audit passed; certificate issued |
| Aug | Phase 2 AI scope finalised |
View the numbers as a table
| Certificate | Rule |
|---|---|
| Concept (P-1) | Amendments create a new version |
| Facility (P-2) | Amendments create a new version |
| Provisional (P-3) | Issued automatically at or below 2.0 kg CO2e per kg H2 |
| Final (P-4) | Payment-gated; acts as the Guarantee of Origin |
Read the detailsTimeline, requirements, rules, decisions, architecture, testing, change control and the Phase 2 plan
There was no as-is process to digitise
The Green Hydrogen Certification of India scheme sits under the National Green Hydrogen Mission at MNRE, and its rules were issued as an Office Memorandum on 29 April 2025. India had no established digital certification process for green hydrogen of this kind, so there was no mature process to take and automate.
The scheme certifies hydrogen in four stages: a Concept Certificate, a Facility Certificate, a Provisional Certificate and a Final Certificate. Producers apply, accredited verifiers (ACVs) audit, and a Technical Committee (TC) decides. A Super Admin and the ministry run the registry, and anyone can verify a certificate without logging in.
Process definition, product design, delivery, stakeholder coordination, security testing and the later AI design all had to happen together rather than in sequence.
Define it, build it and pass the audit, all at once
- No existing certification process, and so no benchmark to build against
- Four certificate types, each needing an auditable record of every amendment
- A fixed public launch, with the cloud environment arriving only two and a half weeks before the first UAT target
- An external security audit by a CERT-In empanelled auditor standing between the build and production
- Validation rules that change through office memoranda, not through releases
- Verifiers and committee members who had never operated the digital process they were about to be measured on
From process definition to a Phase 2 AI scope
I started on the programme in January 2026 as Project Manager, leading a team of ten that included two business analysts, three full-stack developers, a tech lead, QA, UI/UX and DevOps. I owned delivery from process definition through production, ran the client relationship and change control, and wrote the scope for the Phase 2 AI layer.
The reports I wrote kept my own decisions and coordination separate from what the team built. This page does the same.
January to a public launch on 1 July
View the numbers as a table
| Date (2026) | Event |
|---|---|
| Jan | Mandate received; BRD v1.0 submitted |
| 13 Mar | Cloud environment ready |
| 19 Mar | Client meeting chaired by the client CTO; 40 field changes decided; blockchain moved out of Phase 1 |
| 2 Apr | Pre-login site submitted for UAT; certificate flows followed in phases |
| 10 May | UAT round 1 |
| 9 Jun | UAT round 2 workshop with producers, ACV agencies and the Technical Committee |
| 19 to 22 Jun | External security reports received and every finding fixed |
| 1 Jul | Public launch, announced by the Minister |
Between the milestones, the build ran as two-week sprints, about nine of them, with a demo every three. Sprint two built the database schema and registration. Sprint three built the Concept and Facility flows. Sprint four built the Provisional and Final flows, the rules engine and the UAT preparation.
Defining a process that did not exist
The scheme was the starting document. Each step below fed the next, and nothing went to development until the process flow had been presented to and accepted by the client.
- Scheme as guidelinewhat must be done
- User journeysstakeholders and users
- Rules and processesmapped from the journeys
- Benchmarkingacross similar portals
- Gap analysisno gaps left open
- Process flowpresented to the client
- Developmentthen built
Ten people, including me. A daily stand-up, a weekly blocker review, a Director-level review at each milestone, and a monthly progress report on the client's template. Tasks were tracked in OpenForge, an internal NIC tool.
Team to tech lead, to me, to the programme Director, and from there to the client's programme director. Formal letters went at Director level, and approvals ran through the government file system.
A signed baseline, and a controlled way to change it
The business analysts prepared the BRD. I reviewed it and presented it in the regular client connects, and the client Director signed it before sprint one. Nothing in it changed after sign-off. Later changes went in as change requests, recorded in an annexure to the BRD.
| Artefact | What it held |
|---|---|
| BRD v1.0 to v2.0 | Submitted in January; v2.0 shared on 22 April, with the technology references corrected |
| SRS | About 250 features across 11 modules, traced through a requirements traceability matrix from requirement to function to feature |
| Field mapping | 14 sheets mapping fields to each certificate type and each stakeholder |
| Validation rules | 124 rules: 37 for Concept, 40 for Facility, 20 for Provisional and 27 for Final, with 163 mapped to API endpoints |
| Notification matrix | 42 triggers across email and SMS |
| Field change tracker | 40 changes from the 19 March client meeting: 15 at the highest priority, 21 at the next and 4 at the lowest |
| Verifier checklists | Cut from long to brief: 8 items for Concept, 12 for Facility and 12 for Final |
| Records of discussion | After each substantive client meeting: seven decision sections and 14 actions from 19 March alone |
| FAQs and manuals | 74 FAQs across four audiences, and user manuals for producers, verifiers, committee members and super admins |
Requirements came from the scheme text, the client's own field lists, a round of comments from three industry organisations (53 comments in all) and the 19 March meeting chaired by the client CTO. That meeting moved blockchain out of Phase 1.
The scheme, enforced by the system
The platform has 11 modules, among them authentication and role-based access, the application forms, the workflow engine, ACV and TC review, the certificate registry, public verification, notifications, administration and an immutable audit trail. The workflow is a state machine, and every move has a named actor.
View the numbers as a table
| State | Moved by | Next |
|---|---|---|
| Draft | Producer | Submitted or withdrawn |
| Submitted | Producer | ACV review; provisional certificates are issued automatically |
| ACV review | Verification agency (ACV) | ACV report, or clarification requested |
| ACV report | ACV | TC review |
| TC review | Technical Committee | Approved, rejected or clarification requested |
| Rejected | Technical Committee | A second ACV is appointed; its decision is final |
| Approved | Technical Committee | Certified once a valid signature is applied |
| Certified | System | Active, or withdrawn with a reason and a timestamp |
Rules settled, and the reason for each
| Rule | Why |
|---|---|
| A Provisional Certificate is issued automatically, in the same transaction as the submission, with no verifier or committee involved | The scheme says so, and a review step would contradict it |
| When a Final Certificate's carbon intensity exceeds 2.0 kg CO2e per kg H2, every Provisional Certificate for that facility is withdrawn in one transaction | Partial withdrawal would leave the registry in a state the scheme does not allow |
| A fee applies to the Final Certificate only, calculated per 100 kg of hydrogen | The scheme sets no fee for the earlier certificates and provides no refund |
| Every form carries two signature options, Aadhaar eSign and a DSC, and a certificate is generated only after a valid signature | Non-repudiation |
| A facility with the same boundary and meter becomes a new version of the same Facility Certificate; anything else is a new certificate | Phases of one project must not block each other |
| After a rejection, the Technical Committee appoints a second verifier, and its decision is final | The scheme provides for exactly one second opinion |
| Verifier and committee accounts are approved by the implementing agency before they can act | A control before anyone touches the workflow |
| Verifiers and producers communicate through defined threads; there is no direct thread between committee and producer | A team decision, taken on 7 March, to keep every question on the record |
Three calls, each with its cost
Decision 1. Keep every certificate version; never overwrite one.
WhyA certificate is a legal artefact. If an amendment overwrites the original, the evidence of how the decision was reached is destroyed. So an amendment becomes a new record while the original stays intact, across all four certificate types. Concept and Facility certificates, for example, can be amended for an expansion, an ownership transfer or a new unit.
Trade-off acceptedAppend-only costs storage, makes every read path more complex, and means the interface has to explain which version a user is looking at. It buys a trail that survives a challenge to a certification years later.
Decision 2. Run an internal security review before the external audit.
WhyIf the external audit is the moment issues surface, the production date sits at the mercy of a report. The programme reviewed the code internally and fixed things in parallel, so the external audit met a platform that had already been attacked.
Trade-off acceptedIt pulled security effort forward into a window already competing with feature delivery, and some of that effort would have been unnecessary had the audit been lenient. It produced a short fix-and-revalidate round instead of a long remediation cycle.
Decision 3. Keep AI out of Phase 1, deliberately.
WhyAuditors needed to understand and operate the underlying process before they could judge an assistant working on top of it. An AI suggestion that nobody can evaluate is one nobody should trust. The decision was taken with the client on 19 March.
Trade-off acceptedIt delayed the efficiency gain by a full phase and meant launching with manual effort we knew could be reduced. It meant Phase 2 could be accepted on evidence rather than on faith.
Other decisions on the record
| Decision | Choice | What it cost |
|---|---|---|
| Who certifies | The Technical Committee only, not the implementing agency | Less agency control, and a cleaner line of accountability |
| Phase 1 scope | No AI and no blockchain; both moved to Phase 2 | Less to show at launch |
| Account onboarding | Implementing-agency approval for verifier and committee accounts | More administrator work |
| Verifier checklists | Short lists, not exhaustive ones | Less detail on the page, more judgement for the verifier |
| Merging code | Pull requests only, from 3 June, with peer review | Slower merges, and no change reaching production unreviewed |
| During external security testing | A code freeze while findings were fixed | Feature work waited |
| UAT | Two rounds, with the environment reset to a clean state before the second | Time spent on resets |
| Phase 2 procurement | One open-ended request for quotation, no technology prescribed, single cover under GFR 2017 | Bidders gain freedom, and the evaluation has to work harder |
How the system is put together
The platform runs as four deployable services behind a single load balancer: the front end, an authentication service, a user and application service, and an admin and workflow service. They share a versioned internal library. Behind them sit PostgreSQL, Redis for sessions and caching, a message broker for notifications, and object storage for documents and certificates.
Traffic passes a web application firewall with managed rule sets, and secrets and encryption keys sit in a managed vault. There were four environments (development, QA, UAT and production). Every change reached them through the same pipeline: a pull request, peer review, a CI build with a static-analysis quality gate, then a signed-off release.
- Pull requestpeer review
- CI buildquality gate
- Image registryversioned
- Sign-offeight roles
- Release8 to 11 pm window
- Smoke testthen rollback ready
The release window was 8 to 11 pm, after a database backup, with a rollback plan sized at 45 to 60 minutes. Eight roles signed each deployment: development, QA, security, DevOps and four others.
Two rounds of user testing, and one external security audit
UAT ran in two rounds. Round one began on 10 May with test accounts for producers and verifiers. Round two was a workshop at the client venue on 9 June with producers, ACV agencies and the Technical Committee. The environment was reset to a clean state before it, and every P0 and P1 defect was closed before the workshop began. In all, 262 defects were logged through UAT, and by the June review only a handful of low-severity or deferred items remained open.
View the numbers as a table
| Item | Count |
|---|---|
| Closed before external audit | 48 |
| Manually verified, risk signed | 3 |
| Total internal findings | 51 |
Security ran as a delivery stream. The internal review found 51 issues, and 48 were closed before the external audit opened. The external audit by a CERT-In empanelled agency then took one round, and every finding was closed. Its three reports arrived on 19 June and the fixes were back on 22 June, three days later. Clearance followed on 30 June.
Controls the programme added
- Ownership and role checks on every record route
- Short-lived tokens with rotating refresh tokens, and account lockout
- Rate limits on sensitive endpoints, and constant-time checks on one-time passwords
- Secrets and keys held in a vault, with encryption at rest and TLS in transit
- An immutable audit log of actors, actions and outcomes
- A web application firewall in front of everything
The finding types and infrastructure detail stay off this page by design.
Announced by the Minister, on 1 July 2026
The portal went live on 1 July 2026, launched publicly by the Minister for New and Renewable Energy. The week before, I confirmed the date as final, closed the open sprint tasks with the team, and ran the CTO review of the programme. All the integrations the scheme depends on (Aadhaar eSign and DSC signing, notifications and the document locker) are in place now.
Verification of the remaining applications is in progress. After launch I ran an onboarding walkthrough for a second government agency covering the certification journey and the Producer, ACV, TC and Super Admin dashboards.
A formal flow, and a three-day turnaround
After launch, the client asked for changes. Each one went through the same change process, and this is the one I run rather than skipping when a request is urgent.
- Requestfrom the client
- Impact analysismodules, rules, data
- Flow changeformally redrawn
- BRD updatedannexure
- Client approvalbefore any build
- Build and testpull request, review
- Releasesigned off
| Change request 1 | What changed |
|---|---|
| Date-based exceptions | Exceptions to the date-driven rules in the workflow |
| Payment-gateway exemption | An exemption from the payment-gateway step |
| Super Admin credential creation | A change to how credentials are created by the Super Admin |
| Dashboard view | A changed dashboard view |
The workflow itself changed, so the change request went through formal flow change, impact assessment, a BRD update and client approval. It took about three days from the signed request to the change being ready. Claude helped with the impact analysis, the flow design, the exception rules, the code, the tests and the document updates, and I approved each artefact before it went to the client.
Where Claude helped, and what stayed with a person
In use for deliveryPhase 2 AI: approved, in procurement
Claude supported the delivery work below. Phase 1 launched without any AI feature in the live platform.
| Stage | What Claude produced | What stayed a person's call |
|---|---|---|
| Discovery | A searchable copy of the 24-page scheme; clause analyses on refunds, the implementing agency's role and ACV communication | Which clause governs |
| Requirements | Field lists per certificate and stakeholder; the 124-rule validation sheet; the 163-rule API mapping; SRS drafts; records of discussion | What to accept, and the signed baseline |
| Design | Prototypes, three design-validation reports with 61 findings, and the swimlane diagrams | The final screens |
| Build | Code and specification help used daily by the developers | Every merge, by pull request |
| Testing | UAT kits, test cases and bug trackers | Pass or fail, and sign-off |
| Security | Pattern reviews and rate-limit test scripts | Risk acceptance |
| Deployment | The eight-role release checklist and runbook content | Go or no-go |
| Operations | FAQs, user guides and handholding decks | Triage of what users report |
| Reporting | Monthly progress reports, status decks and the CTO review deck | What was mine and what was the team's |
| Procurement | The Phase 2 request for quotation, six versions of it | Scope and approvals |
Two prompts that did real work
"Go through the scheme, proposal, plan to implementation, fields shared and the discussion held with the client, and prepare a list of all information and fields that should be captured in the portal, certificate-wise, under separate stakeholders. We should not capture any information not relevant to the green hydrogen ecosystem."
"Read this PDF and prepare an OCR-compatible document. Do not remove any content. Keep the same order. No information loss. Do not invent any new information. An exact replica."
Where it was wrong
| What went wrong | How it was caught | The lesson |
|---|---|---|
| It cited clauses from the superseded 2024 scheme draft | I supplied the final memorandum and had the citations re-checked | Load the authoritative source first |
| It merged the team's work into my own report | I corrected it in February | Keep a project manager's work separate from the team's |
| Architecture diagrams showed a different front-end framework from the one built; 12 discrepancies | I reviewed the diagrams against the stack | Review every diagram against what exists |
No personal data or credentials in a prompt. Every output reviewed by a person. The developer owns every merged change. Phase 1 contains no AI feature at all. The wider method is on the How I work.
Phase 2: AI, with two rules attached
I wrote the scope for Phase 2. It covers six modules: document intelligence on submissions, emissions anomaly detection, a verification assistant for auditors, application summaries for the committee, compliance pattern intelligence, and process-risk prediction.
AI advises. A named officer approves every consequential action.
Every generated claim cites the document supporting it.
Neither guardrail is negotiable, because an incorrect certification decision carries financial and legal consequences. Acceptance rests on a golden dataset: cases previously answered manually become the reference the AI is measured against. Because the process itself was new, the evaluation method had to be designed as part of the programme. There was no benchmark to borrow.
The request for quotation is approved and procurement is in progress. The plan is six months from award, with two vendor resources working under me. The vendor builds only after procurement completes.
Targets, not results: fewer first-pass rejections (from roughly 30 to 40 percent towards under 5 percent), time saved per application, and measured accuracy against the golden dataset.
Sequencing is a product decision
Holding AI back a phase can be the thing that makes it adoptable. The question is not whether the model is good enough but whether the people accountable for the output can yet tell.
Where a process is genuinely new, the evaluation method is part of the deliverable. Designing the acceptance criteria alongside the thing being accepted is slower, and it is the only way the result means anything.
Change control is worth the three days. The change request that touched the workflow still went through impact analysis, a BRD update and client approval, and that is why the registry's record of what it does stayed true.