HUTN: A User Guide to PAMoLa's Human-Usable Textual Notation

HUTN (Human-Usable Textual Notation) is PAMoLa's family of textual representations for ordia and clades. It is designed to be readable enough for people to author, inspect, review, and diff, while remaining precise enough for a HUTN ware to parse, emit, exchange, and round-trip PAMoLa content.

HUTN is not a separate modelling language with an independent model behind it. It is a textual projection of PAMoLa content. The same authoritative clade can therefore be displayed in several HUTN profiles without becoming several models.

This guide covers the PAMoLa / Ordium v1.0.0 vocabulary and uses four representative profiles:

• CHAS, normally the smallest and most convenient human-oriented form;
• FHAS, the current general-purpose workhorse;
• FHAN, the corresponding numeric-reference form; and
• FLUN, the fullest and most explicit form used here for audit and debugging.

Together these examples demonstrate both choices on every HUTN profile axis without reproducing all sixteen possible combinations.

1. The central idea

A PAMoLa model is a graph of first-class items called ordia. One distinguished relation, hasCustodian, supplies a tree-like locality and naming spine inside that graph. An ordium together with all its direct and indirect wards forms a clade.

A HUTN document renders a selected clade. It may expose custodianship through nesting or through explicit properties; it may write properties in a compact badge-specific form or as full key-value pairs; and it may identify referenced ordia by human-readable names or generated numeric labels. These are notation choices. They do not alter the underlying ordia.

A useful mental model is:

PAMoLa clade
  ├── ordia, identities, properties and references
  ├── HUTN profile choice
  └── textual projection
        ├── CHAS
        ├── FHAS
        ├── FHAN
        └── FLUN

2. Principles

2.1 One clade, many textual projections

The variant name says how a clade is rendered, not what kind of model it is. CHAS and FLUN may look very different, but they can denote the same ordia, custody structure, values, and non-custodial references.

2.2 The Core defines the vocabulary; the ware owns the notation

The protected v1.0.0 Core defines the fixed linguistic categories and universal properties. HUTN's punctuation, abbreviation, nesting, label generation, reference resolution, and pretty-printing belong to HUTN ware. This keeps a notation decision out of the Kernel Core and a storage decision out of the notation.

2.3 Custodianship gives locality, but PAMoLa is still a graph

Nesting can show wards compactly, but references such as hasDeclaredType, hasRelatum, hasTag, refersTo, and hasPredicate may point anywhere that the model permits. HUTN is therefore a notation for a graph with a distinguished custodial spine, not merely a tree format.

2.4 Omission is meaningful

PAMoLa uses sparse property storage and total optionality. An omitted property is not automatically an error.

• An absent Ordium-valued property means that no ordinary target is asserted.
• An absent data-valued property normally causes its declared virtual default to apply.
• Explicit undefined and explicit known-unknown are special values and are not the same as absence.
• § is the compact HUTN lexeme for explicit undefined. The quoted text "§" is simply a one-character string.

An abridged emitter may omit defaults and information recoverable from the selected profile or context. An unabridged emitter expands virtual defaults and identity information, but it must not invent a property edge that is genuinely absent.

2.5 Identity and names are different

Every ordium may be referred to at several levels:

Form	Meaning	Stability
PID	Persistent lifetime identity	Stable across renaming, re-custody, serialisation, and backend migration
FQN	Name derived from the current custodian path	Unique in a well-formed current state, but changes when name or custody changes
SUN	Shortest unique symbolic reference in the current HUTN context	Context-dependent
Numeric label	Generated document-local label such as EN8 or PA2	Local to one serialisation

A numeric label is not an ordium's hasName, FQN, or PID.

2.6 Textual order is not automatically model order

The property follows is a general sequencing pointer. It is not an implicit ward-ordering relation. Indentation or the order of records in a file must not silently create follows facts unless the selected profile explicitly defines such an encoding for that context. Use follows only when the model actually asserts a sequence.

2.7 A HUTN profile is part of the parsing contract

A parser must know—or reliably infer—the selected profile, root context, imports, and reference-resolution environment. Round-trip behaviour is therefore a property of the HUTN text plus its profile and context, not of character strings in isolation.

3. The four profile axes

A HUTN profile name selects one pole on four independent axes:

[Compact / Full]
[Hierarchical / Linear]
[Abridged / Unabridged]
[SUN / Numeric]

The four-letter acronym uses one letter from each row, in that order.

Axis	First choice	Second choice
Representation	Compact: badge-specific signatures and notation sugar	Full: named key-value properties
Custodianship	Hierarchical: nesting expresses custody	Linear: records are separate and hasCustodian is explicit
Defaults/detail	Abridged: selected defaults and reconstructible detail are omitted	Unabridged: virtual defaults, identities, and diagnostic detail are exposed
References	SUN: shortest unique symbolic references	Numeric: generated labels such as EN3 and PA2

Examples:

• FHAS = Full, Hierarchical, Abridged, SUN.
• CHAS = Compact, Hierarchical, Abridged, SUN.
• FHAN = Full, Hierarchical, Abridged, Numeric.
• FLUN = Full, Linear, Unabridged, Numeric.

3.1 Curated profiles used in this guide

Profile	Main use	Relative size	What it demonstrates
CHAS	Human authoring, examples, reviews	Usually smallest	Compact syntax
FHAS	General exchange, fixtures, current PAMoLa work	Medium	Full property syntax with readable references
FHAN	Generated fixtures, ambiguous names, exact local cross-reference	Medium	Numeric references
FLUN	Audit, debugging, conformance, migration	Largest	Linear custody and unabridged detail

Axis	First pole demonstrated by	Second pole demonstrated by
Compact / Full	CHAS	FHAS, FHAN, FLUN
Hierarchical / Linear	CHAS, FHAS, FHAN	FLUN
Abridged / Unabridged	CHAS, FHAS, FHAN	FLUN
SUN / Numeric	CHAS, FHAS	FHAN, FLUN

4. Basic syntax

4.1 Badges

Each rendered ordium begins with a short badge or with a numeric label whose prefix is that badge. In SUN mode, for example:

EN {hasName "Person"}
PA {hasName "customer", hasRelatum Person}

In numeric mode, the same records may begin EN7 and PA1.

Badge	Core category	Main purpose
OM	Ordium	Bootstrap/Core ordium form
EN	Entity	Identity-bearing clabject, including domain types and individuals
RE	Relationship	A connection as a first-class clabject
PA	Participation	A relationship end, role, multiplicity, or access path
CA	Categorisation	A categorisation or generalisation-set structure
IC	Intercalation	A general or special side of a categorisation
AT	Attribute	A data-valued feature or value-bearing moment
ME	Method	An immanent behavioural feature
DT	DataType	A datatype and its value space
DV	DataValue	A typed value, profile value, or tuple component
LI	Literal	A lexical form denoting a value
MK	Marker	A typed annotation, profile adornment, or auxiliary marker
AF	Artifact	A reference to an external artefact
OP	Operation	A reusable callable or rule-bearing operation
PM	Parameter	A formal parameter or rule variable
AG	Argument	An occurrence that binds or fills a parameter
AO	Atom	A predicate application in rule content
IN	Invocation	A static call or invocation description
AC	Action	A runtime or requested action occurrence

The six abstract Core categories—ImmanentOrdium, TranscendentOrdium, BehaviouralOrdium, Clabject, Mediation, and Moment—are normally derived classifications rather than ordinary concrete HUTN badges.

4.2 Full records

Full HUTN writes property names explicitly:

EN {hasName "Person", hasPotency 1, hasDeclaredType O0.OwnerType}

Commas separate properties and nested ward records.

4.3 Compact records

Compact HUTN uses badge-specific signatures:

EN Person : O0.OwnerType ^1 {
  AT name : String {durability=1, mutability=1}
}

The colon expresses declared type, ^1 expresses potency, and the attribute signature abbreviates hasName, hasDataType, hasValue, hasDurability, and hasMutability.

Compact syntax is defined by the profile. It should not be guessed by deleting property names from a full record.

4.4 Hierarchical and linear custody

A hierarchical record uses nesting:

EN {hasName "O1",
  EN {hasName "Person"}
}

A linear record makes custody explicit:

EN5 {hasName "O1", hasCustodian EN1}
EN7 {hasName "Person", hasCustodian EN5}

The two forms express the same custodian edge.

4.5 Strings, scalar values, and references

HUTN parsing is type-directed.

hasName "Person"                 // string-valued property
hasDeclaredType O0.OwnerType     // Ordium-valued reference
hasPotency 2                     // integer-valued property
hasValue 2000-01-01              // Date value in a Date-typed slot
hasUpperBound unlimited          // Multiplicity value

Quoted text denotes a string. An unquoted token in an Ordium-valued slot is resolved as an ordium reference. An unquoted token in a data-valued slot is interpreted according to the property's or attribute's datatype.

4.6 SUN resolution

A SUN is the shortest symbolic form that uniquely resolves in the selected rendering context. For example, AccountType may suffice locally, while O0.AccountType may be needed from another level container.

A resolver may use:

• the local symbol table;
• the current clade and custodian path;
• an FQN;
• a PID;
• an import mapping; or
• a shortest unique path.

SUNs improve readability without replacing persistent identity.

4.7 Names

For ordinary v1.0.0 ordia, hasName follows:

^[A-Za-z][A-Za-z0-9_-]*$

Names begin with a letter and may contain letters, digits, _, and -. . is reserved for FQN/path syntax, : is notation syntax, and § is not part of an ordinary name. DataValue names are the exception because their names may be lexical values such as 0, 1, or *.

5. Running AccountModel Example

The same deliberately small multilevel account model is used in all four renderings.

This is a visual rendering of the AccountModel clase shown below.

AccountModel
├── O0
│   ├── AccountType²
│   └── OwnerType²
├── O1
│   ├── Account⁰
│   │   └── balanceInCents : Integer
│   ├── Person¹ : OwnerType
│   │   └── name : String
│   ├── CheckingAccount¹ : AccountType
│   ├── SavingsAccount¹ : AccountType
│   ├── AccountKinds
│   │   ├── general → Account
│   │   ├── special → CheckingAccount
│   │   └── special → SavingsAccount
│   └── holds¹
│       ├── customer → Person [1..1]
│       └── account  → Account [1..*]
└── O2
    ├── CA776 : CheckingAccount
    │   └── balanceInCents = 200000
    ├── Customer_1 : Person
    │   └── name = "Alex Morgan"
    └── holds1 : holds
        ├── customer → Customer_1
        └── account  → CA776

The O0, O1, and O2 ordia are ordinary organisational entities. They make the ontological strata easy to see, but they are not separate technical metamodel layers.

6. CHAS — the smallest everyday form

CHAS is compact, hierarchical, abridged, and SUN-based. It is generally the shortest useful rendering for a clade-shaped domain model and is well suited to tutorials, reviews, and human authoring.

In this compact profile, the presence of navigable marks the navigable relationship end. Its omission on customer renders the non-navigable case. This is a compact notation convention; the authoritative substrate value remains isNavigableTo false.

// PAMoLa / Ordium v1.0.0
// AccountModel in CHAS: Compact, Hierarchical, Abridged, SUN references.

EN AccountModel {
  EN O0 {
    EN AccountType ^2
    EN OwnerType ^2
  }

  EN O1 {
    EN Account ^0 {
      AT balanceInCents : Integer = 0 {durability=1, mutability=1}
    }

    EN Person : O0.OwnerType ^1 {
      AT name : String {durability=1, mutability=1}
    }

    EN CheckingAccount : O0.AccountType ^1
    EN SavingsAccount : O0.AccountType ^1

    CA AccountKinds {
      isComplete false
      isDisjoint true
      IC generalAccount {isGeneralisation true; hasRelatum Account}
      IC checking {hasRelatum CheckingAccount}
      IC savings {hasRelatum SavingsAccount}
    }

    RE holds ^1 {
      PA customer {hasRelatum Person; [1..1]}
      PA account {hasRelatum Account; [1..*]; navigable}
    }
  }

  EN O2 {
    EN CA776 : O1.CheckingAccount {
      AT balanceInCents : Integer = 200000
    }

    EN Customer_1 : O1.Person {
      AT name : String = "Alex Morgan"
    }

    RE holds1 : O1.holds {
      PA customer {hasRelatum Customer_1}
      PA account {hasRelatum CA776}
    }
  }
}

7. FHAS — the current workhorse

FHAS is full, hierarchical, abridged, and SUN-based. It keeps the custodian tree visible while exposing Core property names. It is the most widely used current profile for fixtures, examples, exchange, and inspection.

// PAMoLa / Ordium v1.0.0
// AccountModel in FHAS: Full, Hierarchical, Abridged, SUN references.
// String-valued properties are quoted; Ordium-valued references are unquoted.

EN {hasName "AccountModel", hasNote "Running example for the PAMoLa HUTN user guide",
  EN {hasName "O0",
    EN {hasName "AccountType", hasPotency 2},
    EN {hasName "OwnerType", hasPotency 2}
  },
  EN {hasName "O1",
    EN {hasName "Account", hasPotency 0,
      AT {hasName "balanceInCents", hasDurability 1, hasMutability 1, hasDataType Integer, hasValue 0}
    },
    EN {hasName "Person", hasPotency 1, hasDeclaredType O0.OwnerType,
      AT {hasName "name", hasDurability 1, hasMutability 1, hasDataType String}
    },
    EN {hasName "CheckingAccount", hasPotency 1, hasDeclaredType O0.AccountType},
    EN {hasName "SavingsAccount", hasPotency 1, hasDeclaredType O0.AccountType},
    CA {hasName "AccountKinds", isComplete false, isDisjoint true,
      IC {hasName "generalAccount", isGeneralisation true, hasRelatum Account},
      IC {hasName "checking", isGeneralisation false, hasRelatum CheckingAccount},
      IC {hasName "savings", isGeneralisation false, hasRelatum SavingsAccount}
    },
    RE {hasName "holds", hasPotency 1, hasAssociationName "holds",
      PA {hasName "customer", hasRoleName "customer", hasLowerBound 1, hasUpperBound 1, isNavigableTo false, hasRelatum Person},
      PA {hasName "account", hasRoleName "account", hasLowerBound 1, hasUpperBound unlimited, isNavigableTo true, hasRelatum Account}
    }
  },
  EN {hasName "O2",
    EN {hasName "CA776", hasPotency 0, hasDeclaredType O1.CheckingAccount,
      AT {hasName "balanceInCents", hasDurability 0, hasMutability 0, hasDataType Integer, hasValue 200000}
    },
    EN {hasName "Customer_1", hasPotency 0, hasDeclaredType O1.Person,
      AT {hasName "name", hasDurability 0, hasMutability 0, hasDataType String, hasValue "Alex Morgan"}
    },
    RE {hasName "holds1", hasPotency 0, hasDeclaredType O1.holds,
      PA {hasName "customer", hasRoleName "customer", hasRelatum Customer_1},
      PA {hasName "account", hasRoleName "account", hasRelatum CA776}
    }
  }
}

8. FHAN — full syntax with numeric references

FHAN differs from FHAS only in the final axis. The generated labels make every in-document reference unambiguous even when several ordia have the same local name. They are particularly useful in generated fixtures and low-context interchange.

External Core, datatype, and profile references may remain imported symbolic references because they are not ordia declared by this document.

// PAMoLa / Ordium v1.0.0
// AccountModel in FHAN: Full, Hierarchical, Abridged, Numeric references.
// Numeric labels are local to this serialisation; they are not PIDs or hasName values.

EN1 {hasName "AccountModel", hasNote "Running example for the PAMoLa HUTN user guide",
  EN2 {hasName "O0",
    EN3 {hasName "AccountType", hasPotency 2},
    EN4 {hasName "OwnerType", hasPotency 2}
  },
  EN5 {hasName "O1",
    EN6 {hasName "Account", hasPotency 0,
      AT1 {hasName "balanceInCents", hasDurability 1, hasMutability 1, hasDataType Integer, hasValue 0}
    },
    EN7 {hasName "Person", hasPotency 1, hasDeclaredType EN4,
      AT2 {hasName "name", hasDurability 1, hasMutability 1, hasDataType String}
    },
    EN8 {hasName "CheckingAccount", hasPotency 1, hasDeclaredType EN3},
    EN9 {hasName "SavingsAccount", hasPotency 1, hasDeclaredType EN3},
    CA1 {hasName "AccountKinds", isComplete false, isDisjoint true,
      IC1 {hasName "generalAccount", isGeneralisation true, hasRelatum EN6},
      IC2 {hasName "checking", isGeneralisation false, hasRelatum EN8},
      IC3 {hasName "savings", isGeneralisation false, hasRelatum EN9}
    },
    RE1 {hasName "holds", hasPotency 1, hasAssociationName "holds",
      PA1 {hasName "customer", hasRoleName "customer", hasLowerBound 1, hasUpperBound 1, isNavigableTo false, hasRelatum EN7},
      PA2 {hasName "account", hasRoleName "account", hasLowerBound 1, hasUpperBound unlimited, isNavigableTo true, hasRelatum EN6}
    }
  },
  EN10 {hasName "O2",
    EN11 {hasName "CA776", hasPotency 0, hasDeclaredType EN8,
      AT3 {hasName "balanceInCents", hasDurability 0, hasMutability 0, hasDataType Integer, hasValue 200000}
    },
    EN12 {hasName "Customer_1", hasPotency 0, hasDeclaredType EN7,
      AT4 {hasName "name", hasDurability 0, hasMutability 0, hasDataType String, hasValue "Alex Morgan"}
    },
    RE2 {hasName "holds1", hasPotency 0, hasDeclaredType RE1,
      PA3 {hasName "customer", hasRoleName "customer", hasRelatum EN12},
      PA4 {hasName "account", hasRoleName "account", hasRelatum EN11}
    }
  }
}

9. FLUN — the fullest diagnostic form

FLUN is full, linear, unabridged, and numeric. It is deliberately verbose. Custody is explicit, every ordium displays its tutorial PID and FQN, and virtual defaults such as potency zero, empty notes, Boolean defaults, multiplicity defaults, durability, and mutability are exposed.

The listing does not manufacture absent optional property facts. For example, an entity with no declared ontological type simply has no hasDeclaredType property. This distinction is required by PAMoLa's sparse-edge semantics.

The PIDs below are deterministic values generated for this guide. A real HUTN emitter must preserve the PIDs held by the source model rather than generate these tutorial values.

// PAMoLa / Ordium v1.0.0
// AccountModel in FLUN: Full, Linear, Unabridged, Numeric references.
// Custodianship is explicit. Virtual defaults and identity data are displayed.
// A genuinely absent optional property remains absent: this listing does not invent edges.
// Tutorial PIDs below are deterministic examples; a real emitter preserves model PIDs.

EN1 {
  hasName "AccountModel",
  hasPID pid:pamola:guide:1270f0b8-e8ac-5c93-a679-92a92d87e502,
  hasFQN Ordium.Domain.AccountModel,
  hasNote "Running example for the PAMoLa HUTN user guide",
  hasCustodian Ordium.Domain,
  hasLinguisticType Ordium.Core.Entity,
  hasPotency 0
}

EN2 {
  hasName "O0",
  hasPID pid:pamola:guide:aa916a51-6476-50d7-a07c-b0f5aeceb0af,
  hasFQN Ordium.Domain.AccountModel.O0,
  hasNote "",
  hasCustodian EN1,
  hasLinguisticType Ordium.Core.Entity,
  hasPotency 0
}

EN3 {
  hasName "AccountType",
  hasPID pid:pamola:guide:fdc1ef8e-cc74-5cad-9148-f5966a01f1d0,
  hasFQN Ordium.Domain.AccountModel.O0.AccountType,
  hasNote "",
  hasCustodian EN2,
  hasLinguisticType Ordium.Core.Entity,
  hasPotency 2
}

EN4 {
  hasName "OwnerType",
  hasPID pid:pamola:guide:884c7ed3-8fda-57d8-bcd7-bda3bd033e0a,
  hasFQN Ordium.Domain.AccountModel.O0.OwnerType,
  hasNote "",
  hasCustodian EN2,
  hasLinguisticType Ordium.Core.Entity,
  hasPotency 2
}

EN5 {
  hasName "O1",
  hasPID pid:pamola:guide:1f93b25e-c2e6-5cce-855e-61ae330e46ee,
  hasFQN Ordium.Domain.AccountModel.O1,
  hasNote "",
  hasCustodian EN1,
  hasLinguisticType Ordium.Core.Entity,
  hasPotency 0
}

EN6 {
  hasName "Account",
  hasPID pid:pamola:guide:e5714629-308e-5550-a012-4794544f29ee,
  hasFQN Ordium.Domain.AccountModel.O1.Account,
  hasNote "",
  hasCustodian EN5,
  hasLinguisticType Ordium.Core.Entity,
  hasPotency 0
}

AT1 {
  hasName "balanceInCents",
  hasPID pid:pamola:guide:32a45f42-ba8a-5369-91fd-8b345f03c0b2,
  hasFQN Ordium.Domain.AccountModel.O1.Account.balanceInCents,
  hasNote "",
  hasCustodian EN6,
  hasLinguisticType Ordium.Core.Attribute,
  hasDurability 1,
  hasMutability 1,
  hasDataType Integer,
  hasValue 0
}

EN7 {
  hasName "Person",
  hasPID pid:pamola:guide:f9572c9a-5735-58f2-93b8-61423d842ae7,
  hasFQN Ordium.Domain.AccountModel.O1.Person,
  hasNote "",
  hasCustodian EN5,
  hasLinguisticType Ordium.Core.Entity,
  hasPotency 1,
  hasDeclaredType EN4
}

AT2 {
  hasName "name",
  hasPID pid:pamola:guide:f03c4367-3f6f-52e4-8dc1-3c3b796e5e4f,
  hasFQN Ordium.Domain.AccountModel.O1.Person.name,
  hasNote "",
  hasCustodian EN7,
  hasLinguisticType Ordium.Core.Attribute,
  hasDurability 1,
  hasMutability 1,
  hasDataType String
}

EN8 {
  hasName "CheckingAccount",
  hasPID pid:pamola:guide:28636ae6-e61f-5308-8159-41d801df272a,
  hasFQN Ordium.Domain.AccountModel.O1.CheckingAccount,
  hasNote "",
  hasCustodian EN5,
  hasLinguisticType Ordium.Core.Entity,
  hasPotency 1,
  hasDeclaredType EN3
}

EN9 {
  hasName "SavingsAccount",
  hasPID pid:pamola:guide:25de3b67-e9d6-52fc-86cd-416b71131e70,
  hasFQN Ordium.Domain.AccountModel.O1.SavingsAccount,
  hasNote "",
  hasCustodian EN5,
  hasLinguisticType Ordium.Core.Entity,
  hasPotency 1,
  hasDeclaredType EN3
}

CA1 {
  hasName "AccountKinds",
  hasPID pid:pamola:guide:414deec5-88cd-543e-a56c-595865e90438,
  hasFQN Ordium.Domain.AccountModel.O1.AccountKinds,
  hasNote "",
  hasCustodian EN5,
  hasLinguisticType Ordium.Core.Categorisation,
  isComplete false,
  isDisjoint true
}

IC1 {
  hasName "generalAccount",
  hasPID pid:pamola:guide:0779c408-d942-5606-acfc-77e1dfaa7d34,
  hasFQN Ordium.Domain.AccountModel.O1.AccountKinds.generalAccount,
  hasNote "",
  hasCustodian CA1,
  hasLinguisticType Ordium.Core.Intercalation,
  isGeneralisation true,
  hasRelatum EN6
}

IC2 {
  hasName "checking",
  hasPID pid:pamola:guide:2caaf546-3876-598d-b9f8-3c5d0ae4a9c6,
  hasFQN Ordium.Domain.AccountModel.O1.AccountKinds.checking,
  hasNote "",
  hasCustodian CA1,
  hasLinguisticType Ordium.Core.Intercalation,
  isGeneralisation false,
  hasRelatum EN8
}

IC3 {
  hasName "savings",
  hasPID pid:pamola:guide:029c93a3-fb5f-5b02-938f-586bf6a8068c,
  hasFQN Ordium.Domain.AccountModel.O1.AccountKinds.savings,
  hasNote "",
  hasCustodian CA1,
  hasLinguisticType Ordium.Core.Intercalation,
  isGeneralisation false,
  hasRelatum EN9
}

RE1 {
  hasName "holds",
  hasPID pid:pamola:guide:1b575c09-864e-5603-b05e-e7157f37b288,
  hasFQN Ordium.Domain.AccountModel.O1.holds,
  hasNote "",
  hasCustodian EN5,
  hasLinguisticType Ordium.Core.Relationship,
  hasPotency 1,
  hasAssociationName "holds"
}

PA1 {
  hasName "customer",
  hasPID pid:pamola:guide:c1f601bc-8288-54bd-a631-d5dd6ee988e5,
  hasFQN Ordium.Domain.AccountModel.O1.holds.customer,
  hasNote "",
  hasCustodian RE1,
  hasLinguisticType Ordium.Core.Participation,
  hasRoleName "customer",
  hasLowerBound 1,
  hasUpperBound 1,
  isOrdered false,
  isUnique true,
  isNavigableTo false,
  hasRelatum EN7
}

PA2 {
  hasName "account",
  hasPID pid:pamola:guide:11228b1f-f611-5a83-bbb8-ef96607a3547,
  hasFQN Ordium.Domain.AccountModel.O1.holds.account,
  hasNote "",
  hasCustodian RE1,
  hasLinguisticType Ordium.Core.Participation,
  hasRoleName "account",
  hasLowerBound 1,
  hasUpperBound unlimited,
  isOrdered false,
  isUnique true,
  isNavigableTo true,
  hasRelatum EN6
}

EN10 {
  hasName "O2",
  hasPID pid:pamola:guide:d4fdff5c-385a-5947-9f03-eb1e8d223b77,
  hasFQN Ordium.Domain.AccountModel.O2,
  hasNote "",
  hasCustodian EN1,
  hasLinguisticType Ordium.Core.Entity,
  hasPotency 0
}

EN11 {
  hasName "CA776",
  hasPID pid:pamola:guide:886002e6-889f-53ee-9fd7-544623d34157,
  hasFQN Ordium.Domain.AccountModel.O2.CA776,
  hasNote "",
  hasCustodian EN10,
  hasLinguisticType Ordium.Core.Entity,
  hasPotency 0,
  hasDeclaredType EN8
}

AT3 {
  hasName "balanceInCents",
  hasPID pid:pamola:guide:095602d9-1eef-55a9-b55a-77b868675870,
  hasFQN Ordium.Domain.AccountModel.O2.CA776.balanceInCents,
  hasNote "",
  hasCustodian EN11,
  hasLinguisticType Ordium.Core.Attribute,
  hasDurability 0,
  hasMutability 0,
  hasDataType Integer,
  hasValue 200000
}

EN12 {
  hasName "Customer_1",
  hasPID pid:pamola:guide:a929f580-431d-536f-9f22-691cd6eb2cd6,
  hasFQN Ordium.Domain.AccountModel.O2.Customer_1,
  hasNote "",
  hasCustodian EN10,
  hasLinguisticType Ordium.Core.Entity,
  hasPotency 0,
  hasDeclaredType EN7
}

AT4 {
  hasName "name",
  hasPID pid:pamola:guide:821636ed-2d14-52bc-8e49-db26ba0cf118,
  hasFQN Ordium.Domain.AccountModel.O2.Customer_1.name,
  hasNote "",
  hasCustodian EN12,
  hasLinguisticType Ordium.Core.Attribute,
  hasDurability 0,
  hasMutability 0,
  hasDataType String,
  hasValue "Alex Morgan"
}

RE2 {
  hasName "holds1",
  hasPID pid:pamola:guide:dae1de70-732e-55ce-b8dc-bf2c71e32ab7,
  hasFQN Ordium.Domain.AccountModel.O2.holds1,
  hasNote "",
  hasCustodian EN10,
  hasLinguisticType Ordium.Core.Relationship,
  hasPotency 0,
  hasDeclaredType RE1
}

PA3 {
  hasName "customer",
  hasPID pid:pamola:guide:cd7450e6-0bab-5d84-9017-c5bf2ab4f107,
  hasFQN Ordium.Domain.AccountModel.O2.holds1.customer,
  hasNote "",
  hasCustodian RE2,
  hasLinguisticType Ordium.Core.Participation,
  hasRoleName "customer",
  hasLowerBound 0,
  hasUpperBound unlimited,
  isOrdered false,
  isUnique true,
  isNavigableTo true,
  hasRelatum EN12
}

PA4 {
  hasName "account",
  hasPID pid:pamola:guide:47cb9953-dcf2-52bb-9453-26c4a5261259,
  hasFQN Ordium.Domain.AccountModel.O2.holds1.account,
  hasNote "",
  hasCustodian RE2,
  hasLinguisticType Ordium.Core.Participation,
  hasRoleName "account",
  hasLowerBound 0,
  hasUpperBound unlimited,
  isOrdered false,
  isUnique true,
  isNavigableTo true,
  hasRelatum EN11
}

10. What changes—and what does not

Concern	CHAS	FHAS	FHAN	FLUN
Linguistic category	Badge	Badge	Numeric label prefix	Numeric label prefix plus explicit hasLinguisticType
Custody	Nesting	Nesting	Nesting	hasCustodian
Ordinary properties	Compact signatures	Explicit property names	Explicit property names	Explicit properties plus defaults/identity detail
Internal references	SUN	SUN	Numeric labels	Numeric labels
PID/FQN display	Usually omitted	Usually omitted	Usually omitted	Explicit
Underlying ordia	Same	Same	Same	Same

A profile should never change a domain fact merely to obtain a shorter or prettier rendering. A compact profile may encode the same fact through punctuation or a keyword; an abridged profile may omit a value that its profile reconstructs; and a numeric profile may replace a contextual name with a document-local label. These are representational transformations, not model transformations.

11. Choosing a profile

Use CHAS when people are the main readers and compact notation is familiar. Use FHAS as the default when clarity, explicit property names, and readable references matter. Use FHAN when generated labels make cross-references safer than contextual names. Use FLUN for debugging, conformance work, migrations, audits, and questions about the exact custody or effective default values.

A practical workflow is:

author or review in CHAS/FHAS
        ↓
parse to the authoritative PAMoLa clade
        ↓
emit FHAS for ordinary exchange
        ↓
emit FHAN or FLUN when diagnosing identity, custody, or resolution

12. Rules are HUTN content too

HUTN is not limited to class-diagram-like content. PAMoLa rules are represented by ordinary behavioural ordia—principally AO, PM, and AG—and can therefore be rendered in the same notation.

A small structural rendering of Clabject(X) :- Entity(X). is:

// Clabject(X) :- Entity(X).
AO {hasName "Clabject", hasPredicate Ordium.Core.Clabject,
  AG {hasName "headX", bindsTo X, fills X},
  AO {hasName "bodyEntity", hasPredicate Ordium.Core.Entity,
    AG {hasName "bodyX", bindsTo X, fills X}
  },
  PM {hasName "X", hasType Ordium}
}

A head atom may custody body atoms; a follows chain can order conjunctive body atoms; shared parameters connect argument occurrences. The same rule content can consequently be inspected as HUTN, exposed as facts about the rule structure, or compiled into executable rule form.

13. Round-trip expectations

A successful HUTN round trip preserves model identity and meaning, subject to the selected profile's declared canonicalisation rules.

• The parser must resolve every SUN or numeric label unambiguously.
• PIDs already present in the model must remain stable.
• FQNs must agree with the current name and custodian path.
• Abridgement must reconstruct only declared defaults or profile-defined sugar.
• Explicit unknown and undefined values must not be confused with absence.
• A HUTN ware may canonicalise scalar lexemes while preserving their typed value; exact byte preservation and exact value preservation are distinct guarantees.
• Unsupported or ambiguous input should fail loudly rather than produce a plausible but incorrect clade.

14. Reading older HUTN material

Pre-v1.0.0 documents remain useful didactically, but their badges, property names, and terminology must not be copied directly into current files.

Pre-v1.0.0 wording or construct	v1.0.0 form
Nested	Hierarchical
Flat	Linear
Non-abridged / explicit	Unabridged
Symbolic reference mode	SUN reference mode
CR / CN	CA / IC
participant or isConnectedTo	hasRelatum
hasType on an AT	hasDataType
IN used for an intercalation	IC; IN now denotes Invocation
followsInList	Removed; use follows only for an actually asserted sequence
isOfKind	Removed from the Core representation; use profiles/markers where such an interpretation is needed
§ embedded in names	Not permitted by the v1.0.0 name grammar
Unquoted string-valued hasName	Quote it, for example hasName "Person"

The current Core seed is authoritative whenever an old guide, paper, example, or implementation disagrees with v1.0.0.

15. Summary

HUTN is best understood as a family of textual projections over PAMoLa clades. Its four independent axes let a user choose between compactness and explicitness, nested and linear custody, abridged and diagnostic detail, and human-readable or generated references.

For most work:

• start with FHAS;
• choose CHAS when compact human authoring matters;
• choose FHAN when local numeric references are safer; and
• choose FLUN when nothing should remain implicit except genuinely absent facts.

The textual forms differ. The authoritative PAMoLa content does not.