Knowledge Platform Comparison

Knowledge Platform Competitive Assessment — Methodology Reference

How each assessment cycle is conducted, validated, and audited

Document type: Methodology reference · Audit support Scope: Cloud-Native Assessment + On-Premise & Hybrid Assessment Current cycle: June 2026 Maintained by: Rainer Geissendoerfer · Knowledge Platform Comparison Project

Disclaimer. This is an independent competitive assessment compiled solely from publicly available sources — vendor product documentation, public release notes and announcements, and published industry-analyst research. It contains no confidential, non-public, or proprietary information of Teradata or any other vendor, and no Teradata internal intellectual property. The analysis and any opinions are the author's own and do not represent an official position or communication of Teradata Corporation. All product names and trademarks are the property of their respective owners; their use is for identification and comparison only and implies no endorsement or affiliation.

Purpose of this document

This document describes, at audit level, how the Knowledge Platform Competitive Assessment is constructed in each cycle. It covers the research methodology, the rating standard, the validation gates applied before any output is published, and a tab-by-tab inventory of every narrative element — what gets re-evaluated, what gets updated automatically, and what requires analyst judgment.

It is intended to give leadership, compliance reviewers, and external briefing recipients confidence that the assessment output is:

Grounded in a consistent, documented methodology applied identically to all vendors
Verified by a structured sequence of programmatic checks before publication
Traceable — every rating change carries a source, a date, and a confidence level
Reproducible — any output file can be regenerated from its data file and template

1. Assessment structure

Two parallel assessments

The comparison runs as two parallel documents serving different audiences and market timescales:

Assessment	Vendors assessed	Vendor count
Cloud-Native	Teradata, Snowflake, Databricks, Microsoft, AWS, Google	6
On-Premise & Hybrid	Teradata, IBM, Oracle, SAP, Cloudera, SAS, Dell	7

Teradata appears in both assessments and is rated against the same requirements and standard in both.

The 4-layer architecture

Every vendor is evaluated through the same four-layer Knowledge Platform architecture, in the order data flows through a production system:

Layer	Function	Strategic role
Knowledge Layer	Turns raw data into interpretable, relational knowledge — unified storage, vectors, knowledge graphs, industry schemas, metadata, lineage	The foundation; without it, agents reason over data dumps, not enterprise knowledge
Translation Layer	Converts knowledge into governed business language consumable by humans and machines — semantic layers, ontologies, reusable logic, NL interfaces	The primary defense against AI hallucinations; the layer where most vendors are weakest
Agentic Layer	Where agents discover, reason over, and act on enterprise knowledge — agent builders, MCP, multi-agent orchestration, evaluation, memory	Production readiness here separates demos from deployed solutions
Policy Layer	The trust layer — embedded governance, AI guardrails, agent identity, FinOps, compliance, sovereignty, model lifecycle	In regulated industries, this layer is the deciding factor

No vendor is allowed a bespoke framing. All four layers are assessed for all vendors using the same structure.

27 analyst-grounded requirements

Each layer breaks down into specific functional requirements — 27 in total (7 Knowledge, 6 Translation, 7 Agentic, 7 Policy). Each requirement carries an analyst-assigned relevance weight (2× or 3×) that acts as a scoring multiplier.

ID	Layer	Requirement	Weight	Primary source
K1	Knowledge	Unified storage for structured + unstructured data	2×	Forrester Data Fabric Q4 2025
K2	Knowledge	Enterprise vector store (embeddings, hybrid search)	3×	Gartner AI Engineering 2025
K3	Knowledge	Metadata & lineage management (technical + business)	3×	Forrester/Gartner D&A Governance
K4	Knowledge	Knowledge graph / entity-relationship modeling	2×	Forrester Data Fabric
K5	Knowledge	Industry data models / domain-specific schemas	3×	Forrester vertical IP
K6	Knowledge	Data quality & observability	2×	Gartner D&A Governance MQ 2026
K7	Knowledge	Unified data catalog with AI-powered discovery	2×	Gartner/Forrester
T1	Translation	Platform-native semantic layer (metrics, business terms)	3×	Forrester/Gartner
T2	Translation	Ontology / business concept modeling	2×	Gartner active metadata
T3	Translation	Reusable business logic across BI, AI, and engineering	3×	Forrester Data Fabric
T4	Translation	Open / interoperable semantic standards	2×	Forrester openness criteria
T5	Translation	Natural language interface to business semantics	2×	Gartner augmented analytics
T6	Translation	Semantic layer for AI grounding (anti-hallucination)	3×	Emerging analyst consensus
A1	Agentic	Agent builder / orchestration (no-code + pro-code)	2×	Forrester agentic AI
A2	Agentic	Knowledge-grounded agents (enterprise context-aware)	3×	Gartner agentic AI
A3	Agentic	MCP server / tool integration protocol	2×	Emerging standard
A4	Agentic	Multi-agent collaboration & orchestration	2×	Gartner multi-agent systems trend 2026
A5	Agentic	RAG pipeline (retrieval, evaluation, guardrails)	3×	Forrester/Gartner
A6	Agentic	Agent evaluation & observability	2×	Gartner AI engineering
A7	Agentic	Agent memory & state management	2×	Gartner production agents
P1	Policy	Embedded governance (access, audit, lineage)	3×	Forrester/Gartner D&A Governance
P2	Policy	AI-specific guardrails (hallucination, toxicity, prompt injection)	3×	Gartner AI Security Platforms 2026
P3	Policy	Agent identity & permission management	2×	Gartner AI Security Platforms 2026
P4	Policy	Cost controls & FinOps for AI workloads	2×	Forrester TCO
P5	Policy	Regulatory compliance frameworks (HIPAA, SOX, GDPR)	3×	Gartner/Forrester
P6	Policy	Data sovereignty & hybrid/multi-cloud deployment	2×	Gartner geopatriation trend 2026
P7	Policy	Governance of AI models & data products	2×	Gartner D&A Governance MQ 2026

Weights are editable in the published Capability Matrix tab, allowing audiences with different priorities (regulated bank, digital-native, data-intensive enterprise) to reweight requirements and see how rankings shift — without changing the underlying evidence.

2. Rating standard

Red / Amber / Green scale

Every vendor is rated on every requirement using a strict three-tier scale applied identically to all vendors, including Teradata:

Rating	Meaning
GREEN	Capability is Generally Available (GA), proven at enterprise scale, and integrated into the platform. Official release notes or documentation confirms GA status.
AMBER	Capability exists but is in Preview, Beta, or Limited Availability; or is partial; or is partner-dependent (see partnership rule). Not yet production-ready by the above standard.
RED	Capability is absent, nascent, requires significant custom engineering, or has been cancelled / discontinued.

Critical rules:

Preview / Beta / Limited Availability is AMBER at most, regardless of vendor roadmap claims or announced timelines
When evidence is ambiguous, the existing rating is kept and the finding is flagged for manual review
A vendor's own product marketing is not sufficient evidence of GA status — official release documentation is required

Weighted scoring

Each vendor receives a weighted score computed as:

$$\text{Score} = \sum_{i=1}^{27} \text{weight}_i \times \text{RAG}_i$$

where $\text{RAG}_i \in \{3, 2, 1\}$ for $\{G, A, R\}$ respectively.

The maximum possible score (all GREEN, all weight-3) defines 100% of the theoretical maximum. Vendor percentages in the Executive Summary and Conclusion tab are computed from this formula and verified programmatically each cycle (see Section 4, Gate §4c-6).

Partnership rating rule

Vendors increasingly close capability gaps through ISV partnerships. The methodology distinguishes three tiers that determine whether a partnership raises a rating:

Tier	Definition	Rating impact
Certified / embedded	Vendor markets it as a joint solution with joint support; joint go-to-market exists	Rate at the same tier as the joint solution's GA status — GREEN if GA
Documented integration	Partner published an official integration guide; vendor engineering validated it	AMBER at most — the integration adds operational ownership the platform vendor does not control
Incidental compatibility	Works via API but no co-marketing or joint support exists	No rating uplift — treated as custom engineering

This rule is applied before Phase 3 recommendations are compiled. The full partnership registry is maintained in Data/partnerships.md and published in the Partnerships tab of each output document.

Update cadence — weekly (Red / Amber) and monthly (full Red / Amber / Green)

The assessment is maintained on a continuous two-tier cadence. Every published edition carries a refresh-scope badge so readers know how deeply it was reviewed.

Cadence	Scope re-examined	What it captures	Edition badge
Weekly	Red and Amber ratings	New GA releases, newly-closed gaps, and emerging risks on the capabilities still in motion. Established Green strengths are carried forward, with a lightweight scan for any regression (a deprecated or discontinued capability).	Two lit dots — Red / Amber update
Monthly	Full Red / Amber / Green	Everything in the weekly pass, plus a full re-review of every Green (production-grade, proven) capability — the GREEN-Refresh. Captures developments that strengthen an already-leading capability (new proof points, expanded scope, fresh GA milestones) and re-tests whether any Green has been matched by a competitor.	Three lit dots — Full Red / Amber / Green update

Why two tiers. Red and Amber capabilities decide near-term competitive position and change week to week, so they warrant constant attention. Green capabilities are stable by definition; re-validating all of them every week would add cost without changing the verdict. The monthly full review keeps even the strengths current and ensures no leadership claim goes unchallenged. In short: the weekly cadence keeps the assessment current on what is changing; the monthly cadence keeps the entire assessment authoritative.

A GREEN rating is the ceiling — the monthly pass never inflates a score. When a Green capability has strengthened, its narrative is augmented, not reset: still-accurate evidence is preserved and only superseded phrasing (an outdated count, a past milestone date) is revised. A Green rating is lowered only if the capability has genuinely regressed or a competitor has reached parity.

3. Source hierarchy and research standards

Evidence is weighted in the following order. Lower-tier sources are used only when higher-tier sources are unavailable or ambiguous:

1. Official vendor documentation — product release notes, GA announcements on vendor blogs, official technical documentation 2. Tier-1 analyst reports — Forrester Wave, Gartner Magic Quadrant/MarketScape, IDC MarketScape (within the past 12–18 months) 3. Analyst blog summaries — Forrester/Gartner analyst blog posts, IDC Perspectives 4. Industry commentary — vendor case studies, partner-published integration documentation

Social media, press releases without product documentation, and unverified third-party commentary are not used as rating evidence.

Time-bounding: Each cycle focuses on announcements and releases from the past 6–12 months. The research window is stated explicitly in the References tab of each output document.

4. The assessment cycle — phase by phase

Each cycle follows a fixed six-phase sequence. No phase may be skipped. Gates between phases are documented and must be explicitly passed before the next phase begins.

Phase 1 — Extract current state

The cycle begins by reading both data files (Data/cloud-data.js and Data/onprem-data.js) and producing a complete rating table for all 27 requirements across all vendors. This table becomes the baseline against which all research findings are compared.

Output: A full rating grid (27 rows × 6 or 7 vendor columns) for each assessment, with flags on requirements likely to have changed since the prior cycle.

Phase 2 — Research latest capabilities

For each requirement that is not GREEN across all vendors, targeted web research is conducted to determine whether capability status has changed.

Priority search targets (highest change velocity first):

Agentic Layer: MCP server GA status (A3), multi-agent orchestration (A4), agent memory (A7), agent builders (A1)
Translation Layer: Semantic layer GA status (T1), ontology/knowledge graph (T2, K4)
Knowledge Layer: Knowledge graph GA transitions (K4)
Policy Layer: AI guardrails (P2), agent identity (P3)

Partnership sweep (mandatory, every cycle — not optional):

For every vendor with an AMBER or RED rating, an open-ended partnership search is conducted to discover whether a certified or documented integration addresses the gap
Existing confirmed partnerships are re-validated to confirm they remain active and relevant
A Partnership Scan Summary table documents every search performed, its outcome, and confidence level

Downgrade scan: Any deprecated, discontinued, or cancelled capabilities are flagged for AMBER→RED or GREEN→AMBER downgrades.

Phase 3 — Compile recommendations

Each research finding is structured as a formal recommendation block:

RECOMMENDATION: UPGRADE | DOWNGRADE | NO CHANGE
Assessment: cloud | onprem | both
Requirement: [ID] — [name]
Vendor: [vendor]
Current: [G/A/R]  →  Proposed: [G/A/R]
Partnership: [Partner — tier]
Evidence: [Product name, date, URL]
Confidence: HIGH | MEDIUM | LOW
New rationale: [One sentence explaining the rating]
New capability description: [Updated short description]

The full recommendation list is presented to the analyst before any data edits are applied. The analyst confirms which recommendations to apply, with the option to skip specific items.

Phase 4 — Apply changes to data files

4a — Rating data updates

For each confirmed recommendation, three fields are updated in the data file:

Field	Location	Content
`REQUIREMENTS[n].ratings[vendor]`	Requirements array	Rating letter: `G`, `A`, or `R`
`RATIONALES[reqId][vendor]`	Rationales object	One sentence: "Rated [GREEN/AMBER/RED] because [reason]."
`REQUIREMENTS[n].details[vendor]`	Requirements array	Short capability description (1–2 sentences)

No rating is changed without updating all three fields.

4b — Narrative content updates

All authored narrative content lives in STATIC_NARRATIVES within each data file — not in the HTML templates. Templates contain only rendering logic. This architectural separation means that every content update is a data file edit, auditable in version control.

Mandatory every cycle:

editionDate — updated to current month + year; drives both the header subtitle and the Architecture tab date automatically
references.methodologyPara2 — the "as of [Month Year]" sentence in the References tab methodology note

Triggered by rating changes:

Narrative field	Trigger for re-evaluation
`execSummaryTakeaways` (5 cloud / 7 on-prem items)	Any rating change, any direction, any weight
`strategicFindings`	Any rating change
`competitiveLandscape[vendor].oneline`	Any rating change for the affected vendor
`fieldGuidance` ("vs. [Vendor]" blocks)	Any rating change for the affected vendor
`winsToday`	Teradata gains or loses a GREEN rating
`mustAccelerate`	Teradata AMBER/RED gap closes or opens
`VLN[vendor].vision`	Weight-3 gap opens/closes, or comparative claim goes stale
`VLN[vendor].[layer].why/capabilities/excels/gaps`	Rating change in that layer for that vendor
`REQUIREMENTS[n].details[vendor]`	Any rating change for that requirement+vendor
`vendorDiffs[vendor].strengths/gaps`	Rating change that is explicitly cited in a bullet

Cumulative-change threshold rule — conclusionIntro ("The Honest Picture") and execSummaryIntro ("What the Data Shows") are re-evaluated whenever:

≥3 rating changes are applied in the cycle, or
Any layer's GREEN count changes for any vendor, or
A vendor is added or removed

Auto-computed fields — no manual update required:

Header subtitle vendor count and requirement count: computed from VENDORS.length and REQUIREMENTS.length at render time
Executive Summary scope paragraph vendor and requirement counts: rendered from {V} and {R} tokens replaced at page load by VENDORS.length and REQUIREMENTS.length
Strategic Findings heading count: computed from strategicFindings.length at render time

4b — Full narrative re-evaluation pass

For every vendor with a changed rating, a structured re-evaluation pass is applied across all narrative fields. This is a rewrite step — not a check-and-flag step. Every sentence in every narrative field for the affected vendor is held against the current live ratings and rewritten if it is stale, contradicted, or no longer accurate.

Cross-vendor consistency rule: After rewriting a changed vendor's text, all other vendors' comparative claims that reference the changed vendor or capability are verified. "The only vendor with X" claims are the highest-risk — they become stale the moment any competitor achieves parity.

4c — Validation gates (mandatory before publication)

Seven programmatic validation gates are run in sequence. No output is regenerated until all gates pass.

Gate	What it checks	Automated?
§4c-1 Stale-narrative grep	Searches data files for strings that would only appear if an old rating were still described (e.g. "no agent memory" after A7 was upgraded)	Script-assisted; requires analyst judgment on hits
§4c-1b Date fields	Confirms `editionDate` and `methodologyPara2` date match the current cycle month + year	Script: checks both fields, flags mismatch
§4c-2 JS syntax	Validates both data files parse without syntax errors	`node --check` — zero tolerance; must pass before rebuild
§4c-3 `vendorDiffs` integrity	Parses every explicit rating code reference in `vendorDiffs` bullets (e.g. `(A7 AMBER)`) and cross-checks against actual `REQUIREMENTS.ratings` — mismatches are blocking errors	Script: fully automated; no judgment required
§4c-4 Comparative-claim scanner	Scans all authored text for: absolute uniqueness claims ("only vendor"), count claims ("3 RED ratings remain"), absence claims ("no agent memory"), first-mover claims, layer-GREEN count claims ("5 vendors have GREEN T1"), framing claims ("highest-velocity battleground"), and vendor-specific uniqueness claims	Script surfaces hits; analyst verifies each one against current ratings
§4c-5 Roadmap-date validation	Finds all quarterly target strings (e.g. "Q3 2026") in data files; flags past-due and current-quarter entries	Script: flags entries; analyst verifies delivery status for each
§4c-6 Score consistency	Computes actual weighted scores from current `REQUIREMENTS.ratings` for all vendors; compares against percentage claims in `strategicFindings[0]` and `execSummaryTakeaways[0]`	Script: flags mismatches >3 percentage points

All seven gates must produce zero blocking errors before Phase 5 executes.

4d — Partnership registry and data constants

The Data/partnerships.md registry is updated with outcomes from the Phase 2 partnership sweep. A script then regenerates the const PARTNERSHIPS array in each data file from the registry, ensuring the Partnerships tab always reflects the current registry state. JS syntax is re-validated after this step.

Phase 5 — Regenerate output HTML

Both output HTML files are regenerated from their respective template + data file pairs using a single Python script:

Template (fixed rendering logic) + Data file (all content) → Output HTML

Each run produces two files: 1. Canonical file — fixed filename, always the latest version (Knowledge Platform Comparison - Cloud.html) 2. Dated archive — filename includes the run date, never overwritten (Knowledge Platform Comparison - Cloud [2026-05-20].html)

The canonical file is safe to share as a link. The dated archives form a permanent, auditable version history.

5. What gets evaluated and updated — tab by tab

This section documents every narrative element in the published output, whether it is evaluated each cycle, and how it is updated.

Tab 1 — Executive Summary

Element	Evaluated?	Update mechanism
Header subtitle (vendor count, requirement count, edition date)	—	Automatic at render time — computed from `VENDORS.length`, `REQUIREMENTS.length`, and `editionDate`
Scope paragraph (vendor count, requirement count)	—	Automatic at render time — `{V}` and `{R}` tokens replaced by `VENDORS.length` and `REQUIREMENTS.length`; surrounding text only updated if framing changes
Edition date throughout document	Mandatory every cycle	`editionDate` field in data file; drives all `<span class="edition-date">` elements automatically
"What the Data Shows" intro paragraph	When ≥3 rating changes occur in cycle, or any layer's GREEN count changes	Manual rewrite in `execSummaryIntro`
Takeaway cards (5 cloud / 7 on-prem)	Required on any rating change	Manual rewrite of affected items in `execSummaryTakeaways[]`
Score percentage claim ("Microsoft reaches 85%")	Every cycle — §4c-6 script computes actual scores and flags mismatches	Manual update of `strategicFindings[0]` and `execSummaryTakeaways[0]` when script flags
Layer-level score bars and heatmap	—	Fully automatic — computed from `REQUIREMENTS.ratings` at render time
KPI score cards per vendor	—	Fully automatic — computed from `REQUIREMENTS.ratings` at render time

Tab 2 — Capability Matrix

Element	Evaluated?	Update mechanism
RAG rating per cell	Core of every cycle	`REQUIREMENTS[n].ratings[vendor]` in data file
Rationale tooltip text	Every rating change	`RATIONALES[reqId][vendor]` in data file
Per-requirement capability description	Every rating change	`REQUIREMENTS[n].details[vendor]` in data file
Weighted scores (default and adjusted)	—	Fully automatic — computed from ratings × weights at render time
Requirement name, weight, source	Only if requirement definition changes (rare)	Manual update to `REQUIREMENTS[n].name/weight/source`
Vendor column headers (`<thead>`)	Only on vendor add/remove/rename	Manual update to template HTML — hardcoded structural chrome
Weight sliders and heatmap coloring	—	Fully automatic — interactive JS

Tab 3 — Architecture Diagram

Element	Evaluated?	Update mechanism
"As of [month year]" date	Mandatory every cycle	Driven automatically by `editionDate` field
Per-vendor "Key Differentiators" bullets	Every rating change affecting a cited rating code	Manual update to `STATIC_NARRATIVES.vendorDiffs[vendor].strengths[]` in data file; verified by §4c-3 script
Per-vendor "Critical Gaps" bullets	Every rating change affecting a cited rating code	Manual update to `STATIC_NARRATIVES.vendorDiffs[vendor].gaps[]` in data file; verified by §4c-3 script
Layer descriptions	Only if architectural framework changes (rare)	Manual update to `LAYERS[n].desc`
Architecture diagram structure	—	Fully automatic — rendered from `LAYERS` array
Vendor strategy text blocks per layer	—	Fully automatic — rendered from `VLN[vendor][layer]` fields

Note on §4c-3 gate: Every explicit rating code reference in the vendorDiffs bullets (e.g. (A7 AMBER)) is mechanically cross-checked against REQUIREMENTS.ratings by a script that runs before every publication. Mismatches are blocking errors. This is the strongest automated consistency guarantee in the entire pipeline.

Tab 4 — Vendor Strategy (per-vendor tabs)

Element	Evaluated?	Update mechanism
Vision statement (`vision`)	When a weight-3 gap opens/closes, or comparative claim goes stale	Manual rewrite in `VLN[vendor].vision`
Layer verdict sentence (`[layer].why`)	Every rating change in that layer	Manual rewrite in `VLN[vendor].[layer].why`
Layer capabilities paragraph (`[layer].capabilities`)	Every rating change in that layer	Manual rewrite in `VLN[vendor].[layer].capabilities`
"Where It Excels" (`[layer].excels`)	Every rating change in that layer	Manual rewrite — remove any strength that is no longer GREEN or best-in-class
"Where It Falls Short" (`[layer].gaps`)	Every rating change in that layer	Manual rewrite — remove closed gaps, add newly opened gaps
Per-requirement capability row	Every rating change	`REQUIREMENTS[n].details[vendor]`
Per-requirement RAG cell	Every rating change	`REQUIREMENTS[n].ratings[vendor]`
Roadmap date strings ("Q3 2026")	Every cycle — §4c-5 script flags past-due dates	Manual update: verify delivery status, upgrade rating or update text
"Only vendor" / comparative claims	Every cycle — §4c-4 scanner flags occurrences	Manual verification against current ratings; rewrite if stale
Vendor tab nav labels ("Teradata", "Google")	Only on vendor add/remove/rename	Manual update to template HTML — hardcoded structural chrome
Vendor `<h2>` headings	Only on vendor add/remove/rename	Manual update to template HTML — hardcoded structural chrome

Tab 5 — Conclusion

Element	Evaluated?	Update mechanism
"The Honest Picture" paragraph (`conclusionIntro`)	When ≥3 rating changes occur, or any layer's GREEN count changes	Manual rewrite in `conclusionIntro`
Strategic Findings count heading	—	Automatic at render time — computed from `strategicFindings.length`
Strategic Findings list items	Required on any rating change	Manual rewrite of stale items in `strategicFindings[]`
"Where Teradata Wins Today" table	When Teradata gains or loses a GREEN	Add/remove rows in `winsToday[]`
"Where AKP investments are pointed" table	When Teradata AMBER/RED changes	Add/remove rows in `mustAccelerate[]`
Competitive Landscape table (`strongestLayer`, `weakestLayer`, `oneline`)	Required on any rating change	Manual update to `competitiveLandscape[vendor]` for affected vendors
Field Guidance bullets (`fieldGuidance[].lead/body`)	Required on any rating change	Manual rewrite of "vs. [Vendor]" block for affected vendors

Tab 6 — Partnerships

Element	Evaluated?	Update mechanism
Partnership cards (all vendors)	Every cycle — full partnership sweep in Phase 2	Registry `Data/partnerships.md` updated; `const PARTNERSHIPS` regenerated by script
New partnership discovery	Every cycle — mandatory open-ended search for every AMBER/RED gap	Analyst research; new rows added to registry
Existing partnership validity	Every cycle — Track B validity check	Analyst research; `status` and `date_confirmed` updated in registry
Partnership rating impact on RAG	Derived from partnership tier + GA status	Applied in Phase 4a as part of rating update

Tab 7 — References

Element	Evaluated?	Update mechanism
"As of [Month Year]" in Methodology Note	Mandatory every cycle	Manual update to `references.methodologyPara2`
Source cards (primaryResearch, supportingResearch, standards)	When a new source is used for a rating change	New card added per Phase 4b Step R1–R3 accountability rule
References intro paragraph	Only if scope changes	Manual update to `references.intro`
Methodology description paragraph	Only if rating methodology changes	Manual update to `references.methodologyPara1`

6. Versioning, traceability, and the audit trail

Output versioning

Every cycle produces:

One canonical output file per assessment (fixed filename — always current)
One dated archive per assessment (filename includes ISO date — permanently retained)

Dated archives are never overwritten. The full version history of both assessments is preserved in OutputVersions/.

Changelog

Every rating change is recorded in OutputVersions/CHANGELOG.md with:

The assessment it applies to (cloud / onprem)
The requirement ID and vendor
The direction of change (old rating → new rating)
The evidence (source name, URL, date)
The confidence level (HIGH / MEDIUM / LOW)

The changelog is the definitive audit trail for rating decisions. Any rating that cannot be traced to a changelog entry is a gap.

Data file as source of truth

The data files (Data/cloud-data.js, Data/onprem-data.js) are the single source of truth for all ratings and narratives. The HTML template files contain only rendering logic — zero authored content. This means:

Any output file can be regenerated exactly from its data file and template
Data file changes are the only form of assessment update — no direct editing of output HTML
The data files are suitable for version control with line-level diff visibility

7. Human review checkpoints

The following steps require analyst judgment and cannot be fully automated:

Checkpoint	What requires judgment
Phase 2 research conclusions	Determining whether a product announcement meets the GA standard; classifying ambiguous capability claims
Phase 3 confidence rating	Assigning HIGH / MEDIUM / LOW to each recommendation based on evidence quality
Phase 3 analyst review	Deciding which recommendations to apply versus flag for further research
§4c-1 stale-string review	Determining whether a flagged string is genuinely stale or contextually accurate
§4c-4 comparative-claim review	Verifying each flagged "only vendor" / count claim against current ratings
§4c-5 roadmap-date review	Verifying delivery status for past-due quarterly target strings
Narrative rewrites	All VLN field rewrites, `conclusionIntro`/`execSummaryIntro` rewrites, and `fieldGuidance` updates

All other validation steps in §4c-1 through §4c-7 are script-assisted or fully automated.

8. Known limitations and scope boundaries

Limitation	Implication
GA-only standard	Announced, roadmap, and preview capabilities are rated AMBER at most. This means the assessment may lag a vendor's actual capability by one cycle if a GA announcement occurs mid-cycle.
Tab navigation and matrix headers	Vendor names in the tab navigation bar and matrix column headers are structural HTML — they require a manual template edit if a vendor is added, removed, or renamed. The skill documents this requirement explicitly.
Narrative framing paragraphs	`conclusionIntro` and `execSummaryIntro` describe competitive landscape framing that drifts gradually. The cumulative-change threshold rule (≥3 rating changes, or any layer's GREEN count changing) provides a concrete trigger for re-evaluation, but does not guarantee that every subtle framing shift is caught within a single cycle.
Single-source risk	When only one source documents a GA capability, that source drives the rating. If the source is later found to be incorrect or retracted, the rating is corrected in the following cycle and logged in the changelog.
Partnership re-validation cadence	Confirmed partnerships are re-validated annually at minimum. A partnership that dissolves mid-year may not be caught until the next cycle if no public announcement is made.

9. Document history

Version	Date	Changes
1.0	May 2026	Initial publication as VP briefing collateral
1.1	June 2026	Added the two-tier update cadence (weekly Red/Amber · monthly full Red/Amber/Green GREEN-Refresh); restyled the HTML edition to the published web styleguide

This document describes the methodology operationalized in the automated assessment skill. It is maintained alongside the assessment and updated whenever the methodology changes. Questions on specific rating decisions should be directed to the changelog entry for that rating.

Authored by Rainer Geissendoerfer · Knowledge Platform Comparison Project