Ownership and Systems
Use this page to understand who owns decisions, who needs to review, which repositories Engineering is responsible for, and how vendors or external services fit into the system.
Sibling teams
Consult the right team before work changes experience, scope, content, or strategy.
| Team | Owns | Consult when |
|---|---|---|
| Design | Visual language, component specifications, user experience standards | Component appearance, interaction behavior, accessibility, and usability change |
| Product Management | Priorities, stakeholders, roadmap, and delivery scope | Scope, roadmap tradeoffs, sprint planning, or stakeholder commitments change |
| Web Experience | Content operations and editorial workflows | CMS authoring, content models, training, or agency editor workflows change |
| Strategic Investments | Opportunities, partnerships, and technology direction | New opportunities need feasibility, risk, architecture, or sizing input |
Engineering roles
| Role | Responsibilities |
|---|---|
| Director, Engineering | Technical direction, roadmap, team priorities, cross-team coordination, vendor expectations, deployment accountability |
| Engineers | Build, test, review, document, and deploy across the repo portfolio |
| Vendor engineers | Contribute within assigned scope under Engineering review |
Engineering review is required for architecture decisions, database schema changes, CI/CD changes, deployment changes, new dependencies, public APIs, production infrastructure, authentication, authorization, secrets, and data-handling changes.
Delivery role map
Use this map when a change touches GitHub, ArgoCD, AWS, production promotion, or emergency response.
| Role | GitHub | ArgoCD | AWS | What they can approve |
|---|---|---|---|---|
| Technical Owner | Team permission admin when repo grants are applied | Full | Full | Critical exceptions and production decisions |
| Technical Admin | Team permission admin when repo grants are applied | Admin | Scoped | Promotions and emergency response |
| Developer | Team permission push when repo grants are applied | Read | None | Code changes, no production actions |
| SRE | Team permission push when repo grants are applied | Read | Scoped | Reliability and release infrastructure issues |
| Security Engineer | Team permission pull when repo grants are applied | Read | None | Security review and advisories |
| QA Engineer | Team permission pull when repo grants are applied | Read | None | Test validation findings |
| Content Administrator | None for this flow | None | None | Drupal and content workflows only |
Exception authority
Exceptions are not convenience paths. A technical owner may approve an emergency bypass only when delay creates more risk than the bypass, and the PR, incident, or ticket must record the reason, approver, scope, and follow-up. Temporary elevated access expires by default and is reviewed with the same evidence as other access changes.
Repository RACI
Check this matrix before starting work that changes architecture, deployment, monitoring, security, or stakeholder-facing behavior.
| Repo | Engineering | Design | Vendors | DoIT Web Services | Notes |
|---|---|---|---|---|---|
mdwds-core | R/A | C | R for assigned work | I | Engineering owns architecture, review, deployment, monitoring, docs, and security |
md-cms | R/A for architecture, review, docs, security | I | R for assigned work | R/A for deployment and monitoring | Shared platform with vendor and DoIT participation |
mdwds-icons | R/A | C/R for icon work | - | - | Engineering owns deployment and package operations |
analytics.maryland.gov | TBD | - | TBD | TBD | Ownership under review |
cms-training.maryland.gov | TBD | - | TBD | TBD | Ownership under review |
digital.maryland.gov | TBD | C | TBD | TBD | Ownership under review |
gitops.maryland.gov | I | - | - | R/A | Engineering has awareness-only involvement |
SOSELF | TBD | - | TBD | R/A | Manual SharePoint deployment path |
documentation | R/A | - | - | - | Engineering owns this handbook |
R means responsible, A means accountable, C means consulted, I means informed, and TBD means ownership is not settled. There should be one accountable owner per activity.
Repository inventory
| Repo | GitHub org | What it is | Engineering role | Deploy owner | Status |
|---|---|---|---|---|---|
mdwds-icons | maryland-gov | Icon package consumed by mdwds-core | Primary owner | Engineering | Active |
mdwds-core | maryland-gov | Maryland Web Design System component library | Primary owner | Engineering | Active |
md-cms | maryland-gov | Drupal CMS consuming mdwds-core | Co-owner | Engineering, vendor team, DoIT Web Services | Active |
cms-training.maryland.gov | maryland-gov | Training site built on the CMS platform | TBD | TBD | Ownership under review |
workbooks | mdds-engineering | Engineering workbooks | Primary owner | Engineering | Active |
documentation | maryland-gov | Engineering handbook | Primary owner | Engineering | Active |
digital.maryland.gov | marylanddigitalservice | Digital Playbook public site | TBD | TBD | Ownership under review |
analytics.maryland.gov | maryland-gov | Analytics platform | TBD | TBD | Ownership under review |
gitops.maryland.gov | marylanddigitalservice | GitOps infrastructure | Awareness only | Infrastructure / DevOps | Active |
SOSELF | DoITWebServices | SharePoint Online SPFx site | TBD | DoIT Web Services | Ownership under review |
Deployment order
When a change spans the Maryland Web Design System and CMS chain, ship in this order.
mdwds-iconsmdwds-coremd-cmscms-training.maryland.gov
Each step must finish before the next begins. Shipping out of order creates missing icons, stale design-system assets, CMS/runtime mismatches, or training-environment drift.
Vendor collaboration
Vendors own day-to-day implementation inside their assigned scope, but Engineering owns the platform contracts they build against.
- Establish a shared channel, written status rhythm, meeting cadence, and escalation path.
- Provision access with least privilege, review it at least quarterly, and revoke it at engagement end.
- Require Engineering approval before vendor-authored PRs merge.
- Record decisions and scope changes in writing.
- Give the first PR extra review detail to calibrate expectations.
External integrations
Treat every external service integration as a provider boundary.
- Store vendor dependencies behind a wrapper in
src/lib/providers/{domain}or the local equivalent. - Import vendor SDKs only in wrapper files, never throughout app services.
- Keep provider interfaces narrow and stable.
- Require a mock implementation for tests.
- Verify inbound webhook signatures before body parsing.
- Enforce replay protection with provider event IDs and time windows.
- Normalize inbound payloads to internal domain events and hand downstream work to a queue.
ATO evidence
For ATO or continuous monitoring, retain the repo inventory, ownership map, GitHub org/repo exports, CODEOWNERS, vendor register, integration inventory, data-flow record, and boundary notes for systems Engineering does not control.
Where to go next
- 00 — Team Operating Model — principles and maturity expectations
- 01 — Shipping Work — how work moves from plan to production
- ATO — Overview — operating model for the systems we run
- ATO — Delivery — delivery and promotion flow