This implementation graded F (55%). The grader evaluated 79 components in this report suite using the strict@2.0 rubric pack. The largest gap is in governance posture (0%); 3 of 3 rules in that category fired.
No prior snapshots of this implementation were detected alongside the input. Without snapshot history, configuration changes cannot be diffed, drift cannot be detected, and audit trails are unavailable for compliance review.
Establish a snapshot directory in version control and schedule regular runs of cja_auto_sdr / aa_auto_sdr to populate it.
No Solution Design Reference (SDR) document was supplied alongside this snapshot. Without an SDR, definitions live only in the platform UI, which makes peer review and onboarding harder and obscures the “why” behind component choices.
Generate the SDR via cja_auto_sdr / aa_auto_sdr and commit it alongside this snapshot. Suppress this rule via .sdr-grader.yaml if the SDR lives somewhere the grader cannot see.
4 references are unresolved — segments or calculated metrics point at IDs not found in this snapshot. This does not prove the live implementation is broken: the export may omit components or inventories. Verify the reference in the source platform and re-export the relevant inventory before changing it.
calc_metric cm_conversion_rate -> missing metrics/orders calc_metric cm_conversion_rate -> missing metrics/visits calc_metric cm_revenue_per_visit -> missing metrics/revenue calc_metric cm_revenue_per_visit -> missing metrics/visits
Verify each unresolved ID in the source platform and export the relevant inventory for the correct data view or report suite. If the reference is confirmed invalid, restore the component or update its consumers.
4 calculated metric references are unresolved — the formula points at components, segments, or other calculated metrics not found in this snapshot. This does not prove the live implementation is broken: the export may omit components or inventories. Verify the reference in the source platform and re-export the relevant inventory before changing it.
cm_conversion_rate -> metrics/orders cm_conversion_rate -> metrics/visits cm_revenue_per_visit -> metrics/revenue cm_revenue_per_visit -> metrics/visits
Verify each unresolved ID in the source platform and export the relevant inventory for the correct data view or report suite. If the reference is confirmed invalid, restore the component or update its consumers.
1 synonym group appears in component names with multiple terms in active use. Inconsistent vocabulary forces analysts to learn each team's idiolect; downstream tooling and segmentation drift apart over time.
[user, visitor] -> user: 1, visitor: 1
Pick one term per concept, document it, and rename existing components to align. The losing synonyms should be deprecated, not silently kept around.
9 metrics in this report suite have empty description fields. Descriptions are the primary way new analysts and AI agents understand what a component measures; missing descriptions force readers to infer intent from names alone, which is frequently wrong.
Metrics: 9 of 15 missing (60%). The rubric threshold is 56%.
Generate the list of components missing descriptions via the data view API and populate them. Establish a CI check that fails new components added without descriptions.
1 segment mixes container types (event / session / person) within a single definition. Mixed containers obscure intent and produce surprising population differences from segments that look superficially similar.
s_returning containers: visitors, visits, hits depth: 2
Decompose the segment into composed sub-segments, one per container level, and combine them at the surface segment.
41 of 75 components (55%) have no tags. Tags are the cheapest way to keep schema browsing tractable as the data view grows; without them, finding components by purpose requires reading every name.
Adopt a small, documented tag taxonomy and apply it via the platform API.
This grade was produced by sdr-grader using the strict@2.0 rubric pack. The rubric encodes 23 rules across 6 active categories; 8 fired against this snapshot. Each rule contributes to a category subtotal weighted by severity (critical: 4, high: 3, medium: 2, low: 1). Category subtotals roll up to the overall score using the category weights defined in the rubric pack.
The grader is rule-based and deterministic — the same input always produces the same grade. Findings carry stable rule IDs that can be checked against the rubric documentation and rule definitions in the sdr-grader repository. Rules can be suppressed or reweighted via a project-level .sdr-grader.yaml.