Platform Methodology

1. What a TVSM-PL score is — and is not

A TVSM-PL score is a capability rating. It measures the platform’s ability to do its job reliably, accurately, and honestly across five dimensions — not the trader’s satisfaction, not the brand’s reputation, not the marketing polish.

The score is the platform’s capability under audit, not a per-trader fit recommendation. Two platforms can both land at 77 and yet suit completely different traders — the dimensional breakdown and “Best-for” capability vectors on each platform page are where fit gets read. Treating 77 as inherently equivalent to 77 on another platform misses the point of the framework.

2. Architecture — two subtypes, one spine

TVSM-PL forks at the variable layer into two subtypes, each carrying its own 22-variable inventory:

The dimension weights are identical across subtypes (30/22/20/12/16 = 100), and the spine — score formula, bands, evidence model, decay engine, trajectory adjustment, hard-cap mechanics — is shared with TVSM-PF and TVSM-BR. That’s what makes scores semantically comparable across subtypes: a 76 on an execution platform means the same thing as a 76 on an analysis platform.

Unit of analysis: the vendor-controlled software system. Broker-side outages, fills, spreads, slippage, and risk-engine rejections are out of scope. When a failure is reported, the vendor-attribution doctrine asks: is the failure reproducible in a vendor-controlled demo, replicated across multiple independent broker infrastructures, or vendor-acknowledged? If none of those hold, single-broker complaints route to a future broker overlay framework — they don’t move the platform’s score.

3. The scoring formula

Each of the 22 variables is scored on a 1–10 integer scale. A platform scores at the highest level whose condition bundle is fully satisfied (AND-logic). Ladders are monotonic and single-axis: every rung scores the same observable; only the threshold moves.

Weights sum to 100, so the formula produces a 0–100 score directly. The trajectory adjustment captures direction, not level: a platform with a strong base that’s trending sharply down publishes at a score 3 points below its base, with the trajectory glyph (▲▲ / ▲ / ▬ / ▼ / ▼▼) visible inline.

4. Score bands

TVSM-PL uses the same risk-framed band labels as TVSM-PF. Boundaries are common across all TVSM 2.0 frameworks.

Affiliate-link rule.Platforms scoring below 50 receive no affiliate links. They carry a “Research Only” label. Public, permanent, non-negotiable. See the affiliate disclosure for the full firewall.

5. The five dimensions

Dimension weights sum to 100%. Dimension 2 swaps content between subtypes (Execution & Data on execution platforms, Analytical Quality on analysis platforms) but keeps the same 22-point weight — which is what preserves cross-subtype score comparability.

6. The 22 variables (execution_platform)

Each variable scores 1–10 on a monotonic predicate ladder. The descriptions below summarize the axis each variable measures; the full per-rung ladders are in the source specification.

6b. analysis_platform divergences

The analysis_platform subtype keeps the same 22-variable structure but substitutes the following variables to reflect its different failure modes and value model:

All other variables — vendor_incident_record, update_regression_rate, incident_transparency, release_documentation_quality, workflow_excellence, market_breadth, data_export_portability, cross_platform_availability, third_party_integration_support, and the three Cost & Transparency variables — apply to both subtypes with the same definitions.

7. Hard caps — four-tier system

Hard caps override the computed composite. They are reserved for danger and disqualification — not for routine weakness, which is what the additive score is for. Every applicable cap is evaluated; the lowest ceiling applies. The cap is shown on the platform page, with the specific evidence that triggered it.

Cap ordering rationale. Information-integrity theory: visible failure collapses the decision space (bounded harm); silent failure corrupts it while permitting decisions (unbounded harm). PL-Cap 1 therefore ranks below PL-Cap 2 in ceiling, even though both indicate serious failure.

Invariant Suppression on PL-Cap 1. When PL-Cap 1 fires, the composite still computes (so rankings remain continuous), but the platform’s dimensional sub-scores are flagged on the page as not interpretable. A silently-corrupting platform’s dimensional breakdown is itself untrustworthy. PL-Cap 2 does not carry this flag — visible unreliability doesn’t corrupt the meaning of sub-scores.

8. Evidence requirements

Every variable score traces to a citation. Source precedence runs vendor documentation and vendor-published metrics first; third-party monitoring next; community pattern evidence last — and only when a pattern is reproducible across multiple independent infrastructures or vendor-acknowledged.

TVSM-PL uses the same five-state evidence model as TVSM-PF: true, false, unknown, contradictory, and stale. A variable that cannot be evidenced at the higher rungs of its ladder defaults to the catch-all level 1 — the “Missing Data Rule.” Vendor opacity is not neutral; it is a risk priced at level 1.

Reference operating load. For variables that can be distorted by arbitrary workload — client responsiveness, signal integrity, alert delivery timeliness — the score is computed against a defined reference workload typical of the platform’s target users, not a stress-test workload. Platforms that tolerate beyond-reference loads aren’t rewarded extra; platforms that fail at beyond-reference loads aren’t penalized unless they explicitly market support for those workflows.

9. Independence firewall

Affiliate relationships never affect scores. The methodology is license-agnostic: no licensee, including a scored vendor, can move its own score. Platforms we don’t editorially recommend do not receive affiliate links. This is stated publicly, in writing, and applies regardless of what commission rate is offered.

A 41/100 score is as important to publish as an 79/100 score. The negative scores are the trust signal that makes the positive scores meaningful. A site that only rates platforms well is not a review site — it is an advertisement.

10. Calibration discipline

TVSM-PL ships with a four-tier calibration protocol:

• Tier 1. Live-platform calibration — every platform we score is fully calibrated against sourced evidence under A6/A7 source precedence and the vendor-attribution doctrine.
• Tier 2. Cross-platform consistency checks — a 76 means the same thing across platforms and across subtypes.
• Tier 3. Historical anchors — retired platforms, defunct services, and pre-rebuild states scored as historical_only reference points. Excluded from live rankings, but they exercise the lower bands and confirm the caps fire on real cases.
• Tier 4. Synthetic stress tests — constructed platforms that trip each PL-Cap, to verify cap mechanics and the invariant-suppression flag in isolation.

The first three tiers guard against “score by reputation” drift; the fourth guards against the cap logic only ever being exercised in the abstract.

11. Version history

Versioning is semantic and per-framework. Patch bumps are predicate-rubric clarifications — no weight changes, no variable additions, no new caps. Minor bumps add variables or change evidence standards. Major bumps change dimension weights by > 3% in absolute terms or add a framework. On any version bump, every scored platform is fully recomputed and a score_history snapshot is recorded with the methodology-driven delta.

12. Primary-source references

Variable scoring draws on platform-vendor primary documentation first. Two representative examples of the vendor-published source class TVSM-PL treats as authoritative:

• Sierra Chart — Teton order-routing documentation ↗

  Authoritative vendor documentation for order-routing topology, server-managed bracket/OCO behavior, and infrastructure redundancy — the kind of vendor-published evidence that drives `order_state_integrity` and `order_type_breadth` scores.

• MetaTrader 5 — official release notes ↗

  Vendor-published versioned changelog with explicit feature additions, breaking-change flags, and bug-fix entries — the kind of release-documentation evidence that drives `update_regression_rate` and `release_documentation_quality` scores.