DBRaven Docs

How to use architecture decision reports in real design reviews.

6decision-ready scenarios19draft reference scenariosEvidence gaps labeledNo confidence percentages

Quick start

Three steps to a review

The whole loop, start to finish. Each step links to where it happens.

1
Run an architecture review
Answer a short profile interview, workload, traffic, team, constraints. DBRaven matches it to a decision-ready scenario.
Start a review →
2
Read the memo
Verdict, what breaks first, why it fits, risk evidence, and next actions, every line traceable to a knowledge entity.
3
Turn risks into review tasks
Simulate the workload and wire the governance guardrails and telemetry before the design is approved, not after.
Open simulations →

Playbook

The design-review workflow

DBRaven makes a review more concrete, it doesn’t replace it. Here is where a decision report fits across the life of a design.

1Before implementation

Pressure-test while it's still a choice

Run the analysis before you start building, while the architecture can still change.
Read the verdict and the first bottleneck you'll hit, with the telemetry signal that precedes it.

2During design review

Put it in the doc and argue with it

Paste the verdict and “what breaks first” into the RFC or design doc.
Use the named risks and sourced precedent to challenge “that won't happen to us.”

3After approval

Convert risks into tasks

Turn each next action into a review task: workload simulation, guardrail checks, telemetry.
Wire the signals that prove the first limit is approaching before it does.

Report anatomy

What’s in a decision memo

Every report is the same six parts, in the same order. Each traces to a specific piece of structured knowledge you can open.

Verdict

Proceed, simplify, or delay, the one-line call, with the reasoning behind it.

Deterministic scenario rubric

What breaks first

The component that saturates first under load, and the telemetry signal that shows it coming.

Topology runway threshold

Why it fits

Which parts of your profile matched the scenario, and the alternatives it weighed against.

Rubric match + comparison

Risk evidence

Named failure modes with blast radius, each linked to the knowledge entity behind it.

Failure-mode relationships

Sourced precedent where available

A documented production system that hit the same limits, when one exists. When none is sourced, the report says so.

Case-study evidence

Next actions

The concrete next step: pressure-tests, guardrail checks, and telemetry to wire before committing.

Recommended action

Trust model

What DBRaven refuses to fake

The same honesty the reports enforce, stated as policy. Determinism is the point: no LLM writes the architecture facts, and the same inputs always produce the same review.

Grounded vs. draft

Every scenario is labeled. Fully-modeled scenarios carry topology, advisor output, and comparison data. Draft scenarios are browsable reference, not decision support.

Sourced precedent where available

Precedent is cited only where a real system documents the same limits. Where there is no sourced precedent, the report says so instead of inventing one.

Quarantined case studies withheld

Case studies that can't be sourced or verified are held out of evidence entirely, not shown with a caveat, not counted as support.

No numeric confidence theater

Confidence is shown as evidence grounding, never a fabricated percentage. The report names what it hasn't modeled instead of guessing a number.

Coverage & limits

What’s modeled, and what isn’t

Be explicit about the boundary. Fully-modeled scenarios are decision support; draft reference scenarios are useful for browsing but are never presented as complete.

fully modeled

draft reference

total

Fully-modeled scenarios carry topology, advisor output, risk intelligence, and comparison dimensions, enough to stand behind a decision. Draft scenarios are labeled and excluded from decision support until they meet that bar.

See the full coverage breakdown →

Read before a consequential decision

DBRaven has never seen your codebase, your traffic, or your team's operational history. It reasons from structured knowledge, not your production data.
Scoring is deterministic and heuristic: the same answers always produce the same review. Your specific context may point to a different optimal choice.
Coverage is bounded by the current knowledge base. Niche patterns (CRDT collaborative state, custom consensus) are not yet modeled.
It does not replace an architecture review with your team. It provides structured starting points and documented tradeoffs; the final judgment is yours.
Analysis is stateless, there is no persistence. Bookmark or share a comparison URL to return to a specific analysis.

Reference