# Gate Registry

The gate registry maps gate IDs to their implementations and metadata. The registry is the authoritative list of which gates are active in the system.

---

## Registry entry format

```
GateRegistryEntry {
  gate_id:          string         -- must match a standard gate_id or be a registered extension
  display_name:     string         -- human-readable label
  description:      string         -- one sentence on what this gate detects
  method:           string         -- "regex" | "rule" | "classifier" | "neural" | "hybrid"
  implementation:   string         -- reference to implementation module or file
  version:          string         -- semver
  enabled:          boolean        -- false to disable without removing from registry
  recall_threshold: float [0, 1]   -- minimum recall this gate is expected to maintain
  activates_specialists: string[]  -- hint: which specialists this gate commonly triggers
  notes:            string?        -- optional
}
```

---

## Active gate registry (initial)

These are the initial gate implementations. All use rule/regex methods as starting points. They will be upgraded to classifiers or neural models as the contract tests stabilize.

| gate_id | method | activates_specialists | enabled |
|---|---|---|---|
| `is_math` | rule | quantity, logic | true |
| `is_code` | rule | code | true |
| `has_temporal_relation` | rule | temporal | true |
| `has_spatial_relation` | rule | spatial | true |
| `has_causal_relation` | rule | causal | true |
| `has_entity_reference` | rule | entity | true |
| `has_coreference` | rule | entity | true |
| `has_quantity` | rule | quantity | true |
| `has_logical_negation` | rule | logic | true |
| `has_comparison` | rule | quantity, logic | true |
| `has_planning` | rule | planning | true |
| `has_constraint` | rule | logic, planning | true |
| `has_state_change` | rule | ownership, temporal | true |
| `has_ownership_transfer` | rule | ownership, entity | true |
| `has_social_intent` | rule | social | true |
| `requires_external_knowledge` | rule | — | true |
| `requires_synthesis_only` | rule | — | true |

---

## Adding a new gate

1. Define a gate ID. Use `has_{relation_family}` for relation detectors and `is_{domain}` for domain detectors.
2. Write the implementation satisfying `gates/contract.md`.
3. Write at least 5 positive recall tests and 5 true negative tests per `tests/contracts/gate_contract_tests.md`.
4. Add an entry to this registry.
5. Update `activates_specialists` with which specialists this gate commonly triggers. This is a hint to the router, not a constraint.

---

## Upgrading a gate implementation

A gate's contract (gate_id, output schema, invariants) does not change when the implementation method changes. A regex gate may be replaced by a neural gate without any other component knowing. The registry `method` field and `version` field must be updated.

---

## Disabling a gate

Set `enabled: false`. Do not remove entries — removal loses the `activates_specialists` hint and breaks the audit trail.