Sounder: explainable Fibonacci estimates for AI tasks
- My contribution
- Design and implementation.
- Scope
- Feature extraction, weighted scoring, Fibonacci buckets and model inventory.
- Evidence
- Implementation inspected at c980fb6; reconstructed examples are labelled.
Page by Julian Ramirez ·
An estimate of “3” looks precise enough to act on. It tells you almost nothing about why it is 3, which part of the task drove the result or whether the same description would receive the same estimate tomorrow.
Sounder makes that reasoning inspectable. It extracts signals from a description, applies weights, adds their contributions and maps the result to a Fibonacci bucket. Feedback can change the weights used by future estimates.
That makes the estimate easier to question. It does not, by itself, make the estimate accurate. The distinction is easiest to see by following one small example all the way through.
My contribution and design scope
I built Sounder as an inspectable estimation pipeline: extract signals, apply weights and map the score to a discrete bucket. The design makes contributions visible and keeps feedback scoped. The worked example demonstrates a repeatable calculation, not validated predictive accuracy.
Start with a description you can trace
For the description “Implement OAuth login flow,” the inspected feature extractor recognizes a code-related signal and text-length signals. These are features extracted from the wording, not a deep semantic analysis of the implementation that OAuth might require.
Sources & implementation notes
This is an important limit of the mechanism. A task description can omit the hard parts, and a text-based estimate cannot inspect requirements that were never supplied. The visible features give the developer somewhere concrete to challenge the result.
From a weighted score to a Fibonacci bucket
With the default weights and no learned overrides, the example produces a raw score of 2.85. Sounder maps that score to the nearest supported Fibonacci bucket, which is 3. Equal-distance ties favor the lower bucket.
The result below was reproduced against revision c980fb6. It is a computed example, not a fabricated benchmark or a recorded delivery outcome.
Sources & implementation notes
The bucket is a discrete representation of the score. It should not be silently converted into hours, cost or a probability of success; this example establishes none of those mappings.
Repeat the estimate, then open its explanation
Repeatability is useful when comparing results across a workflow. With the same input and the same weight state, the scorer repeats the same estimate. Change either one and you have changed the conditions of the comparison.
Learned weights: empty
Same result
Sources & implementation notes
Now open the contribution breakdown. The task.code contribution is 1.50, task.words contributes 0.75, and task.length contributes 0.60. Together they produce the raw score rather than merely attaching an explanation after the fact.
Sources & implementation notes
scoreEstimate({ kind: "task", scope: "default", input: "Implement OAuth login flow", learnedWeights: {} }) returns rawScore 2.85 and bucket 3. Contributions: task.words 1 × 0.75; task.length 0.6 × 1; task.code 1 × 1.5.
That is the part I would inspect first. If the features do not reflect what makes the task difficult, a stable bucket can still be misleading. An explanation earns its value by making the mismatch visible.
Feedback changes the state behind future estimates
When an outcome is recorded, Sounder computes a weight update from the difference between the predicted and actual buckets. Learned weights are scoped by context, kind and feature and can be persisted for later use.
This means “ask twice, get the same answer” needs a qualification: the weight state must remain unchanged. Learning is meant to change future estimates. Whether those changes improve predictive performance would require outcome evidence beyond the calculation shown here.
Model recommendations need an available candidate
Sounder also maps task descriptions to required model tiers and considers supplied inventory. At this revision, that recommendation path classifies the task using default weights, then filters and ranks candidate models.
Sources & implementation notes
Recommendation classifies the task with default weights, then filters and ranks supplied inventory. No claim that a recommended model is always available or best on a benchmark.
If no candidate meets the tier requirement, the fallback is inherit/default with unknown availability. A recommendation therefore reflects both the classification and what the system knows about inventory. It is not a universal ranking of model quality.
Before trusting an estimate, inspect the input, the contributions and the state that produced it. Chest’s evidence-based completion checks apply the same habit at the other end of the task: make the basis for a decision visible enough to review.