# Architecture decision record

> Template — copy this page into `architecture/adrs/{NNN}-slug.md` when recording an architectural decision. Delete this callout when you're done.

|              |                                                          |
| ------------ | -------------------------------------------------------- |
| **Status**   | proposed / accepted / superseded by ADR-### / deprecated |
| **Date**     | YYYY-MM-DD                                               |
| **Deciders** | @owner @reviewer1 @reviewer2                             |

## Context

What's the problem we're trying to solve? Why is the status quo not good enough? What constraints does the system place on us?

Examples:

* "Our diarization pipeline mis-attributes speakers on 12% of multi-party calls. We need a better answer than 'try harder'."
* "Postgres `SELECT FOR UPDATE SKIP LOCKED` is becoming a hotspot at 1000 calls/day."

## Decision

A short, declarative statement of what we decided.

> We will use pyannoteAI for diarization, with Lemonfox built-in diarization as a graceful fallback.

## Alternatives considered

For each option, explain what it is and why it lost.

### Option A — {Name}

* **Pros:** ...
* **Cons:** ...
* **Verdict:** rejected because ...

### Option B — {Name}

* **Pros:** ...
* **Cons:** ...
* **Verdict:** rejected because ...

### Option C — {Name} *(chosen)*

* **Pros:** ...
* **Cons:** ...
* **Verdict:** accepted.

## Consequences

What does choosing this option imply?

* **Positive:** New capability X. Better Y.
* **Negative:** Adds a dependency on Z. Increases per-call cost by $A.
* **Neutral:** We need a fallback path for when pyannote is unreachable.

## Implementation notes

* Migration steps.
* Feature flag for safe rollout.
* Rollback strategy.

## Links

* Related PR(s)
* Related issue(s)
* Related docs ([Diarization](/features/diarization.md), etc.)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.scryon.app/templates/adr.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.