b905b6bbb0
- Introduced `refer_to` slot to link identifiers to entities, with ontology alignment to CIDOC-CRM and DCTerms. - Added `remove` slot for recording objects removed during deaccessioning, aligned with CIDOC-CRM properties. - Created `reported_on` slot to capture URIs of reports documenting entities, with mappings to CIDOC-CRM and Schema.org. - Implemented `signed_by` slot to identify individuals who signed documents, referencing RiC-O and Schema.org. - Established `specified_as` slot to indicate the precision level of place references, with broad mappings to CRM and DQV.
24 lines
1.2 KiB
Markdown
24 lines
1.2 KiB
Markdown
# Rule: No Autonomous Alias Assignment
|
|
|
|
**Status**: ACTIVE
|
|
**Created**: 2026-02-10
|
|
|
|
## Rule
|
|
|
|
The agent MUST NOT assign aliases to canonical slot files on its own. Only the user decides which `new/` slot files are absorbed as aliases into which canonical slots.
|
|
|
|
## Rationale
|
|
|
|
Alias assignment is a semantic decision that determines the conceptual scope of a canonical slot. Incorrect alias assignment conflates distinct concepts. For example, `membership_criteria` (eligibility rules for joining) is not an alias of `has_mission` (organizational purpose), even though both relate to organizational governance.
|
|
|
|
## What the agent MUST do
|
|
|
|
1. When creating or polishing a canonical slot file, leave the `aliases` field empty unless the user has explicitly specified which aliases to include.
|
|
2. When processing `new/` files, present candidates to the user and wait for their alias assignment decisions.
|
|
3. Do NOT delete `new/` files until the user confirms the alias mapping.
|
|
|
|
## What the agent MUST NOT do
|
|
|
|
- Autonomously decide that a `new/` file should become an alias of a canonical slot.
|
|
- Add alias entries without explicit user instruction.
|
|
- Delete `new/` files based on self-determined alias assignments.
|