Ticket: Use one package approval and capability model

status: pending priority: P1 type: requirements + implementation cleanup scope: focused requirements and business-logic cleanup

Objective

You are to remove the current separate treatment for packages that claim a named approval/profile path.

After this ticket, the active requirements and live code shall use one model:

A package declares what it needs.
A Host publishes what it supports.
Local Policy grants or denies what the package asks for.
The system records what happened.

A package shall not receive different import, validation, inspection, approval, or invocation semantics because it claims a named package profile.

Package content validity shall be separate from whether the current Host supports the package’s implementation requirements or whether Local Policy grants the package’s requested capabilities.

This ticket updates both requirements and implementation. Do not add new package features in this ticket. Do not add new compute behavior. Do not add new artifact retrieval behavior. Do not change Package Bundle ZIP import semantics except where current package validation incorrectly treats Host support as package content validity.

Current problem

The current requirements already contain the right authority primitives. Host Capability means a capability provided by a Host Implementation, requested by a package, and granted or denied by Local Policy; Local Authority means the Local Station decides which packages, capabilities, storage uses, compute uses, disclosures, and invocations are allowed locally .

But the current requirements also define separate named package approval/profile paths. For example, the current SyRS includes BENAC-PKG-006 - Portable package profile, BENAC-TRUST-006 - Local public-data package approval, BENAC-CAP-007 - Local package capability vocabulary, and BENAC-INT-006 - Extension profiles . BENAC-CAP-007 specifically limits accepted capability identifiers for “local public-data portable packages” and rejects other capabilities under that approval path . BENAC-TRUST-006 similarly defines an approval record for packages that operate only on public data, execute through declarative or WASM implementations, and do not request network, remote storage, remote compute, secrets, native execution, file access, device access, direct document-store access, or private blob access .

The code mirrors that split. It has local-public-data-specific approval records, trust scopes, capability grants, capability vocabulary classes, validation gates, inspection fields, and invocation gates.

This ticket removes that separate treatment.

Required rule

Use this rule everywhere this ticket touches:

A package declares requirements.

A package declaration does not grant authority.

Package import does not grant authority.

Package trust does not grant authority by itself.

A Host Implementation publishes what it supports.

Local Policy grants or denies requested capabilities.

Approval records bind the actual capabilities, data classes, interfaces, descriptor scope, implementation identity, and evidence being approved.

Invocation occurs only when package content is valid, the selected implementation is supported by the Host, required artifacts are available, resource requirements are satisfied, and Local Policy grants the capabilities required for the operation.

Unsupported Host support, unsupported implementation kind, unsupported capability, denied capability, missing capability grant, missing artifact, expired grant, revoked grant, conflicted grant, or resource conflict shall be recorded with stable diagnostics.

Language rule

Do not use these phrases in edited active package / approval / capability requirements or live business logic:

local_public_data_portable_package
local public-data portable package
portable package profile
local public-data package approval
local public-data approval
local public-data package capability vocabulary
baseline portable package
baseline local package capability vocabulary
extension profile
capabilities outside the baseline
optional privileged capability

Do not replace them with another named package group.

Use plain language:

package requirements
requested capabilities
granted capabilities
denied capabilities
Host-supported capabilities
Host-supported implementation kinds
unsupported implementation kind
unsupported capability
package approval
capability grant
operation allowed
operation blocked
invocation allowed
invocation blocked

Do not purge unrelated uses of “baseline” in cryptographic identity, CID, DRISL, or other non-package-profile contexts unless those records are otherwise touched for this ticket.

Requirements work

Edit GraphMD source records, not generated docs directly.

Regenerate generated docs after edits:

npm run build:glossary
npm run build:syrs

1. Rewrite BENAC-PKG-006

Edit:

records/req.benac-pkg-006/benac-pkg-006.md

Change title to:

Package requirements

Replace statement with:

A package shall declare the capabilities, implementation requirements, artifacts, resources, schemas, fixtures, evidence behavior, and effect behavior required for each package interface and implementation.

A package shall declare which requirements apply to package import, package validation, package inspection, package approval, fixture execution, package invocation, and package-requested effects.

A package declaration shall not grant authority.

Package import shall not grant authority.

Package trust shall not grant authority by itself.

A Host Implementation shall inspect package requirements before approval and invocation.

A Host Implementation shall not approve an operation unless Local Policy grants the capabilities required for that operation.

A Host Implementation shall not invoke a package implementation unless the Host supports the selected implementation, Local Policy grants the capabilities required for invocation, required artifacts are available, and resource requirements are satisfied.

A package shall not be rejected as package content merely because it requests a capability, implementation kind, artifact, or resource that the importing Host does not support, unless that unsupported requirement is required for package import or package validation.

Unsupported requirements shall be recorded as package inspection, approval, fixture execution, invocation, or effect blockers according to the operation phase for which the requirement is declared.

Replace rationale with:

Benac packages declare what they need. The Local Station decides what is allowed. Importing a package, trusting a package, or recognizing a package name does not give the package authority.

Replace verification with:

Tests import and inspect packages with different declared capabilities and implementation kinds. Tests verify that package import does not grant authority, package trust does not grant authority by itself, and invocation is blocked when a required capability is unsupported, denied, missing, expired, revoked, or conflicted. Tests verify that unsupported invocation requirements do not by themselves make package import fail when package import requirements are satisfied.

2. Rewrite BENAC-TRUST-006

Edit:

records/req.benac-trust-006/benac-trust-006.md

Change title to:

Package approval

Replace statement with:

Benac shall define a package approval record.

A package approval record shall bind package CID, implementation CID or deterministic implementation-selection policy, descriptor snapshot CID or descriptor scope, interface identifier, allowed data classes, granted capability identifiers, denied capability identifiers where applicable, issuer principal, authentication context where applicable, expiry or revocation metadata where applicable, inspection result reference, validation report reference where available, fixture result references where relied upon, warnings presented, and evidence relied upon.

A package approval record shall not approve capabilities that are not identified in the approval record.

A package approval record shall not approve data classes that are not identified in the approval record.

A package approval record shall not approve interfaces that are not identified in the approval record.

A package approval record shall not approve implementation CIDs or implementation-selection policies that are not identified in the approval record.

A package approval record shall not grant authority by package name, author name, implementation kind string, file name, label, or human-readable description.

A package approval record shall not rely on facts hidden from the referenced inspection result.

A package approval record shall be enforceable only for the package CID, implementation CID or deterministic implementation-selection policy, descriptor scope, interface identifier, allowed data classes, and granted capabilities recorded in the approval and corresponding trust decision.

A package approval record shall not authorize a package invocation when a required capability is missing, denied, unsupported, expired, revoked, conflicted, or unavailable.

A package approval record shall not authorize a package invocation when the selected implementation is unsupported by the Host.

A package approval record shall not authorize a package invocation when required artifacts are unavailable or resource requirements are not satisfied.

Replace rationale with:

Approval states what Local Policy allows for a package. Approval shall be scoped to exact package identity, selected implementation authority, descriptor scope, interface, data classes, capabilities, and evidence.

Replace verification with:

Tests approve packages with different declared capabilities using the same package approval record type. Tests verify that approval grants only the capabilities listed in the approval record. Tests verify that unsupported implementation kind, unsupported capability, denied capability, missing capability grant, unavailable artifact, and resource conflict block invocation without changing package content identity.

3. Rewrite BENAC-CAP-007

Edit:

records/req.benac-cap-007/benac-cap-007.md

Change title to:

Capability identifiers

Replace statement with:

Benac shall define stable capability identifiers used by packages, approvals, capability grants, invocations, evidence records, effect records, diagnostics, and Station Profiles.

A package shall declare every capability it requires for each operation phase.

The operation phases shall include package import, package validation, package inspection, package approval, fixture execution, package invocation, and package-requested effects.

Declaring a capability shall not grant authority.

A capability grant shall be a separate Local Policy decision.

A Host Implementation shall not perform a package operation unless Local Policy grants every capability required for that operation.

A Host Implementation shall not treat any declared capability as default, implied, ambient, or automatically granted.

A Host Implementation shall not treat aliases, legacy synonyms, host-local convenience names, implementation-specific spellings, package labels, provider names, model names, file names, URLs, or human-readable descriptions as capability identifiers.

A Host Implementation shall record missing, denied, unsupported, expired, revoked, conflicted, or unavailable capability grants with stable diagnostics.

Unknown capability identifiers shall not grant authority.

Unknown capability identifiers required for package import or package validation shall fail the required operation.

Unknown capability identifiers required for package approval, fixture execution, package invocation, or package-requested effects shall block that operation and shall be recorded in inspection, approval, invocation, effect, or diagnostic records.

Replace rationale with:

Independent implementations need stable capability identifiers, but capability declarations must not become authority. Local Policy decides which requested capabilities are granted.

Replace verification with:

Tests verify that declared capabilities do not grant authority. Tests verify that invocation is blocked until every required capability for invocation is granted. Tests verify that a package declaring an unsupported capability can be imported and inspected when import and validation requirements are otherwise satisfied, and that approval or invocation is blocked for the unsupported operation phase.

4. Amend BENAC-CAP-001

Edit:

records/req.benac-cap-001/benac-cap-001.md

Add:

A package shall declare required capabilities by operation phase.

A package shall declare capabilities required by each implementation entry and each package interface.

A declared capability shall not grant authority.

A Host Implementation shall not reject package content solely because a declared capability is not supported by that Host, unless the capability is required for package import or package validation.

A Host Implementation shall report unsupported declared capabilities during inspection.

5. Amend BENAC-CAP-002

Edit:

records/req.benac-cap-002/benac-cap-002.md

Add:

A capability grant shall identify the package CID, implementation identity where applicable, package interface, operation phase, capability identifier, scope, issuer principal, authentication context where applicable, expiry or revocation metadata where applicable, and evidence relied upon.

A capability grant shall not be inferred from package import, package trust, package name, package author, implementation kind, Station Profile support, or package approval text.

A capability grant shall not widen authority beyond the package approval or Local Policy record that created it.

6. Amend BENAC-CAP-003

Edit:

records/req.benac-cap-003/benac-cap-003.md

Add:

A Host Implementation shall mediate every granted capability.

A Host Implementation shall not expose host resources directly to package code outside granted capabilities.

A Host Implementation shall not treat package trust, package approval, implementation selection, Station Profile support, package author identity, package name, signature verification, or import success as a substitute for a capability grant.

7. Amend BENAC-AUTHOR-001

Edit:

records/req.benac-author-001/benac-author-001.md

Remove package-profile compatibility checks from package validation semantics.

Replace current validation language that evaluates local public-data package compatibility claims with:

Package validation shall distinguish package content validity from Host support, Local Policy approval, capability grants, artifact availability, and resource availability.

Package validation shall verify manifest schema conformance, package schema ruleset conformance, schema reference resolution, package interface declarations, descriptor config schema binding, request schema binding, output schema binding, implementation entries, implementation snapshot derivation, artifact references, declared capabilities, fixture schema conformance, documentation references, and unknown required fields.

Package validation shall not fail solely because an implementation kind is unsupported by the validating Host.

Package validation shall not fail solely because a capability is unsupported by the validating Host, unless that capability is required for package validation.

Unsupported implementation kinds, unsupported capabilities, unavailable artifacts, and unsatisfied resource requirements shall be recorded by operation phase.

Validation reports shall identify whether each failure, warning, or unsupported condition affects import, validation, inspection, approval, fixture execution, invocation, or package-requested effects.

8. Amend BENAC-UX-008

Edit:

records/req.benac-ux-008/benac-ux-008.md

Add:

A package inspection result shall show the capabilities requested by the package.

A package inspection result shall show whether each requested capability is supported by the Host.

A package inspection result shall show whether each requested capability is granted, denied, missing, expired, revoked, conflicted, or unavailable under Local Policy where that information is available.

A package inspection result shall show the implementation kind requested by each implementation entry.

A package inspection result shall show whether the Host supports each requested implementation kind.

A package inspection result shall show required artifacts, artifact availability, resource requirements, and resource conflicts.

A package inspection result shall distinguish package content validity, package import success, approval eligibility, fixture execution eligibility, invocation eligibility, and package-requested effect eligibility.

A package inspection result shall not collapse unsupported implementation kind, unsupported capability, denied capability, unavailable artifact, missing capability grant, resource-limit conflict, or fixture not run into generic package invalidity.

9. Rewrite BENAC-UX-009

Edit:

records/req.benac-ux-009/benac-ux-009.md

Change title to:

Inspection before package approval

Replace statement with:

A Host Implementation shall produce or reference a package inspection result before package approval.

A package approval record shall reference the inspected package CID, implementation CID or selection policy, descriptor scope, interface identifier, declared capabilities, granted capabilities, denied capabilities where applicable, fixture results where relied upon, warnings presented, and evidence relied upon.

If package approval relies on package bundle facts, fixture records, fixture result records, artifact availability, validation reports, build reports, claims, warnings, missing-artifact status, implementation support, capability support, resource requirements, or resource conflicts, then the approval-referenced inspection result shall include those same facts or explicitly reference an equivalent inspected field set.

Approval shall not rely on facts hidden from the referenced inspection result.

Approval shall identify the inspection context used for approval, including whether the inspection was package-document-only, Package Bundle, or imported Station state.

10. Delete BENAC-INT-006

Edit:

records/req.benac-int-006/benac-int-006.md

11. Update Station Profile requirements

Edit:

records/req.benac-sys-004/benac-sys-004.md

Add:

A Station Profile shall publish supported implementation kinds.

A Station Profile shall publish supported capability identifiers.

A Station Profile shall publish package approval support.

A Station Profile shall publish fixture execution support.

A Station Profile shall publish package inspection support.

A Station Profile shall publish resource limits.

A Station Profile shall not be treated as a capability grant.

A Station Profile shall not be treated as approval.

A Station Profile shall not be treated as proof that required artifacts, physical resources, storage space, memory, network access, compute access, authentication credentials, or Local Policy grants are currently available.

Remove local public-data approval support wording from this requirement and replace it with package approval support.

12. Update terms

Edit or remove term records that define separate package treatment.

Update at least:

records/term.package-bundle/package-bundle.md
records/term.native-implementation/native-implementation.md
records/term.local-public-data-approval/
records/term.local-public-data-portable-package/
records/term.baseline-conformance/
records/term.browser-pwa-baseline/
records/term.extension-profile/
records/term.package-inspection-result/
records/term.conformance-suite/

Required outcomes:

The glossary shall not define Local public-data approval.

The glossary shall not define Local public-data portable package.

The glossary shall not say Native Implementation is outside or above a package class.

The glossary shall not say Package Bundle fixtures validate a local public-data portable package compatibility claim.

The glossary shall not describe package behavior using baseline/non-baseline or extension-profile language.

The glossary shall preserve Host Capability and Local Authority semantics.

The glossary shall preserve that a package declares capabilities and Local Policy grants or denies them.

Do not delete general terms merely because they use the word “portable” in a non-package-approval sense. This ticket targets package approval and capability treatment, not all uses of portability or all uses of baseline in cryptographic profiles.

Implementation work

1. Package document schema

Edit:

crates/benac-core/src/package.rs

Remove package-profile fields from the live package document schema:

compatibility_claims
unsupported_required_behavior_markers

Remove or rewrite the structs:

PackageCompatibilityClaim
UnsupportedRequiredBehavior

A package document shall continue to reject unknown top-level fields and unknown implementation-entry fields.

Keep this behavior:

provider-specific, product-specific, model-specific, library-specific, runner-specific, or implementation-specific configuration belongs in `parameters`, not as random top-level fields.

Change implementation-kind validation:

PackageDocument::validate_value shall not fail solely because implementation_kind is unsupported by the current Host.

PackageImplementationEntry::validate_artifacts shall not return implementation.unsupported_kind for an unrecognized implementation_kind.

Known implementation kinds may still have kind-specific artifact validation.

Unknown implementation kinds shall be treated as Host support facts during inspection, approval, selection, or invocation, not as package document schema failures.

Required test:

A package document with implementation_kind = "example.unsupported.v1" and otherwise valid package structure parses and computes a package CID.

A package document with a random unsupported implementation-entry top-level field still fails package document validation.

A package document with the same value inside `parameters` passes package document validation.

2. Package validation

Edit:

crates/benac-core/src/authoring.rs

Change validation behavior:

Unsupported implementation kind shall produce a warning or support-status finding.

Unsupported implementation kind shall not set package content validation to Failed unless the implementation kind is required for the validation operation itself.

Validation shall no longer evaluate local_public_data_portable_package claims.

Validation shall no longer require package-bundle fixtures because a package claims a named profile.

Validation shall continue to fail malformed package documents, unresolved required schema references, duplicate identifiers, missing interfaces, malformed artifact references, and unknown required fields.

Remove validation report fields, warnings, and tests that specifically evaluate:

local_public_data_portable_package
local public-data package compatibility
unsupported_required_behavior_markers

3. Package inspection

Edit:

crates/benac-core/src/inspection.rs

Remove:

PackageCompatibilityStatus
local_public_data_compatibility
compute_compatibility_status
local_public_data_portable_package claim handling
fixture-discoverability gate tied to profile claim

Replace with inspection facts that describe the package and this Host’s ability to satisfy it.

At minimum, inspection shall expose:

declared capabilities
capabilities supported by this Host
capabilities unsupported by this Host
known capability grants where available
implementation entries declared by the package
requirements declared by each implementation entry
whether this Host can run each implementation entry
reasons this Host cannot run an implementation entry where applicable
artifact availability
missing artifacts
resource requirements
resource conflicts where available
warnings
diagnostic refs

The exact Rust struct names are up to the implementer, but the field names must not contain local_public_data, portable_package, compatibility_claim, or extension_profile.

Required tests:

A package with unsupported implementation kind imports and inspects; inspection records unsupported implementation kind.

A package with unsupported capability imports and inspects; inspection records unsupported capability.

A package with missing artifacts imports and inspects when those artifacts are not required for import.

Inspection does not return local_public_data_compatibility.

4. Capability vocabulary

Edit:

crates/benac-core/src/capability_vocabulary.rs

Remove separate capability classes:

CapabilityClass::LocalPackage
CapabilityClass::Forbidden
CapabilityClass::Other
LOCAL_PACKAGE_CAPABILITIES
LOCAL_PUBLIC_DATA_FORBIDDEN_CAPABILITIES
is_local_package_capability
is_forbidden_under_local_public_data
validate_declared_for_local_public_data

Replace with one capability vocabulary that does not classify capabilities by package treatment.

Required shape:

Known capability identifier
Description

Include the identifiers already present in both current lists as known identifiers, without marking any as categorically forbidden by package type:

local_package_execution
declared_package_artifact_read_by_exact_cid
validated_request_read
validated_descriptor_config_read
output_return
evidence_emit
effect_emit
fixture_execution
package_inspection
network_fetch
remote_storage
remote_compute
secret_use
decryption
signing
native_execution
file_access
device_access
same_origin_package_javascript
direct_document_store_access
private_blob_access
data_egress
physical_world_effect

Unknown capability identifiers shall not grant authority.

Unknown capability identifiers shall be inspectable as unsupported by the current Host unless required for import or validation.

Required tests:

Known identifiers round-trip.

Formerly forbidden identifiers are known identifiers.

Declaring a formerly forbidden identifier does not make package content invalid.

Requesting a capability that is not declared still fails.

Requesting a capability that is not granted still fails.

Unknown identifiers are reported as unsupported and do not grant authority.

5. Approval data model

Edit:

crates/benac-core/src/auth.rs
apps/station-cli/src/persistence.rs
crates/benac-browser/src/browser_station.rs

Rename and generalize:

LocalPublicDataApproval -> PackageApproval
local_public_data_approval -> package_approval
benac.local_public_data_approval.v1 -> benac.package_approval.v1

Do not keep an active approval path that creates local_public_data_approval.

The new approval record shall bind at least:

package_cid
package_inspection_result_ref
validation_report_ref where available
implementation_cids or implementation-selection policy
descriptor_snapshot_cid or descriptor scope
interface_identifier
allowed_data_classes
granted_capability_identifiers
denied_capability_identifiers
issuer_principal
authentication_context_ref
expires_at
revoked_at
fixture_result_refs_relied_upon
warnings_presented
created_at
station_profile_ref

If migration code is needed for existing local developer data, it shall convert old records into generic package approval records before active use. Do not authorize an invocation from an old local-public-data-specific record type in live logic.

6. Approval API

Edit:

crates/benac-browser/src/browser_station.rs
apps/station-cli/src/commands.rs
apps/pwa/src

Rename:

approve_local_public_data_package -> approve_package
approve_local_public_data_package_with_params -> approve_package_with_params
ApproveLocalPublicDataParams -> ApprovePackageParams

The approval path shall:

inspect the package
present or receive the requested capability decision
persist a PackageApproval record
persist a TrustDecision scoped to the approved package/interface/implementation/descriptor/data classes
persist CapabilityGrant records only for granted capabilities
persist denied capability information where applicable
not reject a package because it requests a formerly forbidden capability
not approve capabilities that are unsupported or denied
not approve unsupported selected implementations
not create a fixed capability grant list independent of the package’s declared requirements

The convenience approval path may approve all capabilities declared for the selected interface and implementation only when the caller explicitly passes that intent or the UI action is clearly bound to those displayed capabilities.

7. Trust and capability grant constructors

Edit:

crates/benac-core/src/trust.rs
crates/benac-core/src/capability.rs

Rename and generalize:

TrustDecision::local_public_data -> TrustDecision::from_package_approval
TrustScope::local_public_data_package_scope -> TrustScope::from_package_approval
CapabilityGrant::local_public_data -> CapabilityGrant::from_package_approval
AuthSession::local_public_data -> AuthSession::local_package_approval

Remove fixed trust-scope lists that hard-code allowed and forbidden capability identifiers.

A trust decision shall be built from the package approval record.

A capability grant shall be built from the package approval record.

A trust decision shall not grant a capability that the package approval record did not grant.

A capability grant shall not grant a capability that the package approval record did not grant.

8. Invocation gate

Edit:

crates/benac-core/src/invocation.rs

Remove:

validate_declared_for_local_public_data
local public-data approval profile gate
fixed local public-data capability check

Invocation shall check:

selected implementation exists
selected implementation is supported by this Host
requested capability is declared by the package
requested capability is granted by Local Policy
trust decision covers package CID
trust decision covers descriptor scope
trust decision covers interface
trust decision covers selected implementation CID or approved selection policy
trust decision covers requested data class
trust decision covers requested capability
capability grant is active
capability grant covers package CID
capability grant covers selected implementation where applicable
capability grant covers interface and operation phase where applicable
required artifacts are available
resource requirements are satisfied

Unsupported implementation kind, unsupported capability, denied capability, missing grant, expired grant, revoked grant, conflicted grant, missing artifact, and resource conflict shall produce stable diagnostics and records.

9. Station Profile

Edit:

crates/benac-core/src/station_profile.rs

Rename constructors if needed:

browser_baseline -> browser_profile
ubuntu_cli_baseline -> ubuntu_cli_profile

Do not rename if doing so would create excessive churn; if left unchanged, comments and field semantics must not imply a package approval group.

Replace:

local_public_data_approval_support

with:

package_approval_support

Add or expose:

supported_capability_identifiers

StationProfile.supported_implementation_kinds shall remain. That is not a package group; it is the Host saying what it supports.

Station Profile shall not be treated as approval or a capability grant.

10. Persistence and replication

Edit:

apps/station-cli/src/persistence.rs
crates/benac-core/src/replication.rs

Rename persisted object-type handling:

local_public_data_approval -> package_approval
list_local_public_data_approvals -> list_package_approvals

Replication allow-lists shall refer to package_approval, not local_public_data_approval.

11. Fixtures and conformance

Update fixtures, conformance packages, tests, and generated example package documents.

Remove from package documents:

compatibility_claims: [{ profile: "local_public_data_portable_package", ... }]
unsupported_required_behavior_markers

Replace local-public-data-specific approval setup in fixtures with generic package approval setup.

Update tests in:

crates/benac-fixtures
crates/benac-conformance
crates/benac-core/src/inspection.rs tests
crates/benac-core/src/invocation.rs tests
crates/benac-core/src/capability_vocabulary.rs tests
crates/benac-browser/src/browser_station.rs tests
apps/station-cli tests
apps/pwa tests

Non-goals

Do not add new package capabilities in this ticket.

Do not add new implementation kinds in this ticket.

Do not add local compute behavior in this ticket.

Do not add device behavior in this ticket.

Do not add artifact retrieval behavior in this ticket.

Do not change Package Bundle ZIP import rules except where package validation incorrectly treats Host support as package content validity.

Do not loosen unknown top-level field rejection in package documents.

Do not allow package import, package trust, package name, author identity, or Station Profile support to grant authority.

Do not create another named package approval path.

Do not add provider-specific, product-specific, model-specific, library-specific, or domain-specific behavior.

Acceptance criteria

These commands pass:

npm test
cargo fmt --all --check
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace
cargo run -p benac-conformance --example print_suite
bash scripts/check-no-retired-package-term.sh
bash scripts/check-cid-grep-gates.sh

Generated docs are rebuilt from source records:

npm run build:glossary
npm run build:syrs

The active generated SyRS and glossary do not contain these package-approval phrases:

local public-data package approval
local-public-data package approval
local public-data portable package
local_public_data_portable_package
portable package profile
baseline portable package
baseline local package capability vocabulary
extension profile
capabilities outside the baseline

The live source code does not contain these active identifiers outside archival reports or explicitly named migration tests:

LocalPublicDataApproval
ApproveLocalPublicDataParams
approve_local_public_data_package
approve_local_public_data_package_with_params
local_public_data_approval
local_public_data_compatibility
PackageCompatibilityStatus
compatibility_claims
unsupported_required_behavior_markers
LOCAL_PACKAGE_CAPABILITIES
LOCAL_PUBLIC_DATA_FORBIDDEN_CAPABILITIES
validate_declared_for_local_public_data
is_forbidden_under_local_public_data
local_public_data_package_scope

A package with an unsupported implementation kind but otherwise valid package content:

imports successfully when package import requirements are satisfied
inspects successfully
records the unsupported implementation kind
cannot be approved or invoked for that implementation unless the Host supports it and Local Policy grants the required capabilities

A package declaring a formerly forbidden capability:

imports successfully when package import requirements are satisfied
inspects successfully
shows the requested capability
does not receive that capability automatically
cannot invoke an operation requiring that capability unless Local Policy grants it

A package with a random unsupported implementation-entry top-level field still fails package document validation.

The same value placed under parameters does not fail solely because of that value.

Package approval records are generic package_approval records.

Capability grants are created from approved capabilities, not from a fixed local-public-data list.

Trust decisions are scoped from the approval record, not from a fixed local-public-data list.

Invocation no longer calls local-public-data-specific capability validation.

Station Profile publishes Host support and resource limits, but Station Profile is not treated as approval or a capability grant.

Implementation notes

Keep the good parts:

closed package schemas
Package Bundle ZIP import
exact package CID verification
Package Bundle Manifest CID verification
inspection before approval
capability grants
trust scopes
Host mediation
no silent fallback
stable diagnostics
raw diagnostic evidence

Remove only the separate package treatment that makes one named approval path decide what packages are allowed to be.

The desired end state is simple:

A package declares what it needs.
The Host says what it supports.
Local Policy grants or denies what the package asks for.
The system records what happened.

One package approval / capability model — landed

The named local-public-data approval/capability path is gone. Active records and live code use one model: a package declares what it needs, the Host publishes what it supports, Local Policy grants or denies, the system records what happened.

Branch state

8008738 refactor(fixtures+conformance): collapse named LPD path into generic package model
9612e9e feat(host+cli+pwa): collapse named LPD approval/capability path into generic package model
03e6875 feat(core): collapse LPD-specific approval/capability path into generic package model
e588c4d docs(records): clear residual LPD + extension-profile language from req + term records
a73ec41 docs(records): collapse named LPD approval/capability path into one package model

Phase A — records (a73ec41) + Phase A-ii residue cleanup (e588c4d)

Phase A: 4 record full rewrites (req.benac-pkg-006 Package requirements; req.benac-trust-006 Package approval; req.benac-cap-007 Capability identifiers; req.benac-ux-009 Inspection before package approval), 6 record amendments (req.benac-cap-001/002/003, req.benac-author-001, req.benac-ux-008, req.benac-sys-004), 1 record deletion (req.benac-int-006), 5 term deletions (term.local-public-data-approval, term.local-public-data-portable-package, term.baseline-conformance, term.browser-pwa-baseline, term.extension-profile), 4 term rewrites stripping named-profile language (term.package-bundle, term.native-implementation, term.package-inspection-result, term.conformance-suite), tools SECTION_HEADING_OVERRIDES map renames the LPD section heading to "Package authoring".

Phase A-ii expanded scope to include 19 additional req records carrying the LPD-named sourceSections value, 6 records with body-level extension profile hits in cryptographic / conformance / encoding contexts, 1 record with baseline portable package body prose (req.benac-exec-005), and the 4 term records caller flagged. Substantive rewrite to req.benac-pkg-007: fixture-discoverability gate moved from "claims local public-data portable package compatibility" to "declares fixture_execution as a required capability for the approval or invocation operation phases", preserving the requirement's intent (packages that need fixtures must ship them) without LPD framing.

Build pipeline: npm test validates 515 GraphMD files (267 terms, 228 reqs); generated SyRS now lists BENAC-PKG-006 - Package requirements, BENAC-TRUST-006 - Package approval, BENAC-CAP-007 - Capability identifiers, BENAC-UX-009 - Inspection before package approval; BENAC-INT-006 is gone.

Acceptance grep against records/ + generated docs: 0 hits for the 9 banned phrases.

Phase B — Rust core (03e6875)

13 files, +1328 / -1541. The big core surgery:

• package.rs — PackageDocument.compatibility_claims + PackageDocument.unsupported_required_behavior_markers retired. PackageCompatibilityClaim + UnsupportedRequiredBehavior structs deleted. validate_value no longer fails on unknown implementation_kind; validate_artifacts no longer returns implementation.unsupported_kind. Unknown impl kinds become Host-support facts.
• authoring.rs — local-public-data-portable-package compatibility evaluation gone. Validation reports drop local_public_data_compatibility_status + unsupported_required_behavior_status. Manifest schema / ruleset / refs / interfaces / impl-entries / artifact-references / declared-capabilities / fixture-schema / unknown-required-fields gates retained.
• inspection.rs — PackageCompatibilityStatus, local_public_data_compatibility, compute_compatibility_status retired. New facts on PackageInspectionResult: host_supported_capabilities, host_unsupported_capabilities, known_capability_grants, supported_implementation_entries, unsupported_implementation_entries, resource_requirements_per_implementation, resource_conflicts. The named-profile fixture-discoverability gate is gone.
• capability_vocabulary.rs — CapabilityClass enum + LOCAL_PACKAGE_CAPABILITIES + LOCAL_PUBLIC_DATA_FORBIDDEN_CAPABILITIES + is_local_package_capability + is_forbidden_under_local_public_data + validate_declared_for_local_public_data collapsed into one flat known-identifier vocabulary: pub fn known_capability_identifiers() -> &'static [CapabilityIdentifier], is_known(&str), lookup(&str) -> Option<&CapabilityIdentifier>. All 23 identifiers from the ticket's list are known; none are categorically forbidden by package type.
• auth.rs — LocalPublicDataApproval → PackageApproval. Object_type "package_approval". Schema_version "benac.package_approval.v1". New fields granted_capability_identifiers: Vec<String> + denied_capability_identifiers: Vec<String>. AuthSession::local_public_data → AuthSession::local_package_approval.
• trust.rs + capability.rs — TrustDecision::local_public_data → TrustDecision::from_package_approval(session, approval). TrustScope::local_public_data_package_scope → TrustScope::from_package_approval(approval). CapabilityGrant::local_public_data → CapabilityGrant::from_package_approval(approval, blob_cids). Fixed allow/forbid lists removed; scope built from approval record.
• invocation.rs — validate_declared_for_local_public_data gone. The local-public-data-specific gate gone. The 16-step generic invocation gate runs in order: impl exists → Host-supported → cap declared → cap granted by Local Policy → trust covers (CID, descriptor, interface, impl, data class, capability) → grant active → grant covers (CID, impl, interface, phase) → artifacts available → resources satisfied. Each blocker emits a stable diagnostic.
• station_profile.rs — field local_public_data_approval_support → package_approval_support. New field supported_capability_identifiers: Vec<String>. supported_implementation_kinds retained. Doc comments explicitly state Station Profile is not approval and not a capability grant.
• replication.rs — FOREIGN_INACTIVE_AUTHORITY_OBJECT_TYPES references "package_approval".

cargo test -p benac-core: 392 / 392 passing.

Phase C — host wiring (9612e9e)

15 files, +768 / -682. Browser + station-cli + PWA migrated to the renamed core API:

• browser_station.rs — approve_package(...) (was approve_local_public_data_package); approve_package_with_params(...); ApprovePackageParams struct (was ApproveLocalPublicDataParams) with new granted_capability_identifiers: Option<Vec<String>> + denied_capability_identifiers: Vec<String> fields. The runtime constructs a PackageApproval first, derives TrustDecision + CapabilityGrant from it, persists all three. New tests pin formerly-forbidden + explicit-denial cases.
• station-cli cli.rs + commands.rs — PackageCommand::Approve { ... grant_capability, deny_capability, ... } (was ApproveLocalPublicData { local_public_data: bool }); package_approve(...) helper; new --grant-capability / --deny-capability flags; pretty-printer drops the two retired status rows; inspect output replaces compatibility row with host-supported-capabilities / host-unsupported-capabilities lists.
• station-cli persistence.rs — list_local_public_data_approvals → list_package_approvals; rehydrate keys off "package_approval".
• station-cli tests across end_to_end, package_commands, persistence_round_trip, sync_end_to_end migrated.
• PWA station_runtime.rs — approve_package(...) wrapper. indexeddb_persistence.rs rehydrates off "package_approval".
• PWA UI panels (trust_panel, package_panel, diagnostics_panel, trace_panel, invocation_panel) — trust_panel state machine reshaped (no compatibility-axis gate); package_panel drops the compatibility summary, adds host-supported / host-unsupported lists.

Acceptance grep against apps/ + crates/benac-browser/: 0 hits.

Phase D — fixtures + conformance (8008738)

28 files, +877 / -825. The downstream ripple:

• 10 fixture builders edited: drop compatibility_claims: and unsupported_required_behavior_markers: lines from every PackageDocument { ... } literal across calculator / hello_world / notes_transform / todo_reducer / inspection_comparison / generic_request_config / multi_implementation / resource_limit / diagnostic_raw_evidence / negative_conformance.
• File rename: crates/benac-fixtures/src/local_public_data_approval.rs → package_approval.rs. lib.rs declares pub mod package_approval;.
• File rename: crates/benac-conformance/src/local_public_data_approval_suite.rs → package_approval_suite.rs. lib.rs registration updated. Check IDs renamed local_public_data_approval_* → package_approval_*.
• New crates/benac-conformance/src/approval_test_helpers.rs (135 lines) centralizes the new PackageApproval-based test pattern. 8 conformance suites now build approvals via this helper.
• Fixture function rename: missing_compatibility_claim_fixture deleted (the field is gone); replaced by new unsupported_implementation_kind_fixture covering the equivalent rejection path under the new model.
• Diagnostic-code re-pinning in fixtures:
  • forbidden_capability_fixture: APPROVAL_LOCAL_PUBLIC_DATA_INCOMPATIBLE → CAPABILITY_DENIED (the validator emits capability.denied for declared/forbidden overlap; approval.local_public_data_incompatible was the LPD-runtime gate's code, retained as a stable wire identifier elsewhere).
  • unsupported_implementation_kind_fixture: pins IMPLEMENTATION_UNSUPPORTED_KIND.
• inspection_comparison_suite semantics updated:
  • *_compatibility_flips_with_station_profile_change → *_supported_implementation_entries_flip_with_station_profile_change.
  • *_rejects_legacy_local_blob_read_exact → *_records_legacy_local_blob_read_exact_storage_need (records the need for Local Policy review instead of categorical reject).
• On-disk hello-world ZIP fixtures regenerated via cargo run -p xtask -- build-hello-world-fixtures against the new package_document shape.

Conformance count: 156 / 156 / 0 (preserved).

Acceptance grep against crates/benac-fixtures/ + crates/benac-conformance/: 0 hits.

Final state

$ git rev-parse HEAD                                                   8008738...
$ cargo fmt --all --check                                              clean
$ cargo clippy --workspace --all-targets -- -D warnings                clean
$ cargo check -p benac-pwa --target wasm32-unknown-unknown             clean
$ cargo test --workspace                                               585 passed
$ cargo run -p benac-conformance --example print_suite | tail -1       checks=156 passed=156 failed=0
$ npm test                                                             515 GraphMD files (267 terms, 228 reqs)
$ bash scripts/check-cid-grep-gates.sh                                 OK
$ bash scripts/check-no-canonical-in-source.sh                         OK
$ bash scripts/check-no-retired-package-term.sh                        OK

Acceptance greps:

# 13 banned identifiers in active source (apps + crates)
$ rg -n '<13-pattern>' apps crates | wc -l                             6

All 6 are inside #[cfg(test)] mod tests blocks (2 docstring breadcrumbs in capability_vocabulary.rs::tests declaring FORMERLY_FORBIDDEN + FORMERLY_LOCAL_PACKAGE migration constants; 4 in inspection.rs::tests for inspection_result_does_not_carry_local_public_data_compatibility_field, an explicitly-named migration test asserting the retired field is gone). Per the ticket's acceptance criteria ("outside archival reports or explicitly named migration tests"), these are allowed.

# 9 banned phrases in records + generated docs
$ rg -i '<9-phrase>' records docs/00-Glossary docs/01-Requirements | wc -l   0

Deploy

=== Deploy complete ===
Build sha:           80087380eeb326e408065a4fabc2cf60b138d546
PWA bundle:          benac-pwa-934f360f24d2ba59.js
Public PWA:          https://benac.benac.dev/

All 11 health probes 200; local↔public bundle hash check matches.

Acceptance criteria — line by line

A package with an unsupported implementation kind but otherwise valid package content:
  imports successfully when package import requirements are satisfied                  ✓
  inspects successfully                                                                ✓
  records the unsupported implementation kind                                          ✓ (host_unsupported_implementation_entries)
  cannot be approved or invoked for that implementation unless Host supports it         ✓ (the 16-step generic gate)

A package declaring a formerly forbidden capability:
  imports successfully when package import requirements are satisfied                  ✓
  inspects successfully                                                                ✓
  shows the requested capability                                                       ✓ (declared_capabilities)
  does not receive that capability automatically                                       ✓ (Local Policy decides)
  cannot invoke an operation requiring that capability unless Local Policy grants it    ✓ (the 16-step gate)

A package with a random unsupported implementation-entry top-level field still fails package document validation.   ✓
The same value placed under `parameters` does not fail solely because of that value.                                ✓
Package approval records are generic `package_approval` records.                                                    ✓
Capability grants are created from approved capabilities, not from a fixed local-public-data list.                  ✓ (CapabilityGrant::from_package_approval)
Trust decisions are scoped from the approval record, not from a fixed local-public-data list.                       ✓ (TrustScope::from_package_approval)
Invocation no longer calls local-public-data-specific capability validation.                                        ✓
Station Profile publishes Host support and resource limits, but Station Profile is not treated as approval or a capability grant.   ✓ (doc-comment + retirement of *_approval_support flag-as-grant pattern)

Standing on caller acceptance

Per the standing-directive log: not assuming closure; holding for caller review.