# Decreen CTO brief

Stop reviewing the same engineering decision twice.

Decreen turns approved engineering decisions into reusable authority for AI-assisted development. It helps teams surface decisions, verify what actually enforces them, and check new changes against what has already been decided.

2-minute overview · evidence included · pilot-ready

## The problem

Engineering decisions live in code, tests, documentation, review comments, and senior engineers’ memory.

As agent-generated changes increase, teams keep having to reconstruct decisions they have already made.

Decreen makes those decisions explicit, reviewable, and reusable throughout the development cycle.

## How Decreen works

From discovered decisions to reusable authority.

1. Discover decisions — Decreen surfaces candidate engineering decisions from existing engineering knowledge.
2. Human approval — Senior engineers approve, edit, or reject candidates.
3. Ratified decisions — Approved decisions become reusable authority.
4. JIT context — Relevant decisions can be supplied during planning, implementation, refactoring, and review.
5. Judge each change — Every change can be checked against the decisions that already apply.
6. Learn and refine — A change can reveal a genuinely new decision or show that an existing rule needs refinement.

Finders propose. Humans establish authority. Decreen reuses approved decisions.

## Enforcement is a separate question

A decision can be authoritative even if enforcement is weak.

After a decision is approved, Decreen asks: what, if anything, mechanically makes this decision true?

It looks for the tests, constraints, guards, schemas, or other mechanisms that support the decision. Where enforcement is incomplete, Decreen can surface the gap as a hardening opportunity rather than pretending the rule is fully protected.

Examples: add a regression test, add a database constraint, introduce a lint rule, close a bypass path.

## Evidence so far

### Decision recovery

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.

### Enforcement

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.

### Judge

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.

## How it fits into your workflow

Reuse the same decisions across many PRs.

Developers / agents → PRs → existing CI / merge workflow → Decreen Judge → Conform / Violation / New Decision / Model Gap.

Relevant approved decisions are reused across PRs instead of being reconstructed from scratch each time. A genuinely new decision goes back through human review before becoming authority for future work.

CI checks whether the change works. Decreen checks whether the change respects decisions the team has already made.

## Where Decreen runs

Decreen analyzes the repository in your execution environment.

Decreen works alongside the tools that already have access to your code. That can include a local agent runtime, a developer workstation, a self-hosted CI runner, or GitHub Actions.

The Decreen CLI and optional skills operate against the repository there. The repository itself does not need to be uploaded to Decreen.

Decreen synchronizes derived product state such as approved decisions, references, workflow state, and review results.

Data handling by your chosen agent runtime, CI provider, or model provider remains subject to that provider’s own configuration and policies.

## Proposed pilot

One repository. Three months.

### Month 1: backtest

Decreen analyzes one repository and a set of past PRs. Your senior engineers review and approve the 15–25 decisions that matter most.

You receive a written report showing:

- the decisions Decreen surfaced,
- which past changes interacted with them,
- which decisions appear weakly enforced or unenforced,
- and where genuinely new judgment was required.

### Months 2–3: live use

Decreen checks new changes against those approved decisions. The pilot remains flag-only: Decreen does not silently approve or block merges.

### What success looks like

The pilot succeeds if it gives your team:

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

### What we are not claiming

Decreen is not an autonomous merge gate. It does not turn model output into authority without human approval. And it does not assume that because the code currently follows a decision, that decision is fully enforced.

The product is designed to keep those distinctions explicit.

## Next step

Would you run Decreen on one repository and its past PRs to see whether it reduces repeated senior review in your AI-assisted development workflow?