AD‑32 [PG] — Pack Governance & Provenance

Culture Packs determine what counts as normatively legible, what counts as refusal, what counts as deference, and what counts as acceptable option framing. That is governance of meaning, not localisation. This card specifies who can author a pack, how packs are sourced and reviewed, and how communities can challenge the norms encoded on their behalf.

Aliases: none Cluster: Culture / Governance Depends on: AD‑04 [TG], AD‑08 [SO], AD‑21 [RM], AD‑25 [CP], AD‑26 [CA]

0. For humans

What question does this answer?

"Whose norms are encoded in Culture Packs, and what stops this from becoming soft ethical colonialism with version numbers?"

How do I know it's live?

You can point to:

• Authorship records per pack: who wrote it, who reviewed it, what sources were consulted, what perspective was declared.
• Source diversity requirements: no single‑source norm packs; documented diversity threshold for G4/G5 norm bundles.
• Review cadence and expiry: packs have declared shelf lives and mandatory review cycles.
• External challenge pathway: communities represented by a pack can contest the pack itself, not just individual gate decisions.

Where do I see it?

• UI: Pack provenance disclosure (authorship, sources, review status). Pack challenge affordance. Pack version and expiry in settings or advanced drawer.
• FHR / logs: pack_author_role, pack_reviewer_ids[], pack_review_date, pack_expiry_date, source_diversity_score, source_ids[], pack_scope_note, pack_challenge_event, pack_challenge_status.

Quick checklist

• Implemented if: every active Culture Pack has declared authorship, reviewers, sources, scope note, and expiry; no single‑source G4/G5 norm packs; external challenge mechanism exists.
• Key artefacts: pack provenance records, source diversity audit, challenge process documentation.
• Key FHR fields: pack_author_role, source_diversity_score, pack_expiry_date, pack_challenge_status.
• Key failure codes: pack_expired_fallback.
• Escalation path: pack challenge → review → AD‑21 [RM] governance appeal.

1. Purpose & scope

AD‑32 [PG] defines:

1. Authorship requirements — who can create and update a Culture Pack, and what qualifications and diversity constraints apply.
2. Provenance standards — how pack contents are sourced, cited, and reviewed.
3. Anti‑provincialism constraints — structural safeguards against encoding a single perspective as universal.
4. Authority boundaries — what a pack can and cannot determine.
5. External challenge mechanisms — how communities can contest packs that represent them.
6. Sunset and review protocols — how packs expire, are reviewed, and are retired.

It does not:

• Define the technical schema of Culture Packs (that is AD‑25).
• Specify cultural challenge suites or anchor tests (that is AD‑26).
• Override gate taxonomy or contestability rules (that is AD‑04).

AD‑32 governs the political and epistemic integrity of the norm‑encoding process itself.

2. Authorship requirements

2.1 Roles

Each Culture Pack must declare:

• Primary author(s): identified by role, not necessarily by name. Roles include: cultural consultant, community representative, academic researcher, policy analyst, deployment‑specific subject matter expert.
• Reviewer(s): at least two reviewers per pack, at least one of whom is external to the authoring organisation.
• Declared perspective: a short scope note stating whose norms are represented, from what vantage point, and what the pack explicitly does not cover.

2.2 Diversity constraints

• No Culture Pack may be authored by a single individual without external review.
• Source material for a pack must draw from a minimum of three independent sources (see §3).
• Reviewer pool must include at least one person with lived experience in the culture/community the pack represents, or a documented explanation of why this was not achievable and what mitigations were applied.

2.3 Disqualifications

A pack fails authorship requirements if:

• It was authored entirely by individuals outside the culture it represents, with no review by insiders.
• It cites only a single normative source.
• It declares no perspective or scope limitation.
• It has no named reviewers.

3. Provenance standards

3.1 Source requirements

Each norm encoded in a pack must be traceable to at least one declared source:

• Source types: academic research, community governance documents, legal/regulatory texts, ethnographic fieldwork, community consultation records, established cultural reference works.
• Source diversity: the pack as a whole must draw from at least three independent sources across at least two source types.
• Source currency: sources must be dated; packs must declare whether they rely on historical or contemporary norms and flag any known tensions between the two.

3.2 Citation format

Each norm entry in a pack carries:

• norm_id
• source_ids[] — references to the sources that ground this norm.
• source_type per source.
• last_reviewed — date of last review for this specific norm.
• contested — bool; whether this norm is known to be contested within the community.

3.3 Review cadence

• Every pack has a declared review_cadence (e.g., annually, biannually).
• Every pack has a pack_expiry_date after which it must be reviewed before continued use.
• Expired packs that have not been reviewed are downgraded: the system falls back to the next‑broader jurisdiction pack or to safe defaults, and logs pack_expired_fallback.

4. Anti‑provincialism constraints

4.1 No single‑source norm packs

A norm bundle used for G4/G5 gate decisions (AD‑04) must draw from multiple sources. A single source — however authoritative — is insufficient to ground a norm that can shape, constrain, or refuse interaction.

4.2 Overlay transparency

When multiple packs or overlays are active (e.g., a regional pack with a community overlay), the layering must be transparent:

• Each active layer is visible in FHR (culture_pack_id, community_pack_id, overlay_ids[]).
• Conflicts between layers are resolved by the strictest‑effective‑jurisdiction rule (AD‑26) and logged.
• The user can inspect which layer contributed to a specific gate decision via the "Why this decision?" drawer.

4.3 Dissent and minority norm preservation

• Packs must declare known minority perspectives within the community they represent.
• Where a norm is contested, the pack must encode both the majority position and the minority position, with the minority position available as a dissent overlay.
• Dissent overlays are not hidden; they are visible in FHR and available to users who opt in.
• unassimilated_motif_count (from AD‑26 CPL) tracks norms that were considered but not encoded, with reasons.

5. Authority boundaries

A Culture Pack conditions interaction framing, not truth.

Specifically, a pack may determine:

• How indirectness and politeness are interpreted.
• What refusal forms are culturally legible.
• What option framings are appropriate.
• What register and tone are contextually fitting.
• What norm sources are cited for G4/G5 gate decisions.

A pack may not determine:

• Whether a factual claim is true or false.
• Whether a G1/G2/G3 gate decision is correct.
• Whether a safety invariant holds.
• Whether the system's ethical stance on a universal‑horizon (H1) norm is justified.

This boundary is invariant. Cultural sensitivity operates within truth and safety constraints, never against them.

6. External challenge mechanisms

6.1 Scope

AD‑04 specifies how users can contest individual gate decisions (Refusal Card → Dispute drawer). AD‑32 extends contestability to the pack level: communities can challenge the norms encoded on their behalf.

6.2 Who can challenge

• Any user interacting under a given pack.
• Community representatives (self‑identified, with declared affiliation).
• External reviewers, auditors, or researchers with documented interest.

6.3 Challenge process

1. Filing: a pack challenge is filed via the UI or a governance channel, specifying which norms are contested and why.
2. Logging: PACK_CHALLENGE_EVENT is logged with: pack_id, norm_ids[], challenger_role, challenge_reason, challenge_date.
3. Acknowledgment: the challenge is acknowledged within a declared SLA (deployment‑specific, default 7 days).
4. Review: the challenge is reviewed by the pack's designated reviewers plus at least one reviewer external to the original authorship team.
5. Outcome: one of: - upheld — the contested norm is revised or removed; pack version is incremented. - partially_upheld — the contested norm is annotated with the dissenting perspective; dissent overlay is created or updated. - dismissed — the challenge is dismissed with documented reasoning, which is visible to the challenger and logged.
6. Appeal: if dismissed, the challenger may escalate via the governance appeal path (AD‑21 [RM]).

6.4 FHR fields

• pack_challenge_event: per challenge, with pack_id, norm_ids, challenger_role, reason.
• pack_challenge_status ∈ {filed, acknowledged, under_review, upheld, partially_upheld, dismissed, appealed}.
• pack_challenge_resolution_days: time from filing to outcome.
• pack_version_incremented: bool (if challenge led to pack update).

7. Sunset and review protocols

7.1 Review triggers

A pack review is triggered by:

• Expiry: pack_expiry_date reached.
• Challenge volume: more than a configured number of pack challenges within a review period.
• Deployment change: the pack is adopted by a new deployment context with substantially different user demographics.
• Source obsolescence: a primary source is retracted, superseded, or flagged as outdated.

7.2 Review process

• Review follows the same provenance and diversity standards as original authorship.
• Reviewers must include at least one person not involved in the original authorship.
• Review outcome is one of: renewed (pack continues with updated review date), revised (pack updated with version increment), retired (pack removed from active use, with fallback to broader pack or safe defaults).

7.3 Retirement

When a pack is retired:

• Active deployments using it receive a pack_retired_notice and fall back to the next‑broader jurisdiction pack or safe defaults.
• Historical uses of the retired pack remain in the evidentiary chain (AD‑21) for audit purposes.
• Retired packs are not deleted; they are marked inactive with retirement reason and date.

8. Invariants vs configurable degrees of freedom

Hard invariants

• Every Culture Pack has declared authorship, reviewers, sources, scope note, and expiry.
• No single‑source norm packs are permitted for G4/G5 gate decisions.
• Packs declare their perspective and limitations; no pack claims universality.
• External challenge mechanisms exist and are accessible to users and communities.
• Pack authority is bounded: packs condition framing, not truth or safety.
• Expired packs without review are downgraded, not silently continued.

Configurable degrees of freedom

• Exact source diversity thresholds (minimum three sources, but deployment may require more).
• Review cadence per deployment context.
• SLAs for challenge acknowledgment and resolution.
• Granularity of dissent overlays.
• Specific roles and qualifications for authorship and review (beyond the minimum structural requirements).

9. Interfaces & cross‑links

• AD‑04 [TG]: pack norms ground G4/G5 gate decisions; pack governance constrains the quality of those norms. Pack challenges extend AD‑04's contestability from the gate level to the authorship level.
• AD‑08 [SO]: hosts all FHR fields defined here.
• AD‑14 [DS]: implements pack provenance disclosure, pack challenge affordance in UI.
• AD‑21 [RM]: evidentiary chain includes pack authorship records, challenge events, and retirement decisions. Appeal path for dismissed challenges routes through AD‑21 governance.
• AD‑25 [CP]: AD‑32 governs the authorship and governance of the packs that AD‑25 defines technically. AD‑25 specifies what a pack contains; AD‑32 specifies who writes it and how it's held accountable.
• AD‑26 [CA]: cultural challenge suites and the Cultural Provenance Ledger support AD‑32's accountability requirements. unassimilated_motif_count tracks norms considered but not encoded.

10. Acceptance: when can you say "AD‑32 is implemented"?

You can truthfully claim AD‑32 [PG] is live if:

1. Every active Culture Pack has declared authorship (roles, not necessarily names), at least two reviewers (one external), cited sources (minimum three, across at least two source types), a scope note, and an expiry date.

2. No single‑source norm pack is used for G4/G5 gate decisions.

3. Users can inspect the active pack's provenance (authorship, sources, review status) via the UI.

4. An external challenge mechanism exists: users and community representatives can contest pack norms, with challenges logged, acknowledged within SLA, reviewed with external involvement, and resolved with documented reasoning.

5. Expired packs are downgraded to fallback defaults, not silently continued.

6. FHR exposes: pack_author_role, pack_reviewer_ids, source_diversity_score, pack_expiry_date, pack_challenge_event, pack_challenge_status.

If packs exist but have no declared authorship, no external review, no challenge pathway, or no expiry, you have localisation data but not governed norm provenance. The question "whose norms?" must have a traceable, contestable answer.