Depth Advantage

Competitive Positioning

While competitors offer shallow pattern matching ("block rm -rf"), RecourseOS provides:

• • Consequence depth: Full blast radius with concrete metrics (object counts, sizes, timestamps)
• • 5-tier recoverability:Not binary "safe/dangerous" but nuanced tiers with detailed reasoning
• • Cryptographic attestation: Signed proofs with reasoning traces, not just audit logs
• • Structured verification: Automatic output interpretation, not manual parsing
• • Cascade analysis: Type-grouped dependency graphs with depth tracking
• • Cross-action detection: Multi-change interaction patterns

Consequence Reasoning Quality

Generic verdicts don't help humans make decisions. RecourseOS provides concrete metrics:

For RDS instances:

RDS instance 'analytics-db' (postgres) is recoverable:
5 snapshots (latest: 4 hours ago), PITR available, 7-day automated backups

Metrics gathered from live state include:

• • S3: objectCount, totalSizeBytes, lastModified, versioning status
• • RDS: snapshotCount, latestSnapshotTime, engine type, backup retention, PITR status
• • DynamoDB: PITR status, AWS Backup recovery points
• • EBS: Snapshot count, cross-region copies, AWS Backup protection

Cascade Analysis

A count of affected resources isn't actionable. RecourseOS groups by type and tracks dependency depth:

The consequence report includes structured cascade data:

{
  "cascadeSummary": "3 subnets, 2 EC2 instances, 1 NAT gateway, 1 RDS instance",
  "maxCascadeDepth": 2,
  "cascadeByType": {
    "aws_subnet": 3,
    "aws_instance": 2,
    "aws_nat_gateway": 1,
    "aws_db_instance": 1
  }
}

Verification Loop

When RecourseOS can't determine recoverability from available state, it suggests verification commands. These include structured patterns for automatic output interpretation:

{
  "evidence_key": "manual_snapshots_exist",
  "description": "Check for manual RDS snapshots",
  "verification": {
    "type": "aws_cli",
    "argv": ["aws", "rds", "describe-db-snapshots",
             "--db-instance-identifier", "prod-db",
             "--snapshot-type", "manual", "--output", "json"]
  },
  "expected_pattern": { "type": "json_array_not_empty" },
  "failure_pattern": { "type": "regex", "regex": "^\\[\\]$" },
  "example_output": "[{\"DBSnapshotIdentifier\": \"prod-db-2024-01-15\"}]"
}

Pattern types:

Workflow:

1. 1. RecourseOS returns verification suggestions with structured patterns
2. 2. Agent runs command, captures exit code and raw output
3. 3. Agent submits evidence via recourse_evaluate_with_evidence
4. 4. Pattern matcher auto-interprets output
5. 5. Verdict upgraded if evidence confirms recovery paths

Attestation Richness

Audit logs prove something happened. Attestations prove what was evaluated and why:

Attestations include a reasoning trace:

{
  "trace": {
    "steps": [
      { "action": "parse_input", "result": "Parsed Terraform plan with 3 resource changes" },
      { "action": "analyze_blast_radius", "result": "Analyzed 3 changes" },
      { "action": "cross_action_analysis", "result": "Checked 8 cross-action patterns" },
      { "action": "policy_evaluation", "result": "Risk assessment: block" }
    ],
    "handlers_invoked": ["aws_db_instance", "aws_s3_bucket"],
    "state_sources": ["terraform-plan", "terraform-state"]
  }
}

Third parties can verify attestations without RecourseOS access using the Go SDK or TypeScript implementation.

Cross-Action Detection

Individual actions may be safe, but their combination can be unrecoverable. RecourseOS detects these patterns:

• • Backup + protected deleted: Deleting a snapshot and its source in the same plan
• • Replica + primary deleted: Deleting a replica and its primary database together
• • Protection disabled then deleted: Removing deletion protection and deleting in one plan
• • Security group referenced: Deleting a security group while EC2 still uses it
• • VPC cascade: Deleting a VPC while resources still depend on it

See Cross-Action Analysis for the full pattern catalog.

Comparison Table