Director

Director is the hosting instance's application for managing the instances it has established and the registrar's profiles of entities.

What it turns on

Installing exposes four tools: director, profile_admin_edit, farm_onboarding and entity_profile_table. The hub opens in one of two configurations, chosen with the director_app query parameter. Each draws a Domain tab last.

Instances (default):

Registrar:

Contact cards, profiles and types

The registrar keeps two kinds of row about an entity.

• Contact card. One row per msn in the registry document, written to the msn_contact_card archetype: msn_id, lcl_id (the type), dns, website, email. A node that runs an instance also carries its public_signature and instance_endpoint. The card is what the network publishes. Its type is the entity's kind.
• Profile. One row in the document the entity's kind keeps, written to that document's archetype:

Each document names its archetype in its metadata (document_metadata["archetype"]), the convention every other corpus document follows. The pairing above is also declared in code (directory.PROFILE_DOCUMENTS); the types view says when a document's metadata names a different archetype from that pairing, or names none.

The types are the children of the node labelled entity_class in the registrar's lcl_domain (the kinds), and their children (the subtypes, such as llc under legal). The node is found by its label. If no node, or more than one, carries that label, there are no types and none is offered.

Standard fields

A profile row carries every one of its document's standard fields, in this order, with an empty value when the fact is unknown:

A row's family is its pair count, so a row whose cells came and went with what was known changed address with every edit. With every cell present, a fact learned later is an edit in place. Director's save writes a legal_entity row in this shape. A row written before it takes the missing cells, empty, on its first save, keeps every cell it held, and moves once to the family six pairs name.

The contact card follows a different convention. Its cells are written in the card's order (msn_id, lcl_id, dns, email, website, then public_signature and instance_endpoint), and an empty cell is left out, because a declaration that merges into the card drops empty values.

Ag profile types

A network profile (the AGNET channel's) is typed by a node of the registrar's ag_profile branch, also found by its label:

The type select lists that branch as the tree holds it, each option labelled by its path ("Hub — farmers market host"). A type is checked against the branch when a profile is created or saved, and anything else is refused. A type written in the numbering used before 2026-09-09 (1-2-*) is translated to the node that carries the same label.

Readers classify a type by its LABEL PATH, never by its address. The 2026-11-11 regroup moved farmers_market_host, csa_operator and food_hub under hub and added consumer, so an address names a different type than it did before, while a label does not change.

An administrative profile records jurisdiction_type (city, village, township, county), not a type. Its type is derived from that value by one declared crosswalk, directory.ADMIN_SUBTYPE_OF_JURISDICTION:

The stored value is not changed: it is the finer fact, and the type is read from it. A value the crosswalk does not map gives no type, and the detail and the types view say which value it was. On the types view each administrative subtype says which jurisdiction values it was counted from.

Opening an entity in the Directory shows three parts:

1. Contact card. dns, email and website can be edited. The type is shown and is not editable here.
2. Profile, titled by its document's archetype. On a legal_entity row the type is a select grouped by kind: the row's kind and its subtypes first, then the other kinds the same document keeps (a legal entity is offered informal and its subtypes), and dns, email and the phone can be edited. On an administrative_entity row the type is shown read-only, with the jurisdiction_type it was derived from, and dns can be edited.
3. Also on record. Rows from every other registrar document that name the entity. Read-only, folded by default.

Above the parts, the detail lists where the card and the profile disagree: no card, no profile, a card with no type, a profile in a document that does not keep the card's kind, a profile type of a different kind from the card's, two profile rows for one msn, or dns values that differ. Nothing is corrected automatically.

Two rows are not defects and are not counted as such. A document's own title row (a lone title at 4-1-1, the text_note convention) is not a contact card. An msn whose segments after the state are all 0 is a placeholder: a place with no county, street or house. Rows filed under it are separate entities with no address yet; the detail says so, and that each needs an address to be given an msn of its own.

A type change is checked by value in save_profile_entry. The new type must be the row's current kind, one of its subtypes, or another kind the same document keeps. Choosing another kind (legal to informal) moves the entity: the profile's type and the contact card's type are written in one transaction, so the two never disagree. The page says so before it saves, and the move is made on the second press of Save. A kind kept in another document (legal to natural) is refused with the reason: that document's archetype has fields the row does not have. A field already on the row is replaced where it stands, so the row keeps its archetype's field order.

The same detail is drawn on a visited profile in the walkthrough, for a different audience: no forms, the card's lcl_id, dns and website only (never its email), no natural person's profile row, and no other documents.

Not done here: moving an entity to a kind kept in another document, and giving a placeholder msn's entities their own addresses.

What it reads and writes

It reads the registrar's legal_entity document, each instance's msn_profile, and the network map payload that entity_profile_table groups.

Status

Built and published. No demo.

Source

• micyte/tools/director.py: the declaration and both configurations
• micyte/tools/profile_admin_edit_viewer.py, micyte/tools/registrar_profile_types.py, micyte/tools/onboarding.py, micyte/tools/entity_profile_table.py
• micyte/domains/registry/directory.py: CARD_DOCUMENT, PROFILE_DOCUMENTS, entity_classes, kind_of, ADMIN_SUBTYPE_OF_JURISDICTION, row_profile_type, is_placeholder_msn, is_self_title_row
• micyte/tools/_declared_hub.py: AppDeclaration, AppVariant, Family, and the Channel tab every declared app draws for the channels it governs
• micyte/channels/preview.py: channels_governed_by, channel_preview
• micyte/tools/_packages.py: _director_package