Meta-Object Ownership & Stewardship

Findings

Catalogue-native findings must describe the information grouped by each layer. This legacy version does not declare them separately.

Questions & artifacts

Questions, artifact requirements and serial naming rules are required by Vercy vNext; they remain unassigned in this reference version.

Dimension & namespace

• REFERENCE `world.accessContract` (S2): every access grant must resolve its grantor against a live ownership record here.
• REFERENCE `world.accessAudit` (S4): reads of ownership data and all registry changes are logged there.
• REFERENCE `world.person` (H1): holders, wards, guardians and delegates are natural persons defined in the person model.
• REFERENCE `world.organization` (O1): organizations appear as holders and stewards; their identity and lifecycle live in their own model.
• REFERENCE `world.disputeResolution` (A19): disputed titles and contested successions are resolved by the courts model; outcomes flow back as transfer or annulment events.
• imports: iso-19152-ladm (ALIGN): the party, right, restriction and responsibility pattern that tenure and shares follow.
• imports: mu-core (EXTEND): the meta-object identity primitive that every registry entry anchors to.

Canon, patches & standards

• REFERENCE `world.accessContract` (S2): every access grant must resolve its grantor against a live ownership record here.
• REFERENCE `world.accessAudit` (S4): reads of ownership data and all registry changes are logged there.
• REFERENCE `world.person` (H1): holders, wards, guardians and delegates are natural persons defined in the person model.
• REFERENCE `world.organization` (O1): organizations appear as holders and stewards; their identity and lifecycle live in their own model.
• REFERENCE `world.disputeResolution` (A19): disputed titles and contested successions are resolved by the courts model; outcomes flow back as transfer or annulment events.
• imports: iso-19152-ladm (ALIGN): the party, right, restriction and responsibility pattern that tenure and shares follow.
• imports: mu-core (EXTEND): the meta-object identity primitive that every registry entry anchors to.

Artifact formats & serial data

Format-independent core. Concrete artifact formats and naming prefixes are not declared in this legacy version.

Policies & accepted processes

• `titleExtract`: a third party reads the current holder of a named object, without history or shares.
• `mandateVerification`: a counterparty checks that a delegate's claimed powers exist, are in scope and are unrevoked before honoring an act.
• `transferWatch`: a subscriber receives transfer events for named objects, typically a creditor or counterparty with a legitimate interest.

Read / add / edit / delete

CRUD procedures and interface bindings are not declared in this legacy version.

Ownership, roles & access

A root registrar archetype keeps this model as the constitutional register of control; recording here is what makes a party the grantor of record for everything else. Access to ownership data itself is granted by each object's holder through S1/S2 contracts, and every read is logged in S4.

Objects

• `registryEntry`: the anchor record that makes an object controllable at all; key attributes: object reference, object kind, registration basis, registered time.
• `ownershipRecord`: the current binding of one or more holders to a registry entry; key attributes: holder references, basis of title, effective from, encumbrances.
• `holdingShare`: one party's fraction of a jointly held object; key attributes: holder, fraction, joint or several, since.
• `steward`: a party charged with operating an object on the holder's behalf without beneficial ownership; key attributes: appointment basis, duty list, term, accountability route.
• `delegationMandate`: a scoped, revocable grant of specific control powers from a holder to a delegate; key attributes: powers, scope, expiry, revocability, sub-delegation flag.
• `guardianshipArrangement`: a substitute-decision arrangement for a holder lacking capacity; key attributes: ward, guardian, legal basis, review date.
• `transferInstrument`: the instrument by which control moves; key attributes: parties, consideration, conditions precedent, execution time.

Relationships

• `ownershipRecord` -> covers -> `registryEntry` (1..1): every title binds holders to exactly one registered object.
• `holdingShare` -> dividedFrom -> `ownershipRecord` (*..1): shares partition one title among co-holders.
• `delegationMandate` -> issuedUnder -> `ownershipRecord` (*..1): delegated powers can never exceed the title they flow from.
• `delegationMandate` -> vestsIn -> `steward` (*..1): the mandate names the party who may act.
• `guardianshipArrangement` -> exercises -> `ownershipRecord` (1..*): the guardian exercises the ward's holdings within the arrangement's basis.
• `transferInstrument` -> conveys -> `ownershipRecord` (1..*): a transfer rewrites which holders a title binds.
• `transferInstrument` -> authorizedBy -> `guardianshipArrangement` (0..1): transfers for wards require the arrangement's authority.

Events

• `objectRegistered`: a meta-object received its registry entry and became controllable.
• `ownershipTransferred`: control of an object passed to a new holder under an executed instrument.
• `shareRestructured`: the fractions or parties of a joint holding changed.
• `mandateGranted`: a holder delegated defined powers to a delegate.
• `mandateRevoked`: a previously granted delegation was withdrawn or expired.
• `stewardAppointed`: a steward took charge of an object under stated duties.
• `guardianshipEstablished`: a guardian was empowered to act for a holder lacking capacity.
• `successionOpened`: a holder's death, dissolution or lapse started the transfer of their holdings.

Projections

• `currentHolderIndex`: object to present holder; omits history, shares, mandates and guardianships.
• `holderPortfolio`: everything one party holds or lawfully exercises; omits all other parties' holdings.
• `chainOfTitle`: the full transfer history of one object; omits the parties' unrelated holdings.