- src/types.hpp: complete UCWM type system in C++20 — 19 enums, 11 facet data types, all core structs (CanonicalObject, Constraint, Facet, GateSignal, WorldState, etc.) with full JSON round-trip serialization - src/main.cpp: smoke test — constructs apple-problem WorldState by hand, serializes to JSON - tests/test_types.cpp: 19 tests, 123 assertions, all passing - CMakeLists.txt: CMake + CPM build with nlohmann/json, spdlog, Catch2 - schemas/: JSON Schema contracts for all UCWM data types - gates/, specialists/, resolver/, synthesis/: language-agnostic interface contracts and domain specs for all pipeline layers - docs/: architecture, vocabulary, decision matrices, roadmap (6 phases, 28 sprints), sprint_001, implementation_constraints Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
3.0 KiB
3.0 KiB
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
- Define a gate ID. Use
has_{relation_family}for relation detectors andis_{domain}for domain detectors. - Write the implementation satisfying
gates/contract.md. - Write at least 5 positive recall tests and 5 true negative tests per
tests/contracts/gate_contract_tests.md. - Add an entry to this registry.
- Update
activates_specialistswith 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.