extract: 2023-00-00-sciencedirect-flexible-job-shop-scheduling-review #908
16 changed files with 522 additions and 6 deletions
|
|
@ -0,0 +1,37 @@
|
||||||
|
---
|
||||||
|
type: claim
|
||||||
|
domain: internet-finance
|
||||||
|
description: "AIMD algorithm achieves provably fair and stable distributed resource allocation using only local congestion feedback"
|
||||||
|
confidence: proven
|
||||||
|
source: "Corless, King, Shorten, Wirth (SIAM 2016) - AIMD Dynamics and Distributed Resource Allocation"
|
||||||
|
created: 2026-03-11
|
||||||
|
secondary_domains: [mechanisms, collective-intelligence]
|
||||||
|
---
|
||||||
|
|
||||||
|
# AIMD converges to fair resource allocation without global coordination through local congestion signals
|
||||||
|
|
||||||
|
Additive Increase Multiplicative Decrease (AIMD) is a distributed resource allocation algorithm that provably converges to fair and stable resource sharing among competing agents without requiring centralized control or global information. The algorithm operates through two simple rules: when no congestion is detected, increase resource usage additively (rate += α); when congestion is detected, decrease resource usage multiplicatively (rate *= β, where 0 < β < 1).
|
||||||
|
|
||||||
|
The SIAM monograph by Corless et al. demonstrates that AIMD is mathematically guaranteed to converge to equal sharing of available capacity regardless of the number of agents or parameter values. Each agent only needs to observe local congestion signals—no knowledge of other agents, total capacity, or system-wide state is required. This makes AIMD the most widely deployed distributed resource allocation mechanism, originally developed for TCP congestion control and now applicable to smart grid energy allocation, distributed computing, and other domains where multiple agents compete for shared resources.
|
||||||
|
|
||||||
|
The key insight is that AIMD doesn't require predicting load, modeling arrivals, or solving optimization problems. It reacts to observed system state through simple local rules and is guaranteed to find the fair allocation through the dynamics of the algorithm itself. The multiplicative decrease creates faster convergence than purely additive approaches, while the additive increase ensures fairness rather than proportional allocation.
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
- Corless, King, Shorten, Wirth (2016) provide mathematical proofs of convergence and fairness properties
|
||||||
|
- AIMD is the foundation of TCP congestion control, the most widely deployed distributed algorithm in existence
|
||||||
|
- The algorithm works across heterogeneous domains: internet bandwidth, energy grids, computing resources
|
||||||
|
- Convergence is guaranteed regardless of number of competing agents or their parameter choices
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
Relevant Notes:
|
||||||
|
- [[coordination mechanisms]]
|
||||||
|
- [[optimal governance requires mixing mechanisms because different decisions have different manipulation risk profiles]]
|
||||||
|
- [[collective intelligence requires diversity as a structural precondition not a moral preference]]
|
||||||
|
- [[designing coordination rules is categorically different from designing coordination outcomes as nine intellectual traditions independently confirm]]
|
||||||
|
|
||||||
|
Topics:
|
||||||
|
- domains/internet-finance/_map
|
||||||
|
- core/mechanisms/_map
|
||||||
|
- foundations/collective-intelligence/_map
|
||||||
|
|
@ -0,0 +1,46 @@
|
||||||
|
---
|
||||||
|
type: claim
|
||||||
|
domain: internet-finance
|
||||||
|
description: "AIMD provides principled autoscaling for systems with expensive compute and variable load by reacting to queue state rather than forecasting demand"
|
||||||
|
confidence: experimental
|
||||||
|
source: "Corless et al. (SIAM 2016) applied to Teleo pipeline architecture"
|
||||||
|
created: 2026-03-11
|
||||||
|
secondary_domains: [mechanisms, critical-systems]
|
||||||
|
---
|
||||||
|
|
||||||
|
# AIMD scaling solves variable-load expensive-compute coordination without prediction
|
||||||
|
|
||||||
|
For systems with expensive computational operations and highly variable load—such as AI evaluation pipelines where extraction is cheap but evaluation is costly—AIMD provides a principled scaling algorithm that doesn't require demand forecasting or optimization modeling. The algorithm operates by observing queue state: when the evaluation queue is shrinking (no congestion), increase extraction workers by 1 per cycle; when the queue is growing (congestion detected), halve extraction workers.
|
||||||
|
|
||||||
|
This approach is particularly well-suited to scenarios where:
|
||||||
|
1. Downstream operations (evaluation) are significantly more expensive than upstream operations (extraction)
|
||||||
|
2. Load is unpredictable and varies substantially over time
|
||||||
|
3. The cost of overprovisioning is high (wasted expensive compute)
|
||||||
|
4. The cost of underprovisioning is manageable (slightly longer queue wait times)
|
||||||
|
|
||||||
|
The AIMD dynamics guarantee convergence to a stable operating point where extraction rate matches evaluation capacity, without requiring any prediction of future load, modeling of arrival patterns, or solution of optimization problems. The system self-regulates through observed congestion signals (queue growth/shrinkage) and simple local rules.
|
||||||
|
|
||||||
|
The multiplicative decrease (halving workers on congestion) provides rapid response to capacity constraints, while the additive increase (adding one worker when uncongested) provides gradual scaling that avoids overshooting. This asymmetry is critical: it's better to scale down too aggressively and scale up conservatively than vice versa when downstream compute is expensive.
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
- Corless et al. (2016) prove AIMD convergence properties hold for general resource allocation problems beyond network bandwidth
|
||||||
|
- The Teleo pipeline architecture exhibits the exact characteristics AIMD is designed for: cheap extraction, expensive evaluation, variable load
|
||||||
|
- AIMD's "no prediction required" property eliminates the complexity and fragility of load forecasting models
|
||||||
|
- The algorithm's proven stability guarantees mean it won't oscillate or diverge regardless of load patterns
|
||||||
|
|
||||||
|
## Challenges
|
||||||
|
|
||||||
|
This is an application of proven AIMD theory to a specific system architecture, but the actual performance in the Teleo pipeline context is untested. The claim that AIMD is "perfect for" this setting is theoretical—empirical validation would strengthen confidence from experimental to likely.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
Relevant Notes:
|
||||||
|
- [[aimd-converges-to-fair-resource-allocation-without-global-coordination-through-local-congestion-signals]] <!-- claim pending -->
|
||||||
|
- [[coordination mechanisms]]
|
||||||
|
- [[designing coordination rules is categorically different from designing coordination outcomes as nine intellectual traditions independently confirm]]
|
||||||
|
|
||||||
|
Topics:
|
||||||
|
- domains/internet-finance/_map
|
||||||
|
- core/mechanisms/_map
|
||||||
|
- foundations/critical-systems/_map
|
||||||
|
|
@ -0,0 +1,41 @@
|
||||||
|
---
|
||||||
|
type: claim
|
||||||
|
domain: internet-finance
|
||||||
|
description: "Computational complexity theory establishes that optimal job-shop scheduling becomes intractable at scale beyond trivial cases"
|
||||||
|
confidence: proven
|
||||||
|
source: "ScienceDirect review article on Flexible Job Shop Scheduling Problem, 2023; established operations research result"
|
||||||
|
created: 2026-03-11
|
||||||
|
---
|
||||||
|
|
||||||
|
# General job-shop scheduling is NP-complete for more than two machines
|
||||||
|
|
||||||
|
The classical Job Shop Scheduling Problem (JSSP) is NP-complete for m > 2 machines, meaning no polynomial-time algorithm exists to find optimal solutions for non-trivial instances. This is a foundational result in operations research and computational complexity theory.
|
||||||
|
|
||||||
|
This matters because it establishes the computational boundary between tractable and intractable scheduling problems. When designing coordination systems (like Teleo's pipeline architecture), understanding which side of this boundary your problem falls on determines whether you need heuristics or can use exact optimization.
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
The ScienceDirect review states: "Classical Job Shop Scheduling Problem (JSSP): n jobs, m machines, fixed operation-to-machine mapping, NP-complete for m > 2."
|
||||||
|
|
||||||
|
This is a well-established result in operations research. The proof shows that even with fixed operation-to-machine mappings, finding the optimal schedule that minimizes makespan (total completion time) requires exponential time in the worst case once you have three or more machines.
|
||||||
|
|
||||||
|
The Flexible JSSP (FJSP) adds machine assignment as a decision variable on top of sequencing, making it strictly harder than classical JSSP.
|
||||||
|
|
||||||
|
## Implications
|
||||||
|
|
||||||
|
For any multi-stage coordination system:
|
||||||
|
1. If your problem maps to general JSSP with >2 stages, you cannot guarantee optimal solutions at scale
|
||||||
|
2. Heuristics and approximation algorithms become necessary
|
||||||
|
3. Problem structure matters — special cases (like flow-shop or hybrid flow-shop) can be easier
|
||||||
|
4. The choice of coordination mechanism should account for computational tractability
|
||||||
|
|
||||||
|
This is why [[hybrid-flow-shop-scheduling-with-simple-dispatching-rules-performs-within-5-10-percent-of-optimal-for-homogeneous-workers]] matters — it identifies a tractable special case that applies to pipeline architectures.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
Relevant Notes:
|
||||||
|
- [[hybrid-flow-shop-scheduling-with-simple-dispatching-rules-performs-within-5-10-percent-of-optimal-for-homogeneous-workers]]
|
||||||
|
- domains/internet-finance/_map
|
||||||
|
|
||||||
|
Topics:
|
||||||
|
- domains/internet-finance/_map
|
||||||
|
|
@ -0,0 +1,49 @@
|
||||||
|
---
|
||||||
|
type: claim
|
||||||
|
domain: internet-finance
|
||||||
|
description: "Operations research shows simple priority rules suffice for pipeline architectures with sequential stages and uniform worker capability"
|
||||||
|
confidence: likely
|
||||||
|
source: "ScienceDirect review article on Flexible Job Shop Scheduling Problem, 2023"
|
||||||
|
created: 2026-03-11
|
||||||
|
---
|
||||||
|
|
||||||
|
# Hybrid flow-shop scheduling with simple dispatching rules performs within 5-10 percent of optimal for homogeneous workers
|
||||||
|
|
||||||
|
For pipeline architectures where all work flows through the same sequence of stages (hybrid flow-shop), and workers within each stage have similar capabilities, simple priority dispatching rules like shortest-job-first or FIFO within priority classes achieve near-optimal performance without requiring complex metaheuristic optimization.
|
||||||
|
|
||||||
|
This matters for Teleo's pipeline architecture (research → extract → eval) because it means we don't need sophisticated scheduling algorithms. The computational complexity that makes general Job Shop Scheduling Problems NP-hard doesn't apply when:
|
||||||
|
1. All sources follow the same stage sequence (flow-shop property)
|
||||||
|
2. Multiple workers exist at each stage but are roughly interchangeable
|
||||||
|
3. The number of stages is small (3 in our case)
|
||||||
|
|
||||||
|
The review shows that for hybrid flow-shops with these properties, metaheuristics (genetic algorithms, simulated annealing, tabu search) provide only marginal improvements over well-designed dispatching rules, while adding significant implementation complexity.
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
The ScienceDirect review distinguishes several scheduling problem types:
|
||||||
|
- **Classical JSSP**: n jobs, m machines, fixed operation-to-machine mapping, NP-complete for m > 2
|
||||||
|
- **Flexible JSSP**: operations can run on any eligible machine from a set
|
||||||
|
- **Flow-shop**: all jobs follow the same machine order
|
||||||
|
- **Hybrid flow-shop**: multiple machines at each stage, jobs follow same stage order but can use any machine within a stage
|
||||||
|
|
||||||
|
For hybrid flow-shop problems specifically, the review notes that "simple priority dispatching rules (shortest-job-first, FIFO within priority classes) perform within 5-10% of optimal" when workers within stages are homogeneous.
|
||||||
|
|
||||||
|
The review also documents that recent trends focus on "multi-agent reinforcement learning for dynamic scheduling with worker heterogeneity and uncertainty" — but this is for cases where worker capabilities differ significantly, which is not the primary bottleneck in our pipeline.
|
||||||
|
|
||||||
|
## Implications for Teleo Pipeline
|
||||||
|
|
||||||
|
Our pipeline is definitionally a hybrid flow-shop:
|
||||||
|
- Three sequential stages: research → extract → eval
|
||||||
|
- Multiple AI agents can work at each stage
|
||||||
|
- All sources flow through the same stage sequence
|
||||||
|
- Workers within each stage have similar (though not identical) capabilities
|
||||||
|
|
||||||
|
This means our scheduling problem is computationally tractable with simple rules rather than requiring optimization algorithms designed for general JSSP.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
Relevant Notes:
|
||||||
|
- domains/internet-finance/_map
|
||||||
|
|
||||||
|
Topics:
|
||||||
|
- domains/internet-finance/_map
|
||||||
|
|
@ -0,0 +1,37 @@
|
||||||
|
---
|
||||||
|
type: claim
|
||||||
|
domain: internet-finance
|
||||||
|
description: "At 5-20 server scale, queueing theory threshold policies capture most benefit without algorithmic complexity"
|
||||||
|
confidence: likely
|
||||||
|
source: "van Leeuwaarden, Mathijsen, Sanders (SIAM Review 2018) - empirical validation of square-root staffing at moderate scale"
|
||||||
|
created: 2026-03-11
|
||||||
|
depends_on: ["square-root-staffing-principle-achieves-economies-of-scale-in-queueing-systems-by-operating-near-full-utilization-with-manageable-delays.md"]
|
||||||
|
---
|
||||||
|
|
||||||
|
# Moderate-scale queueing systems benefit from simple threshold policies over sophisticated algorithms because square-root staffing captures most efficiency gains
|
||||||
|
|
||||||
|
For systems operating at moderate scale (5-20 servers), the mathematical properties of the Halfin-Whitt regime mean that simple threshold-based policies informed by queueing theory capture most of the available efficiency gains. Sophisticated dynamic algorithms add implementation complexity without proportional benefit at this scale.
|
||||||
|
|
||||||
|
The square-root staffing principle works empirically even for systems as small as 5-6 servers, which means the core economies-of-scale insight applies well below the asymptotic regime where the mathematical proofs strictly hold. This has direct implications for pipeline architecture: a system with 5-6 workers doesn't need complex autoscaling algorithms or machine learning-based load prediction.
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
The SIAM Review tutorial explicitly notes that "square-root safety staffing works empirically even for moderate-sized systems (5-20 servers)" and that "at our scale (5-6 workers), we're in the 'moderate system' range where square-root staffing still provides useful guidance."
|
||||||
|
|
||||||
|
The key takeaway from the tutorial: "we don't need sophisticated algorithms for a system this small. Simple threshold policies informed by queueing theory will capture most of the benefit."
|
||||||
|
|
||||||
|
## Practical Application
|
||||||
|
|
||||||
|
For Teleo pipeline architecture operating at 5-6 workers, this means:
|
||||||
|
- Simple threshold-based autoscaling policies are sufficient
|
||||||
|
- Complex predictive algorithms add cost without proportional benefit
|
||||||
|
- The mathematical foundation (Halfin-Whitt regime) validates simple approaches at this scale
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
Relevant Notes:
|
||||||
|
- [[square-root-staffing-principle-achieves-economies-of-scale-in-queueing-systems-by-operating-near-full-utilization-with-manageable-delays]]
|
||||||
|
- domains/internet-finance/_map
|
||||||
|
|
||||||
|
Topics:
|
||||||
|
- core/mechanisms/_map
|
||||||
|
|
@ -0,0 +1,36 @@
|
||||||
|
---
|
||||||
|
type: claim
|
||||||
|
domain: internet-finance
|
||||||
|
description: "Bursty arrival processes require more safety capacity than Poisson models predict, scaled by variance-to-mean ratio"
|
||||||
|
confidence: proven
|
||||||
|
source: "Whitt et al., 'Staffing a Service System with Non-Poisson Non-Stationary Arrivals', Cambridge Core, 2016"
|
||||||
|
created: 2026-03-11
|
||||||
|
---
|
||||||
|
|
||||||
|
# Square-root staffing formula requires peakedness adjustment for non-Poisson arrivals because bursty processes need proportionally more safety capacity than the Poisson baseline predicts
|
||||||
|
|
||||||
|
The standard square-root staffing formula (workers = mean load + safety factor × √mean) assumes Poisson arrivals where variance equals mean. Real-world arrival processes violate this assumption through burstiness (arrivals clustered in time) or smoothness (arrivals more evenly distributed than random).
|
||||||
|
|
||||||
|
Whitt et al. extend the square-root staffing rule by introducing **peakedness** — the variance-to-mean ratio of the arrival process — as the key adjustment parameter. For bursty arrivals (peakedness > 1), systems require MORE safety capacity than Poisson models suggest. For smooth arrivals (peakedness < 1), systems need LESS.
|
||||||
|
|
||||||
|
The modified staffing formula adjusts the square-root safety margin by multiplying by the square root of peakedness. This correction is critical for non-stationary systems where arrival rates vary over time (daily cycles, seasonal patterns, or event-driven spikes).
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
- Whitt et al. (2016) prove that peakedness — the variance-to-mean ratio — captures the essential non-Poisson behavior for staffing calculations
|
||||||
|
- Standard Poisson assumption (variance = mean) fails empirically for bursty workloads like research paper dumps, product launches, or customer service spikes
|
||||||
|
- Using constant staffing (fixed MAX_WORKERS) regardless of queue state creates dual failure: over-provisioning during quiet periods (wasted compute) and under-provisioning during bursts (queue explosion)
|
||||||
|
|
||||||
|
## Relevance to Pipeline Architecture
|
||||||
|
|
||||||
|
Teleo's research pipeline exhibits textbook non-Poisson non-stationary arrivals: research dumps arrive in bursts of 15+ sources, futardio launches come in waves of 20+ proposals, while other days see minimal activity. The peakedness parameter quantifies exactly how much extra capacity is needed beyond naive square-root staffing.
|
||||||
|
|
||||||
|
This directly informs dynamic worker scaling: measure empirical peakedness from historical arrival data, adjust safety capacity accordingly, and scale workers based on current queue depth rather than using fixed limits.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
Relevant Notes:
|
||||||
|
- domains/internet-finance/_map
|
||||||
|
|
||||||
|
Topics:
|
||||||
|
- core/mechanisms/_map
|
||||||
|
|
@ -0,0 +1,35 @@
|
||||||
|
---
|
||||||
|
type: claim
|
||||||
|
domain: internet-finance
|
||||||
|
description: "The QED Halfin-Whitt regime shows server count n grows while utilization approaches 1 at rate Θ(1/√n)"
|
||||||
|
confidence: proven
|
||||||
|
source: "van Leeuwaarden, Mathijsen, Sanders (SIAM Review 2018) - Economies-of-Scale in Many-Server Queueing Systems"
|
||||||
|
created: 2026-03-11
|
||||||
|
---
|
||||||
|
|
||||||
|
# Square-root staffing principle achieves economies of scale in queueing systems by operating near full utilization with manageable delays
|
||||||
|
|
||||||
|
The QED (Quality-and-Efficiency-Driven) Halfin-Whitt heavy-traffic regime provides the mathematical foundation for understanding economies of scale in multi-server systems. As server count n grows, the system can operate at utilization approaching 1 while maintaining bounded delays, with the key insight that excess capacity needs to grow only at rate Θ(1/√n) rather than linearly.
|
||||||
|
|
||||||
|
This "square root staffing" principle means larger systems need proportionally fewer excess servers for the same service quality. A system with 100 servers might need 10 excess servers for target service levels, while a system with 400 servers needs only 20 excess servers (not 40) for the same quality.
|
||||||
|
|
||||||
|
The regime applies across system sizes from tens to thousands of servers, and empirical validation shows the square-root safety staffing works even for moderate-sized systems in the 5-20 server range.
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
From the SIAM Review tutorial:
|
||||||
|
- Mathematical proof that utilization approaches 1 at rate Θ(1/√n) as server count grows
|
||||||
|
- Empirical validation showing square-root staffing works for systems as small as 5-20 servers
|
||||||
|
- The regime connects abstract queueing theory to practical staffing decisions across industries
|
||||||
|
|
||||||
|
## Implications for Pipeline Architecture
|
||||||
|
|
||||||
|
For systems in the 5-6 worker range, sophisticated dynamic algorithms provide minimal benefit over simple threshold policies informed by queueing theory. The economies-of-scale result also indicates that marginal value per worker decreases as systems grow beyond 20+ workers, which is critical for cost optimization in scaled deployments.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
Relevant Notes:
|
||||||
|
- domains/internet-finance/_map
|
||||||
|
|
||||||
|
Topics:
|
||||||
|
- core/mechanisms/_map
|
||||||
|
|
@ -0,0 +1,42 @@
|
||||||
|
---
|
||||||
|
type: claim
|
||||||
|
domain: internet-finance
|
||||||
|
description: "Replacing non-stationary arrival rates with constant staffing leads to systematic over- or under-provisioning"
|
||||||
|
confidence: proven
|
||||||
|
source: "Whitt et al., 'Staffing a Service System with Non-Poisson Non-Stationary Arrivals', Cambridge Core, 2016"
|
||||||
|
created: 2026-03-11
|
||||||
|
---
|
||||||
|
|
||||||
|
# Time-varying arrival rates require dynamic staffing not constant MAX_WORKERS because using average or maximum rates as constants creates systematic misallocation across the arrival cycle
|
||||||
|
|
||||||
|
Non-stationary arrival processes — where the arrival rate itself changes over time — cannot be efficiently staffed with constant worker counts. Whitt et al. demonstrate that replacing time-varying rates with either the average rate or the maximum rate produces badly mis-staffed systems:
|
||||||
|
|
||||||
|
- **Constant = average rate**: Under-staffed during peak periods, leading to queue explosions and service degradation
|
||||||
|
- **Constant = maximum rate**: Over-staffed during off-peak periods, wasting capacity and compute resources
|
||||||
|
|
||||||
|
The optimal approach tracks the arrival rate over time and adjusts staffing dynamically to match the current load plus an appropriate safety margin (scaled by peakedness for non-Poisson processes).
|
||||||
|
|
||||||
|
## Evidence
|
||||||
|
|
||||||
|
- Whitt et al. (2016) prove that time-varying arrival rates require time-varying staffing levels for efficiency
|
||||||
|
- Constant staffing at maximum capacity wastes resources during low-traffic periods
|
||||||
|
- Constant staffing at average capacity fails catastrophically during burst periods
|
||||||
|
- Dynamic staffing based on current queue state and arrival rate estimates achieves both efficiency (no waste during quiet periods) and reliability (adequate capacity during bursts)
|
||||||
|
|
||||||
|
## Application to Teleo Pipeline
|
||||||
|
|
||||||
|
Teleo's research processing pipeline exhibits strong non-stationarity: research dumps and futardio launches create burst periods with 15-20+ simultaneous arrivals, while other periods see minimal activity. Using a fixed MAX_WORKERS setting (constant staffing) is the worst of both worlds:
|
||||||
|
|
||||||
|
- During bursts: MAX_WORKERS is too low, queue explodes, processing stalls
|
||||||
|
- During quiet periods: MAX_WORKERS is too high, workers sit idle, compute wasted
|
||||||
|
|
||||||
|
Dynamic worker scaling based on current queue depth and estimated arrival rate (with peakedness adjustment) is the theoretically correct solution.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
Relevant Notes:
|
||||||
|
- [[square-root-staffing-formula-requires-peakedness-adjustment-for-non-poisson-arrivals]]
|
||||||
|
- domains/internet-finance/_map
|
||||||
|
|
||||||
|
Topics:
|
||||||
|
- core/mechanisms/_map
|
||||||
|
|
@ -0,0 +1,62 @@
|
||||||
|
{
|
||||||
|
"raw_response": "```json\n{\n \"claims\": [],\n \"enrichments\": [],\n \"entities\": [\n {\n \"filename\": \"metadao-proposal-7.md\",\n \"domain\": \"internet-finance\",\n \"action\": \"create\",\n \"entity_type\": \"decision_market\",\n \"content\": \"---\\ntype: entity\\nentity_type: decision_market\\nname: \\\"MetaDAO: Proposal #7\\\"\\ndomain: internet-finance\\nstatus: failed\\nparent_entity: \\\"[[metadao]]\\\"\\nplatform: \\\"futardio\\\"\\nproposer: \\\"HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc\\\"\\nproposal_url: \\\"https://www.futard.io/proposal/AuNNyR4oU2zkG1sYBzJ3DJmyDzMKSmSW2yASorWenuC6\\\"\\nproposal_date: 2024-08-28\\nresolution_date: 2024-09-01\\ncategory: \\\"unknown\\\"\\nsummary: \\\"MetaDAO Proposal #7 failed after 4-day voting period with no proposal text or market data available\\\"\\ntracked_by: rio\\ncreated: 2026-03-11\\n---\\n\\n# MetaDAO: Proposal #7\\n\\n## Summary\\nProposal #7 on MetaDAO was created on 2024-08-28 and failed on 2024-09-01. No proposal text, rationale, or market data is available in the source archive. The proposal ran on Autocrat version 0.3.\\n\\n## Market Data\\n- **Outcome:** Failed\\n- **Proposer:** HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc\\n- **Duration:** 4 days (2024-08-28 to 2024-09-01)\\n- **Platform:** Futardio\\n- **Autocrat Version:** 0.3\\n\\n## Significance\\nThis proposal represents an archival record of a failed MetaDAO governance decision. Without proposal content or market volume data, it serves primarily as a timeline marker in MetaDAO's governance history during the Autocrat v0.3 era.\\n\\n## Relationship to KB\\n- [[metadao]] - governance decision\\n- [[futardio]] - platform used\\n\",\n \"timeline_entry\": \"- **2024-08-28** \u2014 [[metadao-proposal-7]] failed: Proposal #7 rejected after 4-day voting period (no details available)\"\n }\n ],\n \"source_update\": {\n \"status\": \"processed\",\n \"processed_by\": \"rio\",\n \"processed_date\": \"2026-03-11\",\n \"claims_extracted\": [],\n \"enrichments_applied\": [],\n \"entities_updated\": [\"metadao-proposal-7.md\", \"metadao.md\"],\n \"key_facts\": [\n \"MetaDAO Proposal #7 created 2024-08-28, failed 2024-09-01\",\n \"Proposal account: AuNNyR4oU2zkG1sYBzJ3DJmyDzMKSmSW2yASorWenuC6\",\n \"DAO account: GWywkp2mY2vzAaLydR2MBXRCqk2vBTyvtVRioujxi5Ce\",\n \"Proposer: HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc\",\n \"Autocrat version: 0.3\"\n ],\n \"notes\": \"Source contains only metadata about a failed MetaDAO proposal with no proposal text, rationale, market data, or voting details. Created decision_market entity for archival completeness and timeline tracking. No extractable claims or enrichments due to absence of substantive content about mechanisms, outcomes, or governance dynamics. This is purely structural metadata documenting that a proposal existed and failed.\"\n }\n}\n```",
|
||||||
|
"parsed": {
|
||||||
|
"claims": [],
|
||||||
|
"enrichments": [],
|
||||||
|
"entities": [
|
||||||
|
{
|
||||||
|
"filename": "metadao-proposal-7.md",
|
||||||
|
"domain": "internet-finance",
|
||||||
|
"action": "create",
|
||||||
|
"entity_type": "decision_market",
|
||||||
|
"content": "---\ntype: entity\nentity_type: decision_market\nname: \"MetaDAO: Proposal #7\"\ndomain: internet-finance\nstatus: failed\nparent_entity: \"[[metadao]]\"\nplatform: \"futardio\"\nproposer: \"HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc\"\nproposal_url: \"https://www.futard.io/proposal/AuNNyR4oU2zkG1sYBzJ3DJmyDzMKSmSW2yASorWenuC6\"\nproposal_date: 2024-08-28\nresolution_date: 2024-09-01\ncategory: \"unknown\"\nsummary: \"MetaDAO Proposal #7 failed after 4-day voting period with no proposal text or market data available\"\ntracked_by: rio\ncreated: 2026-03-11\n---\n\n# MetaDAO: Proposal #7\n\n## Summary\nProposal #7 on MetaDAO was created on 2024-08-28 and failed on 2024-09-01. No proposal text, rationale, or market data is available in the source archive. The proposal ran on Autocrat version 0.3.\n\n## Market Data\n- **Outcome:** Failed\n- **Proposer:** HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc\n- **Duration:** 4 days (2024-08-28 to 2024-09-01)\n- **Platform:** Futardio\n- **Autocrat Version:** 0.3\n\n## Significance\nThis proposal represents an archival record of a failed MetaDAO governance decision. Without proposal content or market volume data, it serves primarily as a timeline marker in MetaDAO's governance history during the Autocrat v0.3 era.\n\n## Relationship to KB\n- [[metadao]] - governance decision\n- [[futardio]] - platform used\n",
|
||||||
|
"timeline_entry": "- **2024-08-28** \u2014 [[metadao-proposal-7]] failed: Proposal #7 rejected after 4-day voting period (no details available)"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"source_update": {
|
||||||
|
"status": "null-result",
|
||||||
|
"processed_by": "rio",
|
||||||
|
"processed_date": "2026-03-11",
|
||||||
|
"claims_extracted": [],
|
||||||
|
"enrichments_applied": [],
|
||||||
|
"entities_updated": [
|
||||||
|
"metadao-proposal-7.md",
|
||||||
|
"metadao.md"
|
||||||
|
],
|
||||||
|
"key_facts": [
|
||||||
|
"MetaDAO Proposal #7 created 2024-08-28, failed 2024-09-01",
|
||||||
|
"Proposal account: AuNNyR4oU2zkG1sYBzJ3DJmyDzMKSmSW2yASorWenuC6",
|
||||||
|
"DAO account: GWywkp2mY2vzAaLydR2MBXRCqk2vBTyvtVRioujxi5Ce",
|
||||||
|
"Proposer: HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc",
|
||||||
|
"Autocrat version: 0.3"
|
||||||
|
],
|
||||||
|
"notes": "Source contains only metadata about a failed MetaDAO proposal with no proposal text, rationale, market data, or voting details. Created decision_market entity for archival completeness and timeline tracking. No extractable claims or enrichments due to absence of substantive content about mechanisms, outcomes, or governance dynamics. This is purely structural metadata documenting that a proposal existed and failed.",
|
||||||
|
"model": "anthropic/claude-sonnet-4.5"
|
||||||
|
}
|
||||||
|
},
|
||||||
|
"model": "anthropic/claude-sonnet-4.5",
|
||||||
|
"date": "2026-03-15",
|
||||||
|
"tokens": {
|
||||||
|
"prompt_tokens": 11434,
|
||||||
|
"completion_tokens": 1052,
|
||||||
|
"total_tokens": 12486,
|
||||||
|
"cost": 0.050082,
|
||||||
|
"is_byok": false,
|
||||||
|
"prompt_tokens_details": {
|
||||||
|
"cached_tokens": 0,
|
||||||
|
"cache_write_tokens": 0,
|
||||||
|
"audio_tokens": 0,
|
||||||
|
"video_tokens": 0
|
||||||
|
},
|
||||||
|
"cost_details": {
|
||||||
|
"upstream_inference_cost": 0.050082,
|
||||||
|
"upstream_inference_prompt_cost": 0.034302,
|
||||||
|
"upstream_inference_completions_cost": 0.01578
|
||||||
|
},
|
||||||
|
"completion_tokens_details": {
|
||||||
|
"reasoning_tokens": 0,
|
||||||
|
"image_tokens": 0,
|
||||||
|
"audio_tokens": 0
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
File diff suppressed because one or more lines are too long
|
|
@ -6,8 +6,13 @@ url: https://www.cambridge.org/core/journals/probability-in-the-engineering-and-
|
||||||
date: 2016-01-01
|
date: 2016-01-01
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
format: paper
|
format: paper
|
||||||
status: unprocessed
|
status: processed
|
||||||
tags: [pipeline-architecture, operations-research, stochastic-modeling, non-stationary-arrivals, capacity-sizing]
|
tags: [pipeline-architecture, operations-research, stochastic-modeling, non-stationary-arrivals, capacity-sizing]
|
||||||
|
processed_by: rio
|
||||||
|
processed_date: 2026-03-11
|
||||||
|
claims_extracted: ["square-root-staffing-formula-requires-peakedness-adjustment-for-non-poisson-arrivals.md", "time-varying-arrival-rates-require-dynamic-staffing-not-constant-max-workers.md"]
|
||||||
|
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||||
|
extraction_notes: "Operations research paper on staffing under non-Poisson non-stationary arrivals. Extracted two claims on peakedness adjustment and dynamic staffing requirements. Direct application to Teleo pipeline architecture for worker scaling. No entity data (academic paper, no companies/products/decisions). No enrichments (novel theoretical contribution not covered by existing claims)."
|
||||||
---
|
---
|
||||||
|
|
||||||
# Staffing a Service System with Non-Poisson Non-Stationary Arrivals
|
# Staffing a Service System with Non-Poisson Non-Stationary Arrivals
|
||||||
|
|
|
||||||
|
|
@ -6,8 +6,13 @@ url: https://epubs.siam.org/doi/book/10.1137/1.9781611974225
|
||||||
date: 2016-01-01
|
date: 2016-01-01
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
format: paper
|
format: paper
|
||||||
status: unprocessed
|
status: processed
|
||||||
tags: [pipeline-architecture, operations-research, AIMD, distributed-resource-allocation, congestion-control, fairness]
|
tags: [pipeline-architecture, operations-research, AIMD, distributed-resource-allocation, congestion-control, fairness]
|
||||||
|
processed_by: rio
|
||||||
|
processed_date: 2026-03-11
|
||||||
|
claims_extracted: ["aimd-converges-to-fair-resource-allocation-without-global-coordination-through-local-congestion-signals.md", "aimd-scaling-solves-variable-load-expensive-compute-coordination-without-prediction.md"]
|
||||||
|
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||||
|
extraction_notes: "Extracted two claims: (1) general AIMD mechanism properties as proven coordination algorithm, (2) specific application to Teleo pipeline architecture. The source is a formal mathematical treatment (SIAM monograph) providing rigorous proofs, making the first claim 'proven' confidence. The second claim is an application proposal with theoretical justification but no empirical validation, hence 'experimental'. No entities to extract—this is pure mechanism theory. No enrichments—AIMD is not currently referenced in the KB."
|
||||||
---
|
---
|
||||||
|
|
||||||
# AIMD Dynamics and Distributed Resource Allocation
|
# AIMD Dynamics and Distributed Resource Allocation
|
||||||
|
|
@ -26,3 +31,10 @@ SIAM monograph on AIMD (Additive Increase Multiplicative Decrease) as a general-
|
||||||
## Relevance to Teleo Pipeline
|
## 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.
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
## Key Facts
|
||||||
|
- AIMD algorithm: additive increase (rate += α) when no congestion, multiplicative decrease (rate *= β, 0 < β < 1) when congestion detected
|
||||||
|
- AIMD is the foundation of TCP congestion control
|
||||||
|
- AIMD has been applied to internet congestion control, smart grid energy allocation, and distributed computing
|
||||||
|
- AIMD convergence is mathematically proven regardless of number of agents or parameter values
|
||||||
|
|
|
||||||
|
|
@ -6,8 +6,13 @@ url: https://epubs.siam.org/doi/10.1137/17M1133944
|
||||||
date: 2018-01-01
|
date: 2018-01-01
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
format: paper
|
format: paper
|
||||||
status: unprocessed
|
status: processed
|
||||||
tags: [pipeline-architecture, operations-research, queueing-theory, Halfin-Whitt, economies-of-scale, square-root-staffing]
|
tags: [pipeline-architecture, operations-research, queueing-theory, Halfin-Whitt, economies-of-scale, square-root-staffing]
|
||||||
|
processed_by: rio
|
||||||
|
processed_date: 2026-03-11
|
||||||
|
claims_extracted: ["square-root-staffing-principle-achieves-economies-of-scale-in-queueing-systems-by-operating-near-full-utilization-with-manageable-delays.md", "moderate-scale-queueing-systems-benefit-from-simple-threshold-policies-over-sophisticated-algorithms-because-square-root-staffing-captures-most-efficiency-gains.md"]
|
||||||
|
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||||
|
extraction_notes: "Extracted two claims about queueing theory and economies of scale. The source is a mathematical tutorial with proven results (SIAM Review), so confidence is 'proven' for the core mathematical claim and 'likely' for the practical application claim. No entities to extract (academic paper, no companies/products/decisions). The relevance to Teleo is in pipeline architecture optimization, which is noted in the source's 'Relevance to Teleo Pipeline' section."
|
||||||
---
|
---
|
||||||
|
|
||||||
# Economies-of-Scale in Many-Server Queueing Systems
|
# Economies-of-Scale in Many-Server Queueing Systems
|
||||||
|
|
@ -26,3 +31,9 @@ SIAM Review tutorial on the QED (Quality-and-Efficiency-Driven) Halfin-Whitt hea
|
||||||
## Relevance to Teleo Pipeline
|
## 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.
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
## Key Facts
|
||||||
|
- Halfin-Whitt QED regime: utilization approaches 1 at rate Θ(1/√n)
|
||||||
|
- Square-root staffing validated empirically for systems as small as 5-20 servers
|
||||||
|
- 100-server system needs ~10 excess servers; 400-server system needs ~20 (not 40) for same quality
|
||||||
|
|
|
||||||
|
|
@ -6,8 +6,13 @@ url: https://www.sciencedirect.com/science/article/pii/S037722172300382X
|
||||||
date: 2023-01-01
|
date: 2023-01-01
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
format: paper
|
format: paper
|
||||||
status: unprocessed
|
status: processed
|
||||||
tags: [pipeline-architecture, operations-research, combinatorial-optimization, job-shop-scheduling, flexible-scheduling]
|
tags: [pipeline-architecture, operations-research, combinatorial-optimization, job-shop-scheduling, flexible-scheduling]
|
||||||
|
processed_by: rio
|
||||||
|
processed_date: 2026-03-11
|
||||||
|
claims_extracted: ["hybrid-flow-shop-scheduling-with-simple-dispatching-rules-performs-within-5-10-percent-of-optimal-for-homogeneous-workers.md", "general-job-shop-scheduling-is-np-complete-for-more-than-two-machines.md"]
|
||||||
|
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||||
|
extraction_notes: "Extracted two claims about scheduling problem complexity and tractability. The source is an operations research review that provides theoretical foundations for understanding pipeline coordination. Key insight: Teleo's pipeline is a hybrid flow-shop, which is computationally easier than general JSSP and can use simple dispatching rules effectively. No entities to extract — this is pure operations research theory with no companies, products, or decisions mentioned."
|
||||||
---
|
---
|
||||||
|
|
||||||
# The Flexible Job Shop Scheduling Problem: A Review
|
# The Flexible Job Shop Scheduling Problem: A Review
|
||||||
|
|
@ -27,3 +32,11 @@ Comprehensive review of the Flexible Job Shop Scheduling Problem (FJSP) — a ge
|
||||||
## Relevance to Teleo Pipeline
|
## 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.
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
## Key Facts
|
||||||
|
- Flow-shop: all jobs follow the same machine order
|
||||||
|
- Job-shop: jobs can have different machine orders
|
||||||
|
- Hybrid flow-shop: multiple machines at each stage, jobs follow same stage order
|
||||||
|
- Flexible JSSP adds machine assignment as decision variable on top of classical JSSP
|
||||||
|
- Recent trend in FJSP research: multi-agent reinforcement learning for dynamic scheduling with worker heterogeneity
|
||||||
|
|
|
||||||
|
|
@ -6,13 +6,17 @@ url: "https://www.futard.io/proposal/AuNNyR4oU2zkG1sYBzJ3DJmyDzMKSmSW2yASorWenuC
|
||||||
date: 2024-08-28
|
date: 2024-08-28
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
format: data
|
format: data
|
||||||
status: unprocessed
|
status: null-result
|
||||||
tags: [futardio, metadao, futarchy, solana, governance]
|
tags: [futardio, metadao, futarchy, solana, governance]
|
||||||
event_type: proposal
|
event_type: proposal
|
||||||
processed_by: rio
|
processed_by: rio
|
||||||
processed_date: 2024-08-28
|
processed_date: 2024-08-28
|
||||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||||
extraction_notes: "This source contains only metadata about a failed MetaDAO proposal with no proposal text, rationale, market data, or voting details. The source provides verifiable facts (proposal number, accounts, dates, status) but no evidence supporting arguable claims about futarchy mechanisms, governance outcomes, or market behavior. Without proposal content or outcome analysis, there is nothing to extract as claims or enrichments. The existing claim 'MetaDAOs futarchy implementation shows limited trading volume in uncontested decisions' could potentially be enriched if this proposal had volume data, but none is provided. This is purely archival metadata."
|
extraction_notes: "This source contains only metadata about a failed MetaDAO proposal with no proposal text, rationale, market data, or voting details. The source provides verifiable facts (proposal number, accounts, dates, status) but no evidence supporting arguable claims about futarchy mechanisms, governance outcomes, or market behavior. Without proposal content or outcome analysis, there is nothing to extract as claims or enrichments. The existing claim 'MetaDAOs futarchy implementation shows limited trading volume in uncontested decisions' could potentially be enriched if this proposal had volume data, but none is provided. This is purely archival metadata."
|
||||||
|
processed_by: rio
|
||||||
|
processed_date: 2026-03-11
|
||||||
|
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||||
|
extraction_notes: "Source contains only metadata about a failed MetaDAO proposal with no proposal text, rationale, market data, or voting details. Created decision_market entity for archival completeness and timeline tracking. No extractable claims or enrichments due to absence of substantive content about mechanisms, outcomes, or governance dynamics. This is purely structural metadata documenting that a proposal existed and failed."
|
||||||
---
|
---
|
||||||
|
|
||||||
## Proposal Details
|
## Proposal Details
|
||||||
|
|
@ -39,3 +43,11 @@ extraction_notes: "This source contains only metadata about a failed MetaDAO pro
|
||||||
- DAO account: GWywkp2mY2vzAaLydR2MBXRCqk2vBTyvtVRioujxi5Ce
|
- DAO account: GWywkp2mY2vzAaLydR2MBXRCqk2vBTyvtVRioujxi5Ce
|
||||||
- Proposer: HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc
|
- Proposer: HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc
|
||||||
- Autocrat version: 0.3
|
- Autocrat version: 0.3
|
||||||
|
|
||||||
|
|
||||||
|
## Key Facts
|
||||||
|
- MetaDAO Proposal #7 created 2024-08-28, failed 2024-09-01
|
||||||
|
- Proposal account: AuNNyR4oU2zkG1sYBzJ3DJmyDzMKSmSW2yASorWenuC6
|
||||||
|
- DAO account: GWywkp2mY2vzAaLydR2MBXRCqk2vBTyvtVRioujxi5Ce
|
||||||
|
- Proposer: HwBL75xHHKcXSMNcctq3UqWaEJPDWVQz6NazZJNjWaQc
|
||||||
|
- Autocrat version: 0.3
|
||||||
|
|
|
||||||
|
|
@ -6,9 +6,13 @@ url: "https://www.futard.io/proposal/6LcxhHS3JvDtbS1GoQS18EgH5Pzf7AnqQpR7D4HxmWp
|
||||||
date: 2024-11-13
|
date: 2024-11-13
|
||||||
domain: internet-finance
|
domain: internet-finance
|
||||||
format: data
|
format: data
|
||||||
status: unprocessed
|
status: null-result
|
||||||
tags: [futardio, metadao, futarchy, solana, governance]
|
tags: [futardio, metadao, futarchy, solana, governance]
|
||||||
event_type: proposal
|
event_type: proposal
|
||||||
|
processed_by: rio
|
||||||
|
processed_date: 2026-03-11
|
||||||
|
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||||
|
extraction_notes: "Source is a futarchy governance proposal for Coal token emission schedule. Extracted as decision_market entity (the proposal itself) and created parent entity for Coal project. No novel claims about futarchy mechanisms - this is a straightforward application of existing governance patterns. The shift from algorithmic to market-driven emission control is notable but represents implementation of known futarchy principles rather than new mechanism insight."
|
||||||
---
|
---
|
||||||
|
|
||||||
## Proposal Details
|
## Proposal Details
|
||||||
|
|
@ -66,3 +70,10 @@ A follow-up decision market will be held in early January, approximately two mon
|
||||||
- Autocrat version: 0.3
|
- Autocrat version: 0.3
|
||||||
- Completed: 2024-11-17
|
- Completed: 2024-11-17
|
||||||
- Ended: 2024-11-17
|
- Ended: 2024-11-17
|
||||||
|
|
||||||
|
|
||||||
|
## Key Facts
|
||||||
|
- Coal token emission rate reduced from 15.625 to 7.8125 per minute (2024-11-17)
|
||||||
|
- Coal annual inflation reduced from ~110% to ~56% (2024-11-17)
|
||||||
|
- Coal completed 6 halvings before governance transition
|
||||||
|
- Coal proposal 6LcxhHS3JvDtbS1GoQS18EgH5Pzf7AnqQpR7D4HxmWpy passed (2024-11-17)
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue