Ownership matrix

Last updated Jun 14, 2026

This page documents who owns what at Matter. It is reviewed quarterly and updated as the team grows. Customers can identify the right contact for a specific surface; auditors can trace control ownership; on-call escalation is unambiguous.

The ownership matrix is part of the SOC 2 evidence pack (CC1 — Control Environment).

Bounded-context ownership

Note: the team's current size is small; some owners hold multiple contexts. The matrix scales as the team grows. The names are deliberately omitted from this public page; internal-only mirror at apps/docs/internal/ownership.mdx carries the live names.

The primary owner:

• Reviews every PR that touches their context.
• Holds bus-factor responsibility — they are the single point of "ask this person."
• Maintains the context's invariants. Defends against drift in API Council reviews.
• Authors the context's runbooks.
• Sets the context's on-call rotation.

The secondary owner:

• Backs up the primary during vacations, leave, departures.
• Reviews context PRs when the primary is unavailable.
• Maintains awareness of the context's invariants — bus-factor resilience.

The quarterly review lead ensures the context's invariants are tested, the runbooks are current, the SLOs are met, and the threat model entries are accurate.

On-call rotation

Cadence. Weekly. Handover every Monday at 10:00 UTC per the handover protocol.

Tiers.

• Primary on-call. Pages first. Handles SEV3 + SEV4 directly. Triages SEV1 + SEV2 and pulls in secondary.
• Secondary on-call. Pages on escalation_after_min if primary does not acknowledge. Handles SEV1 + SEV2 with primary.
• Manager on-call. Pages on SEV1 declaration. Handles customer comms.
• Engineering lead. Pages on SEV1 sustained > 30 minutes.

Pool. Primary + secondary draw from a rotation of approximately 6 engineers (target). At small team sizes, the same engineer may serve as both primary and secondary across weeks. As the team grows past 8 engineers, the pool widens.

Escalation path per severity

(Full severity definitions at severity-matrix.)

SEV1

1. 0 minutes. Page primary on-call.
2. 0 minutes. Page manager on-call.
3. 0 minutes. Page engineering lead.
4. 5 minutes. Page secondary on-call (if primary unacknowledged).
5. 15 minutes. Status page incident declared.
6. 30 minutes. Customer email sent to affected scope.
7. 30 minutes onwards. Status page update every 30 minutes until resolution.

SEV2

1. 0 minutes. Page primary on-call.
2. 0 minutes. Page manager on-call.
3. 10 minutes. Page secondary on-call (if primary unacknowledged).
4. 30 minutes. Status page incident declared.
5. 60 minutes. Customer email sent to affected scope.
6. 60 minutes onwards. Status page update every 60 minutes until resolution.

SEV3

1. 0 minutes. Ticket in on-call queue.
2. In-hours response. Primary on-call responds during business hours.
3. No page outside business hours unless escalation.
4. Status page: internal-only entry; no customer email.

SEV4

1. Ticket in backlog. No page.
2. No status entry. No customer comms.

Decision rights

Cross-context PR review

A PR that crosses bounded contexts (e.g., a change to @repo/database that affects how @matter/equity-math reads the ShareLedgerEntry table) requires:

• Primary review by the owner of each affected context.
• Architecture-test pass for cross-context import rules.
• Spec PR first if any endpoint shape changes.

The CI gate enforces that PRs touching multiple contexts cannot merge without a "ack" comment from each affected context's owner.

Hiring and handover

When a new engineer is hired into a context:

1. They join the context's rotation as a shadow for 4 weeks. They attend Council reviews, observe on-call, read past post-mortems.
2. They take primary on-call (with secondary live-paired) for 2 weeks.
3. They become eligible to act as secondary independently.
4. After 3 months of context contributions, they become eligible to act as primary independently.

When a primary departs:

1. Secondary becomes primary immediately.
2. A new secondary is named (from the context's rotation or by promotion).
3. The departing primary records a handover doc at apps/docs/internal/handovers/<context>-<yyyy-mm-dd>.mdx covering: known issues, in-flight work, undocumented tribal knowledge, relationships with external vendors / providers.
4. The departing primary remains available for questions for 30 days.

Why this matters

Three reasons.

1. Bus factor. Every context has at least two engineers who can run it. Departures do not break the platform.
2. SOC 2 CC1 (Control Environment). Ownership matrix is part of the evidence pack. Customers' auditors will ask.
3. Customer trust. A customer in an incident wants to know who is on the hook. The escalation path lets them ask the right questions.

See also

• API Council — where context owners gather.
• Handover protocol — weekly on-call handover.
• Severity matrix — what each severity triggers.
• Incident communications — customer-facing templates.