One Resource Changed. One Incident.

You're reviewing a Terraform PR. The diff shows a security group update: tightening ingress rules from 0.0.0.0/0 to a specific CIDR block. Good security hygiene. The plan says one resource will change. You approve.

Two hours later, three services are down. That security group was shared across four workspaces. The tighter rules blocked traffic your application services needed.

The plan showed you what was changing. It didn't show you what depended on it.

The problem: plans don't show dependencies

That security group wasn't inherently dangerous. In isolation, tightening ingress rules is exactly what security teams ask for. The risk came from context you couldn't see: four workspaces, seventeen dependent services, zero visibility in the plan.

This is a fundamental limitation of terraform plan. It shows you what's changing in this workspace. It doesn't show you what depends on those changes in other workspaces. Your security group lives in shared-infra, but the services that use it live in platform-api, customer-portal, and analytics. The plan has no way to know that.

That's the gap Cora fills.

Blast radius: seeing across workspace boundaries

When you upload a Terraform plan, Cora traverses your infrastructure graph to find every resource that could be affected by the change, regardless of which workspace owns it.

For each changed resource, we follow dependencies up to 4 levels deep to build a complete picture of impact:

• Directly affected: The resources being created, updated, or deleted

• Transitively affected: Resources connected via dependencies

• Cross-workspace impact: Resources in other workspaces that reference the changed resources

So what does this look like in practice?

The visibility gap

Here's that same security group PR, side by side:

Plan: 0 to add, 1 to change, 0 to destroy.

Changes to Outputs:
  ~ security_group_id = "sg-0a1b2c3d4e5f"

Risk Score: 1,850 (High)
Blast Radius: 17 resources, 4 workspaces
Max Depth: 3 levels

Same PR. Completely different decision context.

With the plan output, you're making a judgment call based on one line of diff. You might glance at the changed CIDR blocks, think "looks reasonable," and approve. You have no signal that this change could break connectivity for 17 services across 4 teams.

With Cora, you see the 1,850-point risk score and immediately know this isn't a routine change. You see the 4 workspaces and know which teams to loop in. You see the 3 levels of dependency depth and understand that the impact isn't just direct. It ripples through your load balancers, into your application services, and down to your databases.

The plan tells you what's changing. Cora helps you understand what it means.

But how does Cora know that 1,850 points is "High" risk? That's where risk rules come in.

Risk rules that match your reality

Every organization has different definitions of "risky." Cora lets you define rules that stack: each matching rule adds to the total risk score, so a change can accumulate risk from multiple dimensions.

A security group deletion in your production shared-infra workspace matches all four rules: 100 + 200 + 500 + 300 = 1,100 points. The same deletion in a dev sandbox might only match the delete rule: 500 points.

You set thresholds for what constitutes low, medium, high, and critical risk, and configure how many approvers each tier requires:

• Low (0-500): 1 approval, any team member
• Medium (501-1,500): 2 approvals
• High (1,501-3,000): 2 approvals including platform lead
• Critical (3,000+): 3 approvals including security

Once you've defined your rules, adding Cora to your workflow takes minutes.

Integrate with your workflow

PR Risk Assessment works with Atlantis, GitHub Actions, or any CI system:

workflows:
  cora-risk:
    plan:
      steps:
        - init
        - plan
        - run: terraform show -json $PLANFILE > plan.json
        - run: |
            cora plan upload plan.json \
              --workspace "$WORKSPACE" \
              --github-repo "$BASE_REPO_OWNER/$BASE_REPO_NAME" \
              --pr "$PULL_NUM" \
              --commit "$HEAD_COMMIT"

What's next

PR Risk Assessment is available now. We're continuing to build on it:

• Risk-based approval requirements: Automatically adjust required reviewers based on risk score. Low-risk PRs merge fast. High-risk changes require the right people.
• GitHub PR comments: Get risk summaries posted directly to your pull requests
• GitHub check runs: Block merges when risk thresholds are exceeded
• Historical trending: Track risk scores over time to spot patterns

You can't unsee it

Once you've seen your blast radius, reviewing Terraform PRs feels different. That one-line security group change? You'll know it touches 17 resources before you approve. That "simple" IAM update? You'll see which workspaces assume the role.

The incident from the intro didn't have to happen. With visibility into cross-workspace dependencies, you'd have seen the 4 affected workspaces, looped in the right teams, and merged with confidence instead of crossing your fingers.

That's what Cora gives you: the context to make informed decisions, not lucky ones.

See your blast radius →