betterwithage commited on
Commit
e2d1708
·
verified ·
1 Parent(s): fe61b0a

chore(sync): mirror static/3d kit + Dockerfile-COPY'd web/*.html to Space (hf-sync)

Browse files

Automated 3D/web-page asset sync from szl-holdings/a11oy main via hf-sync.
web/*.html set parsed live from the Dockerfile COPY directives.
Added/updated: 48 file(s)
Deleted (gone from GitHub main): (none)

Keeps static/3d/** and every Dockerfile-COPY'd web/<page>.html identical
to GitHub main so an HF factory rebuild never drops a GitHub edit (closes
the chronic hf-module-drift red for the 3D kit + baked web pages).

web/defense-readiness.html ADDED
@@ -0,0 +1,255 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ <!DOCTYPE html>
2
+ <!--
3
+ a11oy · DEFENSE READINESS — public showcase summary (showcase lane).
4
+ © 2026 Lutar, Stephen P. — SZL Holdings. SPDX-License-Identifier: Apache-2.0
5
+ 0 runtime CDN: system fonts only, no external scripts. This is a PUBLIC fit +
6
+ honest-maturity summary. It deliberately exposes NO private application content
7
+ (DARPA / JIATF / NATO / AFWERX submissions are private). It shows the FIT, the
8
+ honest maturity (MODELED bounds + live signed software APIs, NOT flown hardware),
9
+ and links each pathway to the relevant LIVE a11oy surface. Live surfaces are
10
+ probed via fetch with an HONEST NO-LIVE-DATA fallback (doctrine v11).
11
+ -->
12
+ <html lang="en">
13
+ <head>
14
+ <meta charset="utf-8"/>
15
+ <meta name="viewport" content="width=device-width, initial-scale=1"/>
16
+ <title>a11oy · Defense Readiness</title>
17
+ <style>
18
+ :root{
19
+ --bg:#0a0e14; --panel:#121823; --panel2:#0f141d; --line:#1f2a3a;
20
+ --ink:#e6edf3; --mut:#8b98a9; --acc:#5ad1c9; --acc2:#7aa2f7;
21
+ --ok:#3fb950; --warn:#d29922; --err:#f85149; --road:#a371f7;
22
+ }
23
+ *{box-sizing:border-box}
24
+ body{margin:0;background:var(--bg);color:var(--ink);
25
+ font:14px/1.6 ui-monospace,SFMono-Regular,Menlo,Consolas,monospace}
26
+ header{padding:18px 22px;border-bottom:1px solid var(--line);
27
+ background:linear-gradient(180deg,#0d1320,#0a0e14)}
28
+ h1{margin:0;font-size:19px;letter-spacing:.3px}
29
+ .sub{color:var(--mut);font-size:12px;margin-top:4px;max-width:980px}
30
+ .nav{margin-top:10px;display:flex;gap:14px;flex-wrap:wrap;font-size:12px}
31
+ .nav a{color:var(--acc2);text-decoration:none}
32
+ .nav a:hover{text-decoration:underline}
33
+ .wrap{max-width:1080px;margin:0 auto;padding:22px}
34
+ section{margin:0 0 26px}
35
+ .eyebrow{color:var(--acc);font-size:11px;letter-spacing:.16em;text-transform:uppercase;margin-bottom:6px}
36
+ h2{font-size:16px;letter-spacing:.3px;margin:0 0 10px}
37
+ h3{font-size:14px;letter-spacing:.2px;margin:0 0 6px;color:var(--acc)}
38
+ p{margin:0 0 12px}
39
+ .lede{font-size:15px;color:#cdd8e6}
40
+ .card{background:var(--panel);border:1px solid var(--line);border-radius:10px;padding:16px 18px;margin:0 0 14px}
41
+ .quote{border-left:3px solid var(--acc);background:var(--panel2);padding:12px 16px;border-radius:0 8px 8px 0;color:#cdd8e6;margin:0 0 14px}
42
+ .pill{display:inline-block;padding:2px 9px;border-radius:999px;font-size:11px;border:1px solid var(--line);white-space:nowrap}
43
+ .pill.ok,.pill.live{color:var(--ok);border-color:#163a1f;background:#0e2113}
44
+ .pill.err{color:var(--err);border-color:#4a1c1c;background:#240f0f}
45
+ .pill.warn{color:var(--warn);border-color:#3a3015;background:#1f1a0a}
46
+ .pill.road{color:var(--road);border-color:#2e2147;background:#160f24}
47
+ .pill.acc{color:var(--acc);border-color:#13403c;background:#0a201e}
48
+ .pill.modeled{color:var(--warn);border-color:#3a3015;background:#1f1a0a}
49
+ .grid{display:grid;gap:14px;grid-template-columns:repeat(auto-fit,minmax(330px,1fr))}
50
+ .path{background:var(--panel);border:1px solid var(--line);border-radius:10px;padding:16px 18px;display:flex;flex-direction:column}
51
+ .path .head{display:flex;align-items:flex-start;justify-content:space-between;gap:10px;margin-bottom:6px}
52
+ .path h3{margin:2px 0 2px}
53
+ .path .org{color:var(--mut);font-size:11px;letter-spacing:.05em}
54
+ .path .body{color:#c4d0de;flex:1;margin-top:8px}
55
+ .path .fit{margin-top:10px;font-size:12.5px}
56
+ .path .fit b{color:var(--ink)}
57
+ .path .surface{margin-top:10px;padding-top:10px;border-top:1px dotted #1a2435;font-size:12px}
58
+ .live-line{display:flex;align-items:center;gap:8px;margin-top:6px;font-size:12px}
59
+ .live-line .v{color:var(--ink);word-break:break-word}
60
+ .live-line .v a{color:var(--acc2)}
61
+ table{width:100%;border-collapse:collapse;font-size:12.5px;margin:6px 0}
62
+ th,td{text-align:left;padding:8px 10px;border-bottom:1px solid #1a2435;vertical-align:top}
63
+ th{color:var(--mut);font-weight:600}
64
+ a{color:var(--acc2)}
65
+ code{color:var(--acc2);font-size:12px}
66
+ .cite{color:var(--mut);font-size:11.5px;margin-top:8px;line-height:1.6}
67
+ .cite a{color:var(--acc2)}
68
+ footer{color:var(--mut);font-size:11px;padding:18px 22px;border-top:1px solid var(--line);line-height:1.7}
69
+ @media(max-width:640px){.wrap{padding:16px}}
70
+ </style>
71
+ </head>
72
+ <body>
73
+ <header>
74
+ <h1>a11oy · Defense Readiness</h1>
75
+ <div class="sub">SZL Holdings is aligned to multiple federal and allied innovation pathways. This page
76
+ shows the <b>fit</b> and the <b>honest maturity</b> — MODELED physics bounds + live signed software APIs,
77
+ <b>not flown hardware</b> — and links each pathway to the live a11oy surface that backs it. It exposes
78
+ no private submission content. Every maturity claim labelled <span class="pill modeled">MODELED</span>
79
+ <span class="pill live">LIVE</span> <span class="pill road">ROADMAP</span>.</div>
80
+ <nav class="nav">
81
+ <a href="/console/">← Console</a>
82
+ <a href="/signature-is-not-proof">Signature ≠ Proof case study</a>
83
+ <a href="/compliance">Compliance crosswalk</a>
84
+ <a href="/governance">Governance</a>
85
+ </nav>
86
+ </header>
87
+
88
+ <div class="wrap">
89
+
90
+ <section>
91
+ <div class="eyebrow">Posture</div>
92
+ <p class="lede">SZL builds on an explicit doctrine of <b>honest maturity</b>: we publish what is
93
+ MEASURED, label what is MODELED, and claim only what has a checkable artifact. The differentiator is
94
+ not a flown prototype — it is <b>verifiable provenance + assurance, sovereign on-metal compute</b>,
95
+ and a refusal to overclaim. Below: where a11oy and its surfaces fit federal pathways, and exactly how
96
+ mature each claim is.</p>
97
+ <div class="quote"><b>What we are.</b> A governed-AI command platform (deny-by-default 8-gate policy
98
+ engine, DSSE-signed verdicts/receipts, supply-chain assurance mesh, hash-chained governance ledger,
99
+ hybrid post-quantum signing) plus MODELED hard-physics PNT bounds and a sense-and-evidence counter-UAS
100
+ surface. <b>What we are not.</b> We do not claim flown hardware, a fielded prototype, or “proven trust.”
101
+ Λ is Conjecture 1 — advisory, &lt; 1.0, never a theorem.</div>
102
+ </section>
103
+
104
+ <section>
105
+ <div class="eyebrow">Federal &amp; allied pathways · fit + honest maturity</div>
106
+ <h2>Where we align</h2>
107
+ <div class="grid">
108
+
109
+ <!-- DARPA PINPOINT -->
110
+ <div class="path">
111
+ <div class="head">
112
+ <div><h3>DARPA PINPOINT</h3><div class="org">DSO · DARPA-SN-26-88 · PNT</div></div>
113
+ <span class="pill modeled">MODELED</span>
114
+ </div>
115
+ <div class="body">Precision Inertial Navigation &amp; Positioning — highly accurate nav/positioning
116
+ where GPS is unavailable or unreliable. Our PNT engine is a clean-room, closed-form quantum-sensing
117
+ and GNSS-resilience stack.</div>
118
+ <div class="fit"><b>Fit:</b> closed-form cold-atom interferometer sensitivity certificate
119
+ (at/above the Standard Quantum Limit), RAIM/AGC/SQM deny-by-default spoof fusion, GPS-denied
120
+ coasting figure-of-merit, and fundamental compute/energy bounds — all served as live signed
121
+ software APIs.</div>
122
+ <div class="surface">
123
+ <b>Honest maturity:</b> MODELED closed-form physics (stdlib, deterministic), <b>not flown
124
+ hardware</b>. The sensor certificate is labelled MODELED · STRUCTURAL-ONLY.
125
+ <div class="live-line" id="pnt-live"><span class="pill warn">checking…</span><span class="v">PNT mesh</span></div>
126
+ </div>
127
+ <div class="cite">Special Notice (advance notice of a future program); responses due Jul 13, 2026.
128
+ <a href="https://www.highergov.com/contract-opportunity/future-program-announcement-precision-inertial-na-darpa-sn-26-88-s-4a1f7/">DARPA-SN-26-88</a></div>
129
+ </div>
130
+
131
+ <!-- JIATF 401 -->
132
+ <div class="path">
133
+ <div class="head">
134
+ <div><h3>JIATF 401</h3><div class="org">NDAA FY26 §912 · counter-sUAS T&amp;E</div></div>
135
+ <span class="pill live">LIVE</span>
136
+ </div>
137
+ <div class="body">Joint Interagency Task Force 401 approves counter-sUAS systems for Department use
138
+ and published standardized C-UAS test &amp; evaluation criteria (Apr 28, 2026). Our counter-UAS
139
+ surface <b>senses and evidences</b> — it does not jam, spoof, take over, or kinetically defeat.</div>
140
+ <div class="fit"><b>Fit:</b> forensic-evidence and rules-of-engagement alignment — a live Λ decision
141
+ plus an ECDSA-P256 DSSE-signed forensic verdict, verified drone fingerprints, and a Remote-ID
142
+ validator. The value is <b>admissible, replayable evidence</b>, not effects.</div>
143
+ <div class="surface">
144
+ <b>Honest maturity:</b> live sense-and-evidence surface with signed verdicts; each T&amp;E
145
+ criterion is crosswalked honestly as Demonstrated / Modeled / Not-yet / Out-of-scope — never
146
+ assumed.
147
+ <div class="live-line" id="elite-live"><span class="pill warn">checking…</span><span class="v">Counter-UAS surface</span></div>
148
+ </div>
149
+ <div class="cite">Criteria published Apr 28, 2026.
150
+ <a href="https://www.war.gov/News/Releases/External/Article/4473626/jiatf-401-publishes-testing-and-evaluation-criteria-to-inform-future-demonstrat/">war.gov</a></div>
151
+ </div>
152
+
153
+ <!-- NATO DIANA -->
154
+ <div class="path">
155
+ <div class="head">
156
+ <div><h3>NATO DIANA</h3><div class="org">Defence Innovation Accelerator · dual-use</div></div>
157
+ <span class="pill acc">FIT</span>
158
+ </div>
159
+ <div class="body">DIANA accelerates dual-use deep tech across the alliance. a11oy’s governed-AI
160
+ assurance and sovereign-compute provenance are dual-use by construction — civilian supply-chain
161
+ integrity and defense AI governance share the same substrate.</div>
162
+ <div class="fit"><b>Fit:</b> verifiable provenance + assurance mesh (3-axis attestation, C2PA
163
+ content credentials, hash-chained ledger), aligned to EU AI Act Article 50 (effective Aug 2, 2026)
164
+ and NIST AI RMF / ISO 42001 via a live compliance crosswalk.</div>
165
+ <div class="surface">
166
+ <b>Honest maturity:</b> live signed software APIs + compliance crosswalk; trans-Atlantic
167
+ deployment is a roadmap engagement, labelled as such.
168
+ <div class="live-line" id="comp-live"><span class="pill warn">checking…</span><span class="v">Compliance crosswalk</span></div>
169
+ </div>
170
+ </div>
171
+
172
+ <!-- AFWERX SBIR -->
173
+ <div class="path">
174
+ <div class="head">
175
+ <div><h3>AFWERX SBIR</h3><div class="org">Dept. of the Air Force · small-business R&amp;D</div></div>
176
+ <span class="pill acc">FIT</span>
177
+ </div>
178
+ <div class="body">AFWERX SBIR funds small-business innovation with a defense transition path. As a
179
+ US-based small business (NAICS 541715, &lt;500 employees) with live, signed, sovereign-compute
180
+ software, SZL fits the R&amp;D-to-transition model.</div>
181
+ <div class="fit"><b>Fit:</b> governed counter-UAS sense-and-evidence + AI-governance assurance — a
182
+ software-first capability with a clear dual-use transition and a verifiable-provenance moat.</div>
183
+ <div class="surface">
184
+ <b>Honest maturity:</b> live software APIs + MODELED physics bounds; hardware integration and a
185
+ fielded prototype are roadmap, labelled honestly. SAM/UEI/CAGE founder-supplied.
186
+ <div class="live-line" id="elite2-live"><span class="pill warn">checking…</span><span class="v">Elite console</span></div>
187
+ </div>
188
+ </div>
189
+
190
+ </div>
191
+ </section>
192
+
193
+ <section>
194
+ <div class="eyebrow">The honesty is the feature</div>
195
+ <h2>Doctrine v11 as a defense-acquisition advantage</h2>
196
+ <p>In a market where “signed: yes” has already certified a supply-chain worm
197
+ (<a href="/signature-is-not-proof">see the Mini Shai-Hulud case study</a>), an evaluator’s hardest
198
+ problem is telling a real capability from a confident slide. Our doctrine is built to make that easy:</p>
199
+ <div class="card">
200
+ <table>
201
+ <tr><th>Principle</th><th>What it means for an evaluator</th></tr>
202
+ <tr><td><b>Prove-or-downgrade</b></td><td>Every DONE claim has a checkable artifact: a pushed commit SHA, an HTTP 200 from a named endpoint, or a verifying signature. No artifact → it is labelled RECOMMENDED or ROADMAP, not claimed.</td></tr>
203
+ <tr><td><b>Label every value</b></td><td>MEASURED / MODELED / SAMPLE / STRUCTURAL-ONLY. A modeled physics bound is never dressed up as flown telemetry.</td></tr>
204
+ <tr><td><b>Never overclaim</b></td><td>No fabricated numbers, TRL, signatures, partnerships, or flown-hardware claims. Λ is Conjecture 1 (advisory), never “proven trust.”</td></tr>
205
+ <tr><td><b>Behaviour over attestation</b></td><td>We trust the behaviour we can observe and the receipts we can replay — not the attestation we were handed.</td></tr>
206
+ </table>
207
+ </div>
208
+ <p>The result is a capability statement an evaluator can verify in a browser, line by line, against
209
+ live endpoints — the opposite of a black box.</p>
210
+ </section>
211
+
212
+ <section>
213
+ <div class="card">
214
+ <h3>Engagement</h3>
215
+ <p>Founder is handling SAM.gov registration (via an APEX Accelerator) and federal submission
216
+ mechanics; the engineering artifacts behind each pathway are live and verifiable now at
217
+ <a href="https://a11oy.net">a11oy.net</a>. Private submission content is not published here by design.</p>
218
+ </div>
219
+ </section>
220
+
221
+ </div>
222
+
223
+ <footer>
224
+ a11oy showcase · doctrine v11 · honest maturity: MODELED bounds + live signed software APIs, NOT flown
225
+ hardware · prove-or-downgrade · Λ = Conjecture 1 (advisory, &lt; 1.0) · 0 runtime CDN.<br>
226
+ Live surfaces probed from <span style="color:var(--acc2)">/api/a11oy/v1/{pnt, compliance}</span> · <span style="color:var(--acc2)">/elite</span> · <span style="color:var(--acc2)">/elite-console</span> — honest NO-LIVE-DATA fallback, never fabricated.
227
+ SZL Holdings · sovereign-compute, AI-governance &amp; defense-tech, NYC · UEI [PLACEHOLDER: UEI] · CAGE [PLACEHOLDER: CAGE] · NAICS 541715.
228
+ </footer>
229
+
230
+ <script>
231
+ // 0-CDN inline. Probe live a11oy surfaces; render an HONEST NO-LIVE-DATA chip on
232
+ // any failure — never a fabricated value.
233
+ (function(){
234
+ function setLive(id, ok, label, href){
235
+ var el = document.getElementById(id);
236
+ if(!el) return;
237
+ var pill = ok ? '<span class="pill live">LIVE ✓</span>'
238
+ : '<span class="pill warn">NO-LIVE-DATA</span>';
239
+ var v = href ? '<span class="v"><a href="'+href+'">'+label+'</a></span>'
240
+ : '<span class="v">'+label+'</span>';
241
+ el.innerHTML = pill + v;
242
+ }
243
+ function probe(url, id, label, href){
244
+ fetch(url, {headers:{'accept':'application/json'}})
245
+ .then(function(r){ setLive(id, r.ok, label, href); })
246
+ .catch(function(){ setLive(id, false, label, href); });
247
+ }
248
+ probe('/api/a11oy/v1/pnt/limits', 'pnt-live', 'PNT mesh · /api/a11oy/v1/pnt/limits', '/api/a11oy/v1/pnt/limits');
249
+ probe('/elite', 'elite-live', 'Counter-UAS · /elite', '/elite');
250
+ probe('/api/a11oy/v1/compliance', 'comp-live', 'Compliance crosswalk', '/compliance');
251
+ probe('/elite-console', 'elite2-live', 'Elite console · /elite-console', '/elite-console');
252
+ })();
253
+ </script>
254
+ </body>
255
+ </html>
web/signature-is-not-proof.html ADDED
@@ -0,0 +1,350 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ <!DOCTYPE html>
2
+ <!--
3
+ a11oy · A SIGNATURE IS NOT PROOF OF SAFETY — public case study (showcase lane).
4
+ © 2026 Lutar, Stephen P. — SZL Holdings. SPDX-License-Identifier: Apache-2.0
5
+ 0 runtime CDN: system fonts only, no external scripts. Where a claim can be
6
+ proven LIVE it is wired to a real a11oy production endpoint
7
+ (/api/a11oy/v1/{compliance,pinn/certificate,...}) via fetch with an HONEST
8
+ NO-LIVE-DATA fallback — never a fabricated value. Maturity is labelled
9
+ LIVE-today vs ROADMAP throughout (doctrine v11). Content mirrors the
10
+ SZL thought-leadership case study of the same name.
11
+ -->
12
+ <html lang="en">
13
+ <head>
14
+ <meta charset="utf-8"/>
15
+ <meta name="viewport" content="width=device-width, initial-scale=1"/>
16
+ <title>a11oy · A Signature Is Not Proof of Safety</title>
17
+ <style>
18
+ :root{
19
+ --bg:#0a0e14; --panel:#121823; --panel2:#0f141d; --line:#1f2a3a;
20
+ --ink:#e6edf3; --mut:#8b98a9; --acc:#5ad1c9; --acc2:#7aa2f7;
21
+ --ok:#3fb950; --warn:#d29922; --err:#f85149; --road:#a371f7;
22
+ }
23
+ *{box-sizing:border-box}
24
+ body{margin:0;background:var(--bg);color:var(--ink);
25
+ font:14px/1.6 ui-monospace,SFMono-Regular,Menlo,Consolas,monospace}
26
+ header{padding:18px 22px;border-bottom:1px solid var(--line);
27
+ background:linear-gradient(180deg,#0d1320,#0a0e14)}
28
+ h1{margin:0;font-size:19px;letter-spacing:.3px}
29
+ .sub{color:var(--mut);font-size:12px;margin-top:4px;max-width:980px}
30
+ .nav{margin-top:10px;display:flex;gap:14px;flex-wrap:wrap;font-size:12px}
31
+ .nav a{color:var(--acc2);text-decoration:none}
32
+ .nav a:hover{text-decoration:underline}
33
+ .wrap{max-width:1080px;margin:0 auto;padding:22px}
34
+ section{margin:0 0 26px}
35
+ .eyebrow{color:var(--acc);font-size:11px;letter-spacing:.16em;text-transform:uppercase;margin-bottom:6px}
36
+ h2{font-size:16px;letter-spacing:.3px;margin:0 0 10px;color:var(--ink)}
37
+ h3{font-size:14px;letter-spacing:.2px;margin:0 0 6px;color:var(--acc)}
38
+ p{margin:0 0 12px}
39
+ .hook{font-size:26px;line-height:1.35;font-weight:700;letter-spacing:.3px;margin:6px 0 14px}
40
+ .hook .em{color:var(--acc)}
41
+ .lede{font-size:15px;color:#cdd8e6}
42
+ .card{background:var(--panel);border:1px solid var(--line);border-radius:10px;padding:16px 18px;margin:0 0 14px}
43
+ .quote{border-left:3px solid var(--acc);background:var(--panel2);padding:12px 16px;
44
+ border-radius:0 8px 8px 0;color:#cdd8e6;margin:0 0 14px;font-style:normal}
45
+ .quote.big{font-size:16px;color:var(--ink)}
46
+ .pill{display:inline-block;padding:2px 9px;border-radius:999px;font-size:11px;
47
+ border:1px solid var(--line);white-space:nowrap}
48
+ .pill.ok{color:var(--ok);border-color:#163a1f;background:#0e2113}
49
+ .pill.err{color:var(--err);border-color:#4a1c1c;background:#240f0f}
50
+ .pill.warn{color:var(--warn);border-color:#3a3015;background:#1f1a0a}
51
+ .pill.road{color:var(--road);border-color:#2e2147;background:#160f24}
52
+ .pill.acc{color:var(--acc);border-color:#13403c;background:#0a201e}
53
+ .pill.live{color:var(--ok);border-color:#163a1f;background:#0e2113}
54
+ table{width:100%;border-collapse:collapse;font-size:12.5px;margin:6px 0}
55
+ th,td{text-align:left;padding:8px 10px;border-bottom:1px solid #1a2435;vertical-align:top}
56
+ th{color:var(--mut);font-weight:600;letter-spacing:.04em}
57
+ td.no{color:var(--err)} td.yes{color:var(--ok)}
58
+ .grid{display:grid;gap:14px;grid-template-columns:repeat(auto-fit,minmax(300px,1fr))}
59
+ .mech{background:var(--panel);border:1px solid var(--line);border-radius:10px;padding:15px 17px;display:flex;flex-direction:column}
60
+ .mech .head{display:flex;align-items:center;justify-content:space-between;gap:10px;margin-bottom:8px}
61
+ .mech .num{color:var(--mut);font-size:11px}
62
+ .mech h3{margin:2px 0 8px}
63
+ .mech .body{color:#c4d0de;flex:1}
64
+ .mech .status{margin-top:10px;padding-top:10px;border-top:1px dotted #1a2435;font-size:12px;color:var(--mut)}
65
+ .mech .status b{color:var(--ink);font-weight:600}
66
+ .live-line{display:flex;align-items:center;gap:8px;margin-top:8px;font-size:12px}
67
+ .live-line .v{color:var(--ink);word-break:break-word}
68
+ .cite{color:var(--mut);font-size:11.5px;margin-top:10px;line-height:1.6}
69
+ .cite a{color:var(--acc2)}
70
+ a{color:var(--acc2)}
71
+ code{color:var(--acc2);font-size:12px}
72
+ .loading{color:var(--mut)}
73
+ .nolive{color:var(--warn)}
74
+ footer{color:var(--mut);font-size:11px;padding:18px 22px;border-top:1px solid var(--line);line-height:1.7}
75
+ .reflist{font-size:11.5px;color:var(--mut);line-height:1.7}
76
+ .reflist li{margin-bottom:5px}
77
+ .reflist a{color:var(--acc2);word-break:break-all}
78
+ @media(max-width:640px){.hook{font-size:21px}.wrap{padding:16px}}
79
+ </style>
80
+ </head>
81
+ <body>
82
+ <header>
83
+ <h1>a11oy · A Signature Is Not Proof of Safety</h1>
84
+ <div class="sub">SZL Holdings thought leadership · What the May 2026 “Mini Shai-Hulud” npm worm taught us — and why a11oy is built for a world where the cryptography is genuine but the code is not. Every maturity claim labelled <span class="pill live">LIVE</span> / <span class="pill road">ROADMAP</span>; live claims wired to real a11oy endpoints (honest <span class="nolive">NO-LIVE-DATA</span> fallback).</div>
85
+ <nav class="nav">
86
+ <a href="/console/">← Console</a>
87
+ <a href="/governance">Governance</a>
88
+ <a href="/compliance">Compliance crosswalk</a>
89
+ <a href="/defense-readiness">Defense readiness →</a>
90
+ </nav>
91
+ </header>
92
+
93
+ <div class="wrap">
94
+
95
+ <!-- HOOK -->
96
+ <section>
97
+ <div class="eyebrow">SZL Holdings · Thought Leadership · June 2026</div>
98
+ <div class="hook">A signature is not proof of safety.<br><span class="em">The cryptography was genuine. The package was malicious anyway.</span></div>
99
+ <p class="lede">On May 11, 2026, a piece of malware did something the software industry had quietly
100
+ assumed was impossible: it shipped with a valid, cryptographically signed SLSA Build Level 3
101
+ provenance attestation. The signature checked out. The provenance was genuine. The package was
102
+ malicious anyway.</p>
103
+ <p class="cite">Stephen P. Lutar Jr., Founder &amp; CEO, SZL Holdings · <a href="https://a11oy.net">a11oy.net</a></p>
104
+ </section>
105
+
106
+ <!-- 1. WHAT HAPPENED -->
107
+ <section>
108
+ <div class="eyebrow">1 · What happened</div>
109
+ <h2>Mini Shai-Hulud — a signed supply-chain worm</h2>
110
+ <div class="card">
111
+ <p>Between May 10 and 12, 2026 — with the main publishing burst compressed into roughly five
112
+ hours on May 11 — the threat group TeamPCP compromised <b>more than 170 packages</b> across the
113
+ npm and PyPI ecosystems, publishing over 400 malicious versions spanning 19 namespaces.
114
+ Affected projects had accumulated more than <b>half a billion cumulative downloads</b>. It is the
115
+ first documented npm worm to propagate while carrying <b>legitimately attested</b> malicious
116
+ packages.</p>
117
+ <p>The entry point was an orphaned CI/CD trust configuration in TanStack’s GitHub Actions
118
+ workflows — a <code>pull_request_target</code> workflow that retained OIDC federation despite no
119
+ longer being actively maintained. The attacker read short-lived OIDC tokens directly out of the
120
+ GitHub Actions runner’s process memory (<code>/proc/&lt;pid&gt;/mem</code>), then exchanged those
121
+ tokens with the Sigstore Fulcio certificate authority to mint legitimate signing certificates.
122
+ From there: stolen OIDC token → short-lived npm publish token → malicious versions released under
123
+ the real maintainer identity, with valid provenance describing the exact GitHub Actions job that
124
+ produced them.</p>
125
+ <div class="quote">Nothing in the cryptographic chain failed. Sigstore did exactly what it is
126
+ designed to do: it verified the identity of the token presenter. What it cannot do — what no
127
+ signature can do — is verify that the build environment had not been compromised, or that the
128
+ code executing inside that legitimate, identity-verified job was safe.</div>
129
+ <p>The provenance was accurate. It correctly described a build that produced malware. Phase 2 of
130
+ the campaign reportedly reached infrastructure at OpenAI, Grafana, and GitHub itself.</p>
131
+ </div>
132
+ <div class="quote big">The attack did not break the signature. It exploited the gap between
133
+ identity verification and behavioural integrity. The signature told you <i>who</i> built it. It
134
+ told you nothing about <i>what it does</i>.</div>
135
+ </section>
136
+
137
+ <!-- 2. WHY IT MATTERS -->
138
+ <section>
139
+ <div class="eyebrow">2 · Why it matters</div>
140
+ <h2>The signature-trust fallacy</h2>
141
+ <p>A cryptographic signature answers two questions with mathematical confidence: <b>who</b> signed
142
+ this, and <b>what exact bytes</b> were signed. It answers a third question — <i>is the signed thing
143
+ safe?</i> — not at all. The industry has spent a decade conflating the first two with the third.</p>
144
+ <div class="card">
145
+ <table>
146
+ <tr><th>What a signature proves</th><th>What it does NOT prove</th><th>Mini Shai-Hulud reality</th></tr>
147
+ <tr>
148
+ <td>Identity of the signer (the OIDC subject)</td>
149
+ <td class="no">That the signer’s environment was uncompromised</td>
150
+ <td>OIDC tokens stolen from runner memory; identity genuine</td>
151
+ </tr>
152
+ <tr>
153
+ <td>The exact bytes that were signed</td>
154
+ <td class="no">That those bytes are safe to execute</td>
155
+ <td>Provenance accurately described a malicious build</td>
156
+ </tr>
157
+ <tr>
158
+ <td>That a recognized pipeline produced the artifact</td>
159
+ <td class="no">That the pipeline behaved as intended</td>
160
+ <td>Legitimate GitHub Actions job produced malware</td>
161
+ </tr>
162
+ </table>
163
+ </div>
164
+ <p>SLSA and Sigstore are good. They are <b>necessary but not sufficient</b>. When a control becomes
165
+ a checkbox — “signed: yes” — it stops being a security boundary and becomes a false sense of one.</p>
166
+ </section>
167
+
168
+ <!-- 3. THE LESSON -->
169
+ <section>
170
+ <div class="eyebrow">3 · The lesson</div>
171
+ <h2>Doctrine v11 — Signature ≠ Safety</h2>
172
+ <div class="quote big">“A signature is not proof of safety.” Trust the behaviour you can observe
173
+ and the receipts you can replay — not the attestation you were handed.</div>
174
+ <p>The corollary is a posture we call <b>behaviour-over-attestation</b>. An attestation is a claim
175
+ made at build time about the past. Behaviour is evidence gathered at runtime about the present. When
176
+ the two disagree, behaviour wins. The rest of our doctrine follows from this: <b>prove-or-downgrade</b>
177
+ (claim only what has a checkable artifact), label every value <span class="pill acc">MEASURED</span>
178
+ <span class="pill warn">MODELED</span> <span class="pill">SAMPLE</span>, and never present an
179
+ attestation as a guarantee. We do not claim a11oy is unbreakable. We claim it <b>stops trusting the
180
+ signature alone</b>.</p>
181
+ </section>
182
+
183
+ <!-- 4. HOW a11oy IS ARCHITECTED -->
184
+ <section>
185
+ <div class="eyebrow">4 · How a11oy is architected for exactly this</div>
186
+ <h2>Five mechanisms — each labelled LIVE-today vs ROADMAP</h2>
187
+ <p>Below are the five mechanisms that make a11oy a structural answer to a Mini Shai-Hulud-class
188
+ attack. We are explicit throughout about what is live today versus what is roadmap. The credibility
189
+ comes from the honesty. Where a mechanism can be proven right now, the card binds to a real a11oy
190
+ production endpoint below.</p>
191
+
192
+ <div class="grid">
193
+ <!-- 4.1 -->
194
+ <div class="mech">
195
+ <div class="head"><span class="num">4.1</span><span class="pill live">LIVE — GAP1</span></div>
196
+ <h3>Artifact-behaviour monitor</h3>
197
+ <div class="body">Observe what an artifact actually <i>does</i> at runtime and compare it against an
198
+ expected behavioural envelope. A signature would have passed Mini Shai-Hulud straight through; a
199
+ behaviour monitor asks the question the signature cannot — does this thing act the way a safe
200
+ version of it should? Deny-by-default applied to behaviour, not identity.</div>
201
+ <div class="status"><b>Today:</b> live as the GAP1 capability, backed by a certified live PINN
202
+ (physics-informed) certificate from production APIs. <b>Roadmap:</b> broader behavioural-envelope
203
+ catalogue per artifact class / ecosystem (npm, PyPI, container, model).</div>
204
+ <div class="live-line" id="pinn-live"><span class="pill warn">checking…</span><span class="v">PINN certificate</span></div>
205
+ </div>
206
+
207
+ <!-- 4.2 -->
208
+ <div class="mech">
209
+ <div class="head"><span class="num">4.2</span><span class="pill live">LIVE</span></div>
210
+ <h3>3-axis attestation</h3>
211
+ <div class="body">Single-axis attestation is the exact weakness Mini Shai-Hulud exploited: a valid
212
+ build attestation, and nothing binding it to runtime behaviour. a11oy’s assurance mesh binds three
213
+ axes — <b>build provenance · model lineage · runtime behaviour</b> — so compromise of any one axis
214
+ does not silently pass the others. A genuine build signature riding on a malicious runtime fails
215
+ the cross-axis check.</div>
216
+ <div class="status"><b>Today:</b> 3-axis model + DSSE-signed verdicts/receipts in the live mesh.
217
+ <b>Roadmap:</b> deeper third-party STIX/TAXII threat-intel correlation into the model + runtime axes.</div>
218
+ <div class="live-line" id="comp-live"><span class="pill warn">checking…</span><span class="v">Compliance crosswalk</span></div>
219
+ </div>
220
+
221
+ <!-- 4.3 -->
222
+ <div class="mech">
223
+ <div class="head"><span class="num">4.3</span><span class="pill live">LIVE</span></div>
224
+ <h3>Hash-chained Forge ledger + kill switch</h3>
225
+ <div class="body">Every verdict is written to a hash-chained, offline-verifiable governance ledger
226
+ (the Forge ledger), so any action is replayable after the fact and any decision is revocable through
227
+ the kill switch. In a Mini Shai-Hulud scenario this is the difference between “we think we contained
228
+ it” and “we can prove, line by line, what was admitted, when, and on what evidence — and revoke it now.”</div>
229
+ <div class="status"><b>Today:</b> hash-chained ledger + kill switch live, with signed receipts
230
+ (including MEASURED energy receipts via a real NVML exporter, kept distinct from any modeled figure).
231
+ <b>Roadmap:</b> publishing ledger inclusion proofs to an external transparency service (§5).</div>
232
+ </div>
233
+
234
+ <!-- 4.4 -->
235
+ <div class="mech">
236
+ <div class="head"><span class="num">4.4</span><span class="pill live">LIVE</span></div>
237
+ <h3>Hybrid Ed25519 + ML-DSA &amp; C2PA</h3>
238
+ <div class="body">We do not deprecate signing — we harden it and stop over-trusting it. a11oy signs
239
+ with a hybrid <b>Ed25519 + ML-DSA</b> scheme so verdicts remain verifiable in a post-quantum world,
240
+ and attaches <b>C2PA content credentials</b> so the provenance of generated content is transparent.
241
+ This anticipates EU AI Act Article 50 transparency obligations.</div>
242
+ <div class="status"><b>Today:</b> hybrid signing + C2PA implemented, alongside a NIST AI RMF / ISO
243
+ 42001 / EU AI Act compliance crosswalk. <b>Roadmap:</b> third-party attestation of the crosswalk
244
+ mapping ahead of enforcement.</div>
245
+ </div>
246
+
247
+ <!-- 4.5 -->
248
+ <div class="mech">
249
+ <div class="head"><span class="num">4.5</span><span class="pill road">ROADMAP</span></div>
250
+ <h3>SCITT-style independent transparency</h3>
251
+ <div class="body">The deepest lesson of Mini Shai-Hulud is that <b>self-attestation is not enough</b>:
252
+ the build attested honestly to its own malicious output. Independent, append-only transparency
253
+ ledgers — as standardized by IETF SCITT — let third parties verify receipts without trusting the
254
+ producer.</div>
255
+ <div class="status"><b>Today:</b> internal hash-chained ledger (4.3) is live and offline-verifiable.
256
+ <b>Roadmap:</b> external SCITT-style transparency service with third-party inclusion proofs — we label
257
+ this honestly as not-yet-live.</div>
258
+ </div>
259
+ </div>
260
+ </section>
261
+
262
+ <!-- 5. THE BROADER SHIFT -->
263
+ <section>
264
+ <div class="eyebrow">5 · The broader shift</div>
265
+ <h2>From self-attestation to independent, behavioural assurance</h2>
266
+ <div class="grid">
267
+ <div class="card">
268
+ <h3>EU AI Act · Article 50</h3>
269
+ <p>Transparency obligations for AI-generated content take effect <b>August 2, 2026</b>. a11oy’s
270
+ C2PA content credentials and hybrid signing (4.4) are built toward exactly this — provenance of
271
+ generated content, transparent and verifiable.</p>
272
+ </div>
273
+ <div class="card">
274
+ <h3>IETF SCITT</h3>
275
+ <p>Supply Chain Integrity, Transparency and Trust — independent, append-only ledgers that let
276
+ third parties verify receipts without trusting the producer. The direct standards answer to the
277
+ self-attestation gap (4.5, roadmap).</p>
278
+ </div>
279
+ <div class="card">
280
+ <h3>OMB · risk-based shift</h3>
281
+ <p>The 2026 OMB action rescinding the prior secure-software-development self-attestation mandate
282
+ in favor of a risk-based approach reflects the same realization: an attestation checkbox is not a
283
+ risk control. Behaviour and replayable evidence are.</p>
284
+ </div>
285
+ </div>
286
+ </section>
287
+
288
+ <!-- TALK TO US -->
289
+ <section>
290
+ <div class="card">
291
+ <h3>Tabletop it against a live instance</h3>
292
+ <p>We are happy to walk through a Mini Shai-Hulud tabletop against a live a11oy instance — what the
293
+ artifact-behaviour monitor would have flagged, what the 3-axis check would have rejected, and what
294
+ the governance ledger would let you prove and revoke after the fact. Live signed APIs and the GAP1
295
+ behavioural monitor are available now at <a href="https://a11oy.net">a11oy.net</a>.</p>
296
+ </div>
297
+ </section>
298
+
299
+ <!-- REFERENCES -->
300
+ <section>
301
+ <div class="eyebrow">References</div>
302
+ <ol class="reflist">
303
+ <li>Cloud Security Alliance, “Mini Shai-Hulud: When Signed Provenance Certified a Supply Chain Worm,” May 15, 2026. <a href="https://labs.cloudsecurityalliance.org/research/csa-research-note-mini-shai-hulud-supply-chain-sigstore-2026/">labs.cloudsecurityalliance.org</a></li>
304
+ <li>Open Source For U, “Hackers Abuse GitHub Actions and SLSA Signing to Spread Malware Across Open Source Ecosystems,” May 14, 2026. <a href="https://www.opensourceforu.com/2026/05/hackers-abuse-github-actions-and-slsa-signing-to-spread-malware-across-open-source-ecosystems/">opensourceforu.com</a></li>
305
+ <li>EU AI Act Service Desk FAQ. <a href="https://ai-act-service-desk.ec.europa.eu/en/faq">ai-act-service-desk.ec.europa.eu</a>; Latham &amp; Watkins, “AI Act Update,” May 13, 2026. <a href="https://www.lw.com/en/insights/ai-act-update-eu-resolves-to-change-rules-and-extend-deadlines">lw.com</a></li>
306
+ <li>IETF SCITT Working Group, Datatracker (draft-ietf-scitt-architecture; draft-dawkins-scitt-ai-article50-00, filed May 25, 2026). <a href="https://datatracker.ietf.org/wg/scitt/">datatracker.ietf.org/wg/scitt</a></li>
307
+ <li>Wiley Law, “OMB Rescinds Secure Software Development Mandate in Favor of a Risk-Based Approach,” Jan 29, 2026. <a href="https://www.wiley.law/alert-OMB-Rescinds-Secure-Software-Development-Mandate-in-Favor-of-a-Risk-Based-Approach">wiley.law</a></li>
308
+ </ol>
309
+ </section>
310
+
311
+ </div>
312
+
313
+ <footer>
314
+ a11oy showcase · doctrine v11 · A signature is not proof of safety · behaviour-over-attestation ·
315
+ prove-or-downgrade · Λ = Conjecture 1 (advisory, &lt; 1.0) · trust &lt; 100% · 0 runtime CDN ·
316
+ every maturity claim labelled LIVE / ROADMAP.<br>
317
+ Live proofs fetched from <span style="color:var(--acc2)">/api/a11oy/v1/{pinn/certificate, compliance}</span> — honest NO-LIVE-DATA fallback, never fabricated.
318
+ About SZL Holdings · sovereign-compute, AI-governance &amp; defense-tech, NYC · UEI [PLACEHOLDER: UEI] · CAGE [PLACEHOLDER: CAGE] · NAICS 541715.
319
+ </footer>
320
+
321
+ <script>
322
+ // 0-CDN inline. Prove what we can, LIVE, against real a11oy endpoints; otherwise
323
+ // render an HONEST NO-LIVE-DATA chip — never a fabricated value.
324
+ (function(){
325
+ function setLive(id, ok, label, href){
326
+ var el = document.getElementById(id);
327
+ if(!el) return;
328
+ var pill = ok ? '<span class="pill live">LIVE ✓</span>'
329
+ : '<span class="pill warn">NO-LIVE-DATA</span>';
330
+ var v = href && ok
331
+ ? '<span class="v"><a href="'+href+'">'+label+'</a></span>'
332
+ : '<span class="v">'+label+'</span>';
333
+ el.innerHTML = pill + v;
334
+ }
335
+ function probe(url, id, label, href){
336
+ fetch(url, {headers:{'accept':'application/json'}})
337
+ .then(function(r){ return r.ok ? r.json().catch(function(){return {};}) : null; })
338
+ .then(function(j){ setLive(id, j!==null, label, href); })
339
+ .catch(function(){ setLive(id, false, label, href); });
340
+ }
341
+ // 4.1 — certified live PINN (physics-informed) certificate.
342
+ probe('/api/a11oy/v1/pinn/certificate', 'pinn-live',
343
+ 'PINN certificate (GAP1 behaviour monitor)', '/api/a11oy/v1/pinn/certificate');
344
+ // 4.2/4.4 — NIST AI RMF / ISO 42001 / EU AI Act compliance crosswalk.
345
+ probe('/api/a11oy/v1/compliance', 'comp-live',
346
+ 'NIST AI RMF / ISO 42001 / EU AI Act crosswalk', '/compliance');
347
+ })();
348
+ </script>
349
+ </body>
350
+ </html>