Skip to content

Design: a primordial/default ontology as an ingestion fallback #459

@aaronsb

Description

@aaronsb

Idea

There should always be a primordial / default ontology — an always-present collection that ingestion can fall back to when the target ontology is unexpectedly absent at execute time, instead of failing the job with a 'missing target' anomaly and nowhere to land.

Context / motivation

Surfaced while validating #457 (vision facade collapse). The #402 Defect B1 guard in workers/ingestion_worker.py raises when an ontology "existed at submit but was missing at execute" — correctly refusing to silently recreate a dissolved/deleted ontology. That guard is right to refuse silent recreation, but it also means a job can dead-end with no safe landing zone.

A guaranteed default ontology would give such jobs a deterministic home (with an operator-visible signal that the original target was missing), rather than a hard failure. It parallels how many systems keep a 'default'/'uncategorized' bucket that can never be deleted.

Open questions

  • Is the default created at platform init and made non-deletable (lifecycle 'frozen'-against-delete)?
  • Does fallback re-home the job to the default, or just annotate the failure? (Silent re-home risks hiding data-routing mistakes — the Race condition: annealing dissolves ontologies with in-flight ingestion jobs, causing silent data loss #402 guard exists precisely to avoid silent behavior.)
  • Interaction with annealing/dissolve: should a dissolved ontology's future-queued jobs route to default?
  • Naming/semantics: 'primordial' vs 'default' vs 'inbox'.

Scope

Design discussion first (likely an ADR). Not blocking #457. Raised by @aaronsb.

Metadata

Metadata

Assignees

No one assigned

    Labels

    architectureArchitectural decisions/changesenhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions