Shynvo console — what it is

Product surface

Signed-in routes grouped the way operators navigate during an incident. Each card opens directly into the console.

Trust & governance explains how these surfaces fit together for reviewers.

• IncidentsSingle record per event: severity, owner, service link, runbook, timeline, export when DB-backed.Open →
• AutomationsPlaybooks, dry-runs, and guarded execution before production side effects.Open →
• ApprovalsExplicit decisions on high-impact work — a queue you can review, not a disappearing chat thread.Open →
• AuditAppend-oriented activity log for keys, billing sync, automation events, and status transitions.Open →
• RunbooksVersioned procedures and checks the whole team can follow under pressure.Open →
• ConnectorsOptional HTTP backends for health checks, automation, and alerting integrations.Open →
• ReasoningOptional reasoning proxy for Copilot and drafting — configured alongside automation endpoints.Open →
• GovernanceHow trust is assembled: audit, approvals, credentials, execution posture, and limits.Open →

System summary

Shynvo is a controlled operations layer for IT teams. It combines incident response, guarded automation (dry-runs and approvals before side effects), and an auditable trail of operational activity in one web console. Teams use it to respond when things break, propose mechanical remediation, get explicit sign-off where policy requires it, and leave evidence that stands up in review.

Who it is for

• SRE and DevOps teams shipping and operating production services
• Platform engineers standardizing how change is proposed and recorded
• Internal IT operations groups that need defensible automation, not shadow scripts
• Organizations that want human-in-the-loop execution with proof

Core operational flow

This is how modules connect in day-to-day incident response.

1. Signal in — HTTP alert ingest (/api/integrations/alerts) or manual creation in the console.
2. Incident record — Open Incidents: severity, owner, linked service, runbook, timeline when audit append is enabled.
3. Guidance — Runbooks and Copilot structure triage; nothing irreversible runs from chat alone.
4. Automation — Automations with /api/automations/dry-run before production calls.
5. Approval gate — Approvals capture decisions when your process requires them.
6. Evidence — Audit aggregates key events; incidents support markdown export via /api/incidents/[id]/export when backed by the database.

Guarded automation model

“Guarded” means automation is accountable, not silent. Today the product enforces:

• Dry-run path for automations before irreversible connector calls.
• Approvals surface for explicit human decisions.
• Scoped credentials — user API keys and separate alert ingest tokens (see Settings).
• Audit-oriented logging of operational events where the deployment is configured to append.

Roadmap (not implied as shipped): delegated approver roles, fine-grained policy DSL, automatic rollback orchestration, and deep third-party OAuth connectors — see Integrations.

Capabilities (grouped)

Routes are implementation details; buckets are how teams buy.

Incident management

List, create, drill-down, status, owner/runbook context, postmortem, timeline, export — /incidents family.

Automation and execution

Console automations + dry-run API; optional proxies to reasoning and robot backends — /automations, /api/automations/dry-run, /api/reasoning/*, /api/robot/*.

Approvals and control

Human checkpoint before risky automation — /approvals.

Audit and compliance artifacts

Activity log + incident markdown export — /audit, /api/incidents/[id]/export.

Integrations and ingest

Alert ingest, connector health — /api/integrations/alerts, /api/connectors/status, integrations details.

AI copilot

Triage chat and threads — /copilot, /api/copilot/*.

Runtime modes (trust)

• Production mode — Supabase-backed auth, per-user data, RLS, incidents in Postgres, audit append when the service role is configured, billing webhooks when Lemon Squeezy is wired.
• Evaluation mode — When Supabase is not configured, parts of the console run in an isolated browser session so teams can explore workflows without provisioning a database.

What makes this different

• Alerting platforms focus on detection and paging.Shynvo emphasizes controlled change and proof after the alert.
• Traditional ITSM suites emphasize broad process coverage.Shynvo delivers focused console workflows for incident response and guarded automation.
• Shynvo's wedge is unified incident + guarded automation + audit in one product surface, so operators are not stitching three vendors together for a single incident story.

Architecture (text)

Users & webhooks
       │
       ▼
┌──────────────────┐
│   API layer      │  /api/integrations/alerts, /api/copilot/*,
│                  │  /api/automations/dry-run, /api/user/*, …
└────────┬─────────┘
         │
         ▼
┌────────────────────────────────────────┐
│  Console modules                        │
│  Incidents · Automations · Approvals   │
│  Audit · Runbooks · Copilot · Settings │
└────────┬───────────────────────────────┘
         │
         ▼
┌──────────────────┐       ┌─────────────┐
│  Supabase / DB   │       │  Connectors  │  (optional HTTP backends)
│  + audit append  │       │  reasoning   │
└────────┬─────────┘       │  robot       │
         │                 └─────────────┘
         ▼
   Export & review   (incident markdown, audit views)