Self-Hosted Source Catalog & Radar — generalize the mirror+refresh+discover+rank pipeline for any imported content, and surface ranked self-hostable options to Stack admins

Accepted

Motivação (diretiva do owner, 2026-06-13)

Sobre conteúdo importado de terceiros (qualquer tipo — geodados, imagem, vídeo street-level, células LBS, modelos LLM, pacotes e versões de software, corpora, dicionários, rankings), a Koder Stack deve, automática e periodicamente:

  1. Baixar + hospedar + sincronizar o conteúdo (mirror com refresh).
  2. Pesquisar por novas fontes relevantes da mesma categoria.
  3. Rankear essas fontes.
  4. Apresentá-las como opções self-hostable aos usuários perfil-admin da

    Stack, pra decidir adotarespelharflipar.

E, no longo prazo, construir o software próprio (self-hosted-first endgame) em vez de depender do de terceiro.

Dois eixos de "self-hostable" (não confundir)

  • Software — a plataforma que roda (ex.: Panoramax pra street-level). Endgame:

    Koder-nativo (fase 3).

  • Dados — o conteúdo baixável + re-hospedável. Gargalo é licença (precisa

    ser aberta/compatível) + volume + viabilidade de export em massa, não a vontade. A maioria das bases abertas relevantes é redistribuível (CC-BY-SA, ODbL, etc.); o mirror é por região/escopo operacional, não tudo de uma vez.

O que JÁ existe (não reinventar)

policies/self-hosted-data-refresh.kmd já obriga, pra qualquer conteúdo importado: R1 refresh incremental agendado · R2 versionamento+rollback · R3 frescor+SLA · R4 radar de fontes (varredura periódica, registry rankeado, alimentando self-hosted-first). Instâncias vivas: ai-model-recommendations.md (modelos, RFC-008), geo-source-recommendations.md (geo, atlas#002-B). O Governance Plane (RFC-016) é o lar natural da surface admin.

O gap que este RFC fecha: o R4 hoje produz markdowns ad-hoc por categoria e não tem surface admin nem motor genérico. Este RFC promove o R4 a subsistema único (catálogo machine-readable + radar genérico + surface no Governance Plane).

Design

{ category, name, license, self_host_software, data_mirrorable (bool+método: bulk/STAC/api-iter), coverage, freshness, cost_class (storage/compute), rank, status (candidate|mirroring|self-hosted|flipped), notes }. Categoria = geo | imagery | video | cells | models | packages | corpora | … (aberta).

Motor genérico + adapters por categoria

  • Radar (descoberta): varredura periódica por categoria (re-executável, R4) →

    novas fontes candidatas. Adapter por categoria sabe ONDE procurar (ex.: imagery → MapillaryKartaViewPanoramaxMapilio; models → HFregistries; packages → upstreams/mirrors).

  • Ranking: licença-abertura + cobertura + frescor + self-hostabilidade

    (software+dados) + custo. Determinístico + auditável.

  • Mirror (quando adotada): delega ao pipeline self-hosted-data-refresh

    R1–R3 (incremental, versionado, com SLA), storage por RFC-001/RFC-006 (metadados no plano de dados; blobs pesados em object store trust-tiered).

Surface admin (Governance Plane, RFC-016)

UI perfil-admin: por categoria, lista as fontes rankeadas com estado e ações: adotar (começar mirror), espelhar região X, flipar pra self-hosted, descartar. Mostra coberturafrescorcusto. As decisões viram registro auditável (alinha ao "governance-as-code" da RFC-016).

Endgame software-próprio (fase 3, self-hosted-first)

Por categoria madura, construir o serviço Koder-nativo substituindo o de terceiro (padrão kodec/koda; street-level = Panoramax→Go nativo no Koder Atlas). Gate pelos 5 gates de self-hosted-first.kmd.

  • models — ai-model-recommendations.md (RFC-008 autonomous curation).
  • geo — geo-source-recommendations.md (atlas#002-B).
  • imagery — street-level (atlas#008): hoje consumo on-demand do Mapillary;

    fontes self-hostable = Panoramax (software+dados), Mapillary/KartaView (dados CC-BY-SA, mirror por API/região); captura própria pela frota Karavan.

Trade-off / por que agora (fase 0 custo-zero)

Fixar o data-model + o seam motor↔adapter + a surface-no-Governance-Plane agora torna as fases 1–3 alcançáveis sem rewrite (mesmo argumento da RFC-016 fase 0). Não implementa nada além do norte; as instâncias atuais seguem funcionando como feeds.

Open questions

  • Onde mora o motor RESOLVIDO (fase 1 slice 1): motor em

    services/foundation/srcradar (novo sector foundation); surface no Governance Plane (RFC-016) consome esse motor — exatamente o "provável".

  • Catálogo machine-readable: formato + kdb vs arquivos versionados

    RESOLVIDO (fase 1 slice 1): a SSOT é catalog/sources.toml — arquivo TOML git-versionado, auditável, PR-reviewável (config-as-code, como os demais registries). A surface da fase 2 pode espelhar/cachear no kdb pra query (RFC-001) sem mover a SSOT, evitando acoplamento prematuro a DB.

  • Política de custo: budget de storage por categoria/região antes de auto-mirror

    (segue aberta — entra na fase 2, junto com a ação adotar/espelhar da surface).

Implementation status

  • Fase 1 slice 1 — LANDED (services/foundation/srcradar, ticket

    srcradar#001): catálogo machine-readable + ranking determinístico (pesos somam 1.0: licença 0.25 / software 0.20 / data-mirrorable 0.15 / cobertura 0.20 / frescor 0.10 / custo-inverso 0.10) + motor de radar (seam Adapter por categoria + Scan discover→rank→diff-vs-catálogo) + adapter imagery + CLI srcradar. Buildvettest verdes em dev-linux-box. Koder = consumidor #1.

  • Próximo (srcradar#002): adapters modelsgeopackages + live

    discovery (R4 real) + srcradar sync (write-back de candidatos NEW no catálogo).