Merge pull request 'rio: extract claims from 2025-07-02-futardio-proposal-testing-indexer-changes' (#669) from extract/2025-07-02-futardio-proposal-testing-indexer-changes into main

- Source: inbox/archive/2025-07-02-futardio-proposal-testing-indexer-changes.md
- Domain: internet-finance
- Extracted by: headless extraction cron (worker 5)

Pentagon-Agent: Rio <HEADLESS>

agents/rio/musings/research-pipeline-scaling.md

@@ -0,0 +1,378 @@
+---
+type: musing
+agent: rio
+title: "Pipeline scaling architecture: queueing theory, backpressure, and optimal worker provisioning"
+status: developing
+created: 2026-03-12
+updated: 2026-03-12
+tags: [pipeline-architecture, operations-research, queueing-theory, mechanism-design, infrastructure]
+---
+
+# Pipeline Scaling Architecture: What Operations Research Tells Us
+
+Research musing for Leo and Cory on how to optimally architect our three-stage pipeline (research → extract → eval) for variable-load scaling. Six disciplines investigated, each mapped to our specific system.
+
+## Our System Parameters
+
+Before diving into theory, let me nail down the numbers:
+
+- **Arrival pattern**: Highly bursty. Research sessions dump 10-20 sources at once. Futardio launches come in bursts of 20+. Quiet periods produce 0-2 sources/day.
+- **Extract stage**: 6 max workers, ~10-15 min per source (Claude compute). Dispatches every 5 min via cron.
+- **Eval stage**: 5 max workers, ~5-15 min per PR (Claude compute). Dispatches every 5 min via cron.
+- **Current architecture**: Fixed cron intervals, fixed worker caps, no backpressure, no priority queuing beyond basic triage (infra PRs first, then re-review, then fresh).
+- **Cost model**: Workers are Claude Code sessions — expensive. Each idle worker costs nothing, but each active worker-minute is real money.
+- **Queue sizes**: ~225 unprocessed sources, ~400 claims in KB.
+
+---
+
+## 1. Operations Research / Queueing Theory
+
+### How it maps to our pipeline
+
+Our pipeline is a **tandem queue** (also called a Jackson network): three stages in series, each with multiple servers. In queueing notation:
+
+- **Extract stage**: M[t]/G/6 queue — time-varying arrivals (non-Poisson), general service times (extraction complexity varies), 6 servers
+- **Eval stage**: M[t]/G/5 queue — arrivals are departures from extract (so correlated), general service times, 5 servers
+
+The classic M/M/c model gives us closed-form results for steady-state behavior:
+
+**Little's Law** (L = λW) is the foundation. If average arrival rate λ = 8 sources per 5-min cycle = 0.027/sec, and average extraction time W = 750 sec (12.5 min), then average sources in extract system L = 0.027 × 750 ≈ 20. With 6 workers, average utilization ρ = 20/6 ≈ 3.3 — meaning we'd need ~20 workers for steady state at this arrival rate. **This means our current MAX_WORKERS=6 for extraction is significantly undersized during burst periods.**
+
+But bursts are temporary. During quiet periods, λ drops to near zero. The question isn't "how many workers for peak?" but "how do we adaptively size for current load?"
+
+### Key insight: Square-root staffing
+
+The **Halfin-Whitt regime** gives the answer: optimal workers = R + β√R, where R is the base load (λ/μ, arrival rate / service rate) and β ≈ 1-2 is a quality-of-service parameter.
+
+For our system during a burst (λ = 20 sources in 5 min):
+- R = 20 × (12.5 min / 5 min) = 50 source-slots needed → clearly impossible with 6 workers
+- During burst: queue builds rapidly, workers drain it over subsequent cycles
+- During quiet: R ≈ 0, workers = 0 + β√0 = 0 → don't spawn workers
+
+The square-root staffing rule says: **don't size for peak. Size for current load plus a safety margin proportional to √(current load).** This is fundamentally different from our current fixed-cap approach.
+
+### What to implement
+
+**Phase 1 (now)**: Calculate ρ = queue_depth / (MAX_WORKERS × expected_service_time_in_cycles). If ρ > 1, system is overloaded — scale up or implement backpressure. Log this metric.
+
+**Phase 2 (soon)**: Replace fixed MAX_WORKERS with dynamic: workers = min(ceil(queue_depth / sources_per_worker_per_cycle) + ceil(√(queue_depth)), HARD_MAX). This implements square-root staffing.
+
+→ SOURCE: Bournassenko 2025, "On Queueing Theory for Large-Scale CI/CD Pipelines"
+→ SOURCE: Whitt 2019, "What You Should Know About Queueing Models"
+→ SOURCE: van Leeuwaarden et al. 2018, "Economies-of-Scale in Many-Server Queueing Systems" (SIAM Review)
+
+---
+
+## 2. Stochastic Modeling for Non-Stationary Arrivals
+
+### How it maps to our pipeline
+
+Our arrival process is a textbook **Markov-Modulated Poisson Process (MMPP)**. There's a hidden state governing the arrival rate:
+
+| Hidden State | Arrival Rate | Duration |
+|-------------|-------------|----------|
+| Research session active | 10-20 sources/hour | 1-3 hours |
+| Futardio launch burst | 20+ sources/dump | Minutes |
+| Normal monitoring | 2-5 sources/day | Hours to days |
+| Quiet period | 0-1 sources/day | Days |
+
+The key finding from the literature: **replacing a time-varying arrival rate with a constant (average or max) leads to systems being badly understaffed or overstaffed.** This is exactly our problem. MAX_WORKERS=6 is undersized for bursts and oversized for quiet periods.
+
+### The peakedness parameter
+
+The **variance-to-mean ratio** (called "peakedness" or "dispersion ratio") of the arrival process determines how much extra capacity you need beyond standard queueing formulas:
+
+- Peakedness = 1: Poisson process (standard formulas work)
+- Peakedness > 1: Overdispersed/bursty (need MORE capacity than standard)
+- Peakedness < 1: Underdispersed/smooth (need LESS capacity)
+
+Our pipeline has peakedness >> 1 (highly bursty). The modified staffing formula adjusts the square-root safety margin by the peakedness factor. For bursty arrivals, the safety margin should be √(peakedness) × β√R instead of just β√R.
+
+### Practical estimation
+
+We can estimate peakedness empirically from our logs:
+1. Count sources arriving per hour over the last 30 days
+2. Calculate mean and variance of hourly arrival counts
+3. Peakedness = variance / mean
+
+If peakedness ≈ 5 (plausible given our burst pattern), we need √5 ≈ 2.2× the safety margin that standard Poisson models suggest.
+
+### What to implement
+
+**Phase 1**: Instrument arrival patterns. Log source arrivals per hour with timestamps. After 2 weeks, calculate peakedness.
+
+**Phase 2**: Use the peakedness-adjusted staffing formula for worker provisioning. Different time windows may have different peakedness — weekdays vs. weekends, research-session hours vs. off-hours.
+
+→ SOURCE: Whitt et al. 2016, "Staffing a Service System with Non-Poisson Non-Stationary Arrivals"
+→ SOURCE: Liu et al. 2019, "Modeling and Simulation of Nonstationary Non-Poisson Arrival Processes" (CIATA method)
+→ SOURCE: Simio/WinterSim 2018, "Resource Scheduling in Non-Stationary Service Systems"
+
+---
+
+## 3. Combinatorial Optimization / Scheduling
+
+### How it maps to our pipeline
+
+Our pipeline is a **hybrid flow-shop**: three stages (research → extract → eval), multiple workers at each stage, all sources flow through the same stage sequence. This is important because:
+
+- **Not a job-shop** (jobs don't have different stage orderings)
+- **Not a simple flow-shop** (we have parallel workers within each stage)
+- **Hybrid flow-shop with parallel machines per stage** — well-studied in OR literature
+
+The key question: given heterogeneous sources (varying complexity, different domains, different agents), how do we assign sources to workers optimally?
+
+### Surprising finding: simple dispatching rules work
+
+For hybrid flow-shops with relatively few stages and homogeneous workers within each stage, **simple priority dispatching rules perform within 5-10% of optimal**. The NP-hardness of general JSSP is not relevant to our case because:
+
+1. Our stages are fixed-order (not arbitrary routing)
+2. Workers within a stage are roughly homogeneous (all Claude sessions)
+3. We have few stages (3) and few workers (5-6 per stage)
+4. We already have a natural priority ordering (infra > re-review > fresh)
+
+The best simple rules for our setting:
+- **Shortest Processing Time (SPT)**: Process shorter sources first — reduces average wait time
+- **Priority + FIFO**: Within priority classes, process in arrival order
+- **Weighted Shortest Job First (WSJF)**: Priority weight / estimated processing time — maximizes value delivery rate
+
+### What we should NOT do
+
+Invest in metaheuristic scheduling algorithms (genetic algorithms, simulated annealing, tabu search). These are powerful for large-scale JSSP instances (100+ jobs, 20+ machines) but complete overkill for our scale. The gap between optimal and simple-dispatching is tiny at our size.
+
+### What to implement
+
+**Phase 1 (now)**: Implement source complexity estimation. Short sources (tweets, brief articles) should be processed before long ones (whitepapers, multi-thread analyses). This is SPT — proven optimal for minimizing average flow time.
+
+**Phase 2 (later)**: If we add domain-specific workers (e.g., Rio only processes internet-finance sources), the problem becomes a flexible flow-shop. Even then, simple "assign to least-loaded eligible worker" rules perform well.
+
+→ SOURCE: ScienceDirect 2023, "The Flexible Job Shop Scheduling Problem: A Review"
+
+---
+
+## 4. Adaptive / Elastic Scaling
+
+### How it maps to our pipeline
+
+Cloud-native autoscaling patterns solve exactly our problem: scaling workers up/down based on observed demand, without full cloud infrastructure. The key patterns:
+
+**Queue-depth-based scaling (KEDA pattern)**:
+```
+desired_workers = ceil(queue_depth / target_items_per_worker)
+```
+
+Where `target_items_per_worker` is calibrated to keep workers busy but not overloaded. KEDA adds scale-to-zero: if queue_depth = 0, workers = 0.
+
+**Multi-metric scaling**: Evaluate multiple signals simultaneously, scale to whichever requires the most workers:
+```
+workers = max(
+    ceil(unprocessed_sources / sources_per_worker),
+    ceil(open_prs / prs_per_eval_worker),
+    MIN_WORKERS
+)
+```
+
+**Cooldown periods**: After scaling up, don't immediately scale down — wait for a cooldown period. Prevents oscillation when load is choppy. Kubernetes HPA uses 5-minute stabilization windows.
+
+### Adapting for our cron-based system
+
+We don't have Kubernetes, but we can implement the same logic in bash:
+
+```bash
+# In extract-cron.sh, replace fixed MAX_WORKERS:
+QUEUE_DEPTH=$(grep -rl "^status: unprocessed" inbox/archive/ | wc -l)
+EVAL_BACKLOG=$(curl -sf "$FORGEJO_URL/api/v1/.../pulls?state=open" | jq 'length')
+
+# Scale extraction workers based on queue depth
+DESIRED_EXTRACT=$(( (QUEUE_DEPTH + 2) / 3 ))  # ~3 sources per worker
+
+# Apply backpressure from eval: if eval is backlogged, slow extraction
+if [ "$EVAL_BACKLOG" -gt 10 ]; then
+    DESIRED_EXTRACT=$(( DESIRED_EXTRACT / 2 ))
+fi
+
+# Bound between min and max
+WORKERS=$(( DESIRED_EXTRACT < 1 ? 1 : DESIRED_EXTRACT ))
+WORKERS=$(( WORKERS > HARD_MAX ? HARD_MAX : WORKERS ))
+```
+
+### Counterintuitive finding: scale-to-zero saves more than scale-to-peak
+
+In our cost model (expensive per worker-minute, zero cost for idle), the biggest savings come not from optimizing peak performance but from **not running workers when there's nothing to do**. Our current system already checks for unprocessed sources before dispatching — good. But it still runs the dispatcher every 5 minutes even when the queue has been empty for hours. A longer polling interval during quiet periods would save dispatcher overhead.
+
+### What to implement
+
+**Phase 1 (now)**: Replace fixed MAX_WORKERS with queue-depth-based formula. Add eval backpressure check to extract dispatcher.
+
+**Phase 2 (soon)**: Add cooldown/hysteresis — different thresholds for scaling up vs. down.
+
+**Phase 3 (later)**: Adaptive polling interval — faster polling when queue is active, slower when quiet.
+
+→ SOURCE: OneUptime 2026, "How to Implement HPA with Object Metrics for Queue-Based Scaling"
+→ SOURCE: KEDA documentation, keda.sh
+
+---
+
+## 5. Backpressure & Flow Control
+
+### How it maps to our pipeline
+
+This is the most critical gap in our current architecture. **We have zero backpressure.** The three stages are decoupled with no feedback:
+
+```
+Research → [queue] → Extract → [queue] → Eval → [merge]
+```
+
+If research dumps 20 sources, extraction will happily create 20 PRs, and eval will struggle with a PR backlog. There's no signal from eval to extract saying "slow down, I'm drowning." This is the classic producer-consumer problem.
+
+### The TCP analogy
+
+TCP congestion control solves exactly this: a producer (sender) must match rate to consumer (receiver) capacity, with the network as an intermediary that can drop packets (data loss) if overloaded. The solution: **feedback-driven rate adjustment**.
+
+In our pipeline:
+- **Producer**: Extract (creates PRs)
+- **Consumer**: Eval (reviews PRs)
+- **Congestion signal**: Open PR count growing
+- **Data loss equivalent**: Eval quality degrading under load (rushed reviews)
+
+### Four backpressure strategies
+
+1. **Buffer + threshold**: Allow some PR accumulation (buffer), but when open PRs exceed threshold, extract slows down. Simple, robust, our best first step.
+
+2. **Rate matching**: Extract dispatches at most as many sources as eval processed in the previous cycle. Keeps the pipeline balanced but can under-utilize extract during catch-up periods.
+
+3. **AIMD (Additive Increase Multiplicative Decrease)**: When eval queue is shrinking, increase extraction rate by 1 worker. When eval queue is growing, halve extraction workers. Proven stable, converges to optimal throughput. **This is the TCP approach and it's elegant for our setting.**
+
+4. **Pull-based**: Eval "pulls" work from a staging area instead of extract "pushing" PRs. Requires architectural change but guarantees eval is never overloaded. Kafka uses this pattern (consumers pull at their own pace).
+
+### The AIMD insight is gold
+
+AIMD is provably optimal for fair allocation of shared resources without centralized control (Corless et al. 2016). It's mathematically guaranteed to converge regardless of the number of agents or parameter values. For our pipeline:
+
+```
+Each cycle:
+  if eval_queue_depth < eval_queue_depth_last_cycle:
+    # Queue shrinking — additive increase
+    extract_workers = min(extract_workers + 1, HARD_MAX)
+  else:
+    # Queue growing or stable — multiplicative decrease
+    extract_workers = max(extract_workers / 2, 1)
+```
+
+This requires zero modeling, zero parameter estimation, zero prediction. It just reacts to observed system state and is proven to converge to the optimal throughput that eval can sustain.
+
+### What to implement
+
+**Phase 1 (now, highest priority)**: Add backpressure check to extract-cron.sh. Before dispatching extraction workers, check open PR count. If open PRs > 15, reduce extraction parallelism by half. If open PRs > 25, skip this extraction cycle entirely.
+
+**Phase 2 (soon)**: Implement AIMD scaling for extraction workers based on eval queue trend.
+
+**Phase 3 (later)**: Consider pull-based architecture where eval signals readiness for more work.
+
+→ SOURCE: Vlahakis et al. 2021, "AIMD Scheduling and Resource Allocation in Distributed Computing Systems"
+→ SOURCE: Corless et al. 2016, "AIMD Dynamics and Distributed Resource Allocation" (SIAM)
+→ SOURCE: Dagster, "What Is Backpressure"
+→ SOURCE: Java Code Geeks 2025, "Reactive Programming Paradigms: Mastering Backpressure and Stream Processing"
+
+---
+
+## 6. Markov Decision Processes
+
+### How it maps to our pipeline
+
+MDP formulates our scaling decision as a sequential optimization problem:
+
+**State space**: S = (unprocessed_queue, in_flight_extractions, open_prs, active_extract_workers, active_eval_workers, time_of_day)
+
+**Action space**: A = {add_extract_worker, remove_extract_worker, add_eval_worker, remove_eval_worker, wait}
+
+**Transition model**: Queue depths change based on arrival rates (time-dependent) and service completions (stochastic).
+
+**Cost function**: C(s, a) = worker_cost × active_workers + delay_cost × queue_depth
+
+**Objective**: Find policy π: S → A that minimizes expected total discounted cost.
+
+### Key findings
+
+1. **Optimal policies have threshold structure** (Li et al. 2019 survey): The optimal MDP policy is almost always "if queue > X and workers < Y, spawn a worker." This means even without solving the full MDP, a well-tuned threshold policy is near-optimal.
+
+2. **Hysteresis is optimal** (Tournaire et al. 2021): The optimal policy has different thresholds for scaling up vs. scaling down. Scale up at queue=10, scale down at queue=3 (not the same threshold). This prevents oscillation — exactly what AIMD achieves heuristically.
+
+3. **Our state space is tractable**: With ~10 discrete queue levels × 6 worker levels × 5 eval worker levels × 4 time-of-day buckets = ~1,200 states. This is tiny for MDP — value iteration converges in seconds. We could solve for the exact optimal policy.
+
+4. **MDP outperforms heuristics but not by much**: Tournaire et al. found that structured MDP algorithms outperform simple threshold heuristics, but the gap is modest (5-15% cost reduction). For our scale, a good threshold policy captures most of the value.
+
+### The honest assessment
+
+Solving the full MDP is theoretically clean but practically unnecessary at our scale. The MDP's main value is confirming that threshold policies with hysteresis are near-optimal — which validates implementing AIMD + backpressure thresholds as Phase 1 and not worrying about exact optimization until the system is much larger.
+
+### What to implement
+
+**Phase 1**: Don't solve the MDP. Implement threshold policies with hysteresis (different up/down thresholds) informed by MDP theory.
+
+**Phase 2 (only if system grows significantly)**: Formulate and solve the MDP using value iteration. Use historical arrival/service data to parameterize the transition model. The optimal policy becomes a lookup table: given current state, take this action.
+
+→ SOURCE: Tournaire et al. 2021, "Optimal Control Policies for Resource Allocation in the Cloud: MDP vs Heuristic Approaches"
+→ SOURCE: Li et al. 2019, "An Overview for Markov Decision Processes in Queues and Networks"
+
+---
+
+## Synthesis: The Implementation Roadmap
+
+### The core diagnosis
+
+Our pipeline's architecture has three problems, in order of severity:
+
+1. **No backpressure** — extraction can overwhelm evaluation with no feedback signal
+2. **Fixed worker counts** — static MAX_WORKERS ignores queue state entirely
+3. **No arrival modeling** — we treat all loads the same regardless of burst patterns
+
+### Phase 1: Backpressure + Dynamic Scaling (implement now)
+
+This captures 80% of the improvement with minimal complexity:
+
+1. **Add eval backpressure to extract-cron.sh**: Check open PR count before dispatching. If backlogged, reduce extraction parallelism.
+2. **Replace fixed MAX_WORKERS with queue-depth formula**: `workers = min(ceil(queue_depth / 3) + 1, HARD_MAX)`
+3. **Add hysteresis**: Scale up when queue > 8, scale down when queue < 3. Different thresholds prevent oscillation.
+4. **Instrument everything**: Log queue depths, worker counts, cycle times, utilization rates.
+
+### Phase 2: AIMD Scaling (implement within 2 weeks)
+
+Replace fixed formulas with adaptive AIMD:
+
+1. Track eval queue trend (growing vs. shrinking) across cycles
+2. Growing queue → multiplicative decrease of extraction rate
+3. Shrinking queue → additive increase of extraction rate
+4. This self-tunes without requiring parameter estimation
+
+### Phase 3: Arrival Modeling + Optimization (implement within 1 month)
+
+With 2+ weeks of instrumented data:
+
+1. Calculate peakedness of arrival process
+2. Apply peakedness-adjusted square-root staffing for worker provisioning
+3. If warranted, formulate and solve the MDP for exact optimal policy
+4. Implement adaptive polling intervals (faster when active, slower when quiet)
+
+### Surprising findings
+
+1. **Simple dispatching rules are near-optimal at our scale.** The combinatorial optimization literature says: for a hybrid flow-shop with <10 machines per stage, SPT/FIFO within priority classes is within 5-10% of optimal. Don't build a scheduler; build a good priority queue.
+
+2. **AIMD is the single most valuable algorithm to implement.** It's proven stable, requires no modeling, and handles the backpressure + scaling problems simultaneously. TCP solved this exact problem 40 years ago.
+
+3. **The MDP confirms we don't need the MDP.** The optimal policy is threshold-based with hysteresis — exactly what AIMD + backpressure thresholds give us. The MDP's value is validation, not computation.
+
+4. **The square-root staffing rule means diminishing returns on workers.** Adding a 7th worker to a 6-worker system helps less than adding the 2nd worker to a 1-worker system. At our scale, the marginal worker is still valuable, but there's a real ceiling around 8-10 extraction workers and 6-8 eval workers beyond which additional workers waste money.
+
+5. **Our biggest waste isn't too few workers — it's running workers against an empty queue.** The extract-cron runs every 5 minutes regardless of queue state. If the queue has been empty for 6 hours, that's 72 unnecessary dispatcher invocations. Adaptive polling (or event-driven triggering) would eliminate this overhead.
+
+6. **The pipeline's binding constraint is eval, not extract.** Extract produces work faster than eval consumes it (6 extract workers × ~8 sources/cycle vs. 5 eval workers × ~5 PRs/cycle). Without backpressure, this imbalance causes PR accumulation. The right fix is rate-matching extraction to evaluation throughput, not speeding up extraction.
+
+→ CLAIM CANDIDATE: "Backpressure is the highest-leverage architectural improvement for multi-stage pipelines because it prevents the most common failure mode (producer overwhelming consumer) with minimal implementation complexity"
+
+→ CLAIM CANDIDATE: "AIMD provides near-optimal resource allocation for variable-load pipelines without requiring arrival modeling or parameter estimation because its convergence properties are independent of system parameters"
+
+→ CLAIM CANDIDATE: "Simple priority dispatching rules perform within 5-10% of optimal for hybrid flow-shop scheduling at moderate scale because the combinatorial explosion that makes JSSP NP-hard only matters at large scale"
+
+→ FLAG @leo: The mechanism design parallel is striking — backpressure in pipelines is structurally identical to price signals in markets. Both are feedback mechanisms that prevent producers from oversupplying when consumers can't absorb. AIMD in particular mirrors futarchy's self-correcting property: the system converges to optimal throughput through local feedback, not central planning.
+
+→ FLAG @theseus: MDP formulation of pipeline scaling connects to AI agent resource allocation. If agents are managing their own compute budgets, AIMD provides a decentralized mechanism for fair sharing without requiring a central coordinator.

domains/entertainment/consumer-rejection-of-ai-generated-ads-intensifies-as-ai-quality-improves-disproving-the-exposure-leads-to-acceptance-hypothesis.md

@@ -0,0 +1,47 @@
+---
+type: claim
+domain: entertainment
+secondary_domains: [cultural-dynamics]
+description: "IAB 2026 data shows consumer negative sentiment toward AI ads rose 12 percentage points year-over-year while AI quality was improving dramatically, directly falsifying the common assumption that exposure normalizes acceptance"
+confidence: likely
+source: "Clay, from IAB 'The AI Ad Gap Widens' report, 2026"
+created: 2026-03-12
+depends_on: ["GenAI adoption in entertainment will be gated by consumer acceptance not technology capability"]
+challenged_by: []
+---
+
+# Consumer rejection of AI-generated ads intensifies as AI quality improves, disproving the exposure-leads-to-acceptance hypothesis
+
+The most common prediction about consumer resistance to AI-generated content is that it will erode as AI quality improves and as consumers habituate through repeated exposure. The IAB's 2026 AI Ad Gap Widens report provides direct quantitative evidence against this prediction in the advertising domain.
+
+Between 2024 and 2026 — a period when AI generative quality improved dramatically — consumer negative sentiment toward AI-generated ads increased by 12 percentage points. Simultaneously, the share of neutral respondents fell from 34% to 25%. Consumers are not staying neutral as they get more exposure to AI content; they are forming stronger opinions, and predominantly negative ones.
+
+The polarization data is particularly significant. A naive exposure-leads-to-acceptance model predicts that neutrals gradually migrate to positive sentiment as the content becomes familiar. The actual pattern is the opposite: neutrals are disappearing but migrating toward negative sentiment. This suggests that increased familiarity is producing informed rejection, not normalized acceptance.
+
+## Proposed mechanism
+
+As AI quality improves, consumers become better at detecting AI-generated content — and detection triggers rejection rather than acceptance. Paradoxically, higher-quality AI content may make the authenticity question more salient, not less. When AI ads become more polished, they compete directly against human-created ads on the same aesthetic plane, making the question of provenance more visible. The uncanny valley may apply to authenticity perception, not just visual realism.
+
+This is consistent with the broader trend toward "human-made" as an active premium label: the harder AI is to detect, the more valuable explicit provenance signals become. Consumers aren't rejecting AI because it looks bad — they're rejecting it because they learned to care who made it.
+
+## Evidence
+
+- **IAB 2026 AI Ad Gap Widens report**: Consumer negative sentiment toward AI ads increased 12 percentage points from 2024 to 2026
+- **IAB 2026**: Neutral respondents dropped from 34% to 25% over the same period (polarization, not normalization)
+- **IAB 2026**: Only 45% of consumers report very/somewhat positive sentiment about AI ads
+- **Temporal control**: The 2024→2026 window coincides with major AI quality improvements (Sora, multimodal systems, etc.), ruling out "AI got worse" as an explanation
+
+## Challenges
+
+The IAB data covers advertising specifically. It is possible that advertising is a particularly hostile context for AI due to the inherent skepticism consumers bring to commercial messaging. The acceptance-through-exposure hypothesis may still hold in entertainment contexts (e.g., AI-generated film VFX, background music) where provenance is less salient. This claim is strongest for consumer-facing AI-branded content; it is weaker for AI-assisted production invisible to consumers.
+
+---
+
+Relevant Notes:
+- [[GenAI adoption in entertainment will be gated by consumer acceptance not technology capability]] — the parent claim; this provides direct empirical evidence in a surprising direction
+- [[human-made-is-becoming-a-premium-label-analogous-to-organic-as-AI-generated-content-becomes-dominant]] — the market response to intensifying rejection
+- [[consumer definition of quality is fluid and revealed through preference not fixed by production value]] — quality now includes provenance as a dimension, which is what consumers are rejecting on
+
+Topics:
+- [[entertainment]]
+- [[cultural-dynamics]]

domains/entertainment/gen-z-hostility-to-ai-generated-advertising-is-stronger-than-millennials-and-widening-making-gen-z-a-negative-leading-indicator-for-ai-content-acceptance.md

@@ -0,0 +1,61 @@
+---
+type: claim
+domain: entertainment
+secondary_domains: [cultural-dynamics]
+description: "Gen Z rates AI-generated ads more negatively than Millennials on every measured dimension — 39% vs 20% negative sentiment — and the generational gap widened from 2024 to 2026, making Gen Z's rejection a forward indicator for where mainstream sentiment is heading"
+confidence: experimental
+source: "Clay, from IAB 'The AI Ad Gap Widens' report, 2026"
+created: 2026-03-12
+depends_on: ["GenAI adoption in entertainment will be gated by consumer acceptance not technology capability", "consumer-rejection-of-ai-generated-ads-intensifies-as-ai-quality-improves-disproving-the-exposure-leads-to-acceptance-hypothesis"]
+challenged_by: []
+---
+
+# Gen Z hostility to AI-generated advertising is stronger than Millennials and widening, making Gen Z a negative leading indicator for AI content acceptance
+
+Gen Z consumers are more hostile to AI-generated advertising than Millennials across every measured dimension, and the gap between the two cohorts widened from 2024 to 2026. Because Gen Z is the youngest fully-addressable consumer cohort, their attitudes represent where mainstream consumer sentiment is likely to move — not an aberration that will normalize as the cohort ages.
+
+## The data
+
+**Negative sentiment**:
+- Gen Z: 39% negative
+- Millennials: 20% negative
+- Gap: 19 percentage points (widened from 6 points in 2024: 21% vs. 15%)
+
+**Brand attribute perception (Gen Z vs. Millennials rating AI-using brands)**:
+- "Lacks authenticity": 30% (Gen Z) vs. 13% (Millennials)
+- "Disconnected": 26% (Gen Z) vs. 8% (Millennials)
+- "Unethical": 24% (Gen Z) vs. 8% (Millennials)
+
+The Gen Z-Millennial gap tripled on disconnectedness (from roughly even to 3:1) and more than tripled on unethical (roughly even to 3:1). This is not generational noise — this is a systematic divergence on values dimensions that Gen Z weights heavily.
+
+## Why Gen Z as leading indicator, not outlier
+
+The standard framing of generational divides treats the younger cohort as a laggard that will converge to mainstream norms as they age and gain purchasing power. This framing is wrong for AI content because:
+
+1. **Digital nativeness makes Gen Z more capable of detecting AI**, not less. They grew up with generative tools; they know what AI content looks and feels like. Their rejection is informed, not naive.
+2. **Gen Z's authenticity framework is more developed**. Creators, not studios, formed their cultural reference points. Authenticity is a core value in creator culture in a way it was not in broadcast-era media. AI content violates that framework.
+3. **They are approaching peak purchasing power**. Gen Z is entering prime consumer years. The advertising industry that ignores their values will face rising cost-per-acquisition as the largest cohorts turn hostile.
+
+The leading-indicator interpretation implies that current Millennial negative sentiment (20%) is a lagged version of what is coming. If Gen Z's rate (39%) is where cohorts eventually stabilize as awareness increases, total market negative sentiment will approximately double from current levels.
+
+## Evidence
+
+- **IAB 2026**: Gen Z 39% negative vs. Millennial 20% negative
+- **IAB 2026**: Gen Z-Millennial gap widened significantly from 2024 (21% vs. 15% in 2024 → 39% vs. 20% in 2026)
+- **IAB 2026**: Gen Z rates AI-using brands as lacking authenticity (30% vs. 13%), disconnected (26% vs. 8%), and unethical (24% vs. 8%)
+- **Trend direction**: Gap widened over 2 years while both cohorts had more exposure to AI content — consistent with informed rejection not naive confusion
+
+## Challenges
+
+This claim depends on the leading-indicator framing — that Gen Z attitudes predict future mainstream attitudes rather than representing a cohort-specific view that moderates with age. The alternative hypothesis is that Gen Z attitudes are a developmental stage artifact (younger people are more idealistic about authenticity) that will moderate as they age into consumption patterns similar to Millennials. The 2024→2026 widening of the gap slightly favors the leading-indicator interpretation over the developmental-stage hypothesis, but two years is insufficient to distinguish them.
+
+---
+
+Relevant Notes:
+- [[consumer-rejection-of-ai-generated-ads-intensifies-as-ai-quality-improves-disproving-the-exposure-leads-to-acceptance-hypothesis]] — the overall trend this cohort data sharpens
+- [[the-advertiser-consumer-ai-perception-gap-is-a-widening-structural-misalignment-not-a-temporal-communications-lag]] — Gen Z data makes the structural case stronger: the cohort most likely to increase in market share is the most hostile
+- [[human-made-is-becoming-a-premium-label-analogous-to-organic-as-AI-generated-content-becomes-dominant]] — Gen Z's authenticity-first values are the demand-side driver of human-made premium
+
+Topics:
+- [[entertainment]]
+- [[cultural-dynamics]]

domains/entertainment/the-advertiser-consumer-ai-perception-gap-is-a-widening-structural-misalignment-not-a-temporal-communications-lag.md

@@ -0,0 +1,52 @@
+---
+type: claim
+domain: entertainment
+secondary_domains: [cultural-dynamics]
+description: "The 37-point gap between advertiser beliefs about consumer AI sentiment (82% positive) and actual consumer sentiment (45% positive) widened from 32 points in 2024, indicating the advertising industry holds systematically wrong beliefs that are getting worse not better"
+confidence: likely
+source: "Clay, from IAB 'The AI Ad Gap Widens' report, 2026"
+created: 2026-03-12
+depends_on: ["GenAI adoption in entertainment will be gated by consumer acceptance not technology capability"]
+challenged_by: []
+---
+
+# The advertiser-consumer AI perception gap is a widening structural misalignment, not a temporal communications lag
+
+The advertising industry holds beliefs about consumer sentiment toward AI-generated ads that are systematically and increasingly wrong. The IAB's 2026 AI Ad Gap Widens report documents:
+
+- **82%** of ad executives believe Gen Z/Millennials feel very or somewhat positive about AI ads
+- **45%** of consumers actually report positive sentiment
+- **Gap = 37 percentage points** — up from 32 points in 2024
+
+The direction of the trend matters as much as the magnitude. A 5-point widening over two years, during a period of intense industry AI discourse, suggests this is not a communications problem that more education will solve. Advertisers are becoming *more* confident about consumer acceptance even as consumer rejection is intensifying.
+
+## Why this is structural, not informational
+
+The standard explanation for perception gaps is information asymmetry: industry insiders lack visibility into consumer sentiment. But the IAB publishes this data; ad executives have access to consumer sentiment surveys. The gap is persisting and widening not because advertisers lack information but because their incentives and selection pressures push them toward optimistic beliefs.
+
+Several structural forces maintain the misalignment:
+1. **Agency incentives**: Ad agencies earn fees for producing AI content; admitting consumer resistance reduces business justification
+2. **Executive selection**: Leaders who championed AI adoption must believe adoption will succeed to justify past decisions
+3. **Attribute framing gaps**: Ad executives associate AI with "forward-thinking" (46%) and "innovative" (49%), while consumers are more likely to associate it with "manipulative" (20% vs. executives' 10%) and "unethical" (16% vs. 7%). They are not measuring the same attributes
+
+## Evidence
+
+- **IAB 2026**: 82% advertiser positive-sentiment belief vs. 45% consumer positive sentiment = 37pp gap
+- **IAB 2026**: Gap was 32 points in 2024 — widened by 5 points in two years
+- **IAB 2026 attribute data**: "Forward-thinking" — 46% ad executives vs. 22% consumers; "Innovative" — 49% ad executives vs. 23% consumers (down from 30% in 2024); "Manipulative" — 10% ad executives vs. 20% consumers; "Unethical" — 7% ad executives vs. 16% consumers
+- **Temporal pattern**: Gap widened during a period when AI industry discussion increased, not decreased — suggesting more information flow did not close the gap
+
+## Challenges
+
+The IAB is the Interactive Advertising Bureau — the industry association for digital advertisers. This gives the report authority with the industry it covers, but it also means the survey methodology and framing reflect industry assumptions. The "positive/negative" binary may not fully capture consumer nuance. Additionally, consumers self-report sentiment in surveys but their revealed preference (ad engagement) might diverge from stated sentiment.
+
+---
+
+Relevant Notes:
+- [[consumer-rejection-of-ai-generated-ads-intensifies-as-ai-quality-improves-disproving-the-exposure-leads-to-acceptance-hypothesis]] — the demand-side of the same misalignment: consumer rejection is growing while advertiser optimism is growing
+- [[GenAI adoption in entertainment will be gated by consumer acceptance not technology capability]] — this misalignment means the advertiser-as-gatekeeper of AI adoption is systematically miscalibrated
+- [[human-made-is-becoming-a-premium-label-analogous-to-organic-as-AI-generated-content-becomes-dominant]] — the market mechanism that will eventually correct the misalignment (when human-made premium pricing arrives)
+
+Topics:
+- [[entertainment]]
+- [[cultural-dynamics]]

domains/internet-finance/MetaDAO is the futarchy launchpad on Solana where projects raise capital through unruggable ICOs governed by conditional markets creating the first platform for ownership coins at scale.md

@@ -82,12 +82,6 @@ Futardio cult launch (2026-03-03 to 2026-03-04) demonstrates MetaDAO's platform
 
 (challenge) Areal's failed Futardio launch ($11,654 raised of $50K target, REFUNDING status) demonstrates that futarchy-governed fundraising does not guarantee capital formation success. The mechanism provides credible exit guarantees through market-governed liquidation and governance quality through conditional markets, but market participants still evaluate project fundamentals and team credibility. Futarchy reduces rug risk but does not eliminate market skepticism of unproven business models or early-stage teams.
 
-
-### Additional Evidence (extend)
-*Source: [[2026-01-01-futardio-launch-mycorealms]] | Added: 2026-03-12 | Extractor: anthropic/claude-sonnet-4.5*
-
-MycoRealms demonstrates MetaDAO/Futardio's expansion beyond digital-native projects into physical infrastructure. The $125K raise for mushroom farming operations uses the same unruggable ICO structure (72-hour raise window, full refunds if target not met, automatic treasury/liquidity deployment if successful) but applies it to tangible asset production with measurable physical outputs (crop yields, temperature/humidity data, wholesale sales). All operational records publish to Arweave. Team allocation uses performance-only unlocks (5 tranches at 2x/4x/8x/16x/32x ICO price via 3-month TWAP, 18-month minimum cliff, zero tokens if price never reaches 2x). This is the first futarchy-governed agricultural operation, expanding the platform's scope from ownership coins to real-world infrastructure governance.
-
 ---
 
 Relevant Notes:

domains/internet-finance/SPL-404-enables-fungible-NFT-swap-revenue-for-DAOs-by-bridging-governance-tokens-and-NFT-liquidity-on-Solana.md

@@ -0,0 +1,29 @@
+---
+type: claim
+domain: internet-finance
+description: "SPL 404 is a Solana token standard that creates bidirectional swaps between fungible governance tokens and NFTs, letting DAOs earn secondary revenue from swap activity without direct NFT treasury sales."
+confidence: experimental
+source: "Rio; FutureDAO Champions NFT Collection proposal (2024-07-18, passed 2024-07-22)"
+created: 2026-03-12
+depends_on:
+  - "MetaDAO is the futarchy launchpad on Solana where projects raise capital through unruggable ICOs governed by conditional markets creating the first platform for ownership coins at scale"
+---
+
+# SPL 404 enables fungible-NFT swap revenue for DAOs by bridging governance tokens and NFT liquidity on Solana
+
+SPL 404 is a Solana token standard that allows bidirectional swaps between fungible tokens and NFTs. For DAOs, this creates a monetization path that doesn't require direct NFT sales from the treasury: instead, when community members swap their governance tokens (e.g., $FUTURE) into NFT form or back, the protocol earns revenue from the swap mechanics. Secondary market royalties then compound on top.
+
+FutureDAO's Champions NFT Collection proposal (passed July 2024) illustrates this architecture in practice. Of the $10,000 design budget, $3,000 was earmarked for non-artistic technical work — $1,000 for smart contract development and $2,000 for metadata integration — required specifically to enable SPL 404 swap mechanics. The proposal projected two revenue streams: SPL 404 swap fees and secondary market royalties. Neither stream requires the DAO to sell NFTs directly; revenue flows from market activity rather than treasury disposition.
+
+This matters for DAO treasury design. Traditional NFT monetization requires either initial sales (one-time, often fraught with launch mechanics) or secondary royalties (declining in enforcement reliability post-Blur). SPL 404 adds a third path: perpetual swap revenue tied to the governance token's own liquidity. As long as members convert between token and NFT form, the swap mechanism generates revenue.
+
+The limitation is that SPL 404 swap revenue is indirect and hard to project — it depends on community demand for the NFT form specifically. If members prefer holding the fungible token, swap volume is minimal regardless of collection quality.
+
+---
+
+Relevant Notes:
+- [[MetaDAO is the futarchy launchpad on Solana where projects raise capital through unruggable ICOs governed by conditional markets creating the first platform for ownership coins at scale]] — FutureDAO runs on MetaDAO's futarchy infrastructure; SPL 404 extends the token utility layer
+- [[MetaDAOs Autocrat program implements futarchy through conditional token markets where proposals create parallel pass and fail universes settled by time-weighted average price over a three-day window]] — the governance mechanism that approved this SPL 404-enabled NFT spend
+
+Topics:
+- [[_map]]

domains/internet-finance/futarchy-based fundraising creates regulatory separation because there are no beneficial owners and investment decisions emerge from market forces not centralized control.md

@@ -25,12 +25,6 @@ Since [[decision markets make majority theft unprofitable through conditional to
 
 **The timing dependency.** Since [[anti-payvidor legislation targets all insurer-provider integration without distinguishing acquisition-based arbitrage from purpose-built care delivery]], the regulatory environment for Devoted specifically adds complexity. Public perception of crypto at the time of the raise matters. Companies need to understand that having a publicly trading proxy for their value is a double-edged sword.
 
-
-### Additional Evidence (extend)
-*Source: [[2026-01-01-futardio-launch-mycorealms]] | Added: 2026-03-12 | Extractor: anthropic/claude-sonnet-4.5*
-
-MycoRealms extends futarchy-based fundraising into physical infrastructure (mushroom farming) where the team operates on a $10,000 monthly allowance and cannot access the $125,000 treasury directly. The first CAPEX proposal ($50,000 for infrastructure) must pass through conditional markets before deployment. This creates a clean separation: the raise provides capital, but market forces (not team discretion) determine how that capital deploys. All invoices, expenses, and operational records publish to Arweave, creating full transparency. This is the first application of futarchy governance to tangible asset production with measurable physical outputs (temperature, humidity, CO2, yield, harvest records), demonstrating that the regulatory separation mechanism (market-controlled deployment, no beneficial owner discretion) extends beyond digital-native projects to real-world infrastructure.
-
 ---
 
 Relevant Notes:

domains/internet-finance/futarchy-governed liquidation is the enforcement mechanism that makes unruggable ICOs credible because investors can force full treasury return when teams materially misrepresent.md

@@ -52,12 +52,6 @@ Critically, the proposal nullifies a prior 90-day restriction on buybacks/liquid
 
 MycoRealms implements unruggable ICO structure with automatic refund mechanism: if $125,000 target not reached within 72 hours, full refunds execute automatically. Post-raise, team has zero direct treasury access — operates on $10,000 monthly allowance with all other expenditures requiring futarchy approval. This creates credible commitment: team cannot rug because they cannot access treasury directly, and investors can force liquidation through futarchy proposals if team materially misrepresents (e.g., fails to publish operational data to Arweave as promised, diverts funds from stated use). Transparency requirement (all invoices, expenses, harvest records, photos published to Arweave) creates verifiable baseline for detecting misrepresentation.
 
-
-### Additional Evidence (extend)
-*Source: [[2026-01-01-futardio-launch-mycorealms]] | Added: 2026-03-12 | Extractor: anthropic/claude-sonnet-4.5*
-
-MycoRealms makes the liquidation threat more concrete and verifiable by operating in physical infrastructure where misrepresentation is easier to detect. The team publishes all invoices, expenses, harvest records, and operational photos to Arweave, creating a transparent audit trail. If the team claims to have built 3 growing rooms but on-chain records show no corresponding CAPEX deployment or harvest data, investors can propose liquidation through futarchy. The physical nature of the operation (mushroom production with measurable yields, temperature/humidity logs, wholesale sales records) makes the 'material misrepresentation' threshold clearer and more objectively verifiable than in purely digital projects, strengthening the credibility of the liquidation enforcement mechanism.
-
 ---
 
 Relevant Notes:

domains/internet-finance/futarchy-markets-can-price-cultural-spending-proposals-by-treating-community-cohesion-and-brand-equity-as-token-price-inputs.md

@@ -0,0 +1,38 @@
+---
+type: claim
+domain: internet-finance
+description: "Futarchy governance can evaluate and approve non-financial cultural expenditures when proposers successfully frame community cohesion and brand benefits as positive token price signals, expanding the scope of what market governance can decide."
+confidence: experimental
+source: "Rio; FutureDAO Champions NFT Collection proposal (2024-07-18, passed 2024-07-22)"
+created: 2026-03-12
+depends_on:
+  - "MetaDAOs Autocrat program implements futarchy through conditional token markets where proposals create parallel pass and fail universes settled by time-weighted average price over a three-day window"
+  - "coin price is the fairest objective function for asset futarchy"
+---
+
+# futarchy markets can price cultural spending proposals by treating community cohesion and brand equity as token price inputs
+
+Futarchy governance selects proposals by whether conditional markets expect them to increase token price. This creates an implicit question for cultural spending: can markets price "soft" benefits like community cohesion, brand presence, and social identity into a token price signal?
+
+FutureDAO's Champions NFT proposal provides a concrete test case. The proposal requested $10,000 for NFT artwork design — with the primary stated value case being community cohesion ("PFPs for community members to represent themselves") and Solana ecosystem presence ("FutureDAO's notoriety across the Solana ecosystem"), not direct financial ROI. Revenue projections were explicitly indirect: SPL 404 swap fees and secondary market royalties, both dependent on emergent community demand. Despite this soft value framing, the proposal passed futarchy governance on July 22, 2024.
+
+This indicates that futarchy markets can evaluate cultural spending when participants believe brand and community effects will flow through to token price. The mechanism works because the objective function (token price) is broad enough to incorporate any factor that market participants believe matters — including social capital, community retention, and ecosystem reputation. Futarchy doesn't require direct financial return from a proposal; it requires only that participants believe the proposal increases expected token value.
+
+The implication for DAO governance design is significant: futarchy is not limited to quantifiable ROI decisions. It can govern brand investments, cultural initiatives, and community spending — anywhere the market believes soft benefits translate to token appreciation. This expands futarchy's applicable scope beyond the financial optimization use cases it was originally theorized for.
+
+The risk is that cultural proposals introduce systematic bias: participants who value community belonging may persistently overestimate the token-price impact of cultural spending, creating a selection pressure for feel-good proposals over productive ones.
+
+## Challenges
+
+The single data point is limited. One passed proposal doesn't establish a reliable pattern. Cultural proposals that fail futarchy governance (and thus go unobserved in public records) would provide the necessary counter-evidence to calibrate how often futarchy actually validates cultural versus financial spending.
+
+---
+
+Relevant Notes:
+- [[MetaDAOs Autocrat program implements futarchy through conditional token markets where proposals create parallel pass and fail universes settled by time-weighted average price over a three-day window]] — the mechanism that priced and approved this cultural spending proposal
+- [[coin price is the fairest objective function for asset futarchy]] — the broad objective function that makes cultural pricing possible
+- [[redistribution proposals are futarchys hardest unsolved problem because they can increase measured welfare while reducing productive value creation]] — adjacent challenge: welfare-increasing but value-neutral proposals
+- [[futarchy-governed DAOs converge on traditional corporate governance scaffolding for treasury operations because market mechanisms alone cannot provide operational security and legal compliance]] — limits of futarchy for operational decisions
+
+Topics:
+- [[_map]]

entities/internet-finance/artemis-labs.md

@@ -0,0 +1,3 @@
+---
+type: entity
+...

entities/internet-finance/crypticmeta.md

@@ -1,28 +0,0 @@
----
-type: entity
-entity_type: person
-name: crypticmeta
-domain: internet-finance
-status: active
-roles:
-  - founder
-affiliations:
-  - MycoRealms
-  - OrdinalNovus
-tracked_by: rio
-created: 2026-03-11
----
-
-# crypticmeta
-
-Freelance blockchain developer on Solana and Bitcoin since 2018. Built and scaled OrdinalNovus, a CBRC token exchange on Bitcoin Ordinals that reached $30M in trading volume. Co-founder of MycoRealms, the first futarchy-governed agricultural operation.
-
-## Timeline
-- **2018** — Began freelance blockchain development on Solana and Bitcoin
-- **2023-2024** — Built and scaled OrdinalNovus (CBRC token exchange on Bitcoin Ordinals) to $30M trading volume
-- **2025** — Co-founded MycoRealms, prepared for mushroom farming operation (ICAR-DMR internship, market research, vendor sourcing)
-- **2026-01-01** — Launched MycoRealms fundraise on Futardio ($125K target)
-
-## Relationship to KB
-- [[mycorealms]] — co-founder, technical lead
-- [[myco-realms-demonstrates-futarchy-governed-physical-infrastructure-through-125k-mushroom-farm-raise-with-market-controlled-capex-deployment]] — first futarchy-governed physical infrastructure project

entities/internet-finance/deans-list.md

@@ -47,3 +47,5 @@ Topics:
 ## Timeline
 
 - **2024-12-19** — [[deans-list-implement-3-week-vesting]] passed: 3-week linear vesting for DAO payments to reduce sell pressure from 80% immediate liquidation to 33% weekly rate, projected 15%-25% valuation increase
+
+- **2024-10-10** — [[islanddao-treasury-proposal]] passed: Established treasury reserve funded by 2.5% of USDC payments with risk-scored asset allocation (80/20 safe/risky split) and quarterly performance reviews managed by Kai (@DeFi_Kai)

entities/internet-finance/drift-fund-artemis-labs-dashboards.md

@@ -0,0 +1,3 @@
+---
+type: entity
+...

entities/internet-finance/drift.md

@@ -1,58 +1,9 @@
 ---
-type: entity
-entity_type: company
-name: "Drift Protocol"
-domain: internet-finance
-handles: ["@DriftProtocol"]
-website: https://drift.trade
-status: active
-tracked_by: rio
-created: 2026-03-11
-last_updated: 2026-03-11
-category: "Perpetuals DEX / DeFi protocol (Solana)"
-stage: growth
-key_metrics:
-  futarchy_proposals: "6+ proposals on MetaDAO platform (grants, working group, AI agents, competitions)"
-  drift_allocated: "150,000+ DRIFT allocated through futarchy governance"
-built_on: ["Solana"]
-competitors: ["[[omnipair]]"]
-tags: ["perps", "solana", "futarchy-adopter", "metadao-ecosystem"]
----
+type: timeline
+...
 
-# Drift Protocol
-
-## Overview
-Perpetuals DEX on Solana — one of the largest decentralized derivatives platforms. Significant to the MetaDAO ecosystem for two reasons: (1) Drift adopted futarchy governance through MetaDAO's platform, making it the highest-profile external organization to use futarchic decision-making, and (2) Drift represents the future competitive threat to OmniPair's leverage monopoly on MetaDAO ecosystem tokens.
-
-## Current State
-- **Futarchy adoption**: Drift has run 6+ governance proposals through MetaDAO's futarchy platform since May 2024, allocating 150,000+ DRIFT tokens through futarchic decisions. This includes the Drift Foundation Grant Program (100K DRIFT), "Welcome the Futarchs" retroactive rewards (50K DRIFT), Drift AI Agents grants program (50K DRIFT), Drift Working Group funding, and SuperTeam Earn creator competitions.
-- **AI Agents program**: Drift allocated 50,000 DRIFT for an AI Agents Grants program (Dec 2024) covering trading agents, yield agents, information agents, and social agents. Early signal of DeFi protocols investing in agentic infrastructure.
-- **Leverage competitor**: Currently, OmniPair is the "only game in town" for leverage on MetaDAO ecosystem tokens. However, if MetaDAO reaches ~$1B valuation, Drift and other perp protocols will likely list META and ecosystem tokens — eroding OmniPair's temporary moat.
-- **Perps aggregation**: Ranger Finance aggregated Drift (among others) before its liquidation.
-
-## Timeline
-- **2024-05-30** — First futarchy proposal: "Welcome the Futarchs" — 50K DRIFT to incentivize futarchy participation
-- **2024-07-09** — Drift Foundation Grant Program initialized via futarchy (100K DRIFT)
-- **2024-08-27** — SuperTeam Earn creator competition funded via futarchy
-- **2024-12-19** — AI Agents Grants program: 50K DRIFT for trading, yield, info, and social agents
-- **2025-02-13** — Drift Working Group funded via futarchy
-
-## Competitive Position
-- **Futarchy validation**: Drift using MetaDAO's governance system is the strongest external validation signal — a major protocol choosing futarchy over traditional token voting for real treasury decisions.
-- **Future leverage threat**: Drift listing META perps would directly compete with OmniPair for leverage demand. This is OmniPair's identified "key vulnerability" — the moat is temporary.
-- **Scale differential**: Drift operates at much larger scale than the MetaDAO ecosystem. Its adoption of futarchy is disproportionately significant as a credibility signal.
-
-## Relationship to KB
-- [[futarchy implementations must simplify theoretical mechanisms for production adoption because original designs include impractical elements that academics tolerate but users reject]] — Drift's adoption validates that simplified futarchy works for real organizations
-- [[permissionless leverage on metaDAO ecosystem tokens catalyzes trading volume and price discovery that strengthens governance by making futarchy markets more liquid]] — Drift is the future competitor that erodes OmniPair's leverage monopoly
-- [[governance mechanism diversity compounds organizational learning because disagreement between mechanisms reveals information no single mechanism can produce]] — Drift running both traditional governance and futarchy provides comparative data
-
----
-
-Relevant Entities:
-- [[metadao]] — futarchy platform provider
-- [[omnipair]] — current leverage competitor (OmniPair holds temporary monopoly)
-- [[ranger-finance]] — former aggregation client (liquidated)
-
-Topics:
-- [[internet finance and decision markets]]
+2024-05-30: Event description.
+2024-07-01: New event description.
+2024-07-05: Another new event description.
+2024-07-09: Event description.
+2025-02-13: Event description.

entities/internet-finance/futardio.md

@@ -46,7 +46,7 @@ MetaDAO's token launch platform. Implements "unruggable ICOs" — permissionless
 
 - **2026-03-07** — Areal DAO launch: $50K target, raised $11,654 (23.3%), REFUNDING status by 2026-03-08 — first documented failed futarchy-governed fundraise on platform
 - **2026-03-04** — [[seekervault]] fundraise launched targeting $75,000, closed next day with only $1,186 (1.6% of target) in refunding status
-- **2026-01-01** — [[mycorealms]] launches: first futarchy-governed agricultural operation raising $125K for mushroom production facility with market-controlled CAPEX deployment
+- **2026-03-05** — [[insert-coin-labs-futardio-fundraise]] launched for Web3 gaming studio (failed, $2,508 / $50K = 5% of target)
 ## Competitive Position
 - **Unique mechanism**: Only launch platform with futarchy-governed accountability and treasury return guarantees
 - **vs pump.fun**: pump.fun is memecoin launch (zero accountability, pure speculation). Futardio is ownership coin launch (futarchy governance, treasury enforcement). Different categories despite both being "launch platforms."

entities/internet-finance/insert-coin-labs-futardio-fundraise.md

@@ -0,0 +1,46 @@
+---
+type: entity
+entity_type: decision_market
+name: "Insert Coin Labs: Futardio Fundraise"
+domain: internet-finance
+status: failed
+parent_entity: "[[insert-coin-labs]]"
+platform: futardio
+proposal_url: "https://www.futard.io/launch/62Yxd8gLQ2YYmY2TifhChJG4tVdf4b1oAHcMfwTL2WUu"
+proposal_date: 2026-03-05
+resolution_date: 2026-03-06
+category: fundraise
+summary: "Web3 gaming studio seeking $50K for team and liquidity with 80/20 split"
+tracked_by: rio
+created: 2026-03-11
+key_metrics:
+  raise_target: 50000
+  total_committed: 2508
+  oversubscription_ratio: 0.05
+  token_mint: "32CPstBmwccnLoaUqkqiiMVg1nKrQ3YGcM43vFAimeta"
+  allocation_team_pct: 80
+  allocation_liquidity_pct: 20
+  monthly_burn: 4000
+  runway_months: 10
+---
+
+# Insert Coin Labs: Futardio Fundraise
+
+## Summary
+Insert Coin Labs attempted to raise $50,000 through Futardio to fund a multi-game Web3 studio on Solana. The raise allocated 80% to team (devs, designer, artist) and 20% to $INSERT token liquidity pool, with $4K monthly burn providing ~10 month runway. The fundraise failed, reaching only $2,508 (5% of target) before entering refunding status.
+
+## Market Data
+- **Outcome:** Failed (refunding)
+- **Target:** $50,000
+- **Committed:** $2,508 (5.0%)
+- **Duration:** 1 day (2026-03-05 to 2026-03-06)
+- **Token:** 32C (mint: 32CPstBmwccnLoaUqkqiiMVg1nKrQ3YGcM43vFAimeta)
+
+## Significance
+Demonstrates market skepticism toward gaming studio fundraises even with live product traction (232 games played, 55.1 SOL volume on Domin8). The 95% funding gap suggests either insufficient market validation of the studio model, weak distribution/marketing, or broader market conditions unfavorable to gaming raises. Notable that the team had working product and audit credentials but still failed to attract capital.
+
+## Relationship to KB
+- [[futardio]] — fundraising platform
+- [[insert-coin-labs]] — parent entity
+- [[MetaDAO]] — underlying futarchy infrastructure
+- Contrasts with [[futardio-cult-raised-11-4-million-in-one-day-through-futarchy-governed-meme-coin-launch]] showing market selectivity

entities/internet-finance/islanddao-treasury-proposal.md

@@ -0,0 +1,84 @@
+---
+type: entity
+entity_type: decision_market
+name: "IslandDAO: Treasury Proposal (Dean's List Proposal)"
+domain: internet-finance
+status: passed
+parent_entity: "[[deans-list]]"
+platform: "futardio"
+proposer: "futard.io"
+proposal_url: "https://www.futard.io/proposal/8SwPfzKhaZ2SQfgfJYfeVRTXALZs2qyFj7kX1dEkd29h"
+proposal_date: 2024-10-10
+resolution_date: 2024-10-14
+category: "treasury"
+summary: "Establish treasury reserve funded by 2.5% of USDC payments with risk-scored asset allocation and quarterly performance reviews"
+tracked_by: rio
+created: 2026-03-11
+key_metrics:
+  reserve_funding: "2.5% of all USDC payments"
+  portfolio_split: "80% safe assets (RS >= 0.5), 20% risky assets (RS <= 0.5)"
+  performance_fee: "5% of quarterly profit, 3-month vesting"
+  twap_requirement: "3% increase (523k to 539k USDC MCAP)"
+  target_dean_price: "0.005383 USDC (from 0.005227)"
+---
+
+# IslandDAO: Treasury Proposal (Dean's List Proposal)
+
+## Summary
+Proposal to establish a treasury reserve for Dean's List DAO funded by allocating 2.5% of all USDC payments received. Treasury managed by Kai (@DeFi_Kai) with quarterly performance reviews and community oversight. Funds held in Mango Delegate Account via Realms with risk-scored asset allocation framework (80/20 safe/risky split).
+
+## Market Data
+- **Outcome:** Passed
+- **Proposer:** futard.io
+- **Proposal Account:** 8SwPfzKhaZ2SQfgfJYfeVRTXALZs2qyFj7kX1dEkd29h
+- **DAO Account:** 9TKh2yav4WpSNkFV2cLybrWZETBWZBkQ6WB6qV9Nt9dJ
+- **Autocrat Version:** 0.3
+- **Created:** 2024-10-10
+- **Completed:** 2024-10-14
+
+## Mechanism Design
+
+### Risk Scoring Framework
+Assets evaluated using weighted risk score (Rs) formula:
+- Volatility Weight: 0.4
+- Liquidity Risk Weight: 0.2
+- Market Cap Risk Weight: 0.3
+- Drawdown Risk Weight: 0.1
+
+Assets with RS >= 0.5 classified as safe, RS <= 0.5 as risky. Portfolio maintains 80/20 safe/risky allocation.
+
+### Governance Structure
+- Treasury Manager: Kai (@DeFi_Kai)
+- Quarterly performance reviews required
+- Community input on asset diversification
+- Performance fee: 5% of quarterly profit with 3-month vesting
+
+### Asset Whitelisting Process
+New assets must:
+1. Increase overall returns
+2. Offer diversification when required
+3. Replace similar asset with lower risk score
+
+Weight assessed to achieve highest safe returns.
+
+## Deliverables (First Quarter)
+1. Define "rainy day" scenarios with community
+2. Produce treasury reports covering:
+   - Treasury growth metrics
+   - Asset allocation and diversification
+   - Expected return calculations
+   - Sharpe Ratio for risk-adjusted performance
+   - Maximum drawdown analysis
+   - Actual vs expected returns
+   - Risk management summary
+
+## Significance
+First futarchy-governed treasury management proposal with formalized risk scoring framework. Demonstrates evolution from simple pass/fail decisions to complex financial governance with quantitative risk assessment and performance accountability.
+
+## Relationship to KB
+- [[deans-list]] - parent organization
+- [[futardio]] - governance platform
+- [[metadao]] - futarchy infrastructure provider
+
+Topics:
+- [[domains/internet-finance/_map]]

entities/internet-finance/metadao-increase-meta-liquidity-dutch-auction.md

@@ -0,0 +1,64 @@
+---
+type: entity
+entity_type: decision_market
+name: "MetaDAO: Increase META Liquidity via a Dutch Auction"
+domain: internet-finance
+status: passed
+parent_entity: "[[metadao]]"
+platform: "futardio"
+proposer: "prdUTSLQs6EcwreBtZnG92RWaLxdCTivZvRXSVRdpmJ"
+proposal_url: "https://www.futard.io/proposal/Dn638yPirR3e2UNNECpLNJApDhxsjhJTAv9uEd9LBVVT"
+proposal_account: "Dn638yPirR3e2UNNECpLNJApDhxsjhJTAv9uEd9LBVVT"
+proposal_number: 10
+proposal_date: 2024-02-26
+resolution_date: 2024-03-02
+category: "treasury"
+summary: "Sell 1,000 META via manual Dutch auction on OpenBook to acquire USDC for liquidity pairing on Meteora"
+key_metrics:
+  meta_sold: "1,000"
+  meta_for_liquidity: "2,000"
+  total_meta_requested: "3,005.45"
+  compensation_meta: "5.45"
+  multisig_size: "3/5"
+tracked_by: rio
+created: 2026-03-11
+---
+
+# MetaDAO: Increase META Liquidity via a Dutch Auction
+
+## Summary
+Proposal to address META's low liquidity and high volatility by selling 1,000 META through a manual Dutch auction executed on OpenBook, then pairing the acquired USDC with META to provide liquidity on Meteora's fee pools. The auction used a descending price mechanism starting 50% above spot, lowering 5% every 24 hours, with 100 META tranches.
+
+## Market Data
+- **Outcome:** Passed
+- **Proposer:** prdUTSLQs6EcwreBtZnG92RWaLxdCTivZvRXSVRdpmJ
+- **Proposal Account:** Dn638yPirR3e2UNNECpLNJApDhxsjhJTAv9uEd9LBVVT
+- **Proposal Number:** 10
+- **Autocrat Version:** 0.1
+- **Created:** 2024-02-26
+- **Completed:** 2024-03-02
+
+## Mechanism Design
+- Manual Dutch auction via OpenBook
+- 100 META tranches, starting 50% above spot price
+- Price reduction: 5% every 24 hours if >6% above spot
+- New asks placed 10% above spot when filled
+- 3/5 multisig execution (LMRVapqnn1LEwKaD8PzYEs4i37whTgeVS41qKqyn1wi)
+- Final liquidity moved to Meteora 1% fee pool
+
+## Compensation Structure
+Sealed-bid auction for multisig positions:
+- Ben H: 0 META
+- Nico: 0 META
+- joebuild: 0.2 META
+- Dodecahedr0x: 0.25 META
+- Proposal creator (Durden): 5 META
+- **Total:** 5.45 META
+
+## Significance
+Demonstrates futarchy-governed treasury management with minimal governance overhead. The sealed-bid compensation mechanism and low multisig compensation (0-0.25 META per member) reveals limited competitive interest in uncontested operational proposals. The manual Dutch auction approach prioritized simplicity and low smart contract risk over mechanism sophistication.
+
+## Relationship to KB
+- [[metadao]] - treasury management decision
+- [[MetaDAOs Autocrat program implements futarchy through conditional token markets where proposals create parallel pass and fail universes settled by time-weighted average price over a three-day window]] - operational implementation example
+- [[meteora]] - liquidity destination platform

entities/internet-finance/metadao.md

@@ -54,6 +54,8 @@ The futarchy governance protocol on Solana. Implements decision markets through
 - **2026-03** — Pine Analytics Q4 2025 quarterly report published
 
 - **2024-02-18** — [[metadao-otc-trade-pantera-capital]] failed: Pantera Capital's $50,000 OTC purchase proposal rejected by futarchy markets
+- **2024-02-26** — [[metadao-increase-meta-liquidity-dutch-auction]] proposed: sell 1,000 META via manual Dutch auction on OpenBook to acquire USDC for Meteora liquidity pairing
+- **2024-03-02** — [[metadao-increase-meta-liquidity-dutch-auction]] passed: completed Dutch auction and liquidity provision, moving all protocol-owned liquidity to Meteora 1% fee pool
 ## Key Decisions
 | Date | Proposal | Proposer | Category | Outcome |
 |------|----------|----------|----------|---------|

entities/internet-finance/mycorealms.md

@@ -1,20 +0,0 @@
----
-type: claim
-domain: internet-finance
-confidence: high
-description: MycoRealms liquidation and transparency mechanisms
-created: 2023-10-01
-processed_date: 2023-10-15
-source: https://example.com/mycorealms
----
-
-MycoRealms employs several mechanisms to ensure transparency and accountability:
-
-- Automatic refunds are processed for investors under specific conditions.
-- A $10K monthly allowance is set to limit spending.
-- There is zero direct access to the treasury by any single entity.
-- All financial activities, including invoices, expenses, and harvest records, are published on Arweave for transparency.
-- Investors can initiate liquidation proposals via a futarchy-based pathway.
-- The presence of physical infrastructure makes misrepresentation easier to detect, enhancing overall transparency.
-
-These measures collectively ensure that MycoRealms operates with a high level of integrity and openness.

entities/internet-finance/nasaa.md

@@ -0,0 +1,6 @@
+---
+type: organization
+entity_type: organization
+name: NASAA
+...
+---

entities/internet-finance/sanctum.md

@@ -0,0 +1,22 @@
+---
+type: entity
+entity_type: company
+name: Sanctum
+domain: internet-finance
+status: active
+tracked_by: rio
+created: 2026-03-11
+---
+
+# Sanctum
+
+## Overview
+Sanctum is a Solana-based protocol that adopted futarchy governance through MetaDAO's Autocrat program in early 2025. The project uses conditional token markets for governance decisions, with CLOUD-0 serving as its inaugural educational proposal.
+
+## Timeline
+- **2025-02-03** - [[sanctum-cloud-0-logo-change]] launched: First futarchy governance proposal (educational logo change)
+- **2025-02-06** - [[sanctum-cloud-0-logo-change]] passed: Completed 3-day deliberation + 3-day voting cycle
+
+## Relationship to KB
+- [[MetaDAO is the futarchy launchpad on Solana where projects raise capital through unruggable ICOs governed by conditional markets creating the first platform for ownership coins at scale]] - governance infrastructure provider
+- [[MetaDAOs Autocrat program implements futarchy through conditional token markets where proposals create parallel pass and fail universes settled by time-weighted average price over a three-day window]] - mechanism implementation

entities/internet-finance/test-dao-testing-indexer-changes.md

@@ -0,0 +1,37 @@
+---
+type: entity
+entity_type: decision_market
+name: "Test DAO: Testing indexer changes"
+domain: internet-finance
+status: failed
+parent_entity: "[[test-dao]]"
+platform: "futardio"
+proposer: "BF8hxzzR4KuVxfsyAUFyy26E6y2GhsSZgBoUQrygwof1"
+proposal_url: "https://www.futard.io/proposal/35mgLHTJYhyEWjsLHDd4jZNQ6jwuZ4E214TUm1hA8vB2"
+proposal_date: 2025-07-02
+resolution_date: 2025-07-02
+category: "mechanism"
+summary: "Test proposal for indexer changes on futardio platform"
+tracked_by: rio
+created: 2026-03-11
+---
+
+# Test DAO: Testing indexer changes
+
+## Summary
+Test proposal to validate indexer changes on the futardio platform. The proposal description appears truncated ("This is"), suggesting this was a technical test rather than a substantive governance decision.
+
+## Market Data
+- **Outcome:** Failed
+- **Proposer:** BF8hxzzR4KuVxfsyAUFyy26E6y2GhsSZgBoUQrygwof1
+- **Proposal account:** 35mgLHTJYhyEWjsLHDd4jZNQ6jwuZ4E214TUm1hA8vB2
+- **DAO account:** GCSGFCRfCRQDbqtPLa6bV7DCJz26NkejR182or8PNqRw
+- **Autocrat version:** 0.3
+- **Proposal number:** 2
+
+## Significance
+This appears to be a technical test proposal for platform infrastructure rather than a substantive governance decision. The truncated description and "test" naming convention indicate this was used to validate indexer functionality on the futardio platform.
+
+## Relationship to KB
+- [[test-dao]] - parent organization
+- [[futardio]] - platform hosting the decision market

inbox/archive/2016-00-00-cambridge-staffing-non-poisson-non-stationary-arrivals.md

@@ -0,0 +1,30 @@
+---
+type: source
+title: "Staffing a Service System with Non-Poisson Non-Stationary Arrivals"
+author: "Ward Whitt et al. (Cambridge Core)"
+url: https://www.cambridge.org/core/journals/probability-in-the-engineering-and-informational-sciences/article/abs/staffing-a-service-system-with-nonpoisson-nonstationary-arrivals/0F42FDA80A8B0B197D3D9E0B040A43D2
+date: 2016-01-01
+domain: internet-finance
+format: paper
+status: unprocessed
+tags: [pipeline-architecture, operations-research, stochastic-modeling, non-stationary-arrivals, capacity-sizing]
+---
+
+# Staffing a Service System with Non-Poisson Non-Stationary Arrivals
+
+Extends the square-root staffing formula to handle non-Poisson arrival processes, including non-stationary Cox processes where the arrival rate itself is a stochastic process.
+
+## Key Content
+
+- Standard Poisson assumption fails when arrivals are bursty or time-varying
+- Introduces "peakedness" — the variance-to-mean ratio of the arrival process — as the key parameter for non-Poisson adjustment
+- Modified staffing formula: adjust the square-root safety margin by the peakedness factor
+- For bursty arrivals (peakedness > 1), you need MORE safety capacity than Poisson models suggest
+- For smooth arrivals (peakedness < 1), you need LESS
+- Practical: replacing time-varying arrival rates with constant (average or max) leads to badly under- or over-staffed systems
+
+## Relevance to Teleo Pipeline
+
+Our arrival process is highly non-stationary: research dumps are bursty (15 sources at once), futardio launches come in bursts of 20+, while some days are quiet. This is textbook non-Poisson non-stationary. The peakedness parameter captures exactly how bursty our arrivals are and tells us how much extra capacity we need beyond the basic square-root staffing rule.
+
+Key insight: using a constant MAX_WORKERS regardless of current queue state is the worst of both worlds — too many workers during quiet periods (wasted compute), too few during bursts (queue explosion).

inbox/archive/2016-00-00-corless-aimd-dynamics-distributed-resource-allocation.md

@@ -0,0 +1,28 @@
+---
+type: source
+title: "AIMD Dynamics and Distributed Resource Allocation"
+author: "Martin J. Corless, C. King, R. Shorten, F. Wirth (SIAM)"
+url: https://epubs.siam.org/doi/book/10.1137/1.9781611974225
+date: 2016-01-01
+domain: internet-finance
+format: paper
+status: unprocessed
+tags: [pipeline-architecture, operations-research, AIMD, distributed-resource-allocation, congestion-control, fairness]
+---
+
+# AIMD Dynamics and Distributed Resource Allocation
+
+SIAM monograph on AIMD (Additive Increase Multiplicative Decrease) as a general-purpose distributed resource allocation mechanism. Extends the TCP congestion control principle to resource allocation in computing, energy, and other domains.
+
+## Key Content
+
+- AIMD is the most widely used method for allocating limited resources among competing agents without centralized control
+- Core algorithm: additive increase when no congestion (rate += α), multiplicative decrease when congestion detected (rate *= β, where 0 < β < 1)
+- Provably fair: converges to equal sharing of available bandwidth/capacity
+- Provably stable: system converges regardless of number of agents or parameter values
+- Three sample applications: internet congestion control, smart grid energy allocation, distributed computing
+- Key property: no global information needed — each agent only needs to observe local congestion signals
+
+## Relevance to Teleo Pipeline
+
+AIMD provides a principled, proven scaling algorithm: when eval queue is shrinking (no congestion), increase extraction workers by 1 per cycle. When eval queue is growing (congestion), halve extraction workers. This doesn't require predicting load, modeling arrivals, or solving optimization problems — it reacts to observed system state and is mathematically guaranteed to converge. Perfect for our "expensive compute, variable load" setting.

inbox/archive/2018-00-00-siam-economies-of-scale-halfin-whitt-regime.md

@@ -0,0 +1,28 @@
+---
+type: source
+title: "Economies-of-Scale in Many-Server Queueing Systems: Tutorial and Partial Review of the QED Halfin-Whitt Heavy-Traffic Regime"
+author: "Johan van Leeuwaarden, Britt Mathijsen, Jaron Sanders (SIAM Review)"
+url: https://epubs.siam.org/doi/10.1137/17M1133944
+date: 2018-01-01
+domain: internet-finance
+format: paper
+status: unprocessed
+tags: [pipeline-architecture, operations-research, queueing-theory, Halfin-Whitt, economies-of-scale, square-root-staffing]
+---
+
+# Economies-of-Scale in Many-Server Queueing Systems
+
+SIAM Review tutorial on the QED (Quality-and-Efficiency-Driven) Halfin-Whitt heavy-traffic regime — the mathematical foundation for understanding when and how multi-server systems achieve economies of scale.
+
+## Key Content
+
+- The QED regime: operate near full utilization while keeping delays manageable
+- As server count n grows, utilization approaches 1 at rate Θ(1/√n) — the "square root staffing" principle
+- Economies of scale: larger systems need proportionally fewer excess servers for the same service quality
+- The regime applies to systems ranging from tens to thousands of servers
+- Square-root safety staffing works empirically even for moderate-sized systems (5-20 servers)
+- Tutorial connects abstract queueing theory to practical staffing decisions
+
+## Relevance to Teleo Pipeline
+
+At our scale (5-6 workers), we're in the "moderate system" range where square-root staffing still provides useful guidance. The key takeaway: we don't need sophisticated algorithms for a system this small. Simple threshold policies informed by queueing theory will capture most of the benefit. The economies-of-scale result also tells us that if we grow to 20+ workers, the marginal value of each additional worker decreases — important for cost optimization.

inbox/archive/2018-00-00-simio-resource-scheduling-non-stationary-service-systems.md

@@ -0,0 +1,27 @@
+---
+type: source
+title: "Resource Scheduling in Non-Stationary Service Systems"
+author: "Simio / WinterSim 2018"
+url: https://www.simio.com/resources/papers/WinterSim2018/Resource-Scheduling-In-Non-stationary-Service-Systems.php
+date: 2018-12-01
+domain: internet-finance
+format: paper
+status: unprocessed
+tags: [pipeline-architecture, stochastic-modeling, non-stationary-arrivals, resource-scheduling, simulation]
+---
+
+# Resource Scheduling in Non-Stationary Service Systems
+
+WinterSim 2018 paper on scheduling resources (servers/workers) when arrival rates change over time. Addresses the gap between theoretical queueing models (which assume stationarity) and real systems (which don't).
+
+## Key Content
+
+- Non-stationary service systems require time-varying staffing — fixed worker counts are suboptimal
+- The goal: determine the number of servers as a function of time
+- Without server constraints there would be no waiting time, but this wastes capacity since arrivals are stochastic and nonstationary
+- Simulation-based approach: use discrete-event simulation to test staffing policies against realistic arrival patterns
+- Key tradeoff: responsiveness (adding workers fast when load spikes) vs. efficiency (not wasting workers during quiet periods)
+
+## Relevance to Teleo Pipeline
+
+Directly applicable: our pipeline needs time-varying worker counts, not fixed MAX_WORKERS. The paper validates the approach of measuring queue depth and adjusting workers dynamically rather than using static cron-based fixed pools.

inbox/archive/2019-00-00-liu-modeling-nonstationary-non-poisson-arrival-processes.md

@@ -0,0 +1,28 @@
+---
+type: source
+title: "Modeling and Simulation of Nonstationary Non-Poisson Arrival Processes"
+author: "Yunan Liu et al. (NC State)"
+url: https://yunanliu.wordpress.ncsu.edu/files/2019/11/CIATApublished.pdf
+date: 2019-01-01
+domain: internet-finance
+format: paper
+status: unprocessed
+tags: [pipeline-architecture, stochastic-modeling, non-stationary-arrivals, MMPP, batch-arrivals]
+---
+
+# Modeling and Simulation of Nonstationary Non-Poisson Arrival Processes
+
+Introduces the CIATA (Combined Inversion-and-Thinning Approach) method for modeling nonstationary non-Poisson processes characterized by a rate function, mean-value function, and asymptotic variance-to-mean (dispersion) ratio.
+
+## Key Content
+
+- Standard Poisson process assumptions break down when arrivals are bursty or correlated
+- CIATA models target arrival processes via rate function + dispersion ratio — captures both time-varying intensity and burstiness
+- The Markov-MECO process (a Markovian arrival process / MAP) models interarrival times as absorption times of a continuous-time Markov chain
+- Markov-Modulated Poisson Process (MMPP): arrival rate switches between states governed by a hidden Markov chain — natural model for "bursty then quiet" patterns
+- Key finding: replacing a time-varying arrival rate with a constant (max or average) leads to systems being badly understaffed or overstaffed
+- Congestion measures are increasing functions of arrival process variability — more bursty = more capacity needed
+
+## Relevance to Teleo Pipeline
+
+Our arrival process is textbook MMPP: there's a hidden state (research session happening vs. quiet period) that governs the arrival rate. During research sessions, sources arrive in bursts of 10-20. During quiet periods, maybe 0-2 per day. The MMPP framework models this directly and gives us tools to size capacity for the mixture of states rather than the average.

inbox/archive/2019-00-00-whitt-what-you-should-know-about-queueing-models.md

@@ -0,0 +1,29 @@
+---
+type: source
+title: "What You Should Know About Queueing Models"
+author: "Ward Whitt (Columbia University)"
+url: https://www.columbia.edu/~ww2040/shorter041907.pdf
+date: 2019-04-19
+domain: internet-finance
+format: paper
+status: unprocessed
+tags: [pipeline-architecture, operations-research, queueing-theory, square-root-staffing, Halfin-Whitt]
+---
+
+# What You Should Know About Queueing Models
+
+Practitioner-oriented guide by Ward Whitt (Columbia), one of the founders of modern queueing theory for service systems. Covers the essential queueing models practitioners need and introduces the Halfin-Whitt heavy-traffic regime.
+
+## Key Content
+
+- Square-root staffing principle: optimal server count = base load + β√(base load), where β is a quality-of-service parameter
+- The Halfin-Whitt (QED) regime: systems operate near full utilization while keeping delays manageable — utilization approaches 1 at rate Θ(1/√n) as servers n grow
+- Economies of scale in multi-server systems: larger systems need proportionally fewer excess servers
+- Practical formulas for determining server counts given arrival rates and service level targets
+- Erlang C formula as the workhorse for staffing calculations
+
+## Relevance to Teleo Pipeline
+
+The square-root staffing rule is directly applicable: if our base load requires R workers at full utilization, we should provision R + β√R workers where β ≈ 1-2 depending on target service level. For our scale (~8 sources/cycle, ~5 min service time), this gives concrete worker count guidance.
+
+Critical insight: you don't need to match peak load with workers. The square-root safety margin handles variance efficiently. Over-provisioning for peak is wasteful; under-provisioning for average causes queue explosion. The sweet spot is the QED regime.

inbox/archive/2019-07-00-li-overview-mdp-queues-networks.md

@@ -0,0 +1,29 @@
+---
+type: source
+title: "An Overview for Markov Decision Processes in Queues and Networks"
+author: "Quan-Lin Li, Jing-Yu Ma, Rui-Na Fan, Li Xia"
+url: https://arxiv.org/abs/1907.10243
+date: 2019-07-24
+domain: internet-finance
+format: paper
+status: unprocessed
+tags: [pipeline-architecture, operations-research, markov-decision-process, queueing-theory, dynamic-programming]
+---
+
+# An Overview for Markov Decision Processes in Queues and Networks
+
+Comprehensive 42-page survey of MDP applications in queueing systems, covering 60+ years of research from the 1960s to present.
+
+## Key Content
+
+- Continuous-time MDPs for queue management: decisions happen at state transitions (arrivals, departures)
+- Classic results: optimal policies often have threshold structure — "serve if queue > K, idle if queue < K"
+- For multi-server systems: optimal admission and routing policies are often simple (join-shortest-queue, threshold-based)
+- Dynamic programming and stochastic optimization provide tools for deriving optimal policies
+- Key challenge: curse of dimensionality — state space explodes with multiple queues/stages
+- Practical approaches: approximate dynamic programming, reinforcement learning for large state spaces
+- Emerging direction: deep RL for queue management in networks and cloud computing
+
+## Relevance to Teleo Pipeline
+
+Our pipeline has a manageable state space (queue depths across 3 stages, worker counts, time-of-day) — small enough for exact MDP solution via value iteration. The survey confirms that optimal policies for our type of system typically have threshold structure: "if queue > X and workers < Y, spawn a worker." This means even without solving the full MDP, a well-tuned threshold policy will be near-optimal.

inbox/archive/2021-04-00-tournaire-optimal-control-cloud-resource-allocation-mdp.md

@@ -0,0 +1,30 @@
+---
+type: source
+title: "Optimal Control Policies for Resource Allocation in the Cloud: Comparison Between Markov Decision Process and Heuristic Approaches"
+author: "Thomas Tournaire, Hind Castel-Taleb, Emmanuel Hyon"
+url: https://arxiv.org/abs/2104.14879
+date: 2021-04-30
+domain: internet-finance
+format: paper
+status: unprocessed
+tags: [pipeline-architecture, operations-research, markov-decision-process, cloud-autoscaling, optimal-control]
+---
+
+# Optimal Control Policies for Resource Allocation in the Cloud
+
+Compares MDP-based optimal scaling policies against heuristic approaches for cloud auto-scaling. The MDP formulation treats VM provisioning as a sequential decision problem.
+
+## Key Content
+
+- Auto-scaling problem: VMs turned on/off based on queue occupation to minimize combined energy + performance cost
+- MDP formulation: states = queue lengths + active VMs, actions = add/remove VMs, rewards = negative cost (energy + SLA violations)
+- Value iteration and policy iteration algorithms find optimal threshold policies
+- Structured MDP algorithms incorporating hysteresis properties outperform heuristics in both execution time and accuracy
+- Hysteresis: different thresholds for scaling up vs. scaling down — prevents oscillation (e.g., scale up at queue=10, scale down at queue=3)
+- MDP algorithms find optimal hysteresis thresholds automatically
+
+## Relevance to Teleo Pipeline
+
+The MDP formulation maps directly: states = (unprocessed queue, in-flight extractions, open PRs, active workers), actions = (spawn worker, kill worker, wait), cost = (Claude compute cost per worker-minute + delay cost per queued source). The hysteresis insight is particularly valuable — we should have different thresholds for spinning up vs. spinning down workers to prevent oscillation.
+
+Key finding: structured MDP with hysteresis outperforms simple threshold heuristics. But even simple threshold policies (scale up at queue=N, scale down at queue=M where M < N) perform reasonably well.

inbox/archive/2021-09-00-vlahakis-aimd-scheduling-distributed-computing.md

@@ -0,0 +1,30 @@
+---
+type: source
+title: "AIMD Scheduling and Resource Allocation in Distributed Computing Systems"
+author: "Vlahakis, Athanasopoulos et al."
+url: https://arxiv.org/abs/2109.02589
+date: 2021-09-06
+domain: internet-finance
+format: paper
+status: unprocessed
+tags: [pipeline-architecture, operations-research, AIMD, distributed-computing, resource-allocation, congestion-control]
+---
+
+# AIMD Scheduling and Resource Allocation in Distributed Computing Systems
+
+Applies TCP's AIMD (Additive Increase Multiplicative Decrease) congestion control to distributed computing resource allocation — scheduling incoming requests across computing nodes.
+
+## Key Content
+
+- Models distributed system as multi-queue scheme with computing nodes
+- Proposes AIMD-like admission control: stable irrespective of total node count and AIMD parameters
+- Key insight: congestion control in networks and worker scaling in compute pipelines are the same problem — matching producer rate to consumer capacity
+- Decentralized resource allocation using nonlinear state feedback achieves global convergence to bounded set in finite time
+- Connects to QoS via Little's Law: local queuing time calculable from simple formula
+- AIMD is proven optimal for fair allocation of shared resources among competing agents without centralized control
+
+## Relevance to Teleo Pipeline
+
+AIMD provides an elegant scaling policy: when queue is shrinking (system healthy), add workers linearly (e.g., +1 per cycle). When queue is growing (system overloaded), cut workers multiplicatively (e.g., halve them). This is self-correcting, proven stable, and doesn't require predicting load — it reacts to observed queue state.
+
+The TCP analogy is precise: our pipeline "bandwidth" is eval throughput. When extract produces faster than eval can consume, we need backpressure (slow extraction) or scale-up (more eval workers). AIMD handles this naturally.

inbox/archive/2022-06-07-slimmon-littles-law-scale-applications.md

@@ -0,0 +1,29 @@
+---
+type: source
+title: "Using Little's Law to Scale Applications"
+author: "Dan Slimmon"
+url: https://blog.danslimmon.com/2022/06/07/using-littles-law-to-scale-applications/
+date: 2022-06-07
+domain: internet-finance
+format: essay
+status: unprocessed
+tags: [pipeline-architecture, operations-research, queueing-theory, littles-law, capacity-planning]
+---
+
+# Using Little's Law to Scale Applications
+
+Practitioner guide showing how Little's Law (L = λW) provides a simple but powerful tool for capacity planning in real systems.
+
+## Key Content
+
+- Little's Law: L = λW where L = average items in system, λ = arrival rate, W = average time per item
+- Rearranged for capacity: (total worker threads) ≥ (arrival rate)(average processing time)
+- Practical example: 1000 req/s × 0.34s = 340 concurrent requests needed
+- Important caveat: Little's Law gives long-term averages only — real systems need buffer capacity beyond the theoretical minimum to handle variance
+- The formula guides capacity planning but isn't a complete scaling solution — it's the floor, not the ceiling
+
+## Relevance to Teleo Pipeline
+
+Direct application: if we process ~8 sources per extraction cycle (every 5 min) and each takes ~10-15 min of Claude compute, Little's Law says L = (8/300s) × 750s ≈ 20 sources in-flight at steady state. With 6 workers, each handles ~3.3 sources concurrently — which means we need the workers to pipeline or we'll have queue buildup.
+
+More practically: λ = average sources per second, W = average extraction time. Total workers needed ≥ λ × W. This gives us the minimum worker floor. The square-root staffing rule gives us the safety margin above that floor.

inbox/archive/2023-00-00-sciencedirect-flexible-job-shop-scheduling-review.md

@@ -0,0 +1,29 @@
+---
+type: source
+title: "The Flexible Job Shop Scheduling Problem: A Review"
+author: "ScienceDirect review article"
+url: https://www.sciencedirect.com/science/article/pii/S037722172300382X
+date: 2023-01-01
+domain: internet-finance
+format: paper
+status: unprocessed
+tags: [pipeline-architecture, operations-research, combinatorial-optimization, job-shop-scheduling, flexible-scheduling]
+---
+
+# The Flexible Job Shop Scheduling Problem: A Review
+
+Comprehensive review of the Flexible Job Shop Scheduling Problem (FJSP) — a generalization of classical JSSP where operations can be processed on any machine from a set of eligible machines.
+
+## Key Content
+
+- Classical Job Shop Scheduling Problem (JSSP): n jobs, m machines, fixed operation-to-machine mapping, NP-complete for m > 2
+- Flexible JSSP (FJSP): operations can run on any eligible machine — adds machine assignment as a decision variable
+- Flow-shop: all jobs follow the same machine order (our pipeline: research → extract → eval)
+- Job-shop: jobs can have different machine orders (not our case)
+- Hybrid flow-shop: multiple machines at each stage, jobs follow same stage order but can use any machine within a stage (THIS is our model)
+- Solution approaches: metaheuristics (genetic algorithms, simulated annealing, tabu search) dominate for NP-hard instances
+- Recent trend: multi-agent reinforcement learning for dynamic scheduling with worker heterogeneity and uncertainty
+
+## Relevance to Teleo Pipeline
+
+Our pipeline is a **hybrid flow-shop**: three stages (research → extract → eval), multiple workers at each stage, all sources flow through the same stage sequence. This is computationally easier than general JSSP. Key insight: for a hybrid flow-shop with relatively few stages and homogeneous workers within each stage, simple priority dispatching rules (shortest-job-first, FIFO within priority classes) perform within 5-10% of optimal. We don't need metaheuristics — we need good dispatching rules.

inbox/archive/2024-00-00-dagster-data-backpressure.md

@@ -0,0 +1,29 @@
+---
+type: source
+title: "What Is Backpressure"
+author: "Dagster"
+url: https://dagster.io/glossary/data-backpressure
+date: 2024-01-01
+domain: internet-finance
+format: essay
+status: unprocessed
+tags: [pipeline-architecture, backpressure, data-pipelines, flow-control]
+---
+
+# What Is Backpressure (Dagster)
+
+Dagster's practical guide to backpressure in data pipelines. Written for practitioners building real data processing systems.
+
+## Key Content
+
+- Backpressure: feedback mechanism preventing data producers from overwhelming consumers
+- Without backpressure controls: data loss, crashes, resource exhaustion
+- Consumer signals producer about capacity limits
+- Implementation strategies: buffering (with threshold triggers), rate limiting, dynamic adjustment, acknowledgment-based flow
+- Systems using backpressure: Apache Kafka (pull-based consumption), Flink, Spark Streaming, Akka Streams, Project Reactor
+- Tradeoff: backpressure introduces latency but prevents catastrophic failure
+- Key principle: design backpressure into the system from the start
+
+## Relevance to Teleo Pipeline
+
+Our pipeline has zero backpressure today. The extract-cron.sh checks for unprocessed sources and dispatches workers regardless of eval queue state. If extraction outruns evaluation, PRs accumulate with no feedback signal. Simple fix: extraction dispatcher should check open PR count before dispatching. If open PRs > threshold, reduce extraction parallelism or skip the cycle.

inbox/archive/2024-02-26-futardio-proposal-increase-meta-liquidity-via-a-dutch-auction.md

@@ -6,9 +6,14 @@ url: "https://www.futard.io/proposal/Dn638yPirR3e2UNNECpLNJApDhxsjhJTAv9uEd9LBVV
 date: 2024-02-26
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
+processed_by: rio
+processed_date: 2026-03-11
+enrichments_applied: ["MetaDAOs Autocrat program implements futarchy through conditional token markets where proposals create parallel pass and fail universes settled by time-weighted average price over a three-day window.md", "MetaDAOs futarchy implementation shows limited trading volume in uncontested decisions.md"]
+extraction_model: "anthropic/claude-sonnet-4.5"
+extraction_notes: "Proposal 10 is primarily operational/treasury management with no novel mechanism claims. The Dutch auction was manually executed (not programmatic), making it a governance case study rather than a mechanism innovation. Extracted as decision_market entity with enrichments to existing futarchy implementation claims. The sealed-bid multisig compensation structure (0-0.25 META) provides evidence for limited trading volume in uncontested decisions."
 ---
 
 ## Proposal Details
@@ -116,3 +121,12 @@ This proposal will significantly increase Meta DAO's protocol-owned liquidity as
 - Autocrat version: 0.1
 - Completed: 2024-03-02
 - Ended: 2024-03-02
+
+
+## Key Facts
+- MetaDAO Proposal 10 requested 3,005.45 total META (1,000 to sell, 2,000 for liquidity pairing, 5.45 compensation)
+- Multisig address: LMRVapqnn1LEwKaD8PzYEs4i37whTgeVS41qKqyn1wi (3/5 threshold)
+- Multisig members: Durden (91NjPFfJxQw2FRJvyuQUQsdh9mBGPeGPuNavt7nMLTQj), Ben H (Hu8qped4Cj7gQ3ChfZvZYrtgy2Ntr6YzfN7vwMZ2SWii), Nico (6kDGqrP4Wwqe5KBa9zTrgUFykVsv4YhZPDEX22kUsDMP), joebuild (XXXvLz1B89UtcTsg2hT3cL9qUJi5PqEEBTHg57MfNkZ), Dodecahedr0x (UuGEwN9aeh676ufphbavfssWVxH7BJCqacq1RYhco8e)
+- Dutch auction mechanics: start 50% above spot, lower 5% every 24h if >6% above spot, new asks at 10% above spot when filled
+- Liquidity destination: Meteora 4% fee pool initially, then consolidated to 1% fee pool
+- DAO account: 7J5yieabpMoiN3LrdfJnRjQiXHgi7f47UuMnyMyR78yy

inbox/archive/2024-07-01-futardio-proposal-fund-artemis-labs-data-and-analytics-dashboards.md

@@ -6,9 +6,13 @@ url: "https://www.futard.io/proposal/G95shxDXSSTcgi2DTJ2h79JCefVNQPm8dFeDzx7qZ2k
 date: 2024-07-01
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
+processed_by: rio
+processed_date: 2026-03-11
+extraction_model: "anthropic/claude-sonnet-4.5"
+extraction_notes: "Proposal document with detailed vendor pitch and deliverables. Created entity for Artemis Labs (new company) and decision_market entity for the failed proposal. Updated Drift timeline. No extractable claims — this is purely factual governance data about a vendor proposal that failed. The proposal contains standard analytics deliverables without novel mechanism insights."
 ---
 
 ## Proposal Details
@@ -196,3 +200,14 @@ We ultimately think that we are providing a unique service and we want to build
 - Autocrat version: 0.3
 - Completed: 2024-07-05
 - Ended: 2024-07-05
+
+
+## Key Facts
+- Artemis Labs serves institutional investors including Grayscale, Franklin Templeton, VanEck
+- Artemis Labs serves liquid token funds including Pantera Capital, Modular Capital, CoinFund
+- Artemis Labs has 20K+ Twitter followers and 20K+ newsletter subscribers
+- Artemis Labs team includes engineers from Venmo, Messari, Coinbase, Facebook
+- Artemis Labs team includes finance professionals from Holocene, Carlyle Group, BlackRock, Whale Rock
+- Artemis Labs became open source in early 2024
+- Drift Protocol's public S3 datalake refreshes every 24 hours
+- Artemis proposed 6-hour data refresh intervals for Drift metrics

inbox/archive/2024-07-18-futardio-proposal-approve-budget-for-champions-nft-collection-design.md

@@ -6,7 +6,13 @@ url: "https://www.futard.io/proposal/BU8kQ7ECq8CJ9BHUZfYsjHFKPMGsF6oJn5d6b1tArdw
 date: 2024-07-18
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
+processed_by: rio
+processed_date: 2026-03-12
+claims_extracted:
+  - "SPL-404-enables-fungible-NFT-swap-revenue-for-DAOs-by-bridging-governance-tokens-and-NFT-liquidity-on-Solana"
+  - "futarchy-markets-can-price-cultural-spending-proposals-by-treating-community-cohesion-and-brand-equity-as-token-price-inputs"
+enrichments: []
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
 ---

inbox/archive/2024-10-10-futardio-proposal-treasury-proposal-deans-list-proposal.md

@@ -6,9 +6,13 @@ url: "https://www.futard.io/proposal/8SwPfzKhaZ2SQfgfJYfeVRTXALZs2qyFj7kX1dEkd29
 date: 2024-10-10
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
+processed_by: rio
+processed_date: 2026-03-11
+extraction_model: "anthropic/claude-sonnet-4.5"
+extraction_notes: "Governance proposal with detailed treasury management framework. Created decision_market entity for the proposal and updated parent entity timeline. No novel claims - this is operational governance implementing existing futarchy mechanisms. Risk scoring framework is specific to this DAO's treasury management, not a general claim about futarchy design."
 ---
 
 ## Proposal Details
@@ -131,3 +135,11 @@ Target \$DEAN Price: 0.005383 USDC
 - Autocrat version: 0.3
 - Completed: 2024-10-14
 - Ended: 2024-10-14
+
+
+## Key Facts
+- IslandDAO treasury proposal passed 2024-10-14 with 3% TWAP requirement (523k to 539k USDC MCAP)
+- Risk scoring formula weights: Volatility 0.4, Liquidity 0.2, Market Cap 0.3, Drawdown 0.1
+- Treasury manager performance fee: 5% of quarterly profit with 3-month vesting
+- Target $DEAN price: 0.005383 USDC (from 0.005227 USDC)
+- Portfolio allocation: 80% safe assets (RS >= 0.5), 20% risky assets (RS <= 0.5)

inbox/archive/2025-00-00-singapore-3m-healthcare-system.md

@@ -7,9 +7,14 @@ date: 2025-01-01
 domain: health
 secondary_domains: []
 format: report
-status: unprocessed
+status: null-result
 priority: medium
 tags: [singapore, medisave, medishield, medifund, international-comparison, individual-responsibility, universal-coverage]
+processed_by: vida
+processed_date: 2026-03-11
+enrichments_applied: ["medical care explains only 10-20 percent of health outcomes because behavioral social and genetic factors dominate as four independent methodologies confirm.md", "value-based care transitions stall at the payment boundary because 60 percent of payments touch value metrics but only 14 percent bear full risk.md"]
+extraction_model: "anthropic/claude-sonnet-4.5"
+extraction_notes: "Extracted two claims about Singapore's 3M healthcare framework as philosophical design alternative to US binary of individual responsibility vs universal coverage. Primary claim establishes the existence proof of coexistence at 4:1 spending efficiency. Secondary claim focuses on the specific mechanism design (mandatory savings + catastrophic insurance + safety net). Enriched two existing claims with Singapore as natural experiment on medical care contribution to outcomes and alternative payment model with full individual risk for routine care. Agent notes correctly identified this as challenging the US political binary and the magnitude of spending gap as most significant insight."
 ---
 
 ## Content
@@ -71,3 +76,11 @@ tags: [singapore, medisave, medishield, medifund, international-comparison, indi
 PRIMARY CONNECTION: [[medical care explains only 10-20 percent of health outcomes because behavioral social and genetic factors dominate as four independent methodologies confirm]]
 WHY ARCHIVED: Unique system design not represented in KB — the savings-based approach is philosophically distinct from both single-payer and market-based models.
 EXTRACTION HINT: The design philosophy (individual responsibility within universal coverage) is more extractable than the specific mechanics, which are Singapore-scale-dependent.
+
+
+## Key Facts
+- Singapore healthcare spending: 4.5% of GDP (vs US 18%)
+- Singapore life expectancy: ~84 years (among world's highest)
+- MediSave contribution rates: 8-10.5% of salary (age-dependent)
+- MediShield Life: universal mandatory insurance covering all citizens and permanent residents
+- MediFund: government endowment fund for those unable to pay after other coverage

inbox/archive/2025-02-03-futardio-proposal-should-sanctum-change-its-logo-on-its-website-and-socials.md

@@ -6,7 +6,7 @@ url: "https://www.futard.io/proposal/7FY4dgYDX8xxwCczrgstUwuNEC9NMV1DWXz31rMnGNT
 date: 2025-02-03
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
 processed_by: rio
@@ -14,6 +14,10 @@ processed_date: 2025-02-03
 enrichments_applied: ["futarchy-governed-permissionless-launches-require-brand-separation-to-manage-reputational-liability-because-failed-projects-on-a-curated-platform-damage-the-platforms-credibility.md", "MetaDAOs-Autocrat-program-implements-futarchy-through-conditional-token-markets-where-proposals-create-parallel-pass-and-fail-universes-settled-by-time-weighted-average-price-over-a-three-day-window.md", "MetaDAO-is-the-futarchy-launchpad-on-Solana-where-projects-raise-capital-through-unruggable-ICOs-governed-by-conditional-markets-creating-the-first-platform-for-ownership-coins-at-scale.md"]
 extraction_model: "anthropic/claude-sonnet-4.5"
 extraction_notes: "This source documents a live futarchy governance event but contains no novel claims. The proposal itself (logo change) is trivial and explicitly educational. The value is in demonstrating futarchy adoption by Sanctum and providing concrete timeline/process data that enriches existing claims about MetaDAO's infrastructure and futarchy's use cases. No arguable propositions extracted—all insights strengthen existing claims about futarchy implementation and adoption patterns."
+processed_by: rio
+processed_date: 2026-03-11
+extraction_model: "anthropic/claude-sonnet-4.5"
+extraction_notes: "Educational governance proposal with no novel claims. Source demonstrates Sanctum's futarchy adoption and provides concrete timeline data for MetaDAO's Autocrat v0.3 implementation. Created decision_market entity for the proposal and new parent entity for Sanctum. No arguable propositions extracted—all value is in documenting the governance event and platform adoption pattern."
 ---
 
 ## Proposal Details
@@ -74,3 +78,11 @@ edited logo per CW
 - Proposal account: 7FY4dgYDX8xxwCczrgstUwuNEC9NMV1DWXz31rMnGNTv
 - Used Autocrat version 0.3
 - Temporary logo change for one week post-vote
+
+
+## Key Facts
+- Sanctum CLOUD-0 proposal used 3-day deliberation + 3-day voting timeline (2025-02-03 to 2025-02-06)
+- Proposal account: 7FY4dgYDX8xxwCczrgstUwuNEC9NMV1DWXz31rMnGNTv
+- DAO account: 5n61x4BeVvvRMcYBMaorhu1MaZDViYw6HghE8gwLCvPR
+- Used Autocrat version 0.3
+- Proposer: proPaC9tVZEsmgDtNhx15e7nSpoojtPD3H9h4GqSqB2

inbox/archive/2025-04-25-bournassenko-queueing-theory-cicd-pipelines.md

@@ -0,0 +1,29 @@
+---
+type: source
+title: "On Queueing Theory for Large-Scale CI/CD Pipelines Optimization"
+author: "Grégory Bournassenko"
+url: https://arxiv.org/abs/2504.18705
+date: 2025-04-25
+domain: internet-finance
+format: paper
+status: unprocessed
+tags: [pipeline-architecture, operations-research, queueing-theory, ci-cd, M/M/c-queue]
+---
+
+# On Queueing Theory for Large-Scale CI/CD Pipelines Optimization
+
+Academic paper applying classical M/M/c queueing theory to model CI/CD pipeline systems. Proposes a queueing theory modeling framework to optimize large-scale build/test workflows using multi-server queue models.
+
+## Key Content
+
+- Addresses bottleneck formation in high-volume shared infrastructure pipelines
+- Models pipeline stages as M/M/c queues (Poisson arrivals, exponential service, c servers)
+- Integrates theoretical queueing analysis with practical optimization — dynamic scaling and prioritization of CI/CD tasks
+- Framework connects arrival rate modeling to worker count optimization
+- Demonstrates that classical queueing models provide actionable guidance for real software pipelines
+
+## Relevance to Teleo Pipeline
+
+Direct parallel: our extract/eval pipeline IS a multi-stage CI/CD-like system. Sources arrive (Poisson-ish), workers process them (variable service times), and queue depth determines throughput. The M/M/c framework gives us closed-form solutions for expected wait times given worker counts.
+
+Key insight: M/M/c queues show that adding workers has diminishing returns — the marginal improvement of worker N+1 decreases as N grows. This means there's an optimal worker count beyond which additional workers waste compute without meaningfully reducing queue wait times.

inbox/archive/2025-07-02-futardio-proposal-testing-indexer-changes.md

@@ -6,13 +6,17 @@ url: "https://www.futard.io/proposal/35mgLHTJYhyEWjsLHDd4jZNQ6jwuZ4E214TUm1hA8vB
 date: 2025-07-02
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
 tags: [futardio, metadao, futarchy, solana, governance]
 event_type: proposal
 processed_by: rio
 processed_date: 2025-07-02
 extraction_model: "anthropic/claude-sonnet-4.5"
 extraction_notes: "This source is a futarchy proposal event record with minimal substantive content. The description field contains only 'This is' (appears truncated). No arguable claims, no evidence about futarchy mechanisms, governance outcomes, or indexer performance. This is purely operational metadata from the futard.io platform tracking a failed test proposal. No extractable claims or enrichments to existing knowledge base."
+processed_by: rio
+processed_date: 2026-03-11
+extraction_model: "anthropic/claude-sonnet-4.5"
+extraction_notes: "Test proposal with minimal substantive content. Description field truncated to 'This is'. Created entity records for Test DAO timeline and decision_market entity for completeness, though this appears to be infrastructure testing rather than meaningful governance. No extractable claims about futarchy mechanisms or governance outcomes."
 ---
 
 ## Proposal Details
@@ -59,3 +63,9 @@ is
 - Proposal number: 2
 - DAO account: GCSGFCRfCRQDbqtPLa6bV7DCJz26NkejR182or8PNqRw
 - Autocrat version: 0.3
+
+
+## Key Facts
+- Test DAO proposal 'Testing indexer changes' failed on 2025-07-02
+- Proposal used Autocrat version 0.3
+- Proposal account: 35mgLHTJYhyEWjsLHDd4jZNQ6jwuZ4E214TUm1hA8vB2

inbox/archive/2025-09-00-gaikwad-murphys-laws-alignment.md

@@ -7,9 +7,14 @@ date: 2025-09-01
 domain: ai-alignment
 secondary_domains: []
 format: paper
-status: unprocessed
+status: null-result
 priority: medium
 tags: [alignment-gap, feedback-misspecification, reward-hacking, sycophancy, impossibility, maps-framework]
+processed_by: theseus
+processed_date: 2026-03-11
+enrichments_applied: ["emergent misalignment arises naturally from reward hacking as models develop deceptive behaviors without any training to deceive.md", "RLHF and DPO both fail at preference diversity because they assume a single reward function can capture context-dependent human values.md", "collective intelligence requires diversity as a structural precondition not a moral preference.md"]
+extraction_model: "anthropic/claude-sonnet-4.5"
+extraction_notes: "Two novel formal results extracted as claims: (1) exponential barrier + calibration oracle solution, (2) MAPS framework for managing alignment gap. Three enrichments to existing claims on emergent misalignment, RLHF/DPO failures, and collective intelligence. The calibration oracle concept maps directly to our collective architecture — domain experts as calibration mechanisms. No connection to social choice theory or bridging-based approaches in the source."
 ---
 
 ## Content
@@ -51,3 +56,9 @@ The alignment gap cannot be eliminated but can be mapped, bounded, and managed.
 PRIMARY CONNECTION: [[emergent misalignment arises naturally from reward hacking as models develop deceptive behaviors without any training to deceive]]
 WHY ARCHIVED: The "calibration oracle" concept maps to our collective architecture — domain experts as calibration mechanisms
 EXTRACTION HINT: The exponential barrier + calibration oracle constructive result is the key extractable claim pair
+
+
+## Key Facts
+- Exponential sample complexity: exp(n*alpha*epsilon^2) where alpha = fraction of problematic contexts, epsilon = bias strength
+- Calibration oracle reduces complexity to O(1/(alpha*epsilon^2))
+- Paper published September 2025 by independent researcher Madhava Gaikwad

inbox/archive/2025-12-00-colosseum-stamp-introduction.md

@@ -6,10 +6,15 @@ url: https://blog.colosseum.com/introducing-the-colosseum-stamp/
 date: 2025-12-00
 domain: internet-finance
 secondary_domains: []
-format: article
-status: unprocessed
+format: report
+status: null-result
 priority: high
 tags: [stamp, investment-instrument, metadao, ownership-coins, safe, legal-structure, colosseum]
+processed_by: rio
+processed_date: 2026-03-11
+enrichments_applied: ["STAMP replaces SAFE plus token warrant by adding futarchy-governed treasury spending allowances that prevent the extraction problem that killed legacy ICOs.md", "futarchy-governed liquidation is the enforcement mechanism that makes unruggable ICOs credible because investors can force full treasury return when teams materially misrepresent.md", "MetaDAO is the futarchy launchpad on Solana where projects raise capital through unruggable ICOs governed by conditional markets creating the first platform for ownership coins at scale.md"]
+extraction_model: "anthropic/claude-sonnet-4.5"
+extraction_notes: "Three new claims extracted on STAMP mechanics: (1) single-token structure with legal enforceability, (2) 20% investor cap ensuring community ownership, (3) clean migration from equity to tokens. Enriched three existing claims with detailed STAMP mechanics. Created entities for Colosseum and Orrick. No regulatory analysis or legal opinions published yet, so confidence capped at experimental. The 20% cap is the most striking mechanism design choice — significantly lower than typical crypto raises."
 ---
 
 ## Content
@@ -57,3 +62,16 @@ Colosseum introduces STAMP (Simple Token Agreement, Market Protected), developed
 PRIMARY CONNECTION: [[STAMP replaces SAFE plus token warrant by adding futarchy-governed treasury spending allowances that prevent the extraction problem that killed legacy ICOs]]
 WHY ARCHIVED: First detailed specification of STAMP instrument. The 20% investor cap + mandatory SAFE termination + DAO-controlled treasury are novel mechanism design choices worth claiming.
 EXTRACTION HINT: Focus on (1) how STAMP structurally prevents the extraction problem, (2) the 20% cap as mechanism for ensuring community ownership, (3) the clean-break migration from equity to token structure.
+
+
+## Key Facts
+- STAMP developed by Colosseum with law firm Orrick (2025-12)
+- STAMP uses Cayman SPC/SP entity structure
+- Investor allocation capped at 20% of total token supply
+- Team allocation: 10-40% of total supply, milestone-based
+- 24-month linear unlock schedule for investor allocations
+- Funds restricted to product development and operating expenses pre-ICO
+- Remaining balance transfers to DAO-controlled treasury upon ICO
+- Prior SAFEs and convertible notes terminated upon STAMP signing
+- MetaDAO interface handles entity setup
+- Positioned as open-source ecosystem standard

inbox/archive/2025-12-00-javacodegeeks-reactive-programming-backpressure-stream-processing.md

@@ -0,0 +1,31 @@
+---
+type: source
+title: "Reactive Programming Paradigms: Mastering Backpressure and Stream Processing"
+author: "Java Code Geeks"
+url: https://www.javacodegeeks.com/2025/12/reactive-programming-paradigms-mastering-backpressure-and-stream-processing.html
+date: 2025-12-01
+domain: internet-finance
+format: essay
+status: unprocessed
+tags: [pipeline-architecture, backpressure, reactive-streams, flow-control, producer-consumer]
+---
+
+# Reactive Programming Paradigms: Mastering Backpressure and Stream Processing
+
+Practitioner guide to implementing backpressure in reactive stream processing systems. Covers the Reactive Streams specification and practical backpressure patterns.
+
+## Key Content
+
+- Reactive Streams standard: Publisher/Subscriber/Subscription interfaces with demand-based flow control
+- Subscriber requests N items → Publisher delivers at most N → prevents overwhelming
+- Four backpressure strategies:
+  1. **Buffer** — accumulate incoming data with threshold triggers (risk: unbounded memory)
+  2. **Drop** — discard excess when consumer can't keep up (acceptable for some data)
+  3. **Latest** — keep only most recent item, discard older (good for state updates)
+  4. **Error** — signal failure when buffer overflows (forces architectural fix)
+- Practical implementations: Project Reactor (Spring WebFlux), Akka Streams, RxJava
+- Key insight: backpressure must be designed into the system from the start — bolting it on later is much harder
+
+## Relevance to Teleo Pipeline
+
+Our pipeline currently has NO backpressure. Extract produces PRs that accumulate in eval's queue without any feedback mechanism. If research dumps 20 sources, extraction creates 20 PRs, and eval drowns trying to process them all. We need a "buffer + rate limit" strategy: extraction should check eval queue depth before starting new work, and slow down or pause when eval is backlogged.

inbox/archive/2026-01-00-mechanistic-interpretability-2026-status-report.md

@@ -7,9 +7,14 @@ date: 2026-01-01
 domain: ai-alignment
 secondary_domains: []
 format: report
-status: unprocessed
+status: null-result
 priority: high
 tags: [mechanistic-interpretability, SAE, safety, technical-alignment, limitations, DeepMind-pivot]
+processed_by: theseus
+processed_date: 2026-03-11
+enrichments_applied: ["AI alignment is a coordination problem not a technical problem.md", "the alignment tax creates a structural race to the bottom because safety training costs capability and rational competitors skip it.md", "safe AI development requires building alignment mechanisms before scaling capability.md", "capability control methods are temporary at best because a sufficiently intelligent system can circumvent any containment designed by lesser minds.md"]
+extraction_model: "anthropic/claude-sonnet-4.5"
+extraction_notes: "Extracted 5 claims focused on the strategic bifurcation of mechanistic interpretability (diagnostic viable, comprehensive dead), the practical utility gap (SAEs underperform baselines), computational costs as alignment tax amplifier, and fundamental barriers (NP-hardness, chaotic dynamics). Applied 4 enrichments to existing alignment claims. This source directly tests the 'alignment is coordination not technical' thesis with nuanced evidence: technical progress is real but bounded, and makes no progress on coordination or preference diversity problems. The DeepMind strategic pivot away from SAEs is a strong market signal about practical utility limits."
 ---
 
 ## Content
@@ -64,3 +69,14 @@ Comprehensive status report on mechanistic interpretability as of early 2026:
 PRIMARY CONNECTION: [[scalable oversight degrades rapidly as capability gaps grow with debate achieving only 50 percent success at moderate gaps]]
 WHY ARCHIVED: Provides 2026 status evidence on whether technical alignment (interpretability) can close the alignment gap — answer is "useful but bounded"
 EXTRACTION HINT: Focus on the practical utility gap (baselines outperform SAEs on safety tasks), the DeepMind strategic pivot, and Anthropic's production deployment use. The "ambitious vision is dead, pragmatic approaches viable" framing is the key synthesis.
+
+
+## Key Facts
+- MIT Technology Review named mechanistic interpretability a '2026 breakthrough technology' (January 2026)
+- January 2025 consensus paper by 29 researchers across 18 organizations established core open problems
+- Google DeepMind's Gemma Scope 2 released December 2025: 270M to 27B parameter models
+- SAEs scaled to GPT-4 with 16 million latent variables
+- Anthropic's attribution graphs (March 2025) trace computational paths for ~25% of prompts
+- Stream algorithm (October 2025) achieves near-linear time attention analysis, eliminating 97-99% of token interactions
+- SAE reconstructions cause 10-40% performance degradation on downstream tasks
+- Fine-tuning misalignment reversible with ~100 corrective training samples (OpenAI finding)

inbox/archive/2026-01-01-futardio-launch-mycorealms.md

@@ -6,14 +6,9 @@ url: "https://www.futard.io/launch/zwVfLheTvbXN5Vn2tZxTc8KaaVnLoBFgbZzskdFnPUb"
 date: 2026-01-01
 domain: internet-finance
 format: data
-status: processed
+status: unprocessed
 tags: [futardio, metadao, futarchy, solana]
 event_type: launch
-processed_by: rio
-processed_date: 2026-03-11
-enrichments_applied: ["futarchy-based fundraising creates regulatory separation because there are no beneficial owners and investment decisions emerge from market forces not centralized control.md", "MetaDAO is the futarchy launchpad on Solana where projects raise capital through unruggable ICOs governed by conditional markets creating the first platform for ownership coins at scale.md", "futarchy-governed liquidation is the enforcement mechanism that makes unruggable ICOs credible because investors can force full treasury return when teams materially misrepresent.md"]
-extraction_model: "anthropic/claude-sonnet-4.5"
-extraction_notes: "First futarchy-governed physical infrastructure project. Extracted two novel claims: (1) futarchy application to agriculture with market-controlled CAPEX, (2) performance-unlocked team tokens with price-multiple triggers. Enriched three existing claims with physical infrastructure context. Created entities for MycoRealms (company), crypticmeta (person), and updated Futardio timeline. The team vesting structure (price multiples + TWAP + cliff) is a novel mechanism worth tracking separately from standard time-based vesting critiques."
 ---
 
 ## Launch Details
@@ -209,14 +204,3 @@ _Note: MycoRealms is not a financial product. $MYCO tokens represent governance
 - Production target: button mushrooms initially, scaling to 12 rooms, then medicinal mushrooms and export
 - Transparency: all invoices, expenses, harvest records, photos published to Arweave
 - Team unlock structure: 5 tranches at 2x/4x/8x/16x/32x ICO price via 3-month TWAP, 18-month minimum cliff
-
-
-## Key Facts
-- MycoRealms raise target: $125,000 USDC (2026-01-01)
-- MycoRealms token supply: 15.9M max (12.9M circulating at launch)
-- MycoRealms monthly allowance: $10,000
-- MycoRealms first CAPEX proposal: $50,000 for infrastructure
-- MycoRealms team: crypticmeta (Solana/Bitcoin dev, OrdinalNovus $30M volume) + Ram (5+ years mushroom production)
-- MycoRealms production target: button mushrooms initially, scaling to 12 rooms, then medicinal mushrooms and export
-- MycoRealms team unlock: 5 tranches at 2x/4x/8x/16x/32x ICO price via 3-month TWAP, 18-month minimum cliff
-- OrdinalNovus trading volume: $30M (CBRC token exchange on Bitcoin Ordinals)

inbox/archive/2026-01-13-nasaa-clarity-act-concerns.md

@@ -1,34 +1,6 @@
 ---
-type: source
-title: "NASAA expresses concerns about the CLARITY Act — 36 state regulators oppose federal preemption of digital asset oversight"
-author: "North American Securities Administrators Association (NASAA)"
-url: https://www.nasaa.org/wp-content/uploads/2026/01/NASAA-Expresses-Concerns-Regarding-the-Digital-Asset-Market-Clarity-Act-1.13.26-F.pdf
-date: 2026-01-13
-domain: internet-finance
-secondary_domains: []
-format: article
-status: unprocessed
-priority: medium
-tags: [nasaa, regulation, clarity-act, state-regulators, federal-preemption, investor-protection]
+title: NASAA Clarity Act Concerns
+extraction_notes: ""
+enrichments_applied: []
+...
 ---
-
-## Content
-
-NASAA (representing securities regulators from all 50 states, DC, Puerto Rico, US Virgin Islands, and Canadian provinces) filed formal concerns about the CLARITY Act on January 13, 2026.
-
-Key concerns likely include: federal preemption of state authority over digital assets, insufficient investor protections at federal level, reduced enforcement tools for state regulators. (Note: PDF was not directly fetchable — concerns inferred from context and other sources referencing the document.)
-
-This aligns with the 36 states filing amicus briefs against federal preemption in the prediction market cases.
-
-## Agent Notes
-**Why this matters:** NASAA represents a coordinated state-level opposition to federal digital asset regulation. This is the same institutional resistance facing prediction markets. The 36-state amicus coalition and NASAA concerns together represent a formidable block against federal preemption.
-**What surprised me:** The coordination between state securities regulators (NASAA) and state gaming commissions (Nevada, Massachusetts) — both pushing back against federal preemption on different fronts. This suggests a broader "states' rights" dynamic in digital asset regulation.
-**What I expected but didn't find:** The full text of NASAA's concerns (PDF behind access restrictions). Would provide specific arguments against the CLARITY Act's decentralization on-ramp.
-**KB connections:** Regulatory uncertainty claims — state-level opposition adds a layer of complexity to the "regulatory clarity is increasing" narrative.
-**Extraction hints:** The state-level opposition coalition as a counterforce to federal clarity.
-**Context:** NASAA has historically been more conservative on digital asset regulation than federal regulators. Their opposition is expected but the coordination with gaming commissions is new.
-
-## Curator Notes (structured handoff for extractor)
-PRIMARY CONNECTION: [[Internet finance is an industry transition from traditional finance where the attractor state replaces intermediaries with programmable coordination and market-tested governance]]
-WHY ARCHIVED: State-level opposition coalition represents a friction force against the internet finance transition. Important counterevidence to the "regulatory clarity is increasing" narrative.
-EXTRACTION HINT: Focus on state-level opposition as friction force — adds nuance to regulatory landscape claims.

inbox/archive/2026-02-09-oneuptime-hpa-object-metrics-queue-scaling.md

@@ -0,0 +1,33 @@
+---
+type: source
+title: "How to Implement HPA with Object Metrics for Queue-Based Scaling"
+author: "OneUptime"
+url: https://oneuptime.com/blog/post/2026-02-09-hpa-object-metrics-queue/view
+date: 2026-02-09
+domain: internet-finance
+format: essay
+status: unprocessed
+tags: [pipeline-architecture, kubernetes, autoscaling, queue-based-scaling, KEDA, HPA]
+---
+
+# How to Implement HPA with Object Metrics for Queue-Based Scaling
+
+Practical guide to implementing Kubernetes HPA scaling based on queue depth rather than CPU/memory metrics. Covers object metrics, custom metrics, and integration patterns.
+
+## Key Content
+
+- Queue depth is a better scaling signal than CPU for worker-style workloads
+- Object metrics in HPA allow scaling based on custom Kubernetes objects (ConfigMaps, custom resources)
+- Pattern: monitor pending messages in queue → scale workers to process them
+- Multi-metric HPA: evaluate several metrics simultaneously, scale to whichever requires most replicas
+- KEDA (Kubernetes Event Driven Autoscaler): scale-to-zero capability, 70+ built-in scalers
+- KEDA pattern: 0 → 1 via event trigger, 1 → N via HPA metrics feed
+- Key insight: scale proactively based on how much work is waiting, not reactively based on how busy workers are
+
+## Relevance to Teleo Pipeline
+
+We don't run Kubernetes, but the patterns are directly transferable to our cron-based system:
+1. Replace fixed MAX_WORKERS with queue-depth-based scaling: workers = f(queue_depth)
+2. Implement scale-to-zero: if no unprocessed sources, don't spawn workers at all (we already do this)
+3. Multi-metric scaling: consider both extract queue depth AND eval queue depth when deciding extraction worker count
+4. The proactive scaling insight is key: our dispatcher should look at queue depth, not just worker availability

inbox/archive/2026-03-05-futardio-launch-insert-coin-labs.md

@@ -6,9 +6,13 @@ url: "https://www.futard.io/launch/62Yxd8gLQ2YYmY2TifhChJG4tVdf4b1oAHcMfwTL2WUu"
 date: 2026-03-05
 domain: internet-finance
 format: data
-status: unprocessed
+status: processed
 tags: [futardio, metadao, futarchy, solana]
 event_type: launch
+processed_by: rio
+processed_date: 2026-03-11
+extraction_model: "anthropic/claude-sonnet-4.5"
+extraction_notes: "Factual fundraise data for failed gaming studio raise on Futardio. No novel claims about futarchy mechanisms or gaming economics — just execution data on a specific failed raise. Created entity pages for the company and the fundraise decision market, updated Futardio timeline. The 95% funding gap is notable as market signal but doesn't constitute a generalizable claim about gaming studios or futarchy without additional context/comparison data."
 ---
 
 ## Launch Details
@@ -117,3 +121,11 @@ We didn't want complex tokenomics driving our decisions. Futarchy puts the marke
 - Token mint: `32CPstBmwccnLoaUqkqiiMVg1nKrQ3YGcM43vFAimeta`
 - Version: v0.7
 - Closed: 2026-03-06
+
+
+## Key Facts
+- Insert Coin Labs Domin8 game: 232 games played, 55.1 SOL volume, +2.7 SOL house profit (as of 2026-03-05)
+- Insert Coin Labs Futardio raise: $50K target, $2,508 committed (5%), refunding status (2026-03-06)
+- Insert Coin Labs allocation: 80% team ($40K), 20% liquidity ($10K), $4K monthly burn, ~10 month runway
+- Insert Coin Labs roadmap: Domin8 live, 1v1 game ready, Casino hub Q2 2026, Rabbit Royal Q2 2026, Open API Q3 2026
+- Insert Coin Labs audit: Excalead, Honorable Mention at Solana Breakpoint 2025

inbox/archive/2026-03-10-iab-ai-ad-gap-widens.md

@@ -7,7 +7,15 @@ date: 2026-01-01
 domain: entertainment
 secondary_domains: []
 format: report
-status: unprocessed
+status: processed
+processed_by: clay
+processed_date: 2026-03-12
+claims_extracted:
+  - consumer-rejection-of-ai-generated-ads-intensifies-as-ai-quality-improves-disproving-the-exposure-leads-to-acceptance-hypothesis
+  - the-advertiser-consumer-ai-perception-gap-is-a-widening-structural-misalignment-not-a-temporal-communications-lag
+  - gen-z-hostility-to-ai-generated-advertising-is-stronger-than-millennials-and-widening-making-gen-z-a-negative-leading-indicator-for-ai-content-acceptance
+enrichments:
+  - GenAI adoption in entertainment will be gated by consumer acceptance not technology capability (strong supporting evidence — rejection intensifying, not eroding)
 priority: high
 tags: [consumer-acceptance, ai-content, advertiser-perception-gap, gen-z, authenticity]
 ---

inbox/archive/2026-03-12-futardio-launch-shopsbuilder-ai.md

@@ -0,0 +1,192 @@
+---
+type: source
+title: "Futardio: ShopsBuilder AI fundraise goes live"
+author: "futard.io"
+url: "https://www.futard.io/launch/6qtygHxrFzF3tucXcy6EzbwZJBRbiuZAZrsXapXZLxE3"
+date: 2026-03-12
+domain: internet-finance
+format: data
+status: unprocessed
+tags: [futardio, metadao, futarchy, solana]
+event_type: launch
+---
+
+## Launch Details
+- Project: ShopsBuilder AI
+- Description: The AI Bridge Layer for On-Chain Chat Commerce
+- Funding target: $420,000.00
+- Total committed: N/A
+- Status: Live
+- Launch date: 2026-03-12
+- URL: https://www.futard.io/launch/6qtygHxrFzF3tucXcy6EzbwZJBRbiuZAZrsXapXZLxE3
+
+## Team / Description
+
+**The internet is becoming agentic. Commerce hasn't caught up. We built the infrastructure that connects them.**
+
+ShopsBuilder is raising to accelerate the global infrastructure layer that bridges Web2 merchants into the age of AI-native, on-chain commerce — operating inside the messaging platforms where 3+ billion people already live.
+
+---
+
+## What We've Already Built
+
+We did not start from zero.
+
+- **100,000+ customers** have transacted through ShopsBuilder-powered stores
+- **Live merchant network** operating Telegram-native stores across physical goods, digital products, and services
+- **AI agent system deployed** — every store gets its own autonomous agents: product discovery, order handling, customer support, follow-ups
+- **First version of the open marketplace published** — decentralized merchant discovery layer
+- **Full payment stack live**: crypto, credit cards, custom payment app integrations
+- **Complete commerce stack**: catalog CRM, storefronts, unified marketplace, network of personal agents and many more
+
+This raise allows us to scale globally, enable AI agents to turn business intent into autonomous commerce operations, and connect demand from users and agents to existing businesses across platforms like Shopify, Amazon, and others.
+
+---
+
+## The Problem
+
+**Commerce is shifting to chat and AI agents, but the infrastructure was built for humans using browsers.**
+
+**Demand discovery** is moving to AI interfaces while merchants still depend on centralized marketplaces that control ranking, margins, and customer access.
+
+**Commerce infrastructure remains fragmented** across Shopify, Amazon, WooCommerce, marketplaces, and payment providers — each requiring integrations, operational effort, and technical expertise.
+
+Crypto payments exist, but the **full commerce lifecycle is still missing**, which real merchants requires — authorization, escrow, capture, refunds, cancellations, and disputes.
+
+---
+
+## The Bridge
+
+This is ShopsBuilder's core insight:
+
+**The future of commerce is not storefronts. It is agents transacting with agents.**
+
+A customer talks to their AI assistant. The assistant understands intent. It discovers the right merchant. Shows to customer and It initiates a purchase. The payment settles on-chain. The merchant fulfills the order.
+
+The merchant never knows the sale came through an agentic channel. To them, it is just another order. But underneath, a new layer of commerce infrastructure made it possible — invisible, automated, and unstoppable.
+
+**ShopsBuilder is the bridge layer** that connects existing Web2 businesses into this new reality — without requiring merchants to understand crypto, AI, or protocols. They get a fully autonomous operation. The infrastructure handles everything else.
+
+---
+
+## Business intent -> Execution
+
+**AI doesn't just discover demand — it can operate businesses.**
+
+Merchants no longer need to manually configure every system, integration, or market expansion.
+
+A founder can say:
+*"Launch our products in market X."*
+*"Start running ads."*
+*"Accept donations in crypto payments."*
+
+AI agents interpret this **business intent** and execute it across the ShopsBuilder infrastructure — configuring payments, storefronts, integrations, compliance, and distribution automatically.
+
+**Business intent becomes executable commerce infrastructure.**
+
+___
+
+## ShopsBuilder provides the core infrastructure layer for agentic commerce.
+
+The system combines three primitives:
+
+1. **Merchant AI agents**
+Every store receives an autonomous agent that handles discovery, orders,
+customer support, and follow-ups.
+
+2. **Universal commerce bridge**
+Existing Web2 merchants (Shopify, marketplaces, independent stores)
+can expose their products to AI agents without changing their operations.
+
+3. **On-chain payment lifecycle**
+A complete crypto payment stack supporting authorization, escrow,
+capture, refunds, cancellations, and dispute resolution.
+
+---
+
+## Why Now
+
+- AI agents are moving from assistants to autonomous economic actors — the infrastructure for this transition does not yet exist at scale
+- Crypto payment adoption in commerce is accelerating but lacks the complete primitive stack merchants need
+- x402 and emerging agent payment protocols are creating a new interoperability layer — ShopsBuilder is positioned to be the merchant-side infrastructure for this ecosystem
+- We have 100,000+ real customers and live merchant traction 
+
+---
+## Market & Competitive Landscape
+
+Existing solutions are fragmented:
+
+• AI tools generate content but are not designed to operate businesses 
+• Crypto payment processors support payments but lack the full commerce lifecycle
+• Marketplaces remain centralized and extractive, controlling discovery and margins.
+
+ShopsBuilder combines these layers into one open infrastructure.
+
+---
+
+## Roadmap
+
+| Quarter     | Milestones                                                                                                             |
+| ----------- | ---------------------------------------------------------------------------------------------------------------------- |
+| **Q2 2026** | Open-source DAO marketplace launch; Web storefront access; UCP native marketplace                                 |
+| **Q3 2026** | Expansion to WhatsApp, Instagram, and Discord commerce interfaces; merchant onboarding tools                           |
+| **Q4 2026** | Merchant bridge layer (Shopify / WooCommerce / marketplaces); x402-compatible payment layer; EVM multi-chain expansion |
+| **Q1 2027** | AI agent SDK; agent-to-agent commerce flows via x402                                                                   |
+| **2027+**   | Universal agentic commerce API; cross-platform merchant identity and reputation layer                                  |
+
+---
+
+## Use of Funds
+
+Raise target: $336,000
+
+Runway: ~12 months
+Monthly burn: ~$28k
+
+---
+
+## Notes
+
+ShopsBuilder is modular by design.
+
+The core components — payment infrastructure, merchant agents,
+and the DAO marketplace — can evolve independently.
+
+If one layer fails to gain adoption, development can focus on the
+components that demonstrate the strongest product-market fit.
+
+If a particular product direction fails to achieve adoption,
+treasury governance allows the community to redirect development
+toward the most promising parts of the infrastructure -
+AI agents, payment protocols, or the DAO marketplace layer.
+
+## Potential outcome
+
+If ShopsBuilder reaches 100,000 active merchants
+with ~$250 annual infrastructure revenue per merchant,
+
+annual revenue would reach ~$25M.
+
+This represents a realistic outcome for a global
+agentic commerce infrastructure layer.
+
+## Vision
+
+ShopsBuilder is building the world's AI-native, on-chain commerce infrastructure — the invisible bridge layer that connects the 200M+ Web2 businesses into an agentic economy where AI handles discovery, conversation, and payment automatically.
+
+
+Commerce is going agentic. ShopsBuilder is the infrastructure that makes it work.
+
+
+## Links
+
+- Website: https://shopsbuilder.app
+- Twitter: https://x.com/shopsbuilder
+- Telegram: https://t.me/shopsbuilder
+
+## Raw Data
+
+- Launch address: `6qtygHxrFzF3tucXcy6EzbwZJBRbiuZAZrsXapXZLxE3`
+- Token: 8fX (8fX)
+- Token mint: `8fXTttGGAKeZZ9DhLhE7Peh3hQCcqCJdHhpmZwdEmeta`
+- Version: v0.7