/* NeuralVault — data.jsx
   Dual-track positioning: Attention Velocity × Deep Intelligence.
   Content lives here so future pages/CMS can plug in cleanly. */

/* ---------- STORIES: "Space Transitions" — operational reports ---------- */
const STORIES = [
  {
    id: "s01",
    tag: "ATTENTION",
    ref: "REF_0923",
    minutes: 9,
    date: "2026.05",
    fig: "OPS_RPT.01 — VELOCITY GRAPH",
    title: "The Architecture of Attention in 2026",
    snippet: "Why retention is the only honest KPI left, and the four-layer traffic stack we install to defend it across socials, SERP, and owned channels.",
    author: "B. WILLIAMS · PRINCIPAL",
    sections: [
      { type: "body", text: "Attention has always been finite. What changed in the last eighteen months is that it became measurable in ways that make the old acquisition playbook look like guesswork. CPMs are noise. Click-through rates are noise. Retention — specifically D7 and D30 retention measured against a clean cohort — is the one signal that doesn't lie, because it can't be gamed at scale without actually building something worth returning to." },
      { type: "heading", level: 2, text: "Why Retention Is the Only Honest KPI" },
      { type: "body", text: "Every other metric has a market for manipulation. Impressions, clicks, followers — each has a shadow industry built around inflating it cheaply. Retention doesn't. You can buy a user. You cannot buy a user who comes back on day thirty. That second event requires that the product, the content, or the experience actually delivered something. Retention is the market's verdict." },
      { type: "pullquote", text: "You can buy a user. You cannot buy a user who comes back on day thirty." },
      { type: "heading", level: 2, text: "The Four-Layer Stack" },
      { type: "body", text: "Our standard Track A installation runs four layers in sequence. The signal layer collects server-side events with first-party ID resolution — no reliance on browser cookies, no dependence on platform APIs that change quarterly. The content layer produces assets at creator-grade velocity: forty to one-twenty pieces per week, each tagged to a specific funnel position and cohort hypothesis. The distribution layer routes those assets across paid and owned channels with real-time bidding access at the campaign level. The attribution layer closes the loop — multi-touch forensics down to the individual creative unit, with CAC decomposed by channel, format, and audience segment." },
      { type: "table", rows: [
        { k: "Signal Layer", v: "Server-side events · first-party ID resolution" },
        { k: "Content Layer", v: "40–120 assets/week · funnel-tagged" },
        { k: "Distribution Layer", v: "Paid + owned routing · real-time bidding" },
        { k: "Attribution Layer", v: "Multi-touch forensics · SKU-grade CAC" },
      ]},
      { type: "heading", level: 2, text: "What This Looks Like in Practice" },
      { type: "body", text: "A typical engagement begins with a two-week instrumentation sprint. We replace or supplement the client's existing event tracking with a server-side pipeline, establish the ID resolution graph, and run a baseline cohort analysis against the last ninety days of data. From that baseline, we identify the three to five levers with the highest expected return on content and distribution investment. Everything after that is iterative — weekly cadence, tight feedback loops, CAC reviewed at the creative level, not the campaign level." },
      { type: "body", text: "Across ten completed engagements, the median D30 retention improvement is 38 percentage points above the pre-engagement baseline. That number does not come from ad spend. It comes from understanding exactly which content, delivered at which moment, to which cohort, produces a second visit. The stack makes that legible. The operators act on what the stack reveals." },
      { type: "pullquote", text: "The median D30 improvement is 38 points. That number does not come from ad spend." },
    ],
  },
  {
    id: "s02",
    tag: "VISION",
    ref: "REF_0917",
    minutes: 14,
    date: "2026.04",
    fig: "OPS_RPT.02 — EDGE TOPOLOGY",
    title: "Deploying Neural Networks in Consumer Hardware",
    snippet: "A field report on shipping fine-tuned CV models to thirty thousand devices — quantization losses, thermal envelopes, and the latency budget you actually have.",
    author: "B. WILLIAMS · PRINCIPAL",
    sections: [
      { type: "body", text: "There is a version of this report that talks about accuracy benchmarks and validation set performance. That version is not useful. Accuracy on a reference set tells you what the model can do in a controlled environment. It says nothing about what it does at twelve milliseconds, on a three-year-old mid-range device, in a thermal state the test harness never modelled. This report is about the second version of that problem." },
      { type: "heading", level: 2, text: "The Problem with Benchmark Numbers" },
      { type: "body", text: "Model benchmarks are measured on server hardware with unconstrained memory, stable thermal state, and no competing processes. Consumer devices are none of those things. The gap between benchmark accuracy and production accuracy on a median device in the fleet is typically 2–6 percentage points — which sounds small until you understand that at the error rates we operate at, that gap is the difference between a product that works and one that users delete." },
      { type: "pullquote", text: "The gap between benchmark accuracy and production accuracy is typically 2–6 points. At our error rates, that is the difference between a product that works and one that users delete." },
      { type: "heading", level: 2, text: "Quantization in Practice" },
      { type: "body", text: "We quantize all production models to INT8 as a baseline, with selected layers dropped to INT4 where the accuracy loss is below 0.3 percentage points on the domain-specific validation set. The process is not automatic — it requires careful calibration data selection and per-layer sensitivity analysis. Done correctly, INT8 quantization reduces model size by 4× and inference latency by 2–3× compared to FP32, with accuracy loss of under one percent on well-curated calibration data." },
      { type: "table", rows: [
        { k: "FP32 Baseline (server)", v: "99.8% acc · 340MB · 82ms p99" },
        { k: "INT8 Quantized", v: "99.1% acc · 85MB · 28ms p99" },
        { k: "INT8 + INT4 hybrid", v: "98.8% acc · 48MB · 18ms p99" },
        { k: "Production target", v: "≥98.5% acc · ≤50MB · ≤12ms p99" },
      ]},
      { type: "heading", level: 2, text: "Thermal Envelopes" },
      { type: "body", text: "Thermal throttling is the most common cause of production performance regression in deployed models and the least discussed. When a device reaches its thermal limit — typically 85°C junction temperature — the CPU and NPU reduce clock speeds by 30–60% to prevent damage. A model that runs at 12ms p99 in a cold test will routinely exceed 40ms on a device that has been in active use for twenty minutes. We design for the thermal state of a device at the twenty-minute mark, not the cold state." },
      { type: "heading", level: 2, text: "The Latency Budget" },
      { type: "body", text: "The total latency budget from user event to rendered output is constrained by perception. Research consistently places the threshold for 'instant' response at 100ms. Within that budget, our model inference target is 12ms p99 — leaving 88ms for preprocessing, postprocessing, rendering, and any network round-trips the application requires. Models that violate the 12ms constraint are re-architected, not shipped." },
      { type: "table", rows: [
        { k: "Total budget (perceptual threshold)", v: "100ms" },
        { k: "Preprocessing (camera/input)", v: "~15ms" },
        { k: "Model inference target", v: "≤12ms p99" },
        { k: "Postprocessing + rendering", v: "~40ms" },
        { k: "Remaining headroom", v: "~33ms" },
      ]},
      { type: "pullquote", text: "We design for the thermal state of a device at the twenty-minute mark, not the cold state." },
    ],
  },
  {
    id: "s03",
    tag: "VISION",
    ref: "REF_0908",
    minutes: 11,
    date: "2026.03",
    fig: "OPS_RPT.03 — FINE-TUNE MAP",
    title: "What Vision Models Actually See — and Where to Intervene",
    snippet: "Foundation models are not blank slates. Understanding what a vision backbone has already learned — and where that knowledge breaks down — determines whether your fine-tune succeeds or silently fails.",
    author: "B. WILLIAMS · PRINCIPAL",
    sections: [
      { type: "body", text: "Most fine-tuning projects are launched with the wrong question. The team picks a foundation model, assembles a labeled dataset, trains for a few epochs, and checks validation accuracy. If the number is high enough, they ship. What they never ask is: what did the base model already know, and what parts of that knowledge are we inadvertently overwriting? The answer determines the difference between a fine-tune that generalizes and one that memorizes." },
      { type: "heading", level: 2, text: "What the Backbone Already Knows" },
      { type: "body", text: "A vision transformer pretrained on a large corpus — ImageNet-21k, LAION, or a proprietary dataset — has already learned a rich hierarchy of visual features. The early layers encode edges, textures, and local color gradients. Middle layers encode shapes, object parts, and spatial relationships. Late layers encode semantic categories. When you fine-tune the entire network on a narrow domain, you are not teaching new things on top of a clean slate — you are selectively overwriting an existing hierarchy. The question is whether you are overwriting the right layers." },
      { type: "pullquote", text: "You are not teaching new things on top of a clean slate. You are selectively overwriting an existing hierarchy." },
      { type: "heading", level: 2, text: "The Layer Sensitivity Map" },
      { type: "body", text: "Before we fine-tune any backbone, we produce a layer sensitivity map: a per-layer analysis of how much the weights shift in response to domain-specific data, and how much validation accuracy changes when a given layer is frozen versus unfrozen. The map tells us three things. First, which layers contain generic features the model has already solved and should not be modified. Second, which layers contain domain-specific representations that the base model approximated incorrectly and must be retrained. Third, which layers are neutral — they can be trained or frozen without meaningful effect on outcome." },
      { type: "table", rows: [
        { k: "Layers 1–4 (edges, textures)", v: "Freeze — base model solved this" },
        { k: "Layers 5–8 (shapes, parts)", v: "Conditional — freeze unless domain is highly specialized" },
        { k: "Layers 9–12 (semantics)", v: "Train — this is where domain knowledge lives" },
        { k: "Classification head", v: "Always retrain from scratch" },
      ]},
      { type: "heading", level: 2, text: "Where Fine-Tunes Silently Fail" },
      { type: "body", text: "The most common failure mode is not low validation accuracy — it is high validation accuracy on a distribution that does not match production. A model fine-tuned on studio-captured product images will hallucinate confidence when shown the same product in ambient lighting, at an angle, or partially occluded. The validation set passed because it was drawn from the same studio captures. The production environment was never represented in training." },
      { type: "body", text: "The second failure mode is feature collapse. When you fine-tune aggressively on a small dataset with a high learning rate, the model converges to features that are predictive of the training labels but lose the rich intermediate representations that made the backbone useful. The model becomes brittle: accurate on seen examples, confident and wrong on unseen ones. Gradient checkpointing and layerwise learning rate decay are the standard mitigations — but they require knowing the model's architecture deeply enough to apply them correctly." },
      { type: "pullquote", text: "High validation accuracy on the wrong distribution is not a success. It is a silent failure waiting for a production trigger." },
      { type: "heading", level: 2, text: "The Intervention Protocol" },
      { type: "body", text: "Our standard fine-tuning protocol runs in three phases. Phase one: frozen backbone, head-only training for five to ten epochs to establish a stable loss landscape before any backbone weights move. Phase two: progressive unfreezing from the top layer down, with learning rates scaled by depth — typically 10× smaller at the first unfrozen layer than at the head. Phase three: full-network fine-tuning at a very low rate for a short window, with early stopping triggered by validation loss on an out-of-distribution holdout set, not the in-distribution validation split." },
      { type: "table", rows: [
        { k: "Phase 1 — head only", v: "5–10 epochs · LR 1e-3 · backbone frozen" },
        { k: "Phase 2 — progressive unfreeze", v: "Top-down · LR decays 10× per layer group" },
        { k: "Phase 3 — full network", v: "LR 1e-5 · early stop on OOD holdout" },
        { k: "Validation holdout", v: "Must include OOD samples — not just in-distribution" },
      ]},
      { type: "body", text: "The protocol adds two to three days to a typical fine-tuning project. It consistently reduces production error rates by 15–40% compared to naive full-network fine-tuning. The cost is not in compute — it is in discipline: the willingness to slow down before the number on the dashboard looks good enough to ship." },
    ],
  },
];

const STORY_TAGS = [
  { key: "ALL", label: `ALL · ${STORIES.length}` },
  { key: "ATTENTION", label: "Attention" },
  { key: "VISION", label: "Vision / ML" },
];

/* ---------- NAV ---------- */
const NAV_ITEMS = [
  { id: "dashboard", label: "Command" },
  { id: "verticals", label: "Verticals" },
  { id: "stories", label: "Transitions" },
  { id: "portal", label: "Contact" },
];

/* ---------- TICKER: live ops chatter ---------- */
const TICKER_ITEMS = [
  "VELOCITY · TRAFFIC INJECTION +12.4%",
  "CV_MODEL_v4.2 · INFERENCE 12ms p99",
  "EDGE NODES · 30,412 ONLINE",
  "ATTENTION OPS · OH SYNC",
  "ML PIPELINE · RETRAIN Q3",
  "RETARGETING · 4 CHANNELS LIVE",
];

/* ---------- NETWORK ---------- */
const NETWORK_NODES = [
  { code: "VELOCITY-OH", live: true },
  { code: "VELOCITY-NYC", live: false },
  { code: "VISION-OH", live: true },
  { code: "VISION-NYC", live: false },
  { code: "EDGE-OH", live: true },
  { code: "EDGE-NYC", live: false },
];

/* ---------- INQUIRY ---------- */
const SERVICES = [
  "Attention & Scale",
  "Engineer the Data",
  "Computer Vision & ML",
  "Not sure yet — let's talk",
];

const INQUIRY_PANEL = [
  { k: "Response", v: "Within 2 business days" },
  { k: "Direct", v: "inquiries@neuralvault.net" },
  { k: "Engagement", v: "Multi-quarter, instrumented" },
];

/* ---------- VERTICALS: three building blocks ---------- */
const VERTICALS = [
  {
    id: "v01",
    num: "FUND_01",
    ref: "REF_AS_2026",
    title: "Attention & Scale",
    subtitle: "Velocity operations for socials and e-commerce",
    body: "We design, instrument, and operate the traffic systems that move modern consumer brands — from creator-led social funnels to retargeting graphs. Quiet, multi-quarter, instrumented end-to-end.",
    diagram: "traffic",
    capabilities: [
      "Creator-grade content velocity stack",
      "Owned-channel retargeting & ID resolution",
      "Server-side funnel instrumentation",
      "Attribution & CAC forensics",
    ],
  },
  {
    id: "v02",
    num: "FUND_02",
    ref: "REF_DATA_2026",
    title: "Engineer the Data",
    subtitle: "The data backbone underneath every shipped system",
    body: "Before models can think and traffic can route, the data has to be honest. We design the pipelines, edge storage, and telemetry loops that make the rest of the stack possible — quietly, with version control, and built to survive the next migration.",
    diagram: "touch",
    capabilities: [
      "Pipeline architecture & schema design",
      "Edge-node distribution & sync",
      "Real-time telemetry & feedback loops",
      "Data quality, lineage, governance",
    ],
  },
  {
    id: "v03",
    num: "FUND_03",
    ref: "REF_CV_2026",
    title: "Computer Vision & ML",
    subtitle: "Bespoke model architectures, delivered to the consumer",
    body: "We build fine-tuned vision models and ship them where they actually run — phones, kiosks, factory floors. Inference at the edge, training on our compute. The handoff is a binary, not a paper.",
    diagram: "vision",
    capabilities: [
      "Bespoke CV / multimodal architectures",
      "Fine-tuning & domain transfer",
      "Quantization for consumer hardware",
      "Edge inference + telemetry loop",
    ],
  },
];

/* ---------- HERO META STRIP ---------- */
const HERO_META = [
  { k: "Daily Inferences", v: "2.4B", sub: "edge + core" },
  { k: "Traffic Routed", v: "18.6M", sub: "sessions / day" },
  { k: "Active Models", v: "24", sub: "production" },
  { k: "Capital Deployed", v: "$412M", sub: "AUA" },
];

/* ---------- TOUCH ENGINE: edge-node DB readouts ---------- */
const TOUCH_KPIS = [
  { k: "EDGE NODES", v: "30,412", note: "online · 47 regions" },
  { k: "LOOKUP", v: "4ms", note: "p99 · cross-region" },
  { k: "INDEX", v: "142 PB", note: "queryable · live" },
  { k: "SYNC", v: "<80ms", note: "global mesh convergence" },
];

Object.assign(window, {
  STORIES, STORY_TAGS, NAV_ITEMS, TICKER_ITEMS, NETWORK_NODES,
  SERVICES, INQUIRY_PANEL,
  VERTICALS, HERO_META, TOUCH_KPIS,
});
