71 lines
3.0 KiB
Markdown
71 lines
3.0 KiB
Markdown
|
# 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.
|