@zigrivers/scaffold 3.28.0 → 3.29.0

package/content/knowledge/ml/ml-experiment-tracking.md

@@ -2,6 +2,12 @@
 name: ml-experiment-tracking
 description: MLflow and Weights & Biases integration, artifact storage, experiment run comparison, and hyperparameter sweep management
 topics: [ml, experiment-tracking, mlflow, wandb, artifacts, sweeps, reproducibility]
+volatility: fast-moving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://mlflow.org/docs/latest/index.html
+  - url: https://docs.wandb.ai/
 ---
 
 Without experiment tracking, ML development is archaeology: "which config produced that result?" is answered by digging through notebook history, chat logs, and failing memory. Experiment tracking tools are version control for training runs — every metric, every hyperparameter, every artifact, linked to the code that produced it. The discipline of logging everything during training pays dividends when a stakeholder asks "how does this model compare to what we had six months ago?"

package/content/knowledge/ml/ml-model-evaluation.md

@@ -2,6 +2,10 @@
 name: ml-model-evaluation
 description: Train/val/test splits, cross-validation, metrics by task type, holdout sets, and slice analysis for thorough model evaluation
 topics: [ml, evaluation, train-test-split, cross-validation, metrics, holdout, slice-analysis]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Model evaluation is the difference between knowing whether your model works and believing it works. Most ML evaluation bugs are forms of data leakage: the model has seen information during training that it would not have at inference time, making offline metrics look better than production performance. Rigorous evaluation requires careful data splitting, leak-free preprocessing, appropriate metrics for the task, and systematic analysis of where the model fails.

package/content/knowledge/ml/ml-observability.md

@@ -2,6 +2,11 @@
 name: ml-observability
 description: Model monitoring for drift and decay, prediction logging, explainability tools, and alerting on accuracy drops in production ML systems
 topics: [ml, observability, monitoring, drift, model-decay, explainability, alerting, prediction-logging]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://opentelemetry.io/docs/
 ---
 
 A model deployed to production without monitoring is a ticking clock. Models decay silently: the world changes, input distributions shift, and accuracy degrades while dashboards show green. Unlike software bugs that throw exceptions, model degradation has no stack trace — predictions simply become less useful. ML observability is the discipline of detecting these degradations before users notice them, through systematic monitoring of model inputs, outputs, and outcomes.

package/content/knowledge/ml/ml-project-structure.md

@@ -2,6 +2,10 @@
 name: ml-project-structure
 description: Standard ML project directory layout covering src/data, src/models, src/training, src/serving, notebooks, configs, and model artifact storage
 topics: [ml, project-structure, layout, organization, artifacts, notebooks]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 ML projects accumulate files faster than almost any other software domain: datasets, model checkpoints, experiment configs, notebooks, evaluation reports, and serving code. Without a deliberate directory structure, projects become disorganised within weeks and impossible to onboard new team members onto. A well-structured ML project separates concerns clearly: source code from notebooks, training from serving, configs from code, and tracked artifacts from ephemeral outputs.

package/content/knowledge/ml/ml-requirements.md

@@ -2,6 +2,10 @@
 name: ml-requirements
 description: Model performance metrics (accuracy, latency, throughput), business KPIs, fairness/bias requirements, and SLA definitions for ML systems
 topics: [ml, requirements, metrics, fairness, bias, sla, kpi]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 ML requirements differ from traditional software requirements because correctness is probabilistic, not absolute. Before writing a single line of training code, define the target metrics, their measurement methodology, and the business KPIs they serve. Ambiguous requirements — "make the model accurate" — are the root cause of most ML project failures. A requirements document for an ML system must specify numeric thresholds, measurement conditions, and what constitutes an acceptable production deployment.

package/content/knowledge/ml/ml-security.md

@@ -2,6 +2,11 @@
 name: ml-security
 description: ML-specific threats including adversarial attacks and data poisoning, PII handling in training data, model IP protection, and access control for ML systems
 topics: [ml, security, adversarial-attacks, data-poisoning, pii, model-ip, access-control]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://owasp.org/www-project-machine-learning-security-top-10/
 ---
 
 ML systems introduce a new class of security threats that traditional application security does not address. A model trained on poisoned data may behave normally on most inputs but trigger on specific attacker-controlled patterns. A model served via API leaks information about its training data to membership inference attacks. These are not theoretical — they are exploited in production systems. ML security requires defence-in-depth across the data pipeline, training process, and serving infrastructure.

package/content/knowledge/ml/ml-serving-patterns.md

@@ -2,6 +2,10 @@
 name: ml-serving-patterns
 description: Model serving with TorchServe, Triton, and BentoML; batch vs realtime inference patterns; A/B testing and canary deployment strategies
 topics: [ml, serving, torchserve, triton, bentoml, inference, ab-testing, canary, deployment]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Model serving is where ML meets production software engineering. A model that performs well in a notebook is worthless if it cannot serve predictions reliably at scale. Serving patterns address the gap between "it works on my machine" and "it handles 10,000 requests per second with P99 < 100ms and zero data races." The serving layer must be treated with the same engineering rigour as any production microservice.

package/content/knowledge/ml/ml-testing.md

@@ -2,6 +2,10 @@
 name: ml-testing
 description: Unit tests for data transforms, tolerance-based model tests, pipeline integration tests, and regression tests for ML systems
 topics: [ml, testing, unit-tests, model-tests, pipeline-tests, regression-tests, tdd]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 ML code is tested less rigorously than traditional software because "the model is probabilistic" feels like an excuse for skipping tests. It is not. The vast majority of ML code — data transforms, preprocessing, feature engineering, postprocessing, and serving logic — is deterministic and must be unit tested. The probabilistic parts — model weights and accuracy — require tolerance-based tests and regression baselines. Untested ML pipelines fail silently in ways that are expensive to diagnose in production.

package/content/knowledge/ml/ml-training-patterns.md

@@ -2,6 +2,10 @@
 name: ml-training-patterns
 description: Data loaders, training loops, distributed training with DDP and FSDP, checkpointing strategies, and hyperparameter tuning patterns
 topics: [ml, training, data-loaders, distributed-training, ddp, fsdp, checkpointing, hyperparameter-tuning]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 The training loop is the heart of every ML project, but it is also where most bugs hide: data leaking between splits, gradients not zeroed, mixed precision overflows, checkpoints saved incorrectly, and distributed training hanging on a single slow worker. These are not exotic edge cases — they are the standard bugs that every ML engineer encounters. A well-structured training pipeline prevents them through clear separation of concerns and defensive coding.

package/content/knowledge/mobile-app/mobile-app-architecture.md

@@ -2,6 +2,12 @@
 name: mobile-app-architecture
 description: MVVM/MVI/TCA patterns, navigation architecture, dependency injection, and state management for iOS and Android mobile apps
 topics: [mobile-app, architecture, mvvm, mvi, tca, navigation, dependency-injection, state-management]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/documentation/swiftui
+  - url: https://developer.android.com/topic/architecture
 ---
 
 Mobile app architecture determines testability, scalability, and developer velocity. The wrong architecture is expensive to reverse — a monolithic ViewController or God Activity becomes unmaintainable at scale. Both iOS and Android ecosystems have converged on unidirectional data flow patterns: TCA and MVVM+Combine/async for iOS, MVI and MVVM+Flow for Android. Choose the pattern that matches your team's size and complexity requirements, not the most sophisticated available option.

package/content/knowledge/mobile-app/mobile-app-conventions.md

@@ -2,6 +2,12 @@
 name: mobile-app-conventions
 description: Platform naming conventions, accessibility patterns, navigation patterns, and code style for iOS and Android mobile apps
 topics: [mobile-app, conventions, swift, kotlin, naming, accessibility, navigation]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/design/human-interface-guidelines
+  - url: https://developer.android.com/design
 ---
 
 Mobile platform conventions exist for consistency across the ecosystem, toolchain compatibility, and team readability. iOS and Android have distinct naming conventions, navigation paradigms, and accessibility implementation patterns. Mixing conventions or importing web/backend naming styles into mobile code creates cognitive friction and breaks tooling assumptions (SwiftUI previews, Android Studio refactoring, lint rules).

package/content/knowledge/mobile-app/mobile-app-deployment.md

@@ -2,6 +2,12 @@
 name: mobile-app-deployment
 description: App store submission, code signing, provisioning profiles, CI/CD with Fastlane, and release management for iOS and Android
 topics: [mobile-app, deployment, app-store, google-play, code-signing, fastlane, ci-cd, release-management]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/app-store/review/guidelines/
+  - url: https://developer.android.com/studio/publish
 ---
 
 Mobile app deployment is significantly more complex than web deployment: code signing creates a cryptographic chain of trust, app store review is a human process with 24–48 hour latency, and binary deployment means bugs cannot be hot-patched without a full submission cycle. Automate as much of this as possible with Fastlane — manual signing and upload processes are error-prone and do not scale to frequent releases.

package/content/knowledge/mobile-app/mobile-app-dev-environment.md

@@ -2,6 +2,12 @@
 name: mobile-app-dev-environment
 description: Simulator and emulator setup, physical device testing, hot reload, debugging tools, and developer toolchain for iOS and Android
 topics: [mobile-app, dev-environment, simulator, emulator, debugging, xcode, android-studio, hot-reload]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/documentation/xcode
+  - url: https://developer.android.com/studio/intro
 ---
 
 Mobile development environments are significantly more complex than web development: two IDEs, two simulators, hardware-specific debugging, code signing requirements, and platform SDK updates that break builds. A well-configured dev environment reduces friction by 50% — standardize tool versions, automate simulator setup, and document the steps from clean machine to first successful build.

package/content/knowledge/mobile-app/mobile-app-distribution.md

@@ -2,6 +2,12 @@
 name: mobile-app-distribution
 description: TestFlight and Google Play internal track, enterprise MDM distribution, staged rollouts, beta testing programs, and OTA updates for mobile apps
 topics: [mobile-app, distribution, testflight, google-play, enterprise-mdm, staged-rollout, beta-testing, ota]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/testflight/
+  - url: https://developer.android.com/distribute
 ---
 
 Mobile app distribution has more complexity than web deployment: app store review introduces unpredictable latency, staged rollouts require monitoring and rollback planning, enterprise distribution requires MDM infrastructure, and React Native/Expo apps have limited OTA update options for business logic. Design the distribution pipeline before writing code — it affects app architecture (feature flags, forced update logic) and CI/CD setup.

package/content/knowledge/mobile-app/mobile-app-observability.md

@@ -2,6 +2,13 @@
 name: mobile-app-observability
 description: Crash reporting (Crashlytics/Sentry), analytics, performance monitoring, network tracing, and structured logging for mobile apps
 topics: [mobile-app, observability, crashlytics, sentry, analytics, performance-monitoring, network-tracing, logging]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://opentelemetry.io/docs/
+  - url: https://developer.apple.com/documentation/metrickit
+  - url: https://developer.android.com/topic/performance
 ---
 
 Mobile observability is harder than server observability: you cannot SSH into a user's phone, crashes happen on thousands of device/OS combinations you cannot reproduce locally, and performance issues manifest differently across network conditions and hardware tiers. The goal is to know about problems before users report them, understand why they occurred, and have enough context to reproduce and fix them.

package/content/knowledge/mobile-app/mobile-app-offline-patterns.md

@@ -2,6 +2,13 @@
 name: mobile-app-offline-patterns
 description: Local storage (SQLite/Room/Core Data), sync engines, conflict resolution, and background sync for offline-capable mobile apps
 topics: [mobile-app, offline, sqlite, room, core-data, sync, conflict-resolution, background-sync]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/documentation/coredata
+  - url: https://developer.android.com/training/data-storage/room
+  - url: https://developer.android.com/topic/libraries/architecture/workmanager
 ---
 
 Offline capability is not optional for mobile apps — cellular networks are unreliable, users enter tunnels and basements, and users expect their data to persist between sessions. The complexity of offline architecture scales with sync complexity: read-only cache is trivial; bidirectional sync with conflict resolution is one of the hardest problems in software. Define your offline model explicitly before implementing persistence.

package/content/knowledge/mobile-app/mobile-app-project-structure.md

@@ -2,6 +2,12 @@
 name: mobile-app-project-structure
 description: Platform directory layout, shared code modules, asset management, and per-environment configuration for iOS and Android mobile apps
 topics: [mobile-app, project-structure, ios, android, assets, configuration, modules]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/documentation/xcode/managing-files-and-folders-in-your-xcode-project
+  - url: https://developer.android.com/studio/projects
 ---
 
 Mobile project structure decisions affect build times, code sharing, onboarding velocity, and refactoring safety. iOS and Android have platform-mandated directory conventions that tools expect — deviating from them breaks Xcode file resolution, Android Gradle source sets, and code-generation tooling. Within those constraints, module boundaries and shared-code strategies deserve explicit design.

package/content/knowledge/mobile-app/mobile-app-push-notifications.md

@@ -2,6 +2,12 @@
 name: mobile-app-push-notifications
 description: APNs and FCM setup, notification channels, rich notifications, background handling, and permission best practices for mobile apps
 topics: [mobile-app, push-notifications, apns, fcm, firebase, notification-channels, rich-notifications, background]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/documentation/usernotifications
+  - url: https://developer.android.com/develop/ui/views/notifications
 ---
 
 Push notifications are a direct channel to re-engage users, but they are also the fastest way to lose them: irrelevant or excessive notifications get disabled or trigger uninstalls. The technical implementation requires setting up APNs (Apple Push Notification service) for iOS and FCM (Firebase Cloud Messaging) for Android, managing device tokens, and handling notifications in all app states (foreground, background, terminated). Get the permission request timing right — it determines your opt-in rate.

package/content/knowledge/mobile-app/mobile-app-requirements.md

@@ -2,6 +2,13 @@
 name: mobile-app-requirements
 description: Platform guidelines (Apple HIG, Material Design), performance budgets, device matrix, and accessibility requirements for mobile apps
 topics: [mobile-app, requirements, hig, material-design, accessibility, performance, device-matrix]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/design/human-interface-guidelines
+  - url: https://developer.android.com/design
+  - url: https://www.w3.org/WAI/standards-guidelines/wcag/
 ---
 
 Mobile app requirements differ fundamentally from web requirements: platform guidelines are design law, not suggestions; performance budgets are stricter because CPU and battery are finite; accessibility is both a legal obligation and a market expansion. Define all of these explicitly before writing code — changing navigation patterns or accessibility models mid-project is expensive.

package/content/knowledge/mobile-app/mobile-app-security.md

@@ -2,6 +2,14 @@
 name: mobile-app-security
 description: Secure storage (Keychain/Keystore), certificate pinning, biometric authentication, jailbreak/root detection, and data protection for mobile apps
 topics: [mobile-app, security, keychain, keystore, certificate-pinning, biometrics, jailbreak-detection, data-protection]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://owasp.org/www-project-mobile-top-10/
+  - url: https://owasp.org/www-project-mobile-app-security/
+  - url: https://developer.apple.com/documentation/security/keychain_services
+  - url: https://developer.android.com/privacy-and-security/keystore
 ---
 
 Mobile apps operate in an adversarial environment: devices are lost or stolen, users jailbreak/root their devices, and network traffic is subject to interception. Security must be designed in, not bolted on. The most common mobile security failures are storing secrets in plaintext, trusting all TLS certificates (or disabling certificate validation), and failing to protect data at rest. Implement defense in depth — assume any single control will fail.

package/content/knowledge/mobile-app/mobile-app-testing.md

@@ -2,6 +2,12 @@
 name: mobile-app-testing
 description: Unit tests, UI tests (XCTest/Espresso/Detox), snapshot tests, accessibility testing, and test architecture for iOS and Android
 topics: [mobile-app, testing, xctest, espresso, detox, snapshot-testing, accessibility-testing, unit-tests]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/documentation/xctest
+  - url: https://developer.android.com/training/testing
 ---
 
 Mobile testing requires a multi-layer strategy: unit tests for business logic, integration tests for repository and network layers, UI tests for critical user flows, and snapshot tests for visual regression. The test pyramid applies — fast unit tests outnumber slow UI tests. Mobile UI tests are inherently fragile (timing, simulator state, animations) — structure them to minimize flakiness and run only the highest-value flows in CI.

package/content/knowledge/product/gap-analysis.md

@@ -2,6 +2,10 @@
 name: gap-analysis
 description: Systematic approaches to finding gaps in requirements and specifications
 topics: [gap-analysis, requirements, completeness, ambiguity, edge-cases]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Gap Analysis

package/content/knowledge/product/ideation-craft.md

@@ -2,6 +2,10 @@
 name: ideation-craft
 description: Questioning techniques, research methodology, lightweight expansion patterns, and brief synthesis for early-stage idea exploration
 topics: [ideation, questioning, research, competitive-analysis, brief-synthesis, socratic-method]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Ideation Craft

package/content/knowledge/product/prd-craft.md

@@ -2,6 +2,10 @@
 name: prd-craft
 description: What makes a good PRD — problem framing, feature scoping, success criteria, competitive context
 topics: [prd, requirements, product, scoping]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # PRD Craft

package/content/knowledge/product/prd-innovation.md

@@ -2,6 +2,10 @@
 name: prd-innovation
 description: Techniques for discovering feature-level innovation opportunities in product requirements
 topics: [innovation, prd, competitive-analysis, product-thinking, features]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # PRD Innovation

package/content/knowledge/product/vision-craft.md

@@ -2,6 +2,10 @@
 name: vision-craft
 description: What makes a good product vision — strategic framing, audience definition, competitive positioning, guiding principles
 topics: [vision, strategy, product, positioning, competitive-analysis]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Vision Craft

package/content/knowledge/product/vision-innovation.md

@@ -2,6 +2,10 @@
 name: vision-innovation
 description: Techniques for discovering strategic innovation opportunities in product vision
 topics: [innovation, vision, strategy, competitive-positioning, ecosystem, market-opportunities]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Vision Innovation

package/content/knowledge/research/research-architecture.md

@@ -2,6 +2,10 @@
 name: research-architecture
 description: Experiment runner architecture including pluggable experiment and evaluation interfaces, state management patterns, and result persistence
 topics: [research, architecture, experiment-runner, state-management, interfaces, persistence]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 The experiment runner is the central architectural component of a research project. It orchestrates the loop of loading configuration, executing experiments, evaluating results, and deciding whether to keep or discard each run. The runner must be completely decoupled from the specific experiment logic (strategies, models, parameter spaces) so that it can drive any experiment without modification. This separation is what makes autonomous iteration possible -- the agent modifies experiment code while the runner infrastructure remains stable.

package/content/knowledge/research/research-conventions.md

@@ -2,6 +2,12 @@
 name: research-conventions
 description: Coding conventions for research projects including experiment branching, result naming, config management, and reproducibility standards
 topics: [research, conventions, git, branching, reproducibility, config-management]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://the-turing-way.netlify.app/reproducible-research/reproducible-research.html
+  - url: https://git-scm.com/docs
 ---
 
 Research code has a unique lifecycle: most code is written to be tried and discarded. A trading strategy that underperforms is reverted. A hyperparameter sweep that converges to a local minimum is abandoned. The conventions must make this try-and-discard cycle fast and safe while preserving a complete audit trail of what was tried and why it was kept or discarded.

package/content/knowledge/research/research-dev-environment.md

@@ -2,6 +2,12 @@
 name: research-dev-environment
 description: Development tooling for research projects including virtual environments, dependency management, GPU setup, and data access configuration
 topics: [research, dev-environment, dependencies, virtual-env, gpu, data-access, tooling]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://docs.astral.sh/uv/
+  - url: https://the-turing-way.netlify.app/reproducible-research/renv.html
 ---
 
 Research dev environments have stricter reproducibility requirements than typical application development. A trading strategy that produces different results on a different machine is useless -- the environment itself is a variable that must be controlled. At the same time, research environments need flexibility for rapid iteration: installing new packages, switching between CPU and GPU, and accessing large datasets must be frictionless.

package/content/knowledge/research/research-experiment-loop.md

@@ -2,6 +2,10 @@
 name: research-experiment-loop
 description: Autonomous experiment loop patterns including hypothesis-execute-evaluate-keep/discard cycle, iteration control, budget management, and early stopping
 topics: [research, experiment-loop, autonomous, iteration, budget, early-stopping, hypothesis]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 The experiment loop is the defining pattern of research projects: an agent iteratively generates hypotheses, executes experiments, evaluates results, and makes keep/discard decisions. This loop can run autonomously (agent decides everything), with checkpoints (agent pauses for human review at intervals), or human-guided (human decides what to try, agent executes). The loop's correctness depends on proper iteration control, budget enforcement, and state management -- without these, autonomous agents will iterate forever or lose track of what has been tried.

package/content/knowledge/research/research-experiment-tracking.md

@@ -2,6 +2,12 @@
 name: research-experiment-tracking
 description: Experiment results logging including structured result formats, run comparison, reproducibility tracking, and artifact management
 topics: [research, experiment-tracking, results, comparison, reproducibility, artifacts, mlflow]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://mlflow.org/docs/latest/index.html
+  - url: https://the-turing-way.netlify.app/reproducible-research/reproducible-research.html
 ---
 
 Experiment tracking is the difference between research and random exploration. Without structured logging of what was tried, what resulted, and what was decided, a research project becomes impossible to audit, reproduce, or learn from. Tracking must capture the full context of every run: the exact config, the environment, the metrics, and the keep/discard decision with its rationale.

package/content/knowledge/research/research-ml-architecture-search.md

@@ -2,6 +2,10 @@
 name: research-ml-architecture-search
 description: Neural Architecture Search patterns including search space definition, search strategies, mutation operators, performance prediction, and multi-objective optimization
 topics: [research, ml-research, nas, architecture-search, search-space, evolutionary, darts, surrogate-model, multi-objective]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Neural Architecture Search (NAS) automates the discovery of model architectures that outperform hand-designed ones. The core challenge is navigating an exponentially large search space efficiently -- evaluating every candidate is infeasible, so search strategies must balance exploration (trying diverse architectures) with exploitation (refining promising ones). A well-designed NAS pipeline defines the search space precisely, applies an appropriate search strategy, uses performance prediction to avoid wasting compute on bad candidates, and manages the total search budget to stay within resource constraints.

package/content/knowledge/research/research-ml-evaluation.md

@@ -2,6 +2,10 @@
 name: research-ml-evaluation
 description: Research evaluation patterns including ablation studies, statistical significance testing, multiple comparison correction, effect sizes, learning curve analysis, and efficiency frontiers
 topics: [research, ml-research, evaluation, ablation, significance, bootstrap, bonferroni, effect-size, learning-curve, pareto]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Research evaluation differs fundamentally from production ML evaluation. In production, you measure a single model on held-out data and report aggregate metrics. In research, you compare multiple methods, ablate components to understand contributions, test whether differences are statistically significant rather than due to random variation, and characterize the efficiency frontier (what accuracy is achievable at what compute cost). Reporting a number without confidence intervals, without significance testing against baselines, and without ablations is not research evaluation -- it is anecdote.

package/content/knowledge/research/research-ml-experiment-tracking.md

@@ -2,6 +2,12 @@
 name: research-ml-experiment-tracking
 description: Lightweight experiment tracking for ML research including W&B and MLflow integration, experiment tagging, parallel coordinate plots, run comparison dashboards, and checkpoint strategies
 topics: [research, ml-research, experiment-tracking, wandb, mlflow, parallel-coordinates, checkpointing, comparison, tagging]
+volatility: fast-moving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://docs.wandb.ai/
+  - url: https://mlflow.org/docs/latest/index.html
 ---
 
 ML research experiment tracking prioritizes rapid iteration and comparison over production-grade audit trails. The goal is to answer "which of my 200 runs was best and why?" within seconds, not to maintain a production model registry. This means lightweight setup (local or cloud-hosted, not self-managed infrastructure), aggressive tagging and grouping for filtering, visualization tools that reveal patterns across many runs simultaneously, and checkpoint strategies that keep what matters and discard the rest to avoid filling storage with abandoned experiments.

package/content/knowledge/research/research-ml-training-patterns.md

@@ -2,6 +2,10 @@
 name: research-ml-training-patterns
 description: Training loop patterns for research iteration including fast-fail detection, curriculum exploration, hyperparameter-conditioned training, reproducibility seeding, and checkpoint warm-starting
 topics: [research, ml-research, training, fast-fail, curriculum, hyperparameter, reproducibility, checkpoint, warm-start]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Research training differs fundamentally from production training. In production, you train one model to convergence and ship it. In research, you train hundreds or thousands of configurations, most of which will fail -- the goal is to identify failures as early as possible and invest compute only in promising directions. A well-designed research training loop detects bad configurations within the first few percent of training, supports curriculum and schedule exploration without code changes, enables warm-starting from checkpoints to avoid redundant computation, and guarantees reproducibility so that any promising result can be verified.

package/content/knowledge/research/research-observability.md

@@ -2,6 +2,11 @@
 name: research-observability
 description: Monitoring experiment loops including anomaly detection, resource tracking, progress dashboards, and alert thresholds for research projects
 topics: [research, observability, monitoring, anomaly-detection, resource-tracking, dashboards, alerts]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://opentelemetry.io/docs/
 ---
 
 Autonomous experiment loops can run for hours or days without human attention. Without observability, a loop can waste compute on a converged metric, silently produce garbage after a data pipeline failure, or exhaust disk space without anyone noticing. Observability for research is not about uptime SLAs -- it is about experiment health: is the loop making progress, are the results valid, and are resources being consumed at a reasonable rate.

package/content/knowledge/research/research-overfitting-prevention.md

@@ -2,6 +2,11 @@
 name: research-overfitting-prevention
 description: Out-of-sample validation, cross-validation strategies, statistical significance testing, and when to stop iterating to prevent overfitting
 topics: [research, overfitting, validation, cross-validation, statistical-significance, out-of-sample]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://the-turing-way.netlify.app/reproducible-research/reproducible-research.html
 ---
 
 Overfitting is the central risk of iterative research. Every time an agent evaluates a hypothesis against data and uses the result to guide the next hypothesis, it is implicitly fitting to that data. After hundreds of iterations, even random strategies will appear to perform well on the evaluation set -- this is multiple comparisons bias. Preventing overfitting requires rigorous separation of training and evaluation data, statistical significance testing, and disciplined stopping criteria.

package/content/knowledge/research/research-project-structure.md

@@ -2,6 +2,11 @@
 name: research-project-structure
 description: Directory structure for research projects including src, experiments, results, configs, data, and notebooks organization
 topics: [research, project-structure, directory-layout, organization]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://the-turing-way.netlify.app/project-design/project-design.html
 ---
 
 Research projects have a dual structure that traditional software projects do not: a stable infrastructure layer (the experiment runner, evaluation framework, and data pipeline) and a volatile experiment layer (strategies, models, configs, and results) that changes with every iteration. The directory structure must make this distinction explicit so that the experiment loop can modify volatile files without risk of corrupting the infrastructure.

package/content/knowledge/research/research-quant-backtesting.md

@@ -2,6 +2,10 @@
 name: research-quant-backtesting
 description: Backtesting methodology including walk-forward analysis, look-ahead bias prevention, survivorship bias, transaction cost modeling, and engine architecture
 topics: [research, quant-finance, backtesting, walk-forward, look-ahead-bias, survivorship-bias, transaction-costs, validation]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Backtesting is the core evaluation mechanism in quantitative finance research. A backtest simulates how a strategy would have performed on historical data, but the gap between a backtest and live trading is enormous. Every design decision in the backtesting engine -- how fills are modeled, whether future data leaks into past decisions, how the instrument universe is constructed, how transaction costs are estimated -- determines whether the results are meaningful or self-deceptive. The primary goal of backtesting infrastructure is not to produce impressive returns but to produce honest results that predict live performance.

package/content/knowledge/research/research-quant-market-data.md

@@ -2,6 +2,10 @@
 name: research-quant-market-data
 description: Market data sourcing including OHLCV providers, tick data, corporate actions handling, data quality checks, gap handling, and timezone normalization
 topics: [research, quant-finance, market-data, ohlcv, tick-data, corporate-actions, data-quality, alternative-data]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Market data is the foundation of every quantitative strategy. Bad data produces bad backtests, and bad backtests produce strategies that fail in production. The data pipeline must handle multiple source providers with different conventions, normalize timestamps across timezones, adjust prices for corporate actions (splits, dividends, mergers), detect and fill gaps, and validate quality before any data reaches the strategy. Data quality issues are the most common source of phantom alpha -- apparent returns that disappear when data errors are fixed.

package/content/knowledge/research/research-quant-metrics.md

@@ -2,6 +2,10 @@
 name: research-quant-metrics
 description: Quantitative performance metrics including Sharpe ratio, Sortino ratio, Calmar ratio, maximum drawdown, profit factor, win rate, expectancy, and alpha/beta decomposition
 topics: [research, quant-finance, metrics, sharpe, sortino, calmar, drawdown, profit-factor, information-ratio, alpha, beta]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Performance metrics are the lens through which every trading strategy is evaluated. A single metric is never sufficient -- strategies must be assessed across multiple dimensions including risk-adjusted return, tail risk, consistency, and independence from market direction. The choice of which metric to optimize (primary target) versus which to constrain (guardrails) is a fundamental research design decision. Optimizing the wrong metric or ignoring important dimensions leads to strategies that look good on paper but blow up in practice.

package/content/knowledge/research/research-quant-requirements.md

@@ -2,6 +2,10 @@
 name: research-quant-requirements
 description: Trading system research requirements including strategy hypothesis definition, market regime assumptions, risk budgets, data requirements, and performance targets
 topics: [research, quant-finance, requirements, hypothesis, risk-budget, performance-targets, validation]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Trading strategy research requires requirements that go far beyond "find a profitable strategy." Every research project must define the strategy hypothesis with falsifiable predictions, declare market regime assumptions that bound the strategy's expected operating environment, establish risk budgets that constrain position sizing and drawdown limits, specify data requirements including quality standards and survivorship-bias-free universes, set performance targets with statistical significance thresholds, and mandate out-of-sample validation protocols. Without these constraints, a backtest will always find something that looks good on historical data -- the question is whether it will survive contact with live markets.

package/content/knowledge/research/research-quant-risk.md

@@ -2,6 +2,10 @@
 name: research-quant-risk
 description: Risk management for trading research including regime detection, tail risk measures, correlation breakdown, position limits, drawdown controls, and kill switches
 topics: [research, quant-finance, risk, regime-detection, tail-risk, var, cvar, correlation, drawdown-controls, kill-switch]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Risk management in quantitative finance is not an afterthought bolted onto a profitable strategy -- it is the primary constraint that determines whether a strategy survives long enough to realize its edge. Markets exhibit non-stationary behavior: correlations spike during crises, volatility clusters in ways that violate normal distribution assumptions, and tail events occur far more frequently than Gaussian models predict. A strategy without regime awareness, tail risk measurement, position limits, and automated kill switches is not a strategy -- it is a gamble.

package/content/knowledge/research/research-quant-strategy-patterns.md

@@ -2,6 +2,10 @@
 name: research-quant-strategy-patterns
 description: Trading strategy patterns including signal generation, entry/exit rules, position sizing methods, stop-loss patterns, and multi-asset allocation
 topics: [research, quant-finance, strategy, signals, position-sizing, kelly-criterion, stop-loss, allocation, volatility-targeting]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Trading strategies are composed of discrete building blocks that can be mixed, matched, and tested independently: signal generation (what to trade and when), entry/exit rules (how to initiate and close positions), position sizing (how much capital to allocate), and stop-loss management (how to limit downside). Treating each block as a separate, testable component enables systematic exploration of the strategy design space. Resist the temptation to build monolithic strategies -- instead, compose simple, well-tested components.

package/content/knowledge/research/research-requirements.md

@@ -2,6 +2,11 @@
 name: research-requirements
 description: Research project requirements including experiment goals, success metrics, iteration budgets, stopping criteria, and hypothesis documentation
 topics: [research, requirements, experiment-goals, metrics, stopping-criteria, hypothesis]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://the-turing-way.netlify.app/project-design/project-design.html
 ---
 
 Research projects differ from product engineering in a fundamental way: the requirements are not a list of features to build but a set of questions to answer. A research PRD defines the hypothesis space, the metrics that will determine success or failure, the computational and time budgets for exploration, and the stopping criteria that prevent infinite iteration. Without these constraints, autonomous experiment loops run forever and produce nothing actionable.