domain-claims

Files (1)

• SKILL.md

SKILL.md (first lines)

# domain-claims — establish semantic standing before provenance

The governing rule is:

> Before a word becomes a canonical term, identify which domain has standing to
> claim the applicable sense and scope.

For compact handles, an additional rule applies:

> |∆|Acronyms identify; they do not define. Expansions are instance-resolved
> properties, not canonical identities, unless the claiming domain explicitly
> ratifies a fixed expansion as identity-bearing.|∆|

A domain claim does not own a word everywhere. It claims authority over one bounded
sense of that word inside a declared scope.

## Load this when

- A word is being promoted into canon, a theorem, a schema, an ontology, an encoding,
  a skill, a metric, a module field, or another structural control surface.
- A definition is being derived from conversation and will later authorize an
  implementation or encoding.
- The same surface word appears in several domains with different meanings.
- An acronym, initialism, symbol, or compact project handle is being expanded and the
  expansion could be mistaken for the handle's identity.
- A cross-domain import, specialization, translation, or shared term needs to be
  declared.
- An agent must decide whether provenance belongs to this sense of a word or to a
  different homonym.

## Do not load this when

- The user is choosing ordinary prose that will not become canon or structure.
- The task is only to provide a general-language dictionary meaning.
- A spelling, grammar, or style edit does not alter the governing sense of a term.
- The relevant domain claim has already been ratified and no collision or scope
  change is present.

## Zeroth-provenance doctrine

The semantic dependency order is:

```text
domain claim
  -> domain-bound definition
  -> conversational/source provenance
  -> ratification status
  -> canonical semantic record
  -> downstream encoding or implementation
```

Provenance may show where words were spoken or written. It cannot by itself establish
which domain had standing to define the operative sense.

Therefore:

- a definition without a domain claim is **unscoped**;
- provenance attached to an unscoped word is **lexically ambiguous**;
- an encoding based on an unresolved word is **not authorized**;
- a domain collision is a fail-closed boundary, not a cue to choose the most familiar
  meaning.

## Despecified handles

A **despecified handle** is a stable surface identifier whose identity is not exhausted
by, and does not require, one canonical lexical expansion. This is the default treatment
for The Interdependency's acronym-like semantic control surfaces unless a domain claim
explicitly ratifies a fixed expansion.

Despecified does not mean unspecified. Identity remains constrained by the resolved
term id, claiming domain, scope, relations, invariants, provenance, and current instance.
An expansion may improve legibility in one outward-facing artifact without becoming a
global definition.

For an acronym, initialism, symbol, or compact handle, extend the domain-claim record
when needed:

```yaml
handle:
  kind: acronym | initialism | symbol | compact-name
  identity_mode: despecified | fixed-expansion
  canonical_expansion: none | <ratified text> | hmmm
  instance_expansions:
    - text: <expansion used in this instance>
      scope: <artifact, audience, domain, or other bounded context>
      status: instance-definition | proposed | ratified | superseded
      provenance: <source or hmmm>
```

Rules:

- `despecified` means the handle can remain stable while instance expansions vary;
- an instance expansion is a property of that instance, not retroactive authority over
  every use of the handle;
- `fixed-expansion` requires explicit domain ratification; familiarity, search rank,
  historical usage, or lexical plausibility is insufficient;
- external acronym collisions do not redefine an internal handle; they remain separate
  domain claims and are tested only where scopes overlap;
- changing an expansion does not change identity unless the active domain claim makes
  that expansion identity-bearing;
- a handle whose relations, invariants, scope, and provenance cannot recover its
  operative identity is underspecified and remains `hmmm`.

## Domain-claim record

Before canonization or encoding, produce a record containing at least:

```yaml
surface_form: <word or phrase as used>
term_id: <stable domain-qualified identifier>
claiming_domain: <domain with standing over this sense>
claimed_sense: <the distinction the term names>
scope: <where this sense controls interpretation>
claim_type: native | borrowed | specialized | translated | shared | contested | provisional
authority_source: <canon, specification, ratified conversation, or hmmm>
status: proposed | provisional | ratified | contested | superseded
included_uses:
  - <use included by this claim>
excluded_uses:

From The-Interdependency/skill-lib, MPL-2.0.

More from The-Interdependency/skill-lib