TLSStress.Art Datasheet — Security Architecture section (v4.7+)¶

Companion to: TLSStress-Art-Investor-Deck-philosophy.md + slide spec Asset target: Technical datasheet PDF for enterprise sales engineering Authoring discipline: Same Schematic Cinema doctrine; one page, two columns, no marketing prose

This document is the content + composition spec for the Security Architecture section of the technical datasheet. The datasheet talks to SE / SecOps / Risk audiences — different register than the investor deck, but the same restraint. Where the investor deck shows three panels and lets the audience infer, the datasheet shows twelve rows and lets the reader verify line-by-line.

Page layout¶

A single page. Two columns at 50/50 split. Header bar at the top in cyan; footer with the standard datasheet rule at the bottom. The twelve-row layer table fills the left column. The right column carries three blocks stacked vertically: differentiators, compliance mapping, and the patent posture reference.

SECURITY ARCHITECTURE — Zero-Trust-on-Premises (ZTP-prem)
Twelve composed layers · Operator-visible · Code-anchored

Below the header, one body line at intermediate weight:

Built for the only adversary an enterprise audit officer cares about — the operator with kubectl and root. Every layer is in code today or in a shipped scaffold with a published implementation roadmap.

Left column — the twelve-layer table¶

A strict tabular grid. Three columns: layer number (mono), layer name (display small), implementation status (mono). No icons.

#	Layer	Status
01	Cloud HSM custody	runtime gate shipping; real HSM probe scheduled
02	Confidential Computing detection	shipping
03	TPM measured boot	probe scaffold shipping; PCR signing scheduled
04	Sealed audit hash-chain	shipping; cloud replay verifier scheduled
05	K8s admission webhook	audit + enforce + break-glass + cross-correlation shipping
06	Anti-debug runtime posture	distroless + readonly-rootfs + dropped caps shipping
07	Tier A/B code partition	shipping with CI lint enforcement
08	UTXO token vault	shipping; auto-issue dev mode + hardened prod mode
09	Tier B binary obfuscation	shipping (garble CI matrix over 6 Go modules)
10	DLP egress monitor	shipping (5 rules, host skiplist, redaction policy)
11	Behavioural anomaly detector	shipping (4 rule-based detectors)
12	Separation of duties	shipping (CODEOWNERS + nightly SoD audit)

The "shipping" / "scheduled" wording is intentional. Avoid percentages. Avoid quarters. The reader is a sales-engineering reviewer who knows that shipping means "merged into main and deployable today".

Right column — three blocks¶

Block A — Three unusual things¶

Cross-language signing contract — Go and Node runtimes produce byte-identical canonical signatures over the license envelope, including post-quantum primitives. Filed as Patent #18.

UTXO token vault — tokens are tamper-evident notes, not a mutable balance. Each test plan execution burns a note and emits a signed receipt. No race condition. No negative-balance attack.

Admission ↔ sealed audit cross-correlation — K8s admission decisions are lifted from the webhook's local ring buffer into the hash-chain on a schedule. Pod restarts do not erase forensic evidence. Tampering attempts break the chain and are detectable on cloud-side replay.

Block B — Compliance mapping¶

A short table. Two columns: framework / mapping.

Framework	ZTP-prem control points
SOC 2 II — CC1.5 + CC8.1	Layer 12 (CODEOWNERS + SoD audit)
SOC 2 II — CC7.2	Layer 4 (sealed audit) + Layer 11 (anomaly)
ISO 27001 — A.6.1.2	Layer 12
ISO 27001 — A.12.4.1, A.12.4.2	Layer 4 + Layer 10
LGPD / GDPR — Art. 46	Layer 10 (DLP egress) + Layer 4
PCI-DSS 4.0 — 7.2.5	Layer 12 (path-scoped reviewer enforcement)
NIST 800-53 Rev. 5 — AU-10	Layer 4 + Layer 10
NIST 800-53 Rev. 5 — SI-4	Layer 11
FIPS 203 / 204 / 205 (PQ)	Patent #18 — ML-KEM-768 + ML-DSA-65

The mapping is restrained — only the controls a SecOps reviewer would actually look up. Do not list every NIST control just because it could be argued to apply. Datasheet-grade rigor: every line stands up to a question.

Block C — Patent posture (single line + reference)¶

Patent claims #18–25 cover the cross-language signing contract, UTXO token vault primitives, admission-to-chain bridge, sealed audit WORM enforcement, TPM-sealed boot integration, DLP egress redaction policy, Tier A/B partition enforcement, and the behavioural anomaly floor. Filings on record; available under NDA for technical due-diligence.

Followed by a mono reference line in small type:

Reference: pkg/ztp-prem-signctl  ·  pkg/ztp-prem-admission  ·  pkg/ztp-prem-tpm
           dashboard/src/lib/license  ·  dashboard/src/lib/ztp-prem
           platform/ztp-prem/{tier-policy.yaml, *.md}

Standard datasheet footer. Mono small. Pattern:

TLSStress.Art · Security Architecture · v4.7+ · 2026-05-12
Zero-Trust-on-Premises is a TLSStress.Art trademark. All twelve layers
verifiable in source: github.com/nollagluiz/AI_forSE

What this spec deliberately omits¶

Specific deployment SKUs. Pricing and SKU appear on a separate page; this page is architecture-only.
Customer references. This page is for the architecture review, not the social-proof review.
Implementation roadmap dates. Two layers carry "scheduled" rather than dates. SE reviewers know what scheduled means in a real engineering org; calendar promises invite legal exposure for no incremental sales value.
Diagrams of the test-bed. The test-bed architecture page lives earlier in the datasheet; this page is about the trust posture surrounding it, not the test-bed itself.

Fact-check checklist (perform before each datasheet revision)¶

Every "shipping" row corresponds to code currently on main
Every "scheduled" row has a published Wave-B follow-up plan in project_ztp_prem_posture_locked_2026_05_11.md
Compliance mapping rows match the public language of the cited framework (use the cited control identifier verbatim)
Patent reference paragraph matches the latest filing inventory in platform/ztp-prem/CLOUD-HSM-KEY-CUSTODY.md and related memos
Footer year + version current; trademark string current