---
type: Axis
title: visibility (share-scope axis)
description: The visibility/share-scope architecture axis — the default reach of a record to other principals (private → shared → public). A per-entity-with-default axis whose commitment surface is the persistent-data schema (the visibility column + the read-filter it forces). DEEP (RFC #75 5A.4 / P1 #851 → promoted 4.5.0a6 #856); worked example is the dev-private → public-mirror repo split and the recurring "public mirror push HELD" decision as this axis's one-way-exposure gate in practice.
tags: [axis, architecture, visibility, share-scope, access, public, private, rfc-75, deep]
timestamp: 2026-06-20T00:00:00Z
---

# Visibility (share-scope axis)

> **DEEP axis (P1 #851 → 4.5.0a6 #856).** Full §6 depth with a worked example
> from the skill's own history — the repo trio splits visibility (dev repo
> private, public mirror public), and the recurring "public mirror push HELD"
> decision across the 4.2.0/4.3.0 GAs is this axis's one-way-exposure caution
> made operationally real: a force-push of curated history to a PUBLIC repo is
> irreversible in effect, so it is gated on an explicit operator call rather than
> defaulted. Distinct from `sensitivity` (the intrinsic *classification* of the
> data) and `authz-granularity` (how *finely* access is decided): visibility is a
> record's *default share-scope* — who can see it before any per-principal grant.

## Concept

Visibility is the **share-scope** axis (RFC #75 §3): the default reach of a
record to other principals. The ladder runs private (visible only to its owner)
→ shared (visible to an explicit set: a team, the record's collaborators) →
public (visible to everyone, including the unauthenticated). Its **commitment
surface is the persistent-data schema** (§4): the scope is a visibility column
plus the read-filter every query must apply, and once a record was public the
fact that it *was* visible cannot be retracted (cached/copied externally). Its
**scope is per-entity-with-default** (§5): a system-wide default ("records are
private") with per-record sharing/publishing declared in the entity record. (It
is per-entity-with-default rather than system-singleton because the share-scope
is a property *of each record*, defaulted system-wide — the same shape as
`sensitivity`.)

## Why it is an axis (discriminator test — §2)

1. **Ordered tiers** — each rung widens the default audience (private ⊂ shared
   ⊂ public).
2. **Cross-cutting bundle** — a rung dictates the visibility column, the
   read-filter on every query, the share/publish workflow, the cache-ability,
   and the visibility tests.
3. **Asymmetric migration cost** — widening (private → public) is a one-way door
   in *effect*: once seen/cached publicly it cannot be un-seen, so narrowing
   later does not undo the exposure.
4. **Requirement-keyed selection** — falsifiable probes pick the rung.

## Schema view (the §6 entry — validated by `axis_catalog`)

```yaml
id: visibility
kind: architecture-axis
scope: per-entity-with-default
default_tier: private
maintenance_discipline: >-
  records are PRIVATE by default — visible only to their owner. Sharing (to an
  explicit set) or publishing (to everyone) is a deliberate per-record action
  declared in the entity record's axis-materialization facet; every read query
  applies the visibility filter. The discipline treats widening as a ONE-WAY
  exposure (a published record may be cached/copied externally — narrowing later
  does not un-expose it) and forbids a default-public posture for records that
  carry any non-public sensitivity tier. Per-record deviations live in the entity
  record.
selection:
  probes:
    - "Should only the owner see this record? → private."
    - "Should an explicit set (a team, the collaborators) see it? → shared."
    - "Should everyone, including the unauthenticated, see it? → public."
    - "Is a record being published while carrying PII/secret sensitivity? → that is a leak, not a visibility choice."
composes_with:
  - "publish safety = visibility × sensitivity (never publish above public sensitivity)"
applies_when: []
tiers:
  - tier: private
    commitment_delta:
      surface: persistent-data-schema
      delta: "visible only to the owning principal; every read filters to the owner. The safe default."
    admin_tool: "ownership/transfer tool."
    enforcement:
      - "a non-owner read returns nothing; the visibility filter is applied on every query."
    tests:
      - "a non-owner cannot see the record; the owner can."
    forecloses: "any sharing without an explicit action."
    migration_cost_to_next: "low — add a share list + a member-of-share read predicate."
  - tier: shared
    commitment_delta:
      surface: persistent-data-schema
      delta: "visible to an explicit set (a team / collaborators); the read filter admits members of the share. Sharing is auditable + revocable."
    admin_tool: "share-management UI; a who-can-see audit."
    enforcement:
      - "a read is admitted iff the principal is the owner or in the share set; revoking removes access."
    tests:
      - "a shared member sees it; a non-member does not; revocation removes access."
    forecloses: "owner-only simplicity; the share set is now load-bearing."
    migration_cost_to_next: "medium — mark public (drop the membership filter) — a ONE-WAY exposure."
  - tier: public
    commitment_delta:
      surface: persistent-data-schema
      delta: "visible to everyone, including the unauthenticated; the read filter admits all. Cache-able; the exposure is irreversible in effect."
    admin_tool: "publish/unpublish workflow (unpublish does not un-expose)."
    enforcement:
      - "an unauthenticated read is admitted; publishing checks the record carries no non-public sensitivity."
    tests:
      - "an unauthenticated request can read a public record; a publish of a PII/secret-bearing record is blocked."
    forecloses: "controlling who has seen it; external copies persist."
    migration_cost_to_next: "n/a — top of the ladder (widest scope)."
examples:
  - "The skill's repo trio is a live, per-entity instantiation of this whole ladder. The dev repo is PRIVATE — it holds the canonical store, WIP branches, and the running design record, visible only to the operator. The public MIRROR repo is PUBLIC — it carries curated lineage for anyone to read, including the unauthenticated. (The third, docs, sits between as effectively SHARED working state.) The reason this axis grades deep rather than illustrative is the recurring operational scar it explains: the 'public mirror push HELD' decision that has blocked every GA roll-up since 4.2.0 (and again at 4.3.0) is *exactly* the private→public one-way-exposure gate this axis defines. The dev main and the public main have diverged, so promoting requires a FORCE-push of curated-or-verbatim history onto the public repo — and because public is irreversible in effect (once pushed and fetched/cached, the exposure cannot be un-done, and the curated-vs-verbatim intent is itself a content decision), the skill's discipline is to GATE it on an explicit operator call rather than default-publish. That is the migration_cost_to_next made concrete: shared→public is cheap mechanically but a one-way door in consequence, so it is never automated. The composition with sensitivity is also live: the hold is partly because the operator must confirm the curated history carries no data above `public` sensitivity (no leaked TWINE token, no private credential) before it crosses the boundary — publish safety = visibility × sensitivity, enforced as a human gate."
```

## Selection procedure (§8)

Bidirectional check per record under the private default. The escalation pass
asks "who should see this by default?" The publish gate cross-checks sensitivity
(never publish a record above `public` sensitivity). Recorded in the entity
record; a default-public posture on sensitivity-bearing data is a
systems-analysis finding (5A.5).

## Composition (§5)

Visibility × sensitivity = **publish safety** — a record may be published only
when its sensitivity tier is `public`; widening visibility above the sensitivity
floor is a leak. Rule authored in 5A.3.
