Team Operating Guide
Team Operating Guide documentation and operating guidance.
<!-- /hpc-resolution-path/docs/TEAMOPERATINGGUIDE.md --> # Team Operating Guide
Purpose
Use the simulator to create one evidence language across teams that may be governed by different support contracts, vendors, tools, and operational procedures.
Recommended incident rhythm
1. Establish impact
Record affected workload, nodes, users, service level, start time, recent change, and safety or data-integrity risk.
2. Assign one incident commander
The incident commander owns the shared timeline, action ledger, status cadence, escalation packet, and customer-facing message. This role does not replace technical owners.
3. Assign an owner per fault boundary
Examples:
- Compute hardware
- Power, cooling, and facilities
- Management plane and firmware
- Linux and platform services
- Accelerator and runtime
- High-speed fabric
- Storage and filesystem
- Scheduler and workload
4. Return evidence, not unsupported handoffs
Each owner should return:
- What was checked
- Exact timestamp
- Affected and healthy comparison
- What the evidence proves
- What it does not prove
- Recommended next owner or next gate
5. Use a checkpoint
When evidence remains mixed, set a time-bound checkpoint and identify the smallest comparison that can narrow the boundary.
6. Close with validation
Confirm technical recovery, workload recovery, monitoring stability, customer impact, and any follow-up corrective action.
Suggested escalation packet
- Incident summary and impact
- Asset or workload identifiers
- Timeline and recent changes
- Physical and environmental observations
- Management-plane events
- Read-only command outputs
- Healthy-peer comparison
- Firmware, driver, image, or configuration baseline
- Actions already attempted
- Safety conditions
- Current owner and requested decision
Team roles supported by OGO™
OGO™ is not limited to one operations title. It is designed to give the incident bridge a shared evidence language while preserving role boundaries.
| Team | Primary use in OGO™ |
|---|---|
| Technical Account Managers | Customer impact, cross-team coordination, owner routing, escalation quality |
| Solutions Engineers / Architects | Architecture validation, integration boundaries, healthy-versus-affected comparison |
| Resident / Field Engineers | Local evidence collection, approved CLI checks, peer comparison |
| Platform / SRE / Operations | Runtime health, change control, return-to-service proof |
| Domain Specialists | Layer-specific diagnosis and guide contribution |
| Incident / Delivery Leaders | Checkpoints, ownership, communication, risk control |
| Engineering / Operations Leaders | Decision confidence, unresolved risk, authorization visibility |
- Team
- Technical Account Managers
- Primary use in OGO™
- Customer impact, cross-team coordination, owner routing, escalation quality
- Team
- Solutions Engineers / Architects
- Primary use in OGO™
- Architecture validation, integration boundaries, healthy-versus-affected comparison
- Team
- Resident / Field Engineers
- Primary use in OGO™
- Local evidence collection, approved CLI checks, peer comparison
- Team
- Platform / SRE / Operations
- Primary use in OGO™
- Runtime health, change control, return-to-service proof
- Team
- Domain Specialists
- Primary use in OGO™
- Layer-specific diagnosis and guide contribution
- Team
- Incident / Delivery Leaders
- Primary use in OGO™
- Checkpoints, ownership, communication, risk control
- Team
- Engineering / Operations Leaders
- Primary use in OGO™
- Decision confidence, unresolved risk, authorization visibility
No role should use OGO™ to bypass the accountable owner. The guide makes the path visible; authority remains with the team responsible for the production boundary.
Adoption visibility
OGO™ does not identify local users. Local privacy is part of the product boundary.
For a hosted public instance, use aggregate analytics only when explicitly enabled. Suitable events are:
- page viewed
- Studio opened
- technology domain selected
- guide started
- dossier downloaded
Do not collect:
- reported pain text
- evidence answers
- commands
- API keys
- AI brief content
- dossier content
- customer, environment, or company identity
A public “Used by” record should remain consent-based and manually verified.
Team-fit surface
The public team-fit surface should explain real work rather than only showing role names.
For each selected team, it exposes:
- 01the team's primary position in the operating path
- 02its incident responsibility
- 03the outputs it is expected to produce
- 04the shared evidence record used for handoff and coordination
The common path is:
Signal → Scope → Evidence → Fault Boundary → Owner → Safe Action → Validation
This preserves different team responsibilities while giving everyone one visible incident language.