Capability
Task quality, control and the share of outputs that meet a defined acceptance rule.
HubAI separates facts, observed tests, editorial judgement and community feedback. A sponsor can buy visibility. It cannot buy a higher score.
As of 7 October 2026, legacy numerical profile scores are withheld because no published same-task record supports them. Test Lab tables reweight those profile dimensions; they are not instrumented measurements. Approved community runs appear separately and do not establish an independent HubAI test. New products marked Test pending receive no HubAI Score.
A completed same-task study must publish the exact product or model, plan, test dates, fixed inputs, sample size, acceptance criteria, failures, correction effort and observed billed cost. Until that record exists, readers should treat a protocol as a test to run, not evidence that it has been run.
Fit Score is a deterministic shortlist heuristic. For a test-pending product the current algorithm starts from a provisional 58/100 baseline, then applies the disclosed context rules. That starting value is a planning convention, not an observed capability result. Confidence remains Low and the independent-test warning remains visible.
The default weighting is adjusted when the category creates a different kind of risk. The underlying dimensions stay visible.
Task quality, control and the share of outputs that meet a defined acceptance rule.
Complete cost per accepted result, including retries, limits and correction time.
Setup, learning curve, team administration and the route from trial to useful work.
API and product connections that remove copying, re-entry and workflow breaks.
Consistency, failure modes, recovery and operational availability evidence.
Clarity of data use, retention, permissions, controls and buyer-facing documentation.
Moderated, attributable community signal; never invented and never allowed to dominate.
HubAI keeps the editorial score and the context-specific Fit Score separate. Fit Score uses deterministic rules, records the chosen context and prints reason codes beside the result.
Official product information, dated checks and labelled editorial judgement. Observed tests and approved community feedback are additional evidence only where a published record exists.
A missing dimension is not an observed result. Some planning tools use explicit provisional defaults; these must be labelled and must not be described as independent measurements.
Low, limited or medium confidence appears beside contextual results. High confidence requires repeated independent evidence.
Method version, product review date and material pricing or capability changes remain visible to the buyer.
Pricing pages, product documentation, policies and release notes. These establish what a vendor says.
A repeatable task, fixed input and clear acceptance rules. This establishes what the product does in a defined test.
HubAI's interpretation of fit, trade-offs and buyer risk. Opinion is labelled and cannot be purchased.
Moderated user reviews and reactions. These never silently replace editorial scoring.
Weights below describe evaluation emphasis. Benchmark pages publish protocols for buyers to run; a protocol alone is not a completed test.
Output 30 · Control 20 · Value 15 · Ease 10 · Speed 10 · Features 10 · Reliability 5
Code quality 30 · Context 20 · Agent ability 15 · IDE workflow 10 · Speed 10 · Value 10 · Reliability 5
Claim accuracy 25 · Sources 25 · Coverage 15 · Workflow 15 · Value 10 · Privacy 10
Provenance 25 · Auditability 20 · Accuracy 20 · Security 15 · Workflow 10 · Value 10
Product access, pricing and capabilities change quickly. HubAI records review dates, distinguishes editorial updates from vendor changelogs and revisits profiles when a material change alters the buyer decision.