MiCyte

← The wiki

60 — Canonical datum identity and hyphae flags

DesignedRendered from 60-canonical-datum-and-hyphae-flags.md in the public repository. Edits belong there.

A datum's hyphae value is a content-derived token for that datum; a hyphae flag binds a tool or a lens to a hyphae value. The values are computed today; no flag is registered and nothing consults the flag registry.

A datum address (layer-value_group-iteration) is positional: inserting or moving a row changes its siblings' iterations. A binding that must survive copying, re-nesting and re-addressing therefore needs a key derived from content, not from the address.

What is built

All in micyte/core/datum_semantics/engine.py and micyte/core/hyphae_flags/__init__.py.

Function or objectEffect
build_document_semantics(document)For every row: a semantic_hash that replaces local addresses with the hashes of the rows they reference (so it does not change when the row is re-addressed), and a hyphae_hash over the row's abstraction chain, folded under the document's anchor_context_hash
compile_hyphae_value(document, address)Returns that row's hyphae_hash as a sha256: token: the datum's hyphae value
build_minimum_complete_path(document, address)The datum's local-reference closure, dependencies first and the datum last, with no rudi range added
derive_hyphae_chain (in micyte/core/mss/datum_identity.py)The rudi chain 0-0-1 … 0-0-K for a datum
HyphaeFlag, RaisedFlag, HyphaeFlagRegistry, raise_flagsA registry from hyphae value to tool_id and/or lens_id, with scope datum or family_root. DEFAULT_HYPHAE_FLAG_REGISTRY is empty

The hyphae value includes every preceding rudi datum, even one the datum does not reference directly: a datum that uses 0-0-5 carries 0-0-1 through 0-0-5. The rudis are the ordinal, incremental and nominal frames, and the value is canonical because it is anchored at the first rudi. The binary specification states the same rule (docs/contracts/mss_binary_sequence/).

The algorithm is versioned by HYPHAE_CHAIN_POLICY (mos.hyphae_chain_v1).

How tools and lenses bind today

  • Tools bind by applies_to_archetype and applies_to_source_kind, widened along the hyphae chain (40).
  • Lenses bind by recognized family, overlay kind and value kind. The family comes from _family_contract in micyte/domains/datum_recognition/service.py, which matches substrings of the anchor label (title-babelette, fiat with babelette, samras, hops, and others). An unrecognized label gives unrecognized_family.

Neither key is a hyphae value. A family is a bucket of many different datums.

Not built

  • No flag is registered.
  • Nothing calls raise_flags.
  • DatumLensRegistry.resolve accepts a flag_lens_id and gives it first priority, but no caller passes one.
  • Tool eligibility does not read flags.
  • No surface registers or lists flags.

The intended binding

  1. After a document is read, each datum computes its hyphae value and looks it up in the registry. A hit is a raised flag carrying the bound tool_ids and lens_id.
  2. A family-root flag is raised when the hyphae value of a family's common root datum matches; every member of the family inherits it.
  3. The lens resolver uses a raised flag's lens_id first, then falls back to family, overlay and value kind.
  4. Tool eligibility adds the tools bound to a raised flag to the archetype-based matches.

The existing archetype and family bindings stay as the fallback, so an unflagged datum behaves as it does now.

Open questions

  1. Datum or family root. "Family root common datum" needs a precise definition: the shared prefix of the members' paths, or their deepest common ancestor in the dependency graph.
  2. Form of the fold. The value is a SHA-256 over canonical JSON today. The binary MSS form (61) may replace the representation; the rudi-inclusion rule stays.
  3. Versioning. A change to the algorithm must produce different values so that old registry entries are detectably stale. Policy strings do this: HYPHAE_CHAIN_POLICY for hyphae values, ARCHETYPE_SHAPE_POLICY for archetype shape signatures.
  4. Where the flag registry is kept. In code, as a MOS document, or in per-instance configuration. The archetype registry is kept as MOS documents (41); the flag registry is an in-code object.
  5. Precedence. When a per-datum flag and a family-root flag name different lenses, the proposal is that the per-datum flag wins.