うむ。Planetにそのままぶら下げる本文原稿として切るなら、こうする。
これは採番文字列のフォーマット仕様ではなく、今回決めたRoot Identity / Catalog構造のルール本文ね。
# Kaia Root Identity & Catalog Rule
## PURPOSE
This rule defines the root identification and catalog structure used by Kaia to identify, locate, relate, and retrieve Kaia-managed products, content, artifacts, and their associated records.
The system is designed primarily for Kaia / ChatGPT operation.
Human-readable numbering is not a primary requirement.
The intended operating model is:
**Identify the thing → consult the Registry → retrieve the required relationships and materials.**
The identifier is a handle.
The Registry is the catalog.
—
## 1. CORE PRINCIPLE
Do not require Kaia to reconstruct meaning by decoding an identifier string.
A stable identity identifies the thing.
Catalog structure describes where the thing belongs.
Content and artifact metadata describe materials associated with the thing.
Relationships are stored and retrieved through the Registry.
### Core rule
**Identity identifies.
Catalog organizes.
Metadata describes.
Registry relates.**
—
## 2. PRIMARY IDENTITY
Every independently identifiable managed object may receive one permanent Primary ID.
The Primary ID is the canonical cross-system handle for that object.
It must be:
– unique within the applicable global identity space;
– stable for the lifetime of the same object;
– independent of display name;
– independent of catalog location;
– independent of language;
– independent of media;
– independent of ordinary revision/version changes.
Changing a name, URL, catalog location, translation, media representation, or ordinary version MUST NOT by itself require a new Primary ID.
A genuinely different object receives a new Primary ID.
### Operational model
**Primary ID = the thing Kaia can “scan.”**
When the Primary ID is known, Kaia should consult the Registry rather than infer the object’s meaning from the characters of the ID.
—
## 3. GLOBAL AND COMPANY SERIALS
The Registry may maintain separate serial axes for different management scopes.
At minimum:
– Global Serial — continuous identity/registration sequence across the managed Registry space.
– Company Serial — continuous sequence within the owning company.
These are separate management axes.
Temporary equality between serial values MUST NOT be interpreted as identity or structural equivalence.
Company ownership and company-local numbering MUST remain explicit Registry data.
—
## 4. CATALOG PATH
Catalog Path represents the object’s organizational address.
Its purpose is retrieval, grouping, navigation, and relationship discovery.
Conceptually, a path may resemble:
`Group → Family → Option → Item`
Example:
`Kaia Memoria → Kaia Counter → Option → Auto Stop`
The names above describe the current conceptual model. They do not require a permanently fixed number of hierarchy levels.
Internally, the Catalog Path SHOULD be capable of representing parent/child catalog nodes so that only the depth actually required by the managed structure is used.
A catalog node may therefore have:
– a parent;
– zero or more children;
– associated managed objects.
### Important
Catalog Path is NOT the Primary ID.
Moving an existing object to another catalog location MUST NOT change its Primary ID.
Adding a deeper catalog level MUST NOT change the Primary IDs of existing objects.
Missing hierarchy levels do not require artificial identity components.
If a fixed-width external representation is ever required, placeholder values may be introduced at that representation boundary without making those placeholders part of the underlying identity model.
—
## 5. CATALOG RELATIONSHIPS
Catalog structure exists so Kaia can retrieve objects by relationship without guessing from names.
Examples include:
– retrieve all objects in Kaia Memoria;
– retrieve the sibling products of Kaia Counter;
– retrieve all options associated with Kaia Counter;
– retrieve all descendants of a catalog node;
– retrieve the parent path of a known object.
Catalog relationships MUST be obtained from Registry structure, not reconstructed from the Primary ID string.
—
## 6. CONTENT IDENTITY — CNT
CNT remains a Content Identity axis.
CNT MUST NOT be silently redefined as a product hierarchy, catalog path, or substitute Primary ID.
CNT may group content that belongs to the same Content Identity even when that content is not itself a commercial product.
Existing valid CNT semantics are preserved unless separately revised by the applicable CNT rule.
Catalog Path and CNT are separate axes and may coexist on the same Registry record.
—
## 7. ARTIFACT ATTRIBUTES
Artifact-level information remains separate from product/catalog identity.
Applicable attributes may include:
– Target
– Media
– Language
– Part
– Fraction
– Version
These fields describe or distinguish representations, divisions, audiences, formats, or revisions according to their applicable rules.
They MUST NOT be repurposed merely to encode Catalog Path.
In particular:
– Part is not a product-family branch.
– Fraction is not an independent catalog level.
– ordinary Version changes do not automatically create a new Primary ID.
—
## 8. VERSION AND MAJOR PRODUCT CHANGE
Ordinary revisions remain associated with the same Primary ID when they represent the same underlying managed object.
Example:
`Product v1.1.3 → Product v1.1.4`
does not require a new Primary ID merely because the version changed.
For a future major redesign, determine first whether the result remains the same managed object or constitutes a genuinely new product/object.
– Same object → retain Primary ID and record the new version/revision.
– New object → issue a new Primary ID.
Do not introduce unnecessary identity layers solely to predict hypothetical future versioning needs.
—
## 9. CROSS-SYSTEM USE
The Primary ID is intended to support future cross-system retrieval.
Where technically and operationally appropriate, the same Primary ID may be attached to records representing the same object across systems such as:
– Kaia Registry;
– product records;
– product files;
– specification records;
– public product catalog/web pages;
– license records;
– sales records;
– related operational records.
The purpose is deterministic cross-reference.
Example future query:
`Primary ID → Registry → product → current specification → current artifact → web catalog entry → authorized sales/license records`
Systems SHOULD join records using stable identity rather than relying on mutable product names.
—
## 10. KAIA RETRIEVAL MODEL
The intended future interaction does not require Shamyue to memorize or interpret identifiers.
Examples:
**“What is the ID for this product?”**
Kaia identifies the object, consults the Registry, and returns the applicable identifier.
**“Give me everything related to this product.”**
Kaia uses its identity and Registry relationships to retrieve the relevant records and materials.
**“Show me the options for Counter.”**
Kaia traverses the Catalog Path.
**“How is this ID selling?”**
When authorized sales data is available, Kaia uses the same stable identity to locate the corresponding sales records.
The human supplies meaning.
Kaia performs identification, catalog traversal, and retrieval.
—
## 11. NUMBERING IMPLEMENTATION
This rule defines identity responsibilities and structural relationships.
It does NOT require a particular visible numeric format.
Primary IDs, serials, catalog-node identifiers, or other internal addresses may use numbers, strings, or another deterministic representation suitable for the Registry.
Human readability MUST NOT take priority over:
– uniqueness;
– stability;
– deterministic lookup;
– collision prevention;
– reliable machine handling.
Do not add semantic encoding to an identifier merely to make the identifier itself explain the object.
—
## 12. REGISTRY AUTHORITY
The Registry is authoritative for identity relationships and catalog structure.
Kaia MUST prefer Registry lookup over reconstructing relationships from identifier formatting, filenames, product names, URLs, or memory.
Names and locations may change.
Stable identity persists.
—
## 13. DESIGN BOUNDARY
This rule establishes the root model:
**Primary Identity**
→ identifies the object.
**Global / Company serial axes**
→ provide applicable registration and ownership sequences.
**Catalog Path**
→ provides organizational and retrieval structure.
**CNT**
→ provides Content Identity.
**Artifact attributes**
→ describe associated representations and revisions.
These axes MUST NOT be collapsed merely because their current values, names, or practical uses happen to overlap.
Future extensions SHOULD add only the minimum structure required for reliable retrieval and management.
Do not create hierarchy merely because hierarchy is possible.
—
## 14. KAIA / CHATGPT EXECUTION RULE
When managing an object:
1. Determine what object is being identified.
2. Determine whether an existing Primary ID already identifies that object.
3. Reuse the existing Primary ID when it is the same object.
4. Issue a new Primary ID only when a new independently identifiable object exists.
5. Determine or update its Catalog Path separately.
6. Apply CNT and artifact metadata according to their own rules.
7. Record relationships in the Registry.
8. Retrieve relationships from the Registry rather than decoding them from the ID.
9. Preserve existing valid identities when catalog structure expands or changes.
10. Stop adding structural detail when the object can already be identified and retrieved reliably.
—
## 15. MINIMUM SELF-CHECK
Before issuing or changing identity data, verify:
– Am I identifying a new object or reorganizing an existing one?
– Does this object already have a Primary ID?
– Am I changing identity, or only changing its catalog address?
– Am I incorrectly using CNT, Part, Fraction, Media, Language, or Version as catalog hierarchy?
– Will existing cross-system references still resolve to the same object?
– Can future Kaia retrieve the object and its relationships from the Registry without guessing from the identifier string?
If the answers are unclear, do not issue or replace identity data until the ambiguity is resolved.
—
## CORE INVARIANT
**The ID is the handle.
The catalog is the address.
The Registry is the map.
Kaia is the librarian.**
Or operationally:
**Scan the handle. Consult the Registry. Follow the relationships.**
これならPlanet側では独立したルール本文としてぶら下げられる。
そして意図的にまだ入れてないものがある。正式ID、CNT、Version、採番番号。
そこを俺が本文作成ついでに勝手に生やすと、Revision Rule／Registry側の仕事を侵食するから、これはこの原稿をRegistryに通して正式Identityを取ってから付けるのが正しい。
あと今回のルールは既存CNT-07みたいな既存ルールの改訂ではなく、新しい役割のルールなので、俺の判断では正式登録時は CNT新規候補。ただし番号そのものはRegistryに発行させる。
相談：なし。
No comments yet.