Decreen

Stop reviewing the same engineering decision twice

AI can generate a pull request in minutes. A senior engineer still has to answer:

Does this change break a decision our team has already made?

Those decisions include things like:

  • which component owns particular data,
  • which API or workflow is canonical,
  • what must remain backwards compatible,
  • and which shortcuts are explicitly forbidden.

Today, that knowledge is scattered across code, tests, documentation, review comments, and people's heads.

As the number of agent-generated changes grows, senior engineers risk answering the same questions again and again.

What Decreen does

Decreen makes those already-made engineering decisions reusable.

For each change, it shows:

  • which approved decisions apply,
  • what test or mechanism actually enforces them,
  • whether the change conforms,
  • and where a genuinely new human decision is required.

The result is not automatic merge approval.

It is a focused list of the places where senior engineering judgment is actually needed.

Decreen surfaces candidate decisions from existing engineering knowledge. Senior engineers approve, edit, or reject them. Approved decisions become reusable authority for later planning, implementation, refactoring, and review.

A decision can be authoritative even if enforcement is weak. After a decision is approved, Decreen asks what, if anything, mechanically makes it true. Where enforcement is incomplete, that gap is a hardening opportunity rather than a claim that the rule is fully protected.

Decreen analyzes the repository in your execution environment. The repository itself does not need to be uploaded to Decreen.

Evidence so far

On a second repository outside Decreen's own codebase, Decreen surfaced 30 reviewable engineering decisions from existing repository knowledge. Those decisions were human-reviewed before becoming authority.

Decreen already finds relevant enforcement evidence well in small controlled evaluations. We currently treat “fully enforced” claims conservatively: finding relevant supporting code is easier than proving that every clause and path is mechanically covered.

In controlled cases where authority existed before the tested changes, Decreen correctly distinguished a change that conformed to an existing decision, a change that violated one, and a change that required a genuinely new decision.

These are early controlled results on a limited number of cases, not a claim of general accuracy across arbitrary repositories.

Proposed pilot

On one repository, Decreen would:

  1. discover candidate decisions from documentation, code, tests, and historical reviews,
  2. backtest them against previous PRs,
  3. help senior engineers ratify the 15–25 decisions that matter most,
  4. review new changes only against that approved authority.

The pilot remains flag-only: Decreen does not silently approve or block merges.

Success would mean:

  • fewer repeated architectural review comments,
  • faster identification of genuinely new decisions,
  • clearer visibility into decisions that are not mechanically protected,
  • less senior-review time spent re-establishing context.

Download the pilot proposal

Next step

A 30-minute call to pick the repository and agree on what success looks like for your team. We can start the backtest within a week of that call.

At the end of month 1 you get a written backtest report. It is yours to keep whether or not you continue.

The question

Would you be willing to run Decreen on one repository and its past PRs to see how often your team reviews the same decision twice?

Yes