stonks-oracle/.kiro/specs/intelligence-pipeline-v3/tasks.md

Implementation Plan: Intelligence Pipeline v3

Overview

Replace the monolithic 9B model extraction pipeline with a staged, evidence-grounded multi-component architecture. CPU-first specialist services handle routine extraction, sentiment, novelty, and calibration while the existing 9B vLLM model is preserved for semantic adjudication of ambiguous cases. A capability-aware inference gateway replaces duplicated provider branches, a stock-specific impact model replaces generative self-scores, and a full shadow/canary promotion process ensures measured improvement before production influence.

Tasks

• 1. Rotate exposed credentials

  • 1.1 Identify every live or reusable credential in infra/helm/stonks-oracle/values-live-math.yaml and any other tracked files
  • 1.2 Rotate database, MinIO/object-store, Redis, broker, and market-data credentials
  • 1.3 Disable the replaced keys and review relevant access logs
  • 1.4 Remove plaintext values from the working tree without copying them into issues, PRs, logs, or spec comments
  • 1.5 Purge the values from Git history using an approved coordinated history rewrite
  • 1.6 Verify that old credentials no longer authenticate
  • Requirements: 1.1, 1.2, 1.6

• 2. Add managed secret delivery

  • 2.1 Select External Secrets, SOPS, Sealed Secrets, or the cluster-standard mechanism
  • 2.2 Replace Helm secret values with secret references
  • 2.3 Document bootstrap and rotation procedures
  • 2.4 Add a deployment test proving pods receive required keys without values appearing in rendered manifests
  • Requirements: 1.3, 1.6

• 3. Add repository secret scanning

  • 3.1 Add a secret scanner to pre-commit or Kiro hooks
  • 3.2 Add the scanner to pull-request and protected-branch CI
  • 3.3 Add tests/fixtures that prove real-looking secrets fail and explicit safe fixtures pass
  • Requirements: 1.4, 1.5

• 4. Establish the current runtime source of truth

  • 4.1 Inventory active cluster deployments, agent database records, Helm releases, and environment variables
  • 4.2 Record the actual model, quantization, vLLM version, max model length, max sequences, GPU utilization limit, and current provider for every agent
  • 4.3 Resolve the conflicting Qwen/NuExtract defaults in code and infrastructure for the baseline branch
  • 4.4 Produce docs/intelligence-pipeline-v3/current-runtime-baseline.md without credentials
  • Requirements: 3.9

• 5. Build a baseline replay command

  • 5.1 Add a CLI that replays a fixed document set through the current pipeline without writing trading outputs
  • 5.2 Capture structured output, schema validity, retries, duration, token usage, GPU metrics, provider/model lineage, and current downstream mappings
  • 5.3 Pin all baseline configuration and random seeds that the provider supports
  • 5.4 Store baseline reports under a versioned artifact path
  • Requirements: 16.2, 16.3

• 6. Define the v3 annotation schema

  • 6.1 Define labels for entities, canonical companies, events, relations, numeric facts, periods, sentiment, evidence spans, direct effects, inferred exposure, and ambiguity
  • 6.2 Define evidence and adjudication guidelines with positive and negative examples
  • 6.3 Define which fields are safety-critical for promotion gates
  • 6.4 Add schema validators and sample annotations
  • Requirements: 16.1, 16.4

• 7. Create the first Gold Corpus

  • 7.1 Sample at least 1,000 documents stratified by type, event class, length, source, company count, and difficulty
  • 7.2 Include duplicate stories, long filings, transcripts, contradictory reports, macro events, and opposing multi-company effects
  • 7.3 Double-review a hard-case subset and calculate inter-annotator agreement
  • 7.4 Freeze a holdout split that cannot be used for prompt or model tuning
  • Requirements: 16.1

• 8. Implement evaluation metrics

  • 8.1 Implement entity/ticker precision, recall, F1, and ambiguity accuracy
  • 8.2 Implement event and relation macro/micro F1
  • 8.3 Implement numeric exact/tolerance-aware matching
  • 8.4 Implement evidence offset validity and support rate
  • 8.5 Implement sentiment macro-F1 and probability calibration metrics
  • 8.6 Implement latency, throughput, token, CPU, GPU, and memory metrics
  • 8.7 Generate per-document-type and per-difficulty reports
  • Requirements: 16.3, 16.4

• 9. Benchmark corrected current-model extraction

  • 9.1 Run the current request unchanged
  • 9.2 Run the same 9B model with temperature zero
  • 9.3 Run the same 9B model with strict JSON Schema output and temperature zero
  • 9.4 Quantify how much of the apparent architecture gain comes from fixing the current request alone
  • Requirements: 16.2, 16.3, 16.5

• 10. Add shared inference domain models

  • 10.1 Create services/shared/inference/models.py with capabilities, target, request, result, usage, and lineage types
  • 10.2 Create normalized error categories for timeout, authentication, rate limit, server, invalid response, schema, capability, and policy failures
  • 10.3 Add serialization tests proving credentials and sensitive headers are excluded
  • Requirements: 2.1, 2.8, 2.9

• 11. Implement OpenAICompatibleClient

  • 11.1 Implement /v1/chat/completions using httpx.AsyncClient
  • 11.2 Implement Bearer and configurable authentication headers via runtime secret resolution
  • 11.3 Implement standard response_format.json_schema payloads
  • 11.4 Implement configurable vLLM structured_outputs extra-body payloads
  • 11.5 Implement explicit JSON-object and prompt-only fallback policies
  • 11.6 Capture request ID, usage, finish reason, structured mode, retries, and provider error category
  • 11.7 Revalidate parsed JSON locally against the supplied schema
  • 11.8 Add contract tests against a mocked compatible server and the cluster vLLM deployment
  • Requirements: 2.1, 2.2, 2.3, 2.4, 2.5, 2.7, 2.9

• 12. Refactor Ollama support into OllamaNativeClient

  • 12.1 Move current Ollama request logic behind the shared request/result types
  • 12.2 Honor configured max output tokens and context settings consistently
  • 12.3 Preserve native schema formatting when supported and explicitly report prompt-only mode otherwise
  • 12.4 Retain stall/loop detection as Ollama-specific policy without leaking it into the generic protocol
  • Requirements: 2.1, 2.6

• 13. Implement capability probing

  • 13.1 Probe health and model listing
  • 13.2 Probe strict JSON Schema with a minimal schema
  • 13.3 Probe usage metadata, seed behavior, and output-token field compatibility
  • 13.4 Store probe results and software/version metadata with TTL
  • 13.5 Refuse activation when declared required capabilities fail
  • Requirements: 2.10, 2.11

• 14. Replace provider fallback behavior

  • 14.1 Replace VLLMClient with an alias/profile using OpenAICompatibleClient
  • 14.2 Make unknown providers a typed configuration error
  • 14.3 Add migration warnings for vllm provider records
  • 14.4 Add property tests proving unknown providers never invoke Ollama
  • Requirements: 2.2, 2.6

• 15. Migrate all LLM consumers

  • 15.1 Migrate document extraction
  • 15.2 Migrate global event classification
  • 15.3 Migrate thesis rewriting and remove duplicate provider branching
  • 15.4 Replace direct/private _config mutation with an explicit target refresh or client-pool lifecycle
  • 15.5 Fix persistence so actual endpoint, model, and route lineage are recorded
  • Requirements: 2.12, 13.6

• 16. Add registry migrations

  • 16.1 Create inference_endpoints
  • 16.2 Create model_deployments
  • 16.3 Create agent_stage_bindings
  • 16.4 Add revision, audit, uniqueness, and enabled-state constraints
  • 16.5 Add additive lineage columns/tables for existing performance logs
  • Requirements: 3.1, 3.2, 3.3, 3.4

• 17. Implement registry resolver

  • 17.1 Resolve active stage bindings with TTL caching
  • 17.2 Invalidate cache on revisions and failed probes
  • 17.3 Resolve authentication only at invocation time
  • 17.4 Add deterministic resolution and fail-closed tests
  • Requirements: 3.5, 3.9

• 18. Migrate existing provider records

  • 18.1 Create the current Ollama endpoint profile if in use
  • 18.2 Create the current vLLM OpenAI-compatible endpoint profile
  • 18.3 Create model deployments matching actual runtime state
  • 18.4 Convert agent and variant provider/model fields to stage bindings while retaining compatibility reads
  • 18.5 Remove conflicting runtime model defaults after migration verification
  • Requirements: 3.8, 3.9

• 19. Add endpoint API and UI

  • 19.1 Add CRUD endpoints that never return secret values
  • 19.2 Add probe, enable, disable, and test-structured-output actions
  • 19.3 Replace free-text provider inputs with protocol, endpoint, and model-deployment selectors
  • 19.4 Display last probe, capabilities, model limits, and active stage bindings
  • 19.5 Require confirmation for external endpoint egress enablement
  • Requirements: 3.6, 3.7

• 20. Add v3 persistence tables

  • 20.1 Add pipeline runs and stage runs
  • 20.2 Add document chunks and evidence spans
  • 20.3 Add extracted entities, facts, relations, and rejected candidates
  • 20.4 Add company signal candidates and probability distributions
  • 20.5 Add adjudication decisions, routing reasons, calibration references, and model lineage
  • 20.6 Add idempotency and immutable-revision constraints
  • Requirements: 13.1, 13.2, 13.3

• 21. Implement sentence-aware segmenter

  • 21.1 Preserve source offsets and checksums
  • 21.2 Add document-type-specific chunk strategies
  • 21.3 Preserve filing sections and transcript speakers
  • 21.4 Mark boilerplate and duplicate chunks
  • 21.5 Remove the 8,000-character truncation from v3
  • 21.6 Add property tests proving every chunk/evidence span maps exactly to source text
  • Requirements: 4.1, 4.2, 4.3, 4.4, 4.5, 4.6

• 22. Implement compatibility adapter skeleton

  • 22.1 Map approved v3 records to current intelligence and impact data classes
  • 22.2 Persist hybrid lineage plus stage details
  • 22.3 Add golden mapping tests for every legacy enum and field range
  • 22.4 Keep adapter output disabled outside replay/shadow mode
  • Requirements: 13.4, 13.5, 18.2

• 23. Implement deterministic financial parsing

  • 23.1 Parse tickers, currencies, money, percentages, basis points, ranges, EPS, revenue, dates, and fiscal periods
  • 23.2 Store literal and normalized representations
  • 23.3 Link each candidate to exact offsets
  • 23.4 Add broad property tests for numeric formatting and unit conversions
  • Requirements: 5.1, 5.7, 5.8

• 24. Integrate symbol registry resolution

  • 24.1 Build canonical alias indexes from existing companies and symbol registry data
  • 24.2 Return ranked candidates and ambiguity margins
  • 24.3 Separate explicit mentions from inferred exposures
  • 24.4 Preserve unresolved literal entities without invented tickers
  • 24.5 Add tests for aliases shared by multiple companies
  • Requirements: 5.2, 5.3, 5.4, 5.5, 5.6

• 25. Create specialist inference service

  • 25.1 Add typed batch endpoints for entities, classification, relations, and structured extraction
  • 25.2 Integrate pinned GLiNER2 Large as the initial candidate
  • 25.3 Return spans, scores, model version, and schema version
  • 25.4 Add bounded dynamic batching and warm-up
  • 25.5 Add Kubernetes CPU deployment, health probes, and metrics
  • 25.6 Add contract and load tests
  • Requirements: 6.1, 6.2, 6.3, 6.4, 6.5, 6.7, 6.9

• 26. Integrate company-specific sentiment

  • 26.1 Build company-linked evidence groups
  • 26.2 Integrate pinned FinBERT baseline
  • 26.3 Store full probability distributions and evidence IDs
  • 26.4 Implement mixed sentiment from evidence-group disagreement
  • 26.5 Benchmark and calibrate on the Gold_Corpus
  • Requirements: 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7

• 27. Benchmark NuExtract 1.5 Smol

  • 27.1 Add an isolated adapter and CPU/on-demand deployment
  • 27.2 Test hierarchical extraction on long filings and transcripts
  • 27.3 Measure incremental correctness over GLiNER2 plus deterministic parsing
  • 27.4 Measure CPU latency and memory
  • 27.5 Promote it only for document classes where incremental value passes a predefined gate
  • Requirements: 6.6

• 28. Add evidence verification

  • 28.1 Validate offsets, source text, entity association, and numeric consistency
  • 28.2 Add rejected-candidate storage and reason codes
  • 28.3 Benchmark a compact entailment verifier on claims exact matching cannot validate
  • 28.4 Add unsupported-claim and evidence-coverage metrics
  • Requirements: 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7

• 29. Implement retrieval-based novelty

  • 29.1 Add exact and near-duplicate fingerprints
  • 29.2 Add replaceable compact embedding backend
  • 29.3 Index document and canonical company-event embeddings
  • 29.4 Return nearest matches and similarity scores
  • 29.5 Implement and version the novelty formula
  • 29.6 Compare novelty values against human duplicate/novelty labels
  • Requirements: 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7

• 30. Build confidence feature pipeline

  • 30.1 Compute field-level features from extraction, resolution, evidence, sentiment, and agreement
  • 30.2 Train and compare calibration methods on training folds
  • 30.3 Evaluate ECE and Brier score on held-out data
  • 30.4 Version and load calibration artifacts
  • 30.5 Define conservative defaults for underrepresented classes
  • Requirements: 10.1, 10.2, 10.3, 10.4, 10.6, 10.7

• 31. Implement deterministic routing engine

  • 31.1 Define routing reason enums
  • 31.2 Implement hard ambiguity/conflict rules
  • 31.3 Implement calibrated fast-path thresholds by document and event type
  • 31.4 Store every route decision and feature snapshot
  • 31.5 Add property tests for determinism and threshold boundaries
  • Requirements: 10.5, 11.6

• 32. Define adjudication schemas

  • 32.1 Define candidate, conflict, question, evidence, and decision models
  • 32.2 Exclude authoritative confidence, novelty, impact, and horizon from the model output
  • 32.3 Require evidence IDs for every material decision
  • Requirements: 11.2, 11.5, 11.7

• 33. Build focused adjudication prompts

  • 33.1 Build packets from only relevant chunks and candidates
  • 33.2 Use strict JSON Schema and temperature zero
  • 33.3 Set a bounded output budget appropriate to decisions rather than long summaries
  • 33.4 Add prompt/version metadata and exact provider lineage
  • Requirements: 11.2, 11.3, 11.4

• 34. Deploy and validate the 9B adjudicator

  • 34.1 Pin the approved 9B model and vLLM version
  • 34.2 Verify strict structured output with the deployment's actual vLLM version
  • 34.3 Measure peak VRAM against the current baseline and enforce the +5 percent gate
  • 34.4 Load-test concurrency and select a safe application semaphore
  • 34.5 Add availability and queue-depth alerts
  • Requirements: 11.1, 11.10

• 35. Add post-adjudication verification

  • 35.1 Verify every referenced evidence ID was included in the packet
  • 35.2 Reject unsupported or schema-incompatible decisions
  • 35.3 Preserve both pre-adjudication candidates and final decisions
  • 35.4 Route repeated failures to review rather than accepting repaired defaults
  • Requirements: 11.8, 8.7

• 36. Define event-time feature snapshots

  • 36.1 Define feature names, types, timing rules, and missing-value policy
  • 36.2 Include event, sentiment, magnitude, surprise, source, novelty, evidence, company, volatility, volume, and regime features
  • 36.3 Persist immutable feature snapshots at prediction time
  • 36.4 Add leakage tests preventing post-event data from entering features
  • Requirements: 12.2, 12.10

• 37. Build outcome labels

  • 37.1 Define approved market benchmarks and abnormal-return calculations
  • 37.2 Generate signed and absolute response labels for intraday, 1d, 7d, 30d, and 90d horizons
  • 37.3 Generate abnormal-volume and time-to-peak labels where data quality permits
  • 37.4 Version label-generation code and market-data snapshots
  • Requirements: 12.3

• 38. Implement deterministic impact baseline

  • 38.1 Map event classes, sentiment, magnitude, evidence, novelty, and source credibility to conservative outputs
  • 38.2 Unit-test every event type and boundary
  • 38.3 Use this baseline whenever no approved trained model exists
  • Requirements: 12.4, 12.8

• 39. Train calibrated tabular impact models

  • 39.1 Train CPU-efficient gradient-boosted candidates for direction, magnitude, and horizon
  • 39.2 Use walk-forward/out-of-time splits
  • 39.3 Calibrate probabilities on a separate calibration fold
  • 39.4 Report metrics by event, sector, market cap, source, and regime
  • 39.5 Register artifacts, feature versions, training ranges, and model cards
  • Requirements: 12.4, 12.5, 12.6, 12.10

• 40. Integrate impact outputs

  • 40.1 Store full direction, magnitude, horizon, and uncertainty outputs
  • 40.2 Map approved outputs to legacy impact_score and impact_horizon through the compatibility adapter
  • 40.3 Remove generative impact/novelty/confidence from aggregation inputs in v3 mode
  • 40.4 Add comparison dashboards against realized outcomes
  • Requirements: 12.1, 12.7, 12.9

• 41. Implement v3 pipeline orchestrator

  • 41.1 Create explicit stage state transitions and idempotency keys
  • 41.2 Add fast-path, adjudication, persistence, and review queues
  • 41.3 Implement leases, retry policies, dead-letter handling, and resumable stages
  • 41.4 Keep v2 and v3 routing behind independent feature flags
  • Requirements: 14.1, 14.2, 14.5, 14.8

• 42. Add bounded application parallelism

  • 42.1 Replace the single sequential extraction loop for v3 with configurable async workers
  • 42.2 Add specialist micro-batching
  • 42.3 Add adjudicator semaphore and queue backpressure
  • 42.4 Add load shedding rules that never drop safety-critical documents silently
  • Requirements: 14.1, 14.3, 14.4, 14.5

• 43. Add traces and metrics

  • 43.1 Trace every stage under one document trace ID
  • 43.2 Add stage latency, errors, batch size, queue depth, and route metrics
  • 43.3 Add field accuracy, evidence coverage, calibration, fast-path rate, and adjudication reason dashboards
  • 43.4 Add GPU memory, utilization, and GPU-seconds per document
  • 43.5 Add alerts for schema failures, unsupported claims, calibration drift, queue saturation, and provider probe failures
  • Requirements: 14.7, 15.1, 15.2, 15.5

• 44. Add audit/review API and UI

  • 44.1 Display source evidence and offsets for each fact
  • 44.2 Display specialist probabilities, routing reasons, adjudicator decisions, and impact-model outputs separately
  • 44.3 Allow immutable reviewer correction events
  • 44.4 Add filters for low confidence, unsupported claims, and adjudicated documents
  • Requirements: 15.3, 15.4, 15.6, 15.7

• 45. Run offline replay

  • 45.1 Compare every required system configuration on the Gold_Corpus
  • 45.2 Publish field-level, calibration, resource, and difficulty-bucket reports
  • 45.3 Confirm corrected current-9B baseline versus full v3 incremental gain
  • 45.4 Reject or retune any stage failing safety-critical gates
  • Requirements: 16.2, 16.3, 16.4, 16.5

• 46. Enable production shadow mode

  • 46.1 Run v3 for live documents without affecting aggregation or trading
  • 46.2 Compare v2/v3 disagreements and sample reviews by risk
  • 46.3 Measure fast-path coverage, GPU reduction, and operational stability
  • 46.4 Require the configured minimum shadow duration and document count
  • Requirements: 16.6, 16.7, 16.8

• 47. Canary compatibility outputs

  • 47.1 Enable v3 adapter outputs for non-trading consumers first
  • 47.2 Add percentage- and document-type-based routing
  • 47.3 Configure automatic rollback on correctness, latency, queue, or availability thresholds
  • 47.4 Verify rollback leaves v3 audit records intact
  • Requirements: 16.9, 18.4, 18.5

• 48. Canary signal influence

  • 48.1 Enable v3 signals in paper trading at a small percentage
  • 48.2 Report extraction correctness separately from trading outcomes
  • 48.3 Review material recommendation divergences
  • 48.4 Promote only after explicit owner approval and all gates pass
  • Requirements: 16.9, 16.10

• 49. Build active-learning export

  • 49.1 Select low-confidence, conflicting, adjudicated, and corrected cases
  • 49.2 Remove or policy-filter sensitive content
  • 49.3 Export source spans, labels, relations, decisions, and provenance in a versioned format
  • Requirements: 17.1, 17.2

• 50. Fine-tune specialist extractor

  • 50.1 Train GLiNER2 candidate artifacts on the Stonks Oracle schema
  • 50.2 Evaluate against frozen holdout and production artifact
  • 50.3 Calibrate new scores and update routing thresholds
  • 50.4 Promote only when correctness gates pass, not merely when adjudication rate falls
  • Requirements: 17.3, 17.4, 17.5, 17.6

• 51. Deprecate legacy paths

  • 51.1 Remove duplicated VLLMClient/provider branching after all consumers use the gateway
  • 51.2 Remove v2 8,000-character truncation and monolithic extraction prompt after v2 retirement
  • 51.3 Remove obsolete environment/model defaults and provider free-text fields
  • 51.4 Remove compatibility adapter only after every downstream consumer reads v3 natively
  • 51.5 Archive final migration and benchmark reports
  • Requirements: 18.6

• 52. Checkpoint — Ensure all tests pass

  • Ensure all tests pass, ask the user if questions arise.

Task Dependency Graph

{
  "waves": [
    { "id": 0, "tasks": ["1.1", "1.2", "1.3", "1.4", "1.5", "1.6", "2.1", "2.2", "2.3", "2.4", "3.1", "3.2", "3.3", "4.1", "4.2", "4.3", "4.4", "5.1", "5.2", "5.3", "5.4"] },
    { "id": 1, "tasks": ["6.1", "6.2", "6.3", "6.4", "7.1", "7.2", "7.3", "7.4", "8.1", "8.2", "8.3", "8.4", "8.5", "8.6", "8.7", "9.1", "9.2", "9.3", "9.4"] },
    { "id": 2, "tasks": ["10.1", "10.2", "10.3", "11.1", "11.2", "11.3", "11.4", "11.5", "11.6", "11.7", "11.8", "12.1", "12.2", "12.3", "12.4"] },
    { "id": 3, "tasks": ["13.1", "13.2", "13.3", "13.4", "13.5", "14.1", "14.2", "14.3", "14.4", "15.1", "15.2", "15.3", "15.4", "15.5", "16.1", "16.2", "16.3", "16.4", "16.5"] },
    { "id": 4, "tasks": ["17.1", "17.2", "17.3", "17.4", "18.1", "18.2", "18.3", "18.4", "18.5", "19.1", "19.2", "19.3", "19.4", "19.5", "20.1", "20.2", "20.3", "20.4", "20.5", "20.6", "21.1", "21.2", "21.3", "21.4", "21.5", "21.6", "22.1", "22.2", "22.3", "22.4"] },
    { "id": 5, "tasks": ["23.1", "23.2", "23.3", "23.4", "24.1", "24.2", "24.3", "24.4", "24.5", "25.1", "25.2", "25.3", "25.4", "25.5", "25.6", "26.1", "26.2", "26.3", "26.4", "26.5", "27.1", "27.2", "27.3", "27.4", "27.5", "28.1", "28.2", "28.3", "28.4"] },
    { "id": 6, "tasks": ["29.1", "29.2", "29.3", "29.4", "29.5", "29.6", "30.1", "30.2", "30.3", "30.4", "30.5", "31.1", "31.2", "31.3", "31.4", "31.5"] },
    { "id": 7, "tasks": ["32.1", "32.2", "32.3", "33.1", "33.2", "33.3", "33.4", "34.1", "34.2", "34.3", "34.4", "34.5", "35.1", "35.2", "35.3", "35.4"] },
    { "id": 8, "tasks": ["36.1", "36.2", "36.3", "36.4", "37.1", "37.2", "37.3", "37.4", "38.1", "38.2", "38.3", "39.1", "39.2", "39.3", "39.4", "39.5", "40.1", "40.2", "40.3", "40.4"] },
    { "id": 9, "tasks": ["41.1", "41.2", "41.3", "41.4", "42.1", "42.2", "42.3", "42.4", "43.1", "43.2", "43.3", "43.4", "43.5", "44.1", "44.2", "44.3", "44.4"] },
    { "id": 10, "tasks": ["45.1", "45.2", "45.3", "45.4", "46.1", "46.2", "46.3", "46.4", "47.1", "47.2", "47.3", "47.4", "48.1", "48.2", "48.3", "48.4"] },
    { "id": 11, "tasks": ["49.1", "49.2", "49.3", "50.1", "50.2", "50.3", "50.4", "51.1", "51.2", "51.3", "51.4", "51.5"] }
  ]
}

Notes

• This plan is intentionally staged so the current system remains available until the replacement is measured and promoted
• Task 1 (credential rotation) is a BLOCKER — must complete before any feature deployment
• Tasks within the same wave may run in parallel; tasks in later waves depend on earlier waves completing
• Each phase ends with an explicit evidence artifact: test output, benchmark report, migration result, or deployment probe
• The current v2 extractor remains available behind a feature flag until v3 completes shadow and canary promotion
• Peak GPU memory must not exceed the measured current 9B deployment baseline by more than 5 percent
• The definition of done requires: credentials rotated, all consumers on shared gateway, evidence-linked outputs, calibrated scores replacing generative self-scores, 9B preserved for adjudication, and shadow/canary gates passed
• Rollback to the current production path must be exercised successfully before full promotion
• Property tests validate deterministic behaviors (unknown providers fail closed, chunk offsets map to source, routing thresholds are deterministic)
• Deprecated legacy paths (task 51) require separate approval and must not proceed until all downstream consumers read v3 natively