Transilience Report Style

6. Radar Visualization

A custom Flowable rendering a polar threat radar.

6.1 Dimensions

6.2 Background Glow

Concentric filled circles from max_r + 20 down to 0 (step −2), each with increasing alpha (0.03 → 0.05), color rgba(10, 5, 20, alpha).

6.3 Ring Grid

4 dashed concentric rings at 25%, 50%, 75%, 100% of max radius.

• Ring stroke: rgba(105, 65, 198, 0.3), 0.5pt, dash pattern (3, 3)
• Labels positioned along 15° angle from center at each ring's radius, Poppins-Medium 7pt

6.4 Sector Spokes

12 spokes at 30° intervals, representing attack surfaces:

Web Apps/API, Cloud/Infra, Network, Endpoints, Email, Mobile, IoT/OT, Data Storage, Identity, Third-Party, Physical, Social Eng.

• Spoke stroke: rgba(105, 65, 198, 0.25), 0.3pt
• Labels: Poppins-Medium 9pt, white, at max_r + 32 from center
• Alignment: centered if near vertical, left-aligned if right half, right-aligned if left half

6.5 Center Crosshair

• 16pt arms, color rgba(140, 92, 230, 0.4), 0.4pt
• Center glow: 16 concentric circles, rgba(105, 65, 198, 0.04 × (16−r))

6.6 Threat Points

Each threat plotted using theta_deg and radius_norm from data.

Three-layer rendering per point:

1. Outer glow: severity color at 0.12 alpha, radius + 7pt
2. Mid glow: severity color at 0.25 alpha, radius + 3pt
3. Core dot: severity color at 0.9 alpha, exact radius
4. Specular highlight: white at 0.3 alpha, offset (−0.15r, +0.15r), radius 0.35r

7. Advisory Card Structure

Cards are returned as flat lists of Flowables (not wrapped in CardBox), enabling ReportLab page-split. Between cards: CondPageBreak(220) — only breaks if <220pt space remains.

7.1 Card Layout (top to bottom)

7.2 Metadata Row Format

Source: THREAT INTEL │ Surface: Endpoint / Email │ Status: NEW │ First Seen: 2026-02-24

Labels in BPL (#8B5CF6), values in T2, separator: unicode │ (U+2502) with 4-space padding.

Source label mapping: threat → THREAT INTEL, product → PRODUCT VULN, breach → BREACH INTEL.

7.3 Detection Evidence Format

• {TechName}  —  {evidence_string}

Tech name in T1 (white, bold), em-dash separator, evidence string in T2. Max 6 items per card.

7.4 Section Header Coloring

8. Cover Page Layout

8.1 Structure (top to bottom)

8.2 Metadata Fields

9. Table of Contents Layout

10. Report Section Blueprint

10.1 Standard Section Header Pattern

Every numbered section follows this sequence:

1. SectionNumber(num) — decorative ghost number (38pt height)
2. Section title in h1 style (Poppins-Bold 20pt)
3. GradientLine(CW, 2) — full-width separator
4. Spacer(1, 4*mm) — breathing room

10.2 Section Inventory (12 sections)

11. Spacing System

11.1 Vertical Rhythm

11.2 Table Padding

12. Data-Driven Components

12.1 Evidence Map Architecture

Technology evidence is extracted from techstack_report.json and indexed by keyword. The extraction traverses:

• technologies.frontend[] — name, evidence[].finding, evidence[].details
• technologies.backend[] — web servers, frameworks, CMS, languages
• technologies.infrastructure[] — DNS, CDN providers
• technologies.security[] — WAF, certificates, headers, email security
• technologies.third_party[] — analytics, collaboration tools

Each evidence item is indexed under multiple keywords derived from the technology name fragments. Alias mappings expand coverage (e.g., email → proofpoint, microsoft, dmarc).

12.2 Threat-Evidence Matching

get_threat_evidence(threat) scans the threat's title, summary, and threat_name against the keyword index. Returns up to 6 (tech_name, evidence_string) tuples. Deduplication by {tech_name}:{evidence} key.

12.3 Severity Sorting

All threats sorted by: severity rank descending (critical=4, high=3, medium=2, low=1), then prioritization_score descending. Split into four lists for section rendering.

13. Unicode Characters

14. Adaptive Behaviors

14.1 Page Break Strategy

14.2 Card Splittability

Advisory cards return flat list[Flowable] instead of monolithic CardBox. This allows ReportLab's frame to split cards across page boundaries at any Paragraph/Spacer seam, eliminating blank pages.

14.3 Client Adaptation

The design system is client-agnostic. Customized per client:

• Cover: client logo, name, sector, region, report ID
• Executive summary: narrative and key findings
• Attack surface: domain/subdomain inventory
• Evidence map: keyword aliases tuned to client's tech stack
• Security posture: assessments specific to client's infrastructure
• Recommendations: actionable items specific to client's vulnerabilities

All visual elements (colors, typography, spacing, components) remain identical across clients.