Runtime Modes and Data Fallbacks

AuroraSOC supports three operation modes:

• dummy
• dry_run
• real

These modes are not presentation hints. They define how the platform is allowed to behave.

Canonical Rules

Mode	Reads	Analyst-Triggered Mutations	Internal Workflow Records	Showcase Data
dummy	Allowed	Blocked	Blocked	Allowed
dry_run	Allowed	Preview only	Allowed	Not allowed
real	Allowed	Allowed	Allowed	Not allowed

In dry_run, AuroraSOC still persists records produced by live internal pipelines, such as detections, alerts, network-attack correlations, automatically created cases, analyst-style case notes, and simulated investigation dispatch receipts. The mode continues to block operator-triggered state changes and external response actions.

Database Unavailability Policy

AuroraSOC no longer treats database loss as a general-purpose reason to swap into demo data.

The policy is:

1. If the database is available, all modes use live data.
2. If the database is unavailable and the system is in dummy mode, selected read endpoints may serve showcase data.
3. If the database is unavailable and the system is in dry_run or real mode, DB-backed reads must fail clearly with a service-unavailable response.

This keeps dry_run honest for operational rehearsals and keeps real suitable for production reasoning.

Runtime Truth API Contract

AuroraSOC exposes the current runtime truth through GET /api/v1/system/mode.

Key fields:

Field	Meaning
mode	Current runtime mode: dummy, dry_run, or real
is_database_available	Whether AuroraSOC currently has a live database session factory
showcase_reads_allowed	Whether the current mode is permitted to use showcase reads when the database is unavailable
uses_showcase_data	Whether the platform is currently serving showcase reads because the database is unavailable and the mode is dummy
read_data_source	Effective read source: database, showcase, or unavailable
is_mutations_allowed	Whether operator-triggered state-changing operations are currently allowed
is_internal_workflows_allowed	Whether AuroraSOC internal pipelines may persist workflow records in the current mode
is_external_actions_allowed	Whether the platform may execute external response actions in the current mode

This makes the dashboard and operators aware of the difference between live state and showcase behavior without guessing from errors.

Dashboard Degraded-Read Behavior

The overview dashboard reads GET /api/v1/system/mode before loading database-backed widgets. When read_data_source is unavailable, the dashboard keeps the runtime-mode banner and Network Analyzer findings visible, but skips overview calls that require PostgreSQL, such as dashboard stats, alerts, CPS devices, managed agents, network attacks, approvals, MCP health, fleet autoscaler status, and network telemetry status.

This prevents a dry-run laptop bring-up from flooding the browser with expected 503 Service Unavailable responses while still making the missing database explicit to the operator.

Why This Rule Exists

Serving showcase data in dry_run or real mode creates three problems:

1. Analysts cannot trust what they are looking at.
2. Automation and AI flows can reason over synthetic state without an explicit signal.
3. Production outages are masked instead of surfaced.

For a flagship SOC platform, explicit failure is safer than silent substitution.

Implementation Anchors

• aurorasoc/config/settings.py defines the mode semantics.
• aurorasoc/api/runtime.py owns the shared runtime-mode policy, dry-run preview rules, showcase-data fallbacks, and EDR mode gates.
• aurorasoc/api/main.py consumes those runtime helpers and exposes the runtime truth payload consumed by the dashboard.
• aurorasoc/services/fleet_reconciler.py treats database unavailability as a skipped reconciliation pass instead of an unhandled loop error.
• dashboard/src/app/page.tsx gates database-backed overview widgets from the runtime truth payload.
• docker-compose.yml and environment configuration define which runtime profile is actually deployed.

Operational Guidance

• Use dummy mode for showcase demos, documentation captures, and isolated UI work.
• Use dry_run mode for rehearsals against live reads when actions must remain blocked.
• Use real mode only when the deployment is ready to perform full platform behavior.

If a production-like environment cannot satisfy the dependencies required by dry_run or real, fix the environment instead of relying on synthetic data.