-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathindex.html
More file actions
519 lines (486 loc) · 28.8 KB
/
Copy pathindex.html
File metadata and controls
519 lines (486 loc) · 28.8 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Dhwani RIS · DevOps — Practices, Workflows & Compliance</title>
<meta name="description" content="How DevOps keeps every Dhwani RIS application secure, performant, and production-ready — the practices, the workflows that run on every repo, and how each project is proven Dhwani-compliant before it ships." />
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@300;400;500;600;700;800&family=JetBrains+Mono:wght@400;500;600&display=swap" rel="stylesheet" />
<link rel="stylesheet" href="assets/css/styles.css" />
</head>
<body>
<a class="skip" href="#main">Skip to content</a>
<header class="bar">
<div class="bar__inner">
<a class="bar__brand" href="#top">
<span class="bar__mark" aria-hidden="true"></span>
<span>Dhwani RIS · AI-SDLC</span>
</a>
<nav class="bar__nav" aria-label="Primary">
<a href="#process">Lifecycle</a>
<a href="#practices">Practices</a>
<a href="#workflows">Workflows</a>
<a href="#environments">Environments</a>
<a href="#compliance">Compliance</a>
<a href="#devops-charter">Contract</a>
<a href="quick.html" class="bar__cta">Slides →</a>
</nav>
</div>
</header>
<main id="main">
<!-- HERO -->
<section class="hero" id="top">
<div class="container">
<p class="kicker">Dhwani RIS · DevOps</p>
<h1>Every project.<br/>The same checks.<br/><span class="accent">Provably compliant.</span></h1>
<p class="lede">How DevOps keeps every Dhwani application secure, performant, and production-ready — the practices we run, the workflows that fire on every repo, and how each project is proven Dhwani-compliant before it ships.</p>
<p class="hero__meta">Prepared by Dhwani RIS DevOps · v2.2 · 2026-05-27 · Practices · Workflows · Environments · Compliance · Contract</p>
</div>
</section>
<!-- WHERE DEVOPS SITS -->
<section class="band band--alt" id="process">
<div class="container">
<p class="kicker">01 · Where DevOps sits</p>
<h2>DevOps doesn't own a phase. It guards every one.</h2>
<p class="sub">The lifecycle has four steps. The two highlighted below are DevOps-owned end-to-end — but DevOps checks fire across all four, because compliance isn't a stage you reach, it's a state you hold.</p>
<div class="process">
<article class="process-step">
<p class="process-step__n">01</p>
<h3>Understand</h3>
<p>Intent, scope, sign-off. <strong>DevOps touch:</strong> the repo is created from a template that already carries the full check suite, so compliance starts on day zero.</p>
<p class="process-step__time">DevOps · light — scaffolding only</p>
</article>
<article class="process-step">
<p class="process-step__n">02</p>
<h3>Build</h3>
<p>Code written with AI assistance. <strong>DevOps touch:</strong> every pull request runs the quality + security workflow. Defects and vulnerabilities are blocked at write-time, not at the gate.</p>
<p class="process-step__time">DevOps · continuous — PR gate on</p>
</article>
<article class="process-step process-step--accent">
<p class="process-step__n">03</p>
<h3>Ship</h3>
<p>The seven-assessment gate runs. Two DevOps sign-offs. Zero Critical/High. <strong>DevOps owns this step</strong> — nothing reaches production without a signed Release Readiness Report.</p>
<p class="process-step__time">DevOps · owned end-to-end</p>
</article>
<article class="process-step process-step--accent">
<p class="process-step__n">04</p>
<h3>Run</h3>
<p>Continuous repo scanning, health checks, weekly reports. <strong>DevOps owns this step</strong> — every live app is re-scanned and re-reported on a schedule, forever.</p>
<p class="process-step__time">DevOps · owned end-to-end</p>
</article>
</div>
</div>
</section>
<!-- DEVOPS PRACTICES -->
<section class="band" id="practices">
<div class="container">
<p class="kicker kicker--dark">02 · The practices</p>
<h2>What DevOps brings to every project.</h2>
<p class="sub">Six practices, applied uniformly. Nothing here is bespoke per project — that's the point. The same discipline on every repo is what makes "Dhwani-compliant" mean something.</p>
<div class="practice-grid">
<article class="practice">
<div class="practice__icon" aria-hidden="true">01</div>
<h4>Defense-in-depth on every repo</h4>
<p>The day a repo is created it already carries the full check suite — pre-commit hooks, security scans, AI review rules, CI pipeline. No repo starts unprotected.</p>
</article>
<article class="practice">
<div class="practice__icon" aria-hidden="true">02</div>
<h4>Zero-bug, enforced at write-time</h4>
<p>Dhwani's non-negotiable quality standard is checked on every pull request — while code is being written, not after. Cheaper to fix, impossible to forget.</p>
</article>
<article class="practice">
<div class="practice__icon" aria-hidden="true">03</div>
<h4>The seven-assessment gate</h4>
<p>VAPT · SAST · DAST · PENTEST · E2E · performance · load. All seven green, two DevOps sign-offs, zero Critical/High — or the release doesn't ship.</p>
</article>
<article class="practice">
<div class="practice__icon" aria-hidden="true">04</div>
<h4>Continuous post-prod scanning</h4>
<p>Going live isn't the end of scanning. Live repos are re-scanned on a schedule; new CVEs, secret leaks, and licence drift surface in the weekly report.</p>
</article>
<article class="practice">
<div class="practice__icon" aria-hidden="true">05</div>
<h4>KB-backed VAPT (Kotwal)</h4>
<p>Every scan inherits a decade of historical findings from the Kotwal knowledge base. The next project's first scan starts where the last project's last scan finished.</p>
</article>
<article class="practice">
<div class="practice__icon" aria-hidden="true">06</div>
<h4>Compliance by default</h4>
<p>Identical workflows on every project mean every project is checked the same way. Compliance becomes something we can <em>prove</em> from the workflow logs — not something we promise.</p>
</article>
</div>
</div>
</section>
<!-- WORKFLOWS -->
<section class="band band--alt" id="workflows">
<div class="container">
<p class="kicker">03 · What runs on every repo</p>
<h2>Four workflows. Every repo. Same triggers.</h2>
<p class="sub">Each workflow fires on a defined trigger, runs its checks, and ends in a gate or an outcome. Read each row left to right: <strong>when it fires → what it does → what you get</strong>. The bar underneath says what it protects against.</p>
<div class="wf-list">
<article class="wf">
<div class="wf__head">
<span class="wf__trigger">On every pull request</span>
<span class="wf__title">Quality & security check</span>
</div>
<div class="wf__stages">
<div class="wf-stage">
<p class="wf-stage__lbl">Fires when</p>
<p class="wf-stage__val">A developer opens or updates a pull request on any branch.</p>
</div>
<div class="wf-stage">
<p class="wf-stage__lbl">What it does</p>
<p class="wf-stage__val">AI reviews the diff against the coding standard · static security scan · dependency & licence check · secret scan.</p>
</div>
<div class="wf-stage is-outcome">
<p class="wf-stage__lbl">What you get</p>
<p class="wf-stage__val"><strong>A pass or a block.</strong> Critical/High findings stop the merge — no override.</p>
</div>
</div>
<p class="wf__protects"><strong>Defects and known vulnerabilities entering the codebase</strong> — caught at write-time, the cheapest possible moment.</p>
</article>
<article class="wf">
<div class="wf__head">
<span class="wf__trigger">On merge to development</span>
<span class="wf__title">Deploy & regression</span>
</div>
<div class="wf__stages">
<div class="wf-stage">
<p class="wf-stage__lbl">Fires when</p>
<p class="wf-stage__val">An approved PR merges into the working branch.</p>
</div>
<div class="wf-stage">
<p class="wf-stage__lbl">What it does</p>
<p class="wf-stage__val">Auto-deploys to the dev environment · runs the full regression suite · re-checks integration points.</p>
</div>
<div class="wf-stage is-outcome">
<p class="wf-stage__lbl">What you get</p>
<p class="wf-stage__val"><strong>An always-working dev environment</strong> the team and client can watch take shape.</p>
</div>
</div>
<p class="wf__protects"><strong>Integration drift and broken builds</strong> — every merge is proven to deploy and pass regression before anyone relies on it.</p>
</article>
<article class="wf">
<div class="wf__head">
<span class="wf__trigger">Before go-live</span>
<span class="wf__title">The seven-assessment gate</span>
</div>
<div class="wf__stages">
<div class="wf-stage">
<p class="wf-stage__lbl">Fires when</p>
<p class="wf-stage__val">A release candidate is put forward for production, after UAT sign-off.</p>
</div>
<div class="wf-stage">
<p class="wf-stage__lbl">What it does</p>
<p class="wf-stage__val">Runs all seven assessments · aggregates findings by severity · requires two DevOps sign-offs (mid-build + final).</p>
</div>
<div class="wf-stage is-outcome">
<p class="wf-stage__lbl">What you get</p>
<p class="wf-stage__val"><strong>A signed Release Readiness Report</strong> — evidence, not assurances. Zero Critical/High or the gate stays shut.</p>
</div>
</div>
<p class="wf__protects"><strong>Shipping insecure or unproven code to production</strong> — the gate is the last line, and it doesn't negotiate.</p>
</article>
<article class="wf">
<div class="wf__head">
<span class="wf__trigger">Continuously, in production</span>
<span class="wf__title">Re-scan & report</span>
</div>
<div class="wf__stages">
<div class="wf-stage">
<p class="wf-stage__lbl">Fires when</p>
<p class="wf-stage__val">On a schedule — daily scans, weekly reporting — for the life of the application.</p>
</div>
<div class="wf-stage">
<p class="wf-stage__lbl">What it does</p>
<p class="wf-stage__val">Re-scans the repo (secrets · deps · licences) · runs health & performance checks · escalates anomalies.</p>
</div>
<div class="wf-stage is-outcome">
<p class="wf-stage__lbl">What you get</p>
<p class="wf-stage__val"><strong>A weekly health report per app</strong> — uptime, latency, new CVEs, open findings — routed to the owner.</p>
</div>
</div>
<p class="wf__protects"><strong>Drift, new CVEs, and silent degradation after launch</strong> — a compliant release stays compliant.</p>
</article>
</div>
</div>
</section>
<!-- ENVIRONMENTS & PROVISIONING -->
<section class="band" id="environments">
<div class="container">
<p class="kicker kicker--dark">04 · Environments & provisioning</p>
<h2>Four environments. Each one provisioned, not improvised.</h2>
<p class="sub">Every project moves through the same four environments, in order. Each is provisioned by DevOps with a defined trigger, a fixed set of infrastructure, and its own hardening — so a 5-day fit-gap and a 4-week greenfield travel the identical path, just at different depth.</p>
<div class="env-lifecycle">
<article class="env-stage is-repo">
<span class="env-marker" aria-hidden="true">01</span>
<div class="env-body">
<div class="env-body__head">
<h3>Repo creation</h3>
<span class="env-url">github.com/dhwani-{stack}-{client}</span>
</div>
<p class="env-body__lead">One command scaffolds a fully-wired repository — the check suite is present before the first line of code.</p>
<dl class="env-detail">
<div>
<dt>Triggered by</dt>
<dd>Product Builder (or AM on solo projects) runs <code>gh repo create … --template ai-sdlc-stage-a-starter</code></dd>
</div>
<div>
<dt>What's provisioned</dt>
<dd>Folder structure · schemas · CI seed workflows · Pages → CloudFront · the <code>.claude/</code> catalogue</dd>
</div>
<div>
<dt>DevOps hardening</dt>
<dd>Pre-commit hooks, secret scanning, branch protection, and the PR quality/security workflow are present from commit zero</dd>
</div>
<div>
<dt>Outcome</dt>
<dd><strong>Repo ready</strong> — the first AI prompt is executable immediately, on compliant rails</dd>
</div>
</dl>
</div>
</article>
<article class="env-stage is-dev">
<span class="env-marker" aria-hidden="true">02</span>
<div class="env-body">
<div class="env-body__head">
<h3>Dev environment</h3>
<span class="env-url">{project}-dev.dhwaniris.in</span>
</div>
<p class="env-body__lead">Auto-provisioned the moment the repo exists; redeployed on every merge.</p>
<dl class="env-detail">
<div>
<dt>Triggered by</dt>
<dd>Automatic on repo creation; redeploys on every merge to the <code>development</code> branch</dd>
</div>
<div>
<dt>What's provisioned</dt>
<dd>Dev compute via Terraform · auto-deploy pipeline · seeded monitoring · continuous regression runner</dd>
</div>
<div>
<dt>DevOps hardening</dt>
<dd>Isolated network · <strong>no production data</strong> · synthetic fixtures only</dd>
</div>
<div>
<dt>Outcome</dt>
<dd><strong>A dev URL that updates on every merge</strong> — the team and client watch the product take shape; regression runs continuously</dd>
</div>
</dl>
</div>
</article>
<article class="env-stage is-uat">
<span class="env-marker" aria-hidden="true">03</span>
<div class="env-body">
<div class="env-body__head">
<h3>UAT environment</h3>
<span class="env-url">{project}-uat.dhwaniris.in</span>
</div>
<p class="env-body__lead">Provisioned when dev passes regression and the client is ready to validate. <strong>Self-service portal — coming soon:</strong> teams will request a staging/UAT environment from a portal and <strong>DevOps approves</strong> it; until then, ask DevOps directly. Production stays DevOps-only.</p>
<dl class="env-detail">
<div>
<dt>Triggered by</dt>
<dd>AM, after dev passes regression — often optional on small projects, where staging serves as the preview</dd>
</div>
<div>
<dt>What's provisioned</dt>
<dd>Isolated UAT infra · named-approver access · PII-free seed data · UAT-specific monitoring</dd>
</div>
<div>
<dt>DevOps hardening</dt>
<dd>Access restricted to named approvers · PII masked · data export disabled for non-privileged roles</dd>
</div>
<div>
<dt>Outcome</dt>
<dd><strong>Client validates against the original intent</strong> — UAT sign-off captured before the gate runs</dd>
</div>
</dl>
</div>
</article>
<article class="env-stage is-prod">
<span class="env-marker" aria-hidden="true">04</span>
<div class="env-body">
<div class="env-body__head">
<h3>Production environment</h3>
<span class="env-url">{project}.dhwaniris.in</span>
</div>
<p class="env-body__lead">Provisioned only after the seven-assessment gate passes and DevOps + AM sign Go-Live.</p>
<dl class="env-detail">
<div>
<dt>Triggered by</dt>
<dd>Pre-go-live gate green · two DevOps sign-offs · AM Go-Live approval</dd>
</div>
<div>
<dt>What's provisioned</dt>
<dd>Prod compute (blue-green) · DNS · valid SSL · backups + restore test · auto-scale · full metrics/logs/traces stack</dd>
</div>
<div>
<dt>DevOps hardening</dt>
<dd>HTTPS enforced · firewall rules reviewed · admin IP allowlist · 30-min heightened post-deploy monitoring · rollback rehearsed</dd>
</div>
<div class="env-detail__wide">
<dt>Outcome</dt>
<dd><strong>Live, monitored, and on the continuous post-prod schedule</strong> — re-scanned and re-reported for the life of the application (see §03 · the continuous workflow)</dd>
</div>
</dl>
</div>
</article>
</div>
</div>
</section>
<!-- COMPLIANCE -->
<section class="band band--alt" id="compliance">
<div class="container">
<p class="kicker kicker--dark">05 · Per-project assessment & compliance</p>
<h2>"Dhwani-compliant" is a checklist, not a claim.</h2>
<p class="sub">Because every repo runs the identical workflow bundle, every project is held to the same bar — and the proof lives in the workflow logs. Here's what compliant concretely means, and the lever that enforces it.</p>
<div class="compliance-split">
<div class="compliance-checklist">
<h4>A project is Dhwani-compliant when…</h4>
<ul>
<li>The repo was scaffolded from the <strong>standard template</strong> — full check suite present from day zero</li>
<li>Every merged PR <strong>passed the quality & security workflow</strong> — no bypassed blocks</li>
<li>All <strong>seven assessments are green</strong> on the shipped release</li>
<li><strong>Zero Critical/High</strong> findings outstanding; every Medium has a written ETA</li>
<li><strong>Two DevOps sign-offs</strong> recorded — mid-build and final pre-prod</li>
<li>The app is on the <strong>continuous post-prod scan + weekly report</strong> schedule</li>
</ul>
</div>
<aside class="compliance-note">
<p class="callout__tag">The enforcement lever</p>
<h4>Eligibility is the entry ticket.</h4>
<p>The gate services are available <strong>only to projects that ran through the AI-SDLC framework</strong> — Charter, Tech Spec, and a template-scaffolded repo. A project that skipped the framework can't pass eligibility, so the gate never opens for it.</p>
<p><em>Skip the framework → no Dhwani prod deploy.</em> That's what makes the checklist above unavoidable rather than aspirational.</p>
</aside>
</div>
</div>
</section>
<!-- DEVOPS CHARTER -->
<section class="band" id="devops-charter">
<div class="container">
<p class="kicker">06 · The DevOps contract</p>
<h2>DevOps isn't a phase. It's a contract across all of them.</h2>
<p class="sub">The practices, workflows, and compliance checklist above all rest on one contract — three streams that bind the lifecycle together, two sign-offs that gate production, and one severity rule that has no exceptions.</p>
<h3 class="sub-h3">Three streams, every phase</h3>
<div class="charter-streams">
<article class="stream-card is-build">
<p class="stream-card__badge">Stream 01 · Build-time</p>
<h3>AI-leveraged code quality</h3>
<p>Dhwani's <strong>zero-bug non-negotiable</strong> standard is enforced <em>while code is being written</em>, not at the gate. AI agents review every PR against the standard, catch defects at write-time, and refuse merges that don't clear the bar.</p>
<p class="stream-card__when">Active · first AI prompt → final merge</p>
</article>
<article class="stream-card is-gate">
<p class="stream-card__badge">Stream 02 · Pre-prod</p>
<h3>The seven-assessment gate</h3>
<p>Seven assessments, all mandatory. <strong>Two DevOps sign-offs</strong> — one mid-build validation, one final pre-prod validation. Without both, the production deploy doesn't happen.</p>
<p class="stream-card__when">Between UAT sign-off & Go-Live</p>
</article>
<article class="stream-card is-run">
<p class="stream-card__badge">Stream 03 · Post-prod</p>
<h3>The continuous gate</h3>
<p>Continuous repo scanning (SCA · OSS licence · secrets · dependency CVEs) plus a <strong>weekly per-app health report</strong> — same template, every app, generated and routed to the owner automatically.</p>
<p class="stream-card__when">From Go-Live · forever</p>
</article>
</div>
<h3 class="sub-h3">The seven assessments <span style="color:var(--muted);font-weight:400;font-size:0.7em;">— the floor, not the ceiling</span></h3>
<div class="assessment-matrix">
<article class="assessment">
<span class="assessment__num" aria-hidden="true"></span>
<div>
<h4><code>VAPT</code> — Vulnerability Assessment & Pentesting</h4>
<p>Driven by the <strong>Kotwal knowledge base</strong> — Dhwani's structured DB of historical findings, MCP-wrapped so the assistant inherits a decade of pattern knowledge. Every new scan is informed by every finding before it.</p>
</div>
</article>
<article class="assessment">
<span class="assessment__num" aria-hidden="true"></span>
<div>
<h4><code>SAST</code> — Static code scanning</h4>
<p>Semgrep / Snyk rulesets in CI on every PR. Critical + High findings hard-block the merge — no override, no exception path.</p>
</div>
</article>
<article class="assessment">
<span class="assessment__num" aria-hidden="true"></span>
<div>
<h4><code>DAST</code> — Running-app scanning</h4>
<p>Dynamic scan against the staging deployment. Catches misconfigurations and runtime issues static analysis can't see.</p>
</div>
</article>
<article class="assessment">
<span class="assessment__num" aria-hidden="true"></span>
<div>
<h4><code>PENTEST</code> — Manual red-team round</h4>
<p>Security team runs targeted attacks against the staged build. Findings logged into Kotwal so the next project's automated scan inherits them.</p>
</div>
</article>
<article class="assessment">
<span class="assessment__num" aria-hidden="true"></span>
<div>
<h4><code>E2E</code> — End-to-end test finalisation</h4>
<p>The QA sub-persona's E2E suite runs against staging. All critical journeys green. No skipped or flaky tests carried into prod.</p>
</div>
</article>
<article class="assessment">
<span class="assessment__num" aria-hidden="true"></span>
<div>
<h4><code>PERF</code> — Performance baseline</h4>
<p>p50 / p95 / p99 latency captured against the Sol Doc's SLO targets. Regressions vs. the previous release flagged.</p>
</div>
</article>
<article class="assessment">
<span class="assessment__num" aria-hidden="true"></span>
<div>
<h4><code>LOAD</code> — Load test</h4>
<p>Sustained-load scenarios at the SLO's target concurrency. Auto-scale behaviour verified. Failure modes documented in the readiness report.</p>
</div>
</article>
<article class="assessment is-extra">
<span class="assessment__num" aria-hidden="true"></span>
<div>
<h4>Extensible per project type</h4>
<p>Accessibility audits for client-facing portals · OWASP API checks for mobile back-ends · compliance scans for regulated work. The gate grows with the risk surface.</p>
</div>
</article>
</div>
<h3 class="sub-h3">Severity rules · no negotiation</h3>
<div class="severity-tiers">
<article class="tier is-crit">
<p class="tier__label">Critical + High</p>
<p class="tier__verdict">Zero before go-live. Hard fail.</p>
<p><strong>No exception path. No override.</strong> Every Critical and High finding from every assessment must be remediated and re-scanned green before the production deploy unlocks. The assistant blocks the Go-Live command while any remain.</p>
</article>
<article class="tier is-med">
<p class="tier__label">Medium</p>
<p class="tier__verdict">Exception — with a written ETA.</p>
<p>Ships to prod <em>only</em> with a written remediation ETA, owned by the team's priority lead, logged in the tracker. No ETA = no ship. Open Mediums past their ETA surface in the weekly health report until closed.</p>
</article>
<article class="tier is-low">
<p class="tier__label">Low + Informational</p>
<p class="tier__verdict">Logged, batched, quarterly.</p>
<p>Tracked in the repo's security backlog, reviewed at the quarterly portfolio sync. Not a blocker alone — but a repeat-offender pattern across releases is itself a finding.</p>
</article>
</div>
</div>
</section>
<!-- CLOSE -->
<section class="band band--dark" id="close">
<div class="container container--narrow">
<p class="kicker kicker--light">The bottom line</p>
<h2 class="light">Same checks, every repo, every time.</h2>
<ol class="qs">
<li><strong>Uniform, not bespoke.</strong> Every project runs the identical workflow bundle — so compliance is comparable across the whole portfolio.</li>
<li><strong>Proven, not promised.</strong> Every gate decision is backed by workflow logs and a signed report. "Dhwani-compliant" is auditable.</li>
<li><strong>Continuous, not one-shot.</strong> Compliance is held after launch, not just claimed at it — repos keep getting scanned and reported on for the life of the app.</li>
</ol>
<p class="lock light">If it ran through the framework, it's provably compliant. If it didn't, it doesn't ship.</p>
</div>
</section>
<footer class="foot">
<div class="container">
<p><strong>Dhwani RIS</strong> · Empowering Social Impact Through Technology</p>
<p class="foot__meta">Dhwani RIS DevOps · Practices · Workflows · Environments · Compliance · v2.2 · 2026-05-27</p>
</div>
</footer>
</main>
</body>
</html>