Source and version
- Repository path
.agents/skills/source-authority-mapping/SKILL.md- Source revision
341bceb719a28be760775b6322021d78abaa919b- Source SHA-256
706fdafe48f3b9d85533302a2cb6029aefea61364e818939ea152c0b79b386f5- Publication standing
- Public ready
Included source files
This skill has no additional files in its public source package.
Complete skill source
The Markdown below matches the exact source text. The format link above opens the file on its own.
---
name: source-authority-mapping
description: Traces a claim, artifact, or contract through semantic ownership, source location, projections, delivery routes, receiving use, and promotion. Applies when repositories, workspaces, mirrors, snapshots, or publication surfaces make authority and lineage difficult to distinguish.
---
# Source authority mapping
## Contract
- **What:** A portable method for making the authority and receiving path of a claim, artifact, or contract legible across several systems.
- **When:** Source, semantic ownership, schema or contract authority, publication, delivery, snapshotting, or downstream use could be mistaken for one another.
- **Boundaries:** The map records evidenced relations and granted decisions. It leaves private or gated material within its publication boundary, preserves existing licenses and history, and keeps delivery infrastructure separate from semantic ownership.
- **Result:** A concise lineage map that identifies the authoritative source, typed projections, current receiver, promotion boundary, and re-entry condition.
## Rules
### Rule: Begin with the material object
Name the claim, artifact, contract, schema, or package whose route changes a decision. Follow that object through its sources and receivers instead of beginning with a general inventory of platforms or organizations.
### Rule: Keep authority roles independent
Distinguish at least the roles that matter to the current route:
- semantic or meaning authority;
- authored source and exact location;
- schema or contract authority;
- publication authority;
- delivery operator or retrieval route;
- instance, snapshot, or package owner;
- receiving consumer or promotion steward.
One actor or repository may carry several roles. Shared custody remains explicit rather than collapsing the roles into a single owner label.
### Rule: Type each source-to-target relation
Use the smallest literal relation that describes the move: references, projects, snapshots, consumes, hands to, supersedes, mirrors, or another locally defined relation. A projection selects or reformats material while its source retains authority. A snapshot records accepted source coordinates. A handoff names a receiver and leaves acceptance visible.
### Rule: Separate identity from retrieval
A canonical identifier can remain stable while repository paths, branches, mirrors, hosts, or delivery environments change. Record where meaning is authored and where a current representation can be retrieved as separate facts.
### Rule: Carry promotion coordinates
When material crosses into a stable receiver, record the upstream repository or workspace, source path or identifier, accepted revision or observation date, relationship, and retained history or license. Reconcile meaning at promotion time so the receiver does not silently normalize a live source.
### Rule: Respect publication boundaries
Internal or collaboration-ready material can inform the receiving work within its granted scope. A public citation or distribution route points to a publication-ready source whose steward has accepted that role. Adaptation can create that receiver while lineage retains the gated source identity.
### Rule: Keep rest in the resolver
Deferral or rest describes the lineage decision rather than a visitor retrieval route. When a public surface already carries the useful explanation and a fitting public receiver has yet to form, remove the gated source from visitor retrieval, preserve its exact identity in the authorized resolver, and name the source, audience, evidence, or publication change that would reopen projection. The resolver keeps lineage recoverable after the visitor route retires.
### Rule: Resolve publication standing independently from ancestry
Treat Registry placement as one signal. Establish a visitor-ready receiver from the combination that matters to the route:
- ancestor placement and named steward;
- explicit band, projection standing, or publication state;
- body-level source-band, house-annotation, draft, nursery, or private-lineage signals;
- the intended visitor retrieval route; and
- definition equivalence when titles, aliases, or acronyms collide.
Translate portable internal apparatus into ordinary reader-facing structure before routing visitors to the page. Preserve the original apparatus in its authorized lineage surface. Exact-title matching supports discovery; the receiver still has to carry the same construct and reader job.
### Rule: Let reader jobs determine receiver topology
Choose overview, stable section, sibling record, or child surface from the distinctions a reader must retrieve rather than the number of working sources. Reuse an existing public orientation when it already owns the conceptual move. Form a sibling receiver for a distinct operational job. Keep claims together as stable sections when they share authority, currentness, audience, and re-entry; form children when each distinction needs independent identity, standing, retrieval, or lifecycle.
### Rule: Let use earn synchronization
A reviewed snapshot or explicit handoff is sufficient for a bounded promotion. Repeated material drift can later earn continuous mirroring, automated reconciliation, or a stronger shared contract. Semantic ownership remains with the named source until a steward accepts a different relationship.
### Rule: End at a receiving decision
The map supports a concrete choice: keep the current source, change a link, adapt material for publication, accept a snapshot, establish a mirror, defer promotion, or return a question to the steward. Detailed lineage remains proportional to that receiving decision.
## Operating sequence
1. **Name the object and decision:** State what is moving and what the map should make decidable.
2. **Locate current authority:** Read the nearest authoritative source and record its exact location, ancestry, body-level standing signals, visitor route, and relevant publication boundary.
3. **Trace typed relations:** Follow only the projections, snapshots, mirrors, handoffs, and consumers that affect the decision.
4. **Resolve role differences:** Make semantic, schema, publication, delivery, instance, and receiving authority distinct where they diverge.
5. **Inspect the receiver:** Confirm what the destination needs, what it accepts, and which source qualities must survive the move.
6. **Select the route:** Record the smallest promotion, link, adaptation, snapshot, deferral, or steward question that creates a legible result.
7. **Preserve re-entry:** Leave a source pointer, accepted coordinate, relation, evidence limit, and condition for renewed reconciliation.
## Representative scenarios
### Scenario: A private working page has a public counterpart
- Given a visitor-facing page cites a private working source
- And a reviewed public registry page already carries the same cognitive move
- When the citation route is reconciled
- Then the visitor page points to the public receiver
- And the working source remains in the internal lineage record with any uncovered claims marked for adaptation
### Scenario: A repository consumes an accepted snapshot
- Given a standalone repository retains source and release authority
- And an integrated package accepts one revision for coordinated use
- When the snapshot is promoted
- Then its nearest orientation records repository, source path, revision, relationship, and retained history or license
- And later drift reopens reconciliation without changing the source owner
### Scenario: Working sources resolve into complementary public surfaces
- Given several working sources contribute to one public family
- And an existing public page already carries the conceptual orientation
- When the remaining material serves one distinct operational reader job
- Then preserve the existing orientation and form one sibling operational receiver with stable sections
- And keep working-source aliases as discovery and lineage aids rather than additional visitor surfaces
### Scenario: A Registry-situated page still carries internal signals
- Given a candidate receiver sits inside a public-oriented Registry
- And its body still declares an internal band, house annotation, draft apparatus, private nursery lineage, or a colliding definition
- When publication standing is resolved
- Then treat ancestry as evidence of intended placement rather than the complete publication receipt
- And either translate the internal apparatus into a clean reader-facing page or form a fitting projection while the private resolver retains exact lineage
### Scenario: A local explanation carries the visitor job while projection rests
- Given a visitor surface already carries the useful construct, evidence boundary, and onward route
- And the cited working source remains private while the next public receiver is still forming or would repeat the same reader job
- When the route is reconciled
- Then remove the gated locator from visitor retrieval and keep the explanation local
- And preserve exact lineage plus a material re-entry condition in the authorized resolver
## Completion
The map is ready when another collaborator can identify which source defines meaning, locate the current representation, understand every decision-changing projection or handoff, see who may publish or accept the result, and return to the exact point where renewed reconciliation would begin.