Comparison governance
A scoped, source-backed comparison policy
GridNinja comparisons must describe what reviewed public materials establish, not what a competitor supposedly cannot do. Each comparison names the category, capability, source, retrieval date, scope, and limitation. Sources receive quarterly review, and crawlable citations remain available outside interactive drawers. Comparisons are corrected when products, documentation, or evidence change rather than being preserved for marketing convenience.
Definition
What it is
The policy governs comparative wording about categories such as capacity acceptance, DCIM, digital twins, workload orchestration, and runtime assurance.
Category boundary
What it is not
It is not permission to infer unpublished product behavior, customer outcomes, market leadership, or universal absence from a limited documentation review.
Operational significance
Why operators care
Technical evaluators can inspect the source boundary and distinguish architectural roles without relying on an unqualified feature matrix.
Mechanism
How the decision path works
- Step 01
Prefer first-party documentation, standards, and directly inspectable materials.
- Step 02
Record retrieval date, the exact proposition established, and what is not established.
- Step 03
Scope public wording to the evidence and expose stable source anchors.
- Step 04
Review competitor-dependent records at least quarterly or after a known material release.
Textual diagram equivalent
Decision flow
Comparison question → primary-source review → establishes / does not establish → scoped wording → stable citation → quarterly review or correction.
Scoped comparison example
Visibly scoped example
A reviewed document may establish that a product reports facility telemetry. It does not establish that the product lacks a separate capacity-acceptance integration not described in that document.
Failure and no-proof cases
- Absence from one document is presented as proof that a capability does not exist.
- A category comparison becomes an unsupported named-product attack.
- Source links are available only inside client-rendered interaction.
Limitations
- Public materials may lag current product behavior.
- Category boundaries overlap and must be presented as architectural roles, not absolutes.
- Legal review may be required for named comparisons.
Evidence and sources
Inspect the basis, not just the answer
Local evidence objects show the GridNinja proof contract. Primary sources provide external standards and risk-management context; they do not validate GridNinja performance.
Related operator resources
Continue the proof path
- Before you trust another megawatt, ask what proves it.Compare GridNinja's inside-the-fence capacity-acceptance role with DCIM, digital twins, AIOps, and grid flexibility platforms using scoped public sources.
- The platform for runtime-assured virtual capacitySee how GridNinja coordinates workloads, cooling, storage, and bridge power inside a runtime-assured dispatch envelope.
- Corrections remain visible and attributableThe publication-gated GridNinja method for permanent correction, expiry, and retraction records for public technical claims.
Proof before autonomy
Test the evidence boundary against your capacity question
Start with a Capacity Audit or read-only Shadow Mode discussion. GridNinja does not require control authority to identify where a capacity claim remains unproven.