Updated 14 days ago
Roles and Contacts#
This document defines who does what in SpringBoard — who reviews builds, who approves tools, and who to contact when something goes wrong.
Framework roles#
| Role | Person | Contact | Responsibilities |
|---|---|---|---|
| Peer reviewer | Any team member | — | Reviews Yellow builds. Checks that the builder followed the checklist and the tool works as described. |
| Technical reviewer | Engineering Lead (Product & Engineering tribe) | tech-review@springpod.com | Reviews Orange builds. Checks security, data handling, access controls, and technical architecture. |
| Designated reviewer | Oliver Fisher (CPO) or delegate | designated-review@springpod.com | Signs off Red builds. Verifies compliance, privacy impact, and age-appropriate design. Has authority to approve or block launch. |
| Framework contact | SpringBoard Admin | springboard@springpod.com | Answers questions about SpringBoard itself. Updates framework documents. Runs training sessions. |
| Emergency contact | On-call Engineering | emergency@springpod.com / Slack: #incident-response | First call for critical incidents (data exposure, safety risk, compliance breach). Available outside business hours. |
Who reviews what#
| Build path | Reviewer role | What they check |
|---|---|---|
| Green (Quick Build) | No formal review required | Builder self-checks using the Green Checklist |
| Yellow (Standard Build) | Peer reviewer | Checklist completion, basic functionality, realistic data testing |
| Orange (Reviewed Build) | Technical reviewer | Security, data handling, branding, access controls, third-party services |
| Red (Protected Build) | Designated reviewer | Everything above, plus compliance, privacy impact, age-appropriate design, incident response plan |
Green builds are low-risk — a self-check is enough. As risk increases, you need reviewers with more expertise. A peer can check if a tool works correctly. A technical reviewer can check if it is secure. A designated reviewer can check if it is compliant. Matching reviewer expertise to risk level keeps the process efficient without cutting corners.
Escalation path#
When you are not sure what to do, follow this path:
Can you solve it yourself using the framework docs?
Is it a question about how to build something?
Is it a security or data concern?
Is it a compliance, legal, or safety issue?
Is something broken in a live tool?
See When to Escalate for more detailed guidance.
Backup contacts#
| Role | Backup person | Backup contact |
|---|---|---|
| Technical reviewer | Senior Engineer (rotating) | tech-review-backup@springpod.com |
| Designated reviewer | Tom Hyams (COO) | designated-review-backup@springpod.com |
| Emergency contact | Sam Hyams (CEO) | ceo@springpod.com |
Response time expectations#
| Role | Expected response time |
|---|---|
| Peer reviewer | Within 2 business days |
| Technical reviewer | Within 3 business days |
| Designated reviewer | Within 5 business days |
| Framework contact | Within 1 business day |
| Emergency contact | Within 1 hour for Critical severity, 4 hours for High |
Related documents#
- Review Request — the form to submit when requesting a review
- Incident Report — the form to submit when something goes wrong
- When to Escalate — guidance on when to ask for help
- Company Context — Springpod's values and constraints
Was this page helpful?