Contributing to the Standard

AggieDB, the Aggie Brand Theme, and the AggieViz system are living standards — they evolve as the platform grows. This guide explains how to propose, test, and ship changes.

Key Principle

Changes to standards affect every report. Propose through ADR, test thoroughly, merge with review.

What Can Be Changed

Component	Examples	Impact
AggieDB naming	New domain prefix, new conformed dimension, column naming rule	Every Lakehouse + semantic model
Aggie Brand Theme	New accent color, font change, dark mode palette	Every report
AggieViz templates	New page type, new shell layout, visual defaults	Generated reports
Governance policies	New RLS pattern, endorsement rule, sensitivity label mapping	Workspace access
Documentation	New guide, correction, improved example	This site

The ADR Process

Significant changes go through an Architecture Decision Record (ADR) — a permanent record of what was decided, why, and what alternatives were considered.

When an ADR Is Required

Adding or changing a conformed dimension
Modifying the brand theme's primary or accent colors
Changing the medallion tier definitions (Bronze/Silver/Gold)
Adding a new AggieViz page type
Changing RLS or endorsement policies

When an ADR Is NOT Required

Fixing a typo in documentation
Adding a new DAX measure to a specific model
Creating a new report (follows existing templates)
Minor CSS/layout tweaks to AggieViz

How to Submit an ADR

Go to the Architecture Decisions section
Click + New ADR
Fill in:
- Title: What is being decided (e.g., "Add Department hierarchy dimension to AggieDB")
- Context: Why this change is needed
- Decision: What you're proposing
- Alternatives considered: What other approaches were evaluated
- Consequences: What changes if this is approved
Submit for review — the platform team reviews and discusses
Once approved, the ADR becomes a permanent record and the change is implemented

Testing Changes

Brand Theme Changes

Apply the modified theme JSON to a test report
Verify all 6 visual types render correctly (bar, line, table, card, slicer, matrix)
Check light AND dark mode
Run WCAG contrast checks on all text-on-background combinations
Compare against the current theme to identify any visual regressions

AggieDB Schema Changes

Create the new table/column in a DEV Lakehouse
Add to a DEV semantic model
Verify DirectLake works (no fallback)
Verify existing relationships aren't broken
Update the AggieDB documentation with the new convention

AggieViz Template Changes

Run the generator against a test workspace
Verify all pages render (no broken visual references)
Check the theme slicer (light/dark toggle) works
Review the output PBIR JSON for correctness

Review Workflow

Contributor ──> Branch ──> Pull Request ──> Review ──> Merge ──> Deploy
                                │
                                ├── AggieDB changes → reviewed by data architecture lead
                                ├── Theme changes → reviewed by TAMU MarComm + AggieUX team
                                ├── AggieViz changes → reviewed by platform team
                                └── Docs changes → reviewed by any team member

All changes are committed to Git and deployed through the standard CI/CD pipeline. No changes are made directly in production workspaces.

Architecture Decisions

Browse existing ADRs and their outcomes

AggieDB Standards

Current naming conventions and schema patterns