Lexery Wiki

Lexery - Import Proposal Loop

3 хв читання

Lexery — Import Proposal Loop

This note describes the closed loop from a user query through Brain to a human- or AI-governed import decision in Supabase. It is the operational bridge between catalog truth and indexed corpus.

End-to-end flow

User query
  → Brain retrieval
  → [[Lexery - DocList Surface|DocList]] check
  → gap detected
  → U6 emits `lldbi_admin_hints` (and/or trace-derived signals)
  → LLDBI admin scans recent runs
  → import **proposal** created
  → `legislation_import_proposals` (Supabase)
  → human / AI review → import or reject

The Brain signals; LLDBI admin owns lifecycle and deduplication. This keeps the hot path fast and the corpus changes deliberate.

Signal types

SignalMeaning
catalog_gapAct exists in DocList catalog but is missing or inadequate in LLDBI Qdrant
import_requestedExplicit pipeline or operator intent to import
touchAct was referenced or touched; may warrant refresh or prioritization

These are the primary categories extracted from snapshot.lldbi_admin_hints and related run data.

Fallback: doclist_trace

When explicit lldbi_admin_hints are absent, brainSignals.ts can still derive usable signals from snapshot.doclist_trace. That fallback prevents “silent” gaps when hints were not wired for a particular path but the trace still encodes catalog/index tension.

Conservative by design

Emitting a signal is not the same as importing. Proposals aggregate noise; dedupe and review prevent thrash.

Supabase: legislation_import_proposals

Proposals are durable rows — audit trail, reviewer identity, and outcome. They connect run-time traces to offline corpus operations.

Deduplication: new proposals are checked against existing pending rows and recent decisions so the same gap does not spawn unbounded duplicate tickets.

Observed live state

As of recent observation, the latest pending proposal example was:

  • rada_nreg = 2811-20
  • proposed_by = ai

Treat this as an instance illustrating the pipeline, not a permanent invariant.

Relationship to U6 and recovery

U6 is where many hints originate after retrieval and DocList interaction. Coverage gap honesty and retry logic must remain consistent with “we know the act exists in catalog but not in index” scenarios — those are prime catalog_gap drivers.

Relationship to LLDBI admin CI

Scheduled scans (see Lexery - LLDBI Surface and .github/workflows/lldbi-brain-admin.yml) widen the funnel beyond a single run: they catch recurring gaps across many sessions.

See Also

Вигляд графа

Зворотні посилання