# Decide whether BLOGE belongs in this system

## When to use

Use this task before adding BLOGE to a new system or widening an existing adoption. Stop with `STOP` when a hard constraint is incompatible with an embedded Java orchestration engine. Return `PROBE` when one decisive runtime fact is unknown. Return `ADOPT` only when the constraints and evidence support a bounded use case.

## Inspect first

- Identify the Java and Maven baselines, deployment topology, latency budget, and ownership model.
- Draw the current workflow: dependencies, fan-out, branches, failure policy, waits, recovery, and external effects.
- Check whether the problem is orchestration or merely one local method call.
- Read [what BLOGE is](/en/v/0.9.8-RC1/01-why-bloge) and the [selection comparison](/en/v/0.9.8-RC1/33-migration-and-comparison).

## Required inputs

Obtain the business outcome, maximum interruption window, persistence requirements, expected scale, operator ownership, compliance constraints, and rollback path. Do not substitute a feature checklist for these constraints.

## Implementation path

1. Record hard constraints that can reject BLOGE without a prototype.
2. Map each surviving requirement to a BLOGE capability and its evidence source.
3. Mark every unsupported or unmeasured claim as unknown.
4. Design the smallest probe that can resolve the most important unknown.
5. Write a short ADR with the decision, evidence, rejected alternatives, and reversal condition.
6. If the result is `ADOPT`, choose one bounded workflow and defer unrelated extensions.

## MUST / SHOULD / MAY

- **MUST** state `STOP`, `PROBE`, or `ADOPT` and name the condition that produced it.
- **MUST** distinguish source capability from production evidence in the target system.
- **MUST** keep external effect semantics and operational ownership explicit.
- **SHOULD** compare architecture fit rather than raw feature count.
- **SHOULD** prefer a reversible probe before fleet-wide migration.
- **MAY** decide not to use BLOGE; the documentation does not presume adoption.

## Failure patterns

- “BLOGE supports retries, therefore it fits”: retry is one mechanism, not an architecture decision.
- “The example runs, therefore capacity is sufficient”: a functional example does not measure the target workload.
- “All facts are known”: convert assumptions into named unknowns and probes.
- “Adopt everywhere”: reduce the decision to one workflow boundary and one accountable owner.

## Validation

Review the ADR against the actual repository and deployment constraints. If `PROBE`, run the named probe and attach its command, input, result, and limits. No code change is required for `STOP`; a correct rejection is a valid result.

## Evidence

- [BLOGE mental model](/en/v/0.9.8-RC1/01-why-bloge)
- [Migration and comparison](/en/v/0.9.8-RC1/33-migration-and-comparison)
- [Version and evidence reference](/agent/en/v/0.9.8-RC1/reference/version-and-evidence.md)
- [Source and claim discipline](/agent/en/v/0.9.8-RC1/policies/source-and-claim-discipline.md)