<!-- GENERATED FILE: edit records/req.*/*.md and run npm run build:syrs. -->

# System Requirements Specification

This SyRS is generated from GraphMD requirement records.

## Source

**Source document:** `/home/johnb/Downloads/benac_syrs_v0_4_integrated_authentication.md`, `user-requested schema-first requirements cleanup`, `operator ticket 266e382d-cab9-4be7-b70c-6cfb7b49dccb`, `operator ticket 258d5227-5a33-4b7f-aa96-3bea75ffa1c6`, `operator ticket 2c9740bd-6943-49e6-bf89-6462e8993fd2`, `operator ticket dc3af413-dc52-4b70-afd0-527af9270195`, `user-requested requirements cleanup`

**Source version:** v0.4, 2026-05-06, 2026-05-04, 2026-05-05, DRISL terminology cleanup pass

## Requirement Index

- [[req:benac-crypto-001]] BENAC-CRYPTO-001 - Versioned cryptographic, content-identity, and DRISL encoding profile
- [[req:benac-crypto-002]] BENAC-CRYPTO-002 - Baseline exact content identifier
- [[req:benac-crypto-003]] BENAC-CRYPTO-003 - Algorithm, profile, and identifier-class identifiers
- [[req:benac-crypto-004]] BENAC-CRYPTO-004 - Structured object binding and raw blob role binding
- [[req:benac-crypto-005]] BENAC-CRYPTO-005 - DRISL document hashing and signing
- [[req:benac-crypto-006]] BENAC-CRYPTO-006 - Signed claim target binding
- [[req:benac-id-001]] BENAC-ID-001 - Station identity
- [[req:benac-id-002]] BENAC-ID-002 - Principal identities
- [[req:benac-id-003]] BENAC-ID-003 - Identity and authentication are not authority
- [[req:benac-sign-001]] BENAC-SIGN-001 - Signed claim support
- [[req:benac-sign-002]] BENAC-SIGN-002 - Signatures separate from package identity
- [[req:benac-sign-003]] BENAC-SIGN-003 - Signature verification before reliance
- [[req:benac-key-001]] BENAC-KEY-001 - Key lifecycle support
- [[req:benac-key-002]] BENAC-KEY-002 - Private keys do not replicate by default
- [[req:benac-name-001]] BENAC-NAME-001 - Names are claims
- [[req:benac-auth-001]] BENAC-AUTH-001 - Distinct authentication model
- [[req:benac-auth-002]] BENAC-AUTH-002 - Authentication is not authority
- [[req:benac-auth-003]] BENAC-AUTH-003 - Local user authentication for sensitive actions
- [[req:benac-auth-004]] BENAC-AUTH-004 - Host-specific authentication methods
- [[req:benac-auth-005]] BENAC-AUTH-005 - Station-to-Station authentication
- [[req:benac-auth-006]] BENAC-AUTH-006 - Replay-resistant remote operations
- [[req:benac-auth-007]] BENAC-AUTH-007 - Agent authentication
- [[req:benac-auth-008]] BENAC-AUTH-008 - Agent authentication cannot self-authorize
- [[req:benac-auth-009]] BENAC-AUTH-009 - Package content authentication
- [[req:benac-auth-010]] BENAC-AUTH-010 - Host-mediated external service authentication
- [[req:benac-auth-011]] BENAC-AUTH-011 - Packages do not receive raw authentication secrets by default
- [[req:benac-auth-012]] BENAC-AUTH-012 - Replication authentication is not content trust
- [[req:benac-auth-013]] BENAC-AUTH-013 - Authentication context in records
- [[req:benac-auth-014]] BENAC-AUTH-014 - Authentication expiry and revocation
- [[req:benac-auth-015]] BENAC-AUTH-015 - Authentication profile
- [[req:benac-sys-001]] BENAC-SYS-001 - Host-neutral core
- [[req:benac-sys-002]] BENAC-SYS-002 - Mobile browser PWA host
- [[req:benac-sys-003]] BENAC-SYS-003 - Desktop platform support
- [[req:benac-sys-004]] BENAC-SYS-004 - Station profile publication
- [[req:benac-sys-005]] BENAC-SYS-005 - No provider-specific core behavior
- [[req:benac-sys-006]] BENAC-SYS-006 - Server is not authority
- [[req:benac-sys-007]] BENAC-SYS-007 - Agent-neutral kernel scope
- [[req:benac-doc-001]] BENAC-DOC-001 - Couch/Pouch-compatible operational document model
- [[req:benac-doc-002]] BENAC-DOC-002 - Local-first operation
- [[req:benac-doc-003]] BENAC-DOC-003 - Optional replication
- [[req:benac-doc-004]] BENAC-DOC-004 - Replication does not grant trust
- [[req:benac-doc-005]] BENAC-DOC-005 - Immutable document identity
- [[req:benac-doc-006]] BENAC-DOC-006 - Append-only record preference
- [[req:benac-doc-007]] BENAC-DOC-007 - Conflict fail-closed behavior
- [[req:benac-doc-008]] BENAC-DOC-008 - Encrypted replicated documents
- [[req:benac-blob-001]] BENAC-BLOB-001 - Local content-addressed blob store
- [[req:benac-blob-002]] BENAC-BLOB-002 - Document-to-blob separation
- [[req:benac-blob-003]] BENAC-BLOB-003 - Blob verification before use
- [[req:benac-blob-004]] BENAC-BLOB-004 - Public and private blob classes
- [[req:benac-blob-005]] BENAC-BLOB-005 - Blob manifests and chunking
- [[req:benac-blob-006]] BENAC-BLOB-006 - Blob availability records
- [[req:benac-blob-007]] BENAC-BLOB-007 - Deduplication for public blobs
- [[req:benac-blob-008]] BENAC-BLOB-008 - Private blob identity
- [[req:benac-blob-009]] BENAC-BLOB-009 - Missing blob fail-closed behavior
- [[req:benac-blob-010]] BENAC-BLOB-010 - No silent remote fetch
- [[req:benac-enc-001]] BENAC-ENC-001 - Client-side encryption for private blobs
- [[req:benac-enc-002]] BENAC-ENC-002 - Encrypted document envelopes
- [[req:benac-enc-003]] BENAC-ENC-003 - Encrypted Package Bundle export/import
- [[req:benac-enc-004]] BENAC-ENC-004 - Envelope encryption
- [[req:benac-enc-005]] BENAC-ENC-005 - Authenticated associated data
- [[req:benac-enc-006]] BENAC-ENC-006 - No deterministic encryption by default
- [[req:benac-enc-007]] BENAC-ENC-007 - Explicit recipient sharing
- [[req:benac-enc-008]] BENAC-ENC-008 - Decryption as capability
- [[req:benac-enc-009]] BENAC-ENC-009 - Private keys not package-readable
- [[req:benac-enc-010]] BENAC-ENC-010 - Plaintext disclosure effects
- [[req:benac-enc-011]] BENAC-ENC-011 - Remote compute decryption treated as disclosure
- [[req:benac-enc-012]] BENAC-ENC-012 - Output encryption requirements
- [[req:benac-enc-013]] BENAC-ENC-013 - Data classes
- [[req:benac-enc-014]] BENAC-ENC-014 - Disclosure warnings
- [[req:benac-enc-015]] BENAC-ENC-015 - Honest limits of encryption
- [[req:benac-enc-016]] BENAC-ENC-016 - Integrity after decryption
- [[req:benac-enc-017]] BENAC-ENC-017 - Revocation honesty
- [[req:benac-enc-018]] BENAC-ENC-018 - Local protected storage
- [[req:benac-enc-019]] BENAC-ENC-019 - Encryption failure fail-closed
- [[req:benac-enc-020]] BENAC-ENC-020 - Stronger privacy mechanisms require separate requirements
- [[req:benac-pkg-001]] BENAC-PKG-001 - Content-addressed packages
- [[req:benac-pkg-002]] BENAC-PKG-002 - Required package document
- [[req:benac-pkg-003]] BENAC-PKG-003 - Package document schema
- [[req:benac-pkg-004]] BENAC-PKG-004 - Package names are non-authoritative
- [[req:benac-pkg-005]] BENAC-PKG-005 - Package interfaces
- [[req:benac-pkg-006]] BENAC-PKG-006 - Package requirements
- [[req:benac-pkg-007]] BENAC-PKG-007 - Package fixtures
- [[req:benac-pkg-008]] BENAC-PKG-008 - Package claims external to package identity
- [[req:benac-pkg-009]] BENAC-PKG-009 - Invocation contract identity
- [[req:benac-pkg-011]] BENAC-PKG-011 - Package artifact availability resolution
- [[req:benac-pkg-012]] BENAC-PKG-012 - Package Bundle Manifest schema
- [[req:benac-desc-001]] BENAC-DESC-001 - Descriptor separation
- [[req:benac-desc-002]] BENAC-DESC-002 - Descriptor config validation
- [[req:benac-schema-001]] BENAC-SCHEMA-001 - Required package schema ruleset
- [[req:benac-desc-003]] BENAC-DESC-003 - Descriptor content addressing
- [[req:benac-desc-004]] BENAC-DESC-004 - Secret references in descriptors
- [[req:benac-desc-005]] BENAC-DESC-005 - Descriptor claims
- [[req:benac-pkg-010]] BENAC-PKG-010 - Interface contract binding
- [[req:benac-schema-002]] BENAC-SCHEMA-002 - Minimum JSON Schema vocabulary
- [[req:benac-schema-003]] BENAC-SCHEMA-003 - Schema reference resolution
- [[req:benac-trust-006]] BENAC-TRUST-006 - Package approval
- [[req:benac-cap-007]] BENAC-CAP-007 - Capability identifiers
- [[req:benac-author-001]] BENAC-AUTHOR-001 - Package validation semantics
- [[req:benac-author-002]] BENAC-AUTHOR-002 - Package build semantics
- [[req:benac-author-003]] BENAC-AUTHOR-003 - Package validation and build reports
- [[req:benac-author-004]] BENAC-AUTHOR-004 - Authoring operations exposed through tools and APIs
- [[req:benac-test-001]] BENAC-TEST-001 - Fixture schema
- [[req:benac-test-002]] BENAC-TEST-002 - Fixture execution semantics
- [[req:benac-test-003]] BENAC-TEST-003 - Fixture result records
- [[req:benac-wasm-001]] BENAC-WASM-001 - WASM package-host calling convention
- [[req:benac-inv-007]] BENAC-INV-007 - Generic invocation input envelope
- [[req:benac-wasm-002]] BENAC-WASM-002 - WASM mediated access restrictions
- [[req:benac-inv-008]] BENAC-INV-008 - Request and output snapshots
- [[req:benac-wasm-003]] BENAC-WASM-003 - WASM package-host calling convention template
- [[req:benac-wasm-004]] BENAC-WASM-004 - Resource limits and enforcement
- [[req:benac-exec-008]] BENAC-EXEC-008 - Interface invocation input
- [[req:benac-ux-008]] BENAC-UX-008 - Package inspection data contract
- [[req:benac-ux-009]] BENAC-UX-009 - Inspection before package approval
- [[req:benac-trust-001]] BENAC-TRUST-001 - Local trust required
- [[req:benac-trust-002]] BENAC-TRUST-002 - Trust is scoped
- [[req:benac-trust-003]] BENAC-TRUST-003 - Authenticated and attributed trust decisions
- [[req:benac-cap-001]] BENAC-CAP-001 - Explicit capability declaration
- [[req:benac-cap-002]] BENAC-CAP-002 - Explicit capability grants
- [[req:benac-trust-004]] BENAC-TRUST-004 - Signatures are evidence, not authority
- [[req:benac-cap-003]] BENAC-CAP-003 - Capability mediation
- [[req:benac-trust-005]] BENAC-TRUST-005 - Revocation
- [[req:benac-cap-004]] BENAC-CAP-004 - Data egress as effect
- [[req:benac-cap-005]] BENAC-CAP-005 - Capability conflict fail-closed behavior
- [[req:benac-cap-006]] BENAC-CAP-006 - Effect-time capability checks
- [[req:benac-exec-001]] BENAC-EXEC-001 - Schema-defined package behavior
- [[req:benac-exec-002]] BENAC-EXEC-002 - WASM package-host calling convention
- [[req:benac-exec-003]] BENAC-EXEC-003 - Isolated execution
- [[req:benac-exec-004]] BENAC-EXEC-004 - No arbitrary same-origin JavaScript packages
- [[req:benac-exec-005]] BENAC-EXEC-005 - Host-native operation attempts
- [[req:benac-exec-006]] BENAC-EXEC-006 - Invocation contract record
- [[req:benac-exec-007]] BENAC-EXEC-007 - Host-mediated package APIs
- [[req:benac-inv-001]] BENAC-INV-001 - Invocation record required
- [[req:benac-inv-002]] BENAC-INV-002 - Invocation fields
- [[req:benac-inv-003]] BENAC-INV-003 - Request validation
- [[req:benac-inv-004]] BENAC-INV-004 - Output validation
- [[req:benac-inv-005]] BENAC-INV-005 - No silent fallback
- [[req:benac-inv-006]] BENAC-INV-006 - Invocation attribution
- [[req:benac-inv-009]] BENAC-INV-009 - Mediated package composition
- [[req:benac-evd-001]] BENAC-EVD-001 - Evidence ledger
- [[req:benac-eff-001]] BENAC-EFF-001 - Effect ledger
- [[req:benac-evd-002]] BENAC-EVD-002 - Raw evidence before interpretation
- [[req:benac-eff-002]] BENAC-EFF-002 - Denied effects recorded
- [[req:benac-aud-001]] BENAC-AUD-001 - Inspectability
- [[req:benac-aud-002]] BENAC-AUD-002 - Causal record linking
- [[req:benac-aud-003]] BENAC-AUD-003 - Queryable inspection
- [[req:benac-aud-crypto-001]] BENAC-AUD-CRYPTO-001 - Tamper-evident records
- [[req:benac-aud-crypto-002]] BENAC-AUD-CRYPTO-002 - Signed remote evidence
- [[req:benac-stor-001]] BENAC-STOR-001 - Storage Station identity and authentication
- [[req:benac-stor-002]] BENAC-STOR-002 - Storage offers
- [[req:benac-stor-003]] BENAC-STOR-003 - Storage descriptors
- [[req:benac-stor-004]] BENAC-STOR-004 - Storage leases
- [[req:benac-stor-005]] BENAC-STOR-005 - Storage operations as effects
- [[req:benac-stor-006]] BENAC-STOR-006 - Storage receipts
- [[req:benac-stor-007]] BENAC-STOR-007 - CID verification on retrieval
- [[req:benac-stor-008]] BENAC-STOR-008 - Public/private storage policy
- [[req:benac-stor-009]] BENAC-STOR-009 - Client-side encryption for private remote storage
- [[req:benac-stor-010]] BENAC-STOR-010 - Blob location claims
- [[req:benac-stor-011]] BENAC-STOR-011 - Storage discovery
- [[req:benac-stor-012]] BENAC-STOR-012 - Storage lease requests
- [[req:benac-stor-013]] BENAC-STOR-013 - Storage/compute coordination
- [[req:benac-stor-014]] BENAC-STOR-014 - No storage authority by replication
- [[req:benac-stor-015]] BENAC-STOR-015 - Missing blob behavior
- [[req:benac-stor-016]] BENAC-STOR-016 - Deletion honesty
- [[req:benac-stor-017]] BENAC-STOR-017 - Storage capability vocabulary
- [[req:benac-stor-018]] BENAC-STOR-018 - Byte and retention limits
- [[req:benac-stor-019]] BENAC-STOR-019 - Storage failure evidence
- [[req:benac-stor-020]] BENAC-STOR-020 - Standard Benac CAS exchange profile
- [[req:benac-comp-001]] BENAC-COMP-001 - Compute offers
- [[req:benac-comp-002]] BENAC-COMP-002 - Compute Station identity and authentication
- [[req:benac-comp-003]] BENAC-COMP-003 - Compute as package/descriptor
- [[req:benac-comp-004]] BENAC-COMP-004 - Host compute and remote compute distinction
- [[req:benac-comp-005]] BENAC-COMP-005 - Compute lease requests
- [[req:benac-comp-006]] BENAC-COMP-006 - Compute leases
- [[req:benac-comp-007]] BENAC-COMP-007 - Remote compute evidence
- [[req:benac-comp-008]] BENAC-COMP-008 - No compute bypass
- [[req:benac-comp-009]] BENAC-COMP-009 - Authenticated remote result binding
- [[req:benac-comp-010]] BENAC-COMP-010 - Plaintext compute warning
- [[req:benac-sec-001]] BENAC-SEC-001 - Host-mediated secrets and authentication credentials
- [[req:benac-sec-002]] BENAC-SEC-002 - Secrets do not replicate by default
- [[req:benac-sec-003]] BENAC-SEC-003 - Secret metadata separation
- [[req:benac-sec-004]] BENAC-SEC-004 - Redaction
- [[req:benac-sec-005]] BENAC-SEC-005 - No default telemetry
- [[req:benac-sec-006]] BENAC-SEC-006 - Raw secrets prohibited outside protected secret handling
- [[req:benac-agt-002]] BENAC-AGT-002 - Agent identity and authentication
- [[req:benac-agt-004]] BENAC-AGT-004 - Agents cannot self-trust
- [[req:benac-agt-005]] BENAC-AGT-005 - Trust and capability requests
- [[req:benac-agt-009]] BENAC-AGT-009 - Agent action audit
- [[req:benac-agt-010]] BENAC-AGT-010 - Machine-readable errors
- [[req:benac-io-001]] BENAC-IO-001 - Local package import
- [[req:benac-io-002]] BENAC-IO-002 - HTTPS import
- [[req:benac-io-004]] BENAC-IO-004 - Missing blob reporting
- [[req:benac-io-005]] BENAC-IO-005 - Package Bundle integrity
- [[req:benac-io-006]] BENAC-IO-006 - Encrypted Package Bundles
- [[req:benac-int-001]] BENAC-INT-001 - DRISL for structured content identity and signatures
- [[req:benac-int-003]] BENAC-INT-003 - Stable diagnostic format
- [[req:benac-io-007]] BENAC-IO-007 - Package Bundle ZIP file structure
- [[req:benac-int-002]] BENAC-INT-002 - Raw byte blob CIDs
- [[req:benac-int-004]] BENAC-INT-004 - Conformance test suite
- [[req:benac-int-005]] BENAC-INT-005 - Same package content and record behavior
- [[req:benac-ux-001]] BENAC-UX-001 - Package inspection
- [[req:benac-ux-002]] BENAC-UX-002 - Trust and capability review
- [[req:benac-ux-003]] BENAC-UX-003 - Invocation trace inspection
- [[req:benac-ux-004]] BENAC-UX-004 - Principal and claim inspection
- [[req:benac-ux-005]] BENAC-UX-005 - Storage and compute authorization review
- [[req:benac-ux-006]] BENAC-UX-006 - Plaintext disclosure review
- [[req:benac-io-003]] BENAC-IO-003 - Package Bundle export
- [[req:benac-ux-007]] BENAC-UX-007 - Authentication review
- [[req:benac-avl-001]] BENAC-AVL-001 - Offline app shell
- [[req:benac-avl-002]] BENAC-AVL-002 - Offline package invocation
- [[req:benac-avl-003]] BENAC-AVL-003 - Clear network/resource failure
- [[req:benac-agt-001]] BENAC-AGT-001 - Machine-readable client API
- [[req:benac-perf-001]] BENAC-PERF-001 - Mobile practicality
- [[req:benac-perf-002]] BENAC-PERF-002 - Large blob caution
- [[req:benac-agt-003]] BENAC-AGT-003 - Agent package authoring
- [[req:benac-safe-001]] BENAC-SAFE-001 - Physical-world effects are explicit
- [[req:benac-safe-002]] BENAC-SAFE-002 - Human approval gates
- [[req:benac-safe-003]] BENAC-SAFE-003 - Emergency revocation
- [[req:benac-safe-004]] BENAC-SAFE-004 - Fail-closed default
- [[req:benac-safe-005]] BENAC-SAFE-005 - User override with receipt
- [[req:benac-host-001]] BENAC-HOST-001 - Host API semantics
- [[req:benac-host-002]] BENAC-HOST-002 - Package host interface mediation
- [[req:benac-host-003]] BENAC-HOST-003 - Package-visible input boundary
- [[req:benac-repl-001]] BENAC-REPL-001 - Replication interface CID verification
- [[req:benac-stor-021]] BENAC-STOR-021 - Storage interface
- [[req:benac-comp-011]] BENAC-COMP-011 - Compute interface
- [[req:benac-auth-016]] BENAC-AUTH-016 - Authentication interface
- [[req:benac-data-001]] BENAC-DATA-001 - Minimum logical data object CID fields
- [[req:benac-data-002]] BENAC-DATA-002 - Package authoring logical objects

## 10.1 Cryptographic identity, content identity, and provenance foundation

Baseline terminology: In baseline Benac requirements, "CID" means DASL CID v1 unless a future codec or hash extension explicitly permits otherwise. A raw blob CID identifies the exact raw byte sequence using DASL CID raw codec 0x55. A structured document CID identifies the DRISL byte representation of the logical Benac object using DASL CID DRISL codec 0x71. Portable Benac records shall use CIDs, not bare digest strings, for exact content identity. "Hash" refers to the digest operation or digest component inside a content identifier unless the requirement explicitly says otherwise.

The baseline profile shall normatively identify the exact DASL CID, DRISL, CBOR, CBOR Tag 42, RFC 4648 base32, and SHA-256 specifications and versions used for conformance.

### BENAC-CRYPTO-001 - Versioned cryptographic, content-identity, and DRISL encoding profile

**Statement:** Benac shall define a versioned cryptographic profile covering DASL CID content identifiers, hash algorithms, signature algorithms, key identifier formats, signed claim envelopes, encryption envelopes, DRISL encoding rules for structured objects that are content-addressed or signed, object-type and context binding rules, key wrapping, encrypted object metadata, Couch/Pouch projection rules for payloads used in CIDs or signatures, and conformance vectors. The baseline exact content-identity profile shall use DASL CID v1. The baseline structured-object encoding profile for signed or content-addressed structured Benac objects shall use DRISL.

**Rationale:** Independent implementations must agree on the exact bytes being hashed, signed, encrypted, verified, imported, exported, replicated, and disclosed. Couch/Pouch provides the operational document model, while DRISL provides deterministic structured bytes and DASL CIDs provide exact content identity.

**Verification:** Conformance tests use the published cryptographic profile and test vectors across browser PWA, Ubuntu, macOS, and Windows Host Platforms, including DASL CID parsing, generation, rejection, and normalization vectors; DRISL encoding vectors; Couch/Pouch-to-DRISL projection vectors; signed claim vectors; encrypted envelope vectors; and cross-platform content identity vectors.

**Status:** draft

**Source record:** `records/req.benac-crypto-001/benac-crypto-001.md`

### BENAC-CRYPTO-002 - Baseline exact content identifier

**Statement:** Benac shall use DASL CID v1 as the required baseline exact content identifier for raw blobs and content-addressed structured documents. Raw blob CIDs shall be computed over the exact raw byte sequence using SHA-256 and DASL CID raw codec 0x55. Structured document CIDs shall be computed over the DRISL bytes produced by encoding the logical Benac object according to the required DRISL rules using SHA-256 and DASL CID DRISL codec 0x71. The baseline DASL CID profile shall use string prefix b, lowercase RFC 4648 base32 string encoding, CID byte version 0x01, SHA-256 hash type 0x12, hash size 0x20, and a 32-byte digest.

**Rationale:** All implementations need one common exact content identifier format, not merely one common digest algorithm. DASL CID v1 gives Benac a portable identifier for raw byte content and DRISL-encoded structured content.

**Verification:** Cross-platform vectors produce identical DASL CIDs for identical raw byte sequences and identical DRISL-encoded structured documents. Malformed CIDs, unsupported versions, unsupported codecs, unsupported hash types, wrong hash sizes, truncated digests, extra bytes, and malformed string encodings are rejected. CID string vectors shall verify prefix b, lowercase RFC 4648 base32 encoding, required CID string form, and rejection of uppercase, padded, mixed-case, wrong-prefix, malformed, truncated, or trailing-byte forms unless a future codec or encoding addition explicitly permits another encoding.

**Status:** draft

**Source record:** `records/req.benac-crypto-002/benac-crypto-002.md`

### BENAC-CRYPTO-003 - Algorithm, profile, and identifier-class identifiers

**Statement:** Portable Benac records shall represent exact content identity as DASL CIDs rather than bare digest strings. DASL CIDs carry the content-identity version, content codec, hash algorithm, hash size, and digest. Signatures, encrypted objects, wrapped keys, key identifiers, authentication records, signed claim envelopes, and encryption envelopes shall still include explicit algorithm or profile identifiers sufficient for unambiguous interpretation. Structured Benac objects that are content-addressed or signed shall identify their Benac object type, schema/profile version, and required semantic context inside the logical payload encoded as DRISL. Signed and encrypted envelopes shall additionally identify their own envelope object type, algorithm profile, and cryptographic context.

**Rationale:** Algorithm agility and safe upgrades require unambiguous interpretation. CIDs identify exact content, while signatures, encryption envelopes, claims, and keys still require their own algorithm and profile identifiers.

**Verification:** Objects lacking required algorithm, profile, or identifier-class information are rejected. Portable records that use bare SHA-256 digest strings where DASL CIDs are required are rejected.

**Status:** draft

**Source record:** `records/req.benac-crypto-003/benac-crypto-003.md`

### BENAC-CRYPTO-004 - Structured object binding and raw blob role binding

**Statement:** Benac shall ensure that content-addressed structured object identity is separated by object type and profile version. For structured content-addressed documents, object-type and profile separation shall be achieved by mandatory fields inside the logical payload encoded as DRISL, including at least Benac object type, schema/profile version, and required semantic role fields. For raw blobs, the DASL CID shall identify only the exact raw byte sequence. Benac-specific roles for raw blobs, including package artifact, evidence body, encrypted payload, media object, compute input, storage chunk, or package bundle component, shall be bound by typed references, manifests, signed claims, invocations, evidence records, effect records, leases, or policies. Benac shall not apply Benac-only hash-input prefixes and then represent the result as an ordinary DASL CID unless such behavior is explicitly defined as a separate content-identity profile.

**Rationale:** A structured package document must not be confused with a schema, claim, descriptor, invocation, evidence record, effect record, receipt, or package bundle. DASL CIDs identify raw bytes or DRISL bytes; Benac object semantics are bound through typed content and typed references.

**Verification:** Cross-object confusion fixtures are rejected. Structured objects with missing or mismatched Benac type, schema/profile version, or required semantic role fields fail validation. Raw blob CIDs remain identical for identical bytes regardless of role, but role substitution fails through typed-reference, claim, manifest, invocation, evidence, effect, lease, or policy validation.

**Status:** draft

**Source record:** `records/req.benac-crypto-004/benac-crypto-004.md`

### BENAC-CRYPTO-005 - DRISL document hashing and signing

**Statement:** Benac shall use DRISL as the baseline deterministic structured encoding for all structured Benac objects that are content-addressed, signed, exported as immutable, included in tamper-evident records, or verified across implementations. For such objects, Benac shall validate the logical Benac object and encode that logical object as DRISL before hashing or signing. Couch/Pouch-compatible documents are operational storage and replication envelopes. Couch/Pouch-managed metadata, including _id, _rev, revision history, conflict metadata, sync state, local availability, local verification status, local UI state, and host-local indexes, shall not be included in the logical payload used for CIDs or signatures. If a Benac schema needs analogous information, it shall define explicit logical payload fields for that information rather than relying on Couch/Pouch-managed metadata. The baseline JSON projection of CID links shall use the AT-style {"$link": "b..."} representation. CIDs inside DRISL shall be encoded using CBOR Tag 42 over a byte string containing 0x00 followed by the binary DASL CID bytes. Signed claim envelopes and signed claim payloads shall be signed over DRISL bytes or over another explicitly defined byte sequence derived from DRISL.

**Rationale:** Different JSON formatting, document-store metadata, Couch/Pouch revision state, or host-local fields must not produce different identities for the same logical object. DRISL gives independent implementations the same structured bytes.

**Verification:** DRISL encoding vectors match across Host Platforms. Couch/Pouch documents with different _id, _rev, local state, sync state, or field ordering but the same logical payload produce the same DRISL bytes and structured CID. Payload mutations produce different CIDs. DRISL rejection vectors cover unsupported tags, non-string map keys, unsupported simple values, trailing bytes, concatenated objects, and other DRISL-invalid encodings. CID-in-DRISL vectors shall verify CBOR Tag 42 encoding with byte-string payload 0x00 || binary_dasl_cid and shall reject malformed Tag 42 payloads.

**Status:** draft

**Source record:** `records/req.benac-crypto-005/benac-crypto-005.md`

### BENAC-CRYPTO-006 - Signed claim target binding

**Statement:** Signed claims shall bind explicitly to a typed target reference. For content-addressed target objects, the typed target reference shall include target DASL CID, target CID codec, target Benac object type or role, and target schema/profile identifier where applicable. For non-content-addressed targets, including principals, authentication sessions, names, or other identifier classes, the typed target reference shall include target identifier class, profile-defined target identifier, target type or role, and applicable identifier/profile version. All signed claims shall bind claim type, issuer principal, cryptographic profile, signed-claim envelope profile, content-identity profile where applicable, structured-object encoding profile where applicable, and claim payload used for signature verification. A claim about one target identifier, object, role, profile, issuer, or claim type shall not be transferable to another.

**Rationale:** A claim about one exact object, role, profile, or claim type must not be transferable to another object or misread under another profile.

**Verification:** Claim substitution tests fail verification or policy evaluation when the target identifier class, target identifier, target CID, target CID codec, object type, role, schema/profile, claim type, issuer, cryptographic profile, signed-claim envelope profile, content-identity profile, structured-object encoding profile, or signed payload changes.

**Status:** draft

**Source record:** `records/req.benac-crypto-006/benac-crypto-006.md`

### BENAC-ID-001 - Station identity

**Statement:** Each Benac Station shall generate or import a cryptographic Station principal used to attribute local invocations, exports, replication participation, Station-to-Station authentication, remote-resource offers, receipts, and locally produced claims.

**Rationale:** Station identity allows Benac to attribute actions without relying on a central account provider or registry.

**Verification:** Create a fresh Station and verify that it has a Station principal, that the principal can be referenced in records, and that no remote authority is required to create it.

**Status:** draft

**Source record:** `records/req.benac-id-001/benac-id-001.md`

### BENAC-ID-002 - Principal identities

**Statement:** Benac shall represent users, agents, package authors, reviewers, Storage Stations, Compute Stations, Host Implementations, and organizations as cryptographic principals where cross-Station attribution, provenance, or authorization is required.

**Rationale:** Decentralized systems need key-based attribution without a central account provider.

**Verification:** Signed claim fixtures validate principal identifiers and signatures.

**Status:** draft

**Source record:** `records/req.benac-id-002/benac-id-002.md`

### BENAC-ID-003 - Identity and authentication are not authority

**Statement:** A principal identity and an authenticated session shall not grant authority by themselves. Local policy shall decide whether a claim, actor, package, Station, Storage Station, Compute Station, agent, or authenticated session may be relied on or used.

**Rationale:** Decentralized systems need attribution and authentication, but Benac remains locally sovereign.

**Verification:** Import a signed claim from an authenticated principal that is not locally trusted and verify that the claim is visible as evidence but does not grant execution or capability authority.

**Status:** draft

**Source record:** `records/req.benac-id-003/benac-id-003.md`

### BENAC-SIGN-001 - Signed claim support

**Statement:** Benac shall support signed claim documents targeting content-addressed objects, principals, descriptors, tests, storage offers, storage receipts, compute offers, compute results, trust requests, name bindings, package bundles, and disclosure records.

**Rationale:** Provenance and decentralized review require attributable claims.

**Verification:** Signed claim import, verification, invalid signature, and unknown signer tests.

**Status:** draft

**Source record:** `records/req.benac-sign-001/benac-sign-001.md`

### BENAC-SIGN-002 - Signatures separate from package identity

**Statement:** Package signatures and attestations shall be separate claim documents that reference package CIDs. Adding or removing a signature shall not change the package CID.

**Rationale:** Package content identity must remain stable as independent parties add reviews or attestations.

**Verification:** Same package CID remains unchanged after adding signed claim documents.

**Status:** draft

**Source record:** `records/req.benac-sign-002/benac-sign-002.md`

### BENAC-SIGN-003 - Signature verification before reliance

**Statement:** Benac shall verify signed claims before displaying them as verified, using them in policy, or including them as verified evidence.

**Rationale:** Unverified claims must not be mistaken for trusted provenance.

**Verification:** Invalid signature claim appears unverified and cannot satisfy policy.

**Status:** draft

**Source record:** `records/req.benac-sign-003/benac-sign-003.md`

### BENAC-KEY-001 - Key lifecycle support

**Statement:** Benac shall support key generation, import, export or backup where allowed, rotation, revocation, compromise marking, and compromise recovery for Station, user, and agent principals.

**Rationale:** Long-lived decentralized systems need recoverable and revocable identity.

**Verification:** Key lifecycle test flows; revoked principal cannot satisfy future policy unless explicitly allowed.

**Status:** draft

**Source record:** `records/req.benac-key-001/benac-key-001.md`

### BENAC-KEY-002 - Private keys do not replicate by default

**Statement:** Private keys shall not replicate by default through Couch/Pouch replication, package export, package bundle export, storage upload, or package import.

**Rationale:** Replication and storage should not spread signing authority.

**Verification:** Export, replication, and storage tests confirm private key material is excluded unless explicitly encrypted and exported by local policy.

**Status:** draft

**Source record:** `records/req.benac-key-002/benac-key-002.md`

### BENAC-NAME-001 - Names are claims

**Statement:** Human-readable names, aliases, tags, and package labels used across Stations shall be represented as local or signed name-binding claims and shall not override content identity or principal identity.

**Rationale:** Names are useful but mutable and non-authoritative.

**Verification:** Invocation records use resolved CIDs and principal IDs, not names alone.

**Status:** draft

**Source record:** `records/req.benac-name-001/benac-name-001.md`

## 10.2 Authentication and authority boundaries

### BENAC-AUTH-001 - Distinct authentication model

**Statement:** Benac shall distinguish identity, authentication, authorization, and trust in data models, API responses, user-facing reviews, and conformance tests.

**Rationale:** Multiple implementations must not treat login, signature verification, or peer authentication as automatic permission.

**Verification:** Inspect the system schema and run conformance tests proving that an authenticated principal remains unauthorized until local policy grants authority.

**Status:** draft

**Source record:** `records/req.benac-auth-001/benac-auth-001.md`

### BENAC-AUTH-002 - Authentication is not authority

**Statement:** Authentication shall not by itself grant package execution authority, capability grants, secret access, storage authority, compute authority, replication authority, plaintext disclosure authority, or trust.

**Rationale:** A Station can authenticate a dangerous or untrusted actor perfectly. Benac must still govern power locally.

**Verification:** Authenticate a remote Station, package author, and agent that lack local grants and verify that each remains unable to perform authority-bearing operations.

**Status:** draft

**Source record:** `records/req.benac-auth-002/benac-auth-002.md`

### BENAC-AUTH-003 - Local user authentication for sensitive actions

**Statement:** Each Host Station shall support a local user authentication or re-authentication mechanism for vault unlock and sensitive authority-bearing actions, including package trust, capability grants, secret use, private blob sharing, key wrapping, private data export, storage leases, compute leases, and plaintext disclosure approvals.

**Rationale:** Authority-bearing actions must reflect authenticated local intent rather than accidental UI state or agent request text.

**Verification:** Attempt sensitive actions before and after local user authentication and verify that unauthenticated attempts fail closed or remain pending approval.

**Status:** draft

**Source record:** `records/req.benac-auth-003/benac-auth-003.md`

### BENAC-AUTH-004 - Host-specific authentication methods

**Statement:** Benac shall define the semantics required for local user authentication while allowing each Host Implementation to use platform-appropriate mechanisms, such as passphrases, passkeys, biometric-mediated host flows, OS keychain unlock, browser-supported credential flows, or equivalent local mechanisms.

**Rationale:** Mobile browser, desktop browser, Ubuntu, macOS, and Windows cannot be forced into one identical authentication implementation, but they can share semantics.

**Verification:** Review authentication profile support and conformance traces showing that each Station records authentication context for local authority-bearing actions. Traces shall record method class, issuer principal, scope, creation time, expiry, approval binding, and any host/platform evidence actually available to that implementation. Conformance verifies shared authentication semantics, not identical platform mechanisms.

**Status:** draft

**Source record:** `records/req.benac-auth-004/benac-auth-004.md`

### BENAC-AUTH-005 - Station-to-Station authentication

**Statement:** Benac shall support cryptographic authentication of Station principals for Station-to-Station communication where identity, receipts, claims, storage, compute, replication, or data disclosure depend on the remote Station.

**Rationale:** HTTPS or network reachability alone is not Benac identity. Remote operations must be attributable to Station principals.

**Verification:** Complete an authenticated challenge/response or signed-message exchange with a Peer Station and verify that records bind the operation to the authenticated Station principal.

**Status:** draft

**Source record:** `records/req.benac-auth-005/benac-auth-005.md`

### BENAC-AUTH-006 - Replay-resistant remote operations

**Statement:** Remote compute results, storage receipts, lease-bound operations, and authenticated remote claims shall be bound to request CIDs or profile-defined request identifiers, nonces or challenges, relevant lease identifiers, Station principals, package CIDs and invocation contract snapshot CIDs where applicable, output/evidence CIDs, and timestamps or sequence information.

**Rationale:** Authentication must prevent trivial substitution or replay of stale results and receipts.

**Verification:** Replay an old authenticated result with a new request or nonce and verify that Benac rejects it or records it as invalid.

**Status:** draft

**Source record:** `records/req.benac-auth-006/benac-auth-006.md`

### BENAC-AUTH-007 - Agent authentication

**Statement:** Benac shall support authentication of agent principals or locally scoped agent sessions and shall bind agent actions to authenticated agent identity where agent authority, package authoring, invocation, storage lease requests, compute lease requests, trust requests, or auditing depends on attribution.

**Rationale:** Agents are first-class Benac clients and must be accountable without becoming sovereign.

**Verification:** Have two agents perform package-authoring and trust-request actions and verify that records identify the correct authenticated agent or local agent session.

**Status:** draft

**Source record:** `records/req.benac-auth-007/benac-auth-007.md`

### BENAC-AUTH-008 - Agent authentication cannot self-authorize

**Statement:** Agent authentication shall not allow agents to grant themselves package trust, capability grants, secret access, storage leases, compute leases, decryption authority, plaintext disclosure authority, or policy mutation authority.

**Rationale:** Agent authentication should make experimentation attributable without turning identity into authority. Agents may build, test, invoke, and request power, but approval and escalation remain separate Local Policy decisions.

**Verification:** Authenticate an agent and verify that attempts to self-approve sensitive authority fail closed or create pending requests only.

**Status:** draft

**Source record:** `records/req.benac-auth-008/benac-auth-008.md`

### BENAC-AUTH-009 - Package content authentication

**Statement:** Benac shall authenticate package content by DASL CID and authenticate package-related authorship, review, build, test, name-binding, and conformance claims through signed claim documents.

**Rationale:** Package identity is content identity; author identity and review provenance are separate signed claims.

**Verification:** Add or remove a package signature and verify that the package CID does not change, while claim verification status changes separately.

**Status:** draft

**Source record:** `records/req.benac-auth-009/benac-auth-009.md`

### BENAC-AUTH-010 - Host-mediated external service authentication

**Statement:** Benac shall support host-mediated authentication to external services through descriptor authentication references, local vault entries, scoped credential use, and approved capability grants.

**Rationale:** Packages need to use APIs and services, but they shall not receive raw credentials by default.

**Verification:** Invoke a package that authenticates to an external service and verify that the Host Station injects or applies credentials only through an approved operation and redacts secrets from evidence.

**Status:** draft

**Source record:** `records/req.benac-auth-010/benac-auth-010.md`

### BENAC-AUTH-011 - Packages do not receive raw authentication secrets by default

**Statement:** Packages shall not receive raw passwords, tokens, API keys, private keys, session cookies, or other authentication secrets by default. Secret or credential use shall be mediated by the Host Station and recorded as an effect.

**Rationale:** Package code should not be able to exfiltrate long-lived credentials merely because it can request an authenticated operation.

**Verification:** Inspect package inputs and host interface calls during an authenticated external request and verify that raw secret material is not exposed to the package unless explicitly granted by a high-risk policy.

**Status:** draft

**Source record:** `records/req.benac-auth-011/benac-auth-011.md`

### BENAC-AUTH-012 - Replication authentication is not content trust

**Statement:** Benac may authenticate replication peers or document-store endpoints, but replicated content shall still be subject to CID verification, signature verification, schema validation, conflict policy, encryption policy, and local trust decisions.

**Rationale:** An authenticated sync peer can still send incorrect, malicious, stale, or unauthorized data.

**Verification:** Replicate invalid or untrusted content from an authenticated peer and verify that Benac stores or rejects it according to policy without granting execution authority.

**Status:** draft

**Source record:** `records/req.benac-auth-012/benac-auth-012.md`

### BENAC-AUTH-013 - Authentication context in records

**Statement:** Benac shall record relevant authentication context in invocation, evidence, effect, trust, capability, storage, compute, disclosure, replication, secret-use, and audit records.

**Rationale:** Operators, users, agents, and conformance tests need to know which authenticated actor or Station participated in an action.

**Verification:** Perform authenticated user approval, authenticated agent action, authenticated storage operation, and authenticated compute operation and inspect the resulting records.

**Status:** draft

**Source record:** `records/req.benac-auth-013/benac-auth-013.md`

### BENAC-AUTH-014 - Authentication expiry and revocation

**Statement:** Benac shall support authentication/session expiry, credential revocation metadata, failed authentication records, and failure-closed behavior for expired, missing, revoked, malformed, replayed, or invalid authentication.

**Rationale:** Authentication must be accountable over time and cannot be treated as permanent once observed.

**Verification:** Expire or revoke an authenticated session or credential and verify that subsequent authority-bearing operations fail or require fresh authentication.

**Status:** draft

**Source record:** `records/req.benac-auth-014/benac-auth-014.md`

### BENAC-AUTH-015 - Authentication profile

**Statement:** Benac shall define a versioned authentication profile covering local user authentication semantics, Station-to-Station authentication, agent authentication, external-service authentication mediation, authentication context records, session expiry, revocation, replay protection, and conformance vectors.

**Rationale:** Multiple Host Implementations may use different authentication mechanisms while still producing interoperable authority and audit semantics.

**Verification:** Implementations publish supported authentication profile features and pass profile-specific conformance tests.

**Status:** draft

**Source record:** `records/req.benac-auth-015/benac-auth-015.md`

## 10.3 Host neutrality and platform coverage

### BENAC-SYS-001 - Host-neutral core

**Statement:** Benac Core shall be defined independently of any single host platform, programming language, browser, operating system, cloud provider, database implementation, registry, Storage Station, Compute Station, or account provider.

**Rationale:** Multiple teams must be able to implement Benac on mobile browser, desktop browser, Ubuntu, macOS, and Windows without changing package semantics.

**Verification:** Architecture inspection; conformance tests executed against at least two independently implemented Host Platforms.

**Status:** draft

**Source record:** `records/req.benac-sys-001/benac-sys-001.md`

### BENAC-SYS-002 - Mobile browser PWA host

**Statement:** A Benac browser host shall be installable as an HTTPS-served Progressive Web App and shall operate in mobile browsers on iOS and Android using browser-available capabilities only.

**Rationale:** The mobile browser host is the strict capability floor that prevents the core from depending on privileged platform assumptions.

**Verification:** Demonstration on iOS and Android mobile browsers; offline app shell test; package import and hello-world invocation test.

**Status:** draft

**Source record:** `records/req.benac-sys-002/benac-sys-002.md`

### BENAC-SYS-003 - Desktop platform support

**Statement:** Benac shall support Host Implementations on Ubuntu, macOS, and Windows while preserving the same package, descriptor, invocation, identity, trust, capability, encryption, storage, compute, evidence, effect, document, blob, and signed claim semantics used by the browser host.

**Rationale:** Benac must be multi-platform without fragmenting into incompatible products.

**Verification:** Same conformance package runs on browser PWA, Ubuntu, macOS, and Windows implementations.

**Status:** draft

**Source record:** `records/req.benac-sys-003/benac-sys-003.md`

## Host neutrality and platform coverage

### BENAC-SYS-004 - Station profile publication

**Statement:** Each Benac Station shall publish a machine-readable Station Profile describing known Station information useful for planning, inspection, diagnostics, conformance, and user review.

A Station Profile shall describe Host Platform, Host Implementation, Host artifact or Host version where available, known Benac semantic interfaces, known package document versions, known schema rulesets, known artifact availability mechanisms, known fixture execution behavior, known package inspection behavior, known package approval behavior, known capability identifiers the Station can mediate where known, known authentication features, known cryptographic features, known replication features, known storage features, known compute features, known calling conventions, and conservative policy-relevant constraints.

A Station Profile shall publish known package-authoring and operation limits where known, including maximum package document size, Package Bundle size, schema size, fixture size, artifact size, request size, descriptor config size, output size, memory, operation time or fuel policy, log size, evidence record size, and effect record size.

A Station Profile shall not be treated as a complete list of everything the Host Platform can do.

A Station Profile shall not be treated as proof that a requested capability is currently available.

A Station Profile shall not be treated as proof that a requested operation will succeed.

A Station Profile shall not be treated as proof that required artifacts, physical resources, external services, platform permissions, network connectivity, storage offers, compute offers, authentication state, or Local Policy grants are currently available.

A Station Profile shall not be treated as approval.

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

A Station can update known status after inspection, Local Policy decisions, allowed probes, allowed attempts, platform permission decisions, resource checks, artifact checks, failures, or completed operations.

A Station Profile shall not classify packages.

A Station Profile shall not classify how package work is performed.

**Rationale:** Agents, users, and package authors need a starting map for planning and review, but actual use is governed by Local Policy, capability grants, leases, offers, allowed probes, allowed attempts, conformance traces, and failure records.

**Verification:** Validate the Station Profile schema. Conformance tests inspect the profile for known Station information and published limits, then verify behavior through inspection, package approval, invocation, evidence, effect, and failure records. Tests verify that Station Profile information does not grant authority and does not prove current resource availability.

**Status:** draft

**Source record:** `records/req.benac-sys-004/benac-sys-004.md`

## 10.3 Host neutrality and platform coverage

### BENAC-SYS-005 - No provider-specific core behavior

**Statement:** Benac Core and baseline hosts shall not include built-in behavior specific to OpenAI, Anthropic, Gemini, Qwen, MCP, Hue, weather APIs, smart-home products, vehicles, games, cloud object stores, cloud compute providers, or any other provider/product/domain.

**Rationale:** Provider, domain, Storage Station, and Compute Station behavior belongs in packages, not in the kernel.

**Verification:** Code and manifest inspection; fresh database contains no provider-specific package by default.

**Status:** draft

**Source record:** `records/req.benac-sys-005/benac-sys-005.md`

### BENAC-SYS-006 - Server is not authority

**Statement:** A server that serves the PWA or assists a host shall not be required as the authority for package identity, trust decisions, execution permission, principal identity, storage authority, compute authority, or invocation evidence.

**Rationale:** Benac must remain local-first and decentralized.

**Verification:** PWA can import, trust, invoke, store locally, export, and inspect a package without a central service after installation.

**Status:** draft

**Source record:** `records/req.benac-sys-006/benac-sys-006.md`

## 10.3 Host-neutral and platform scope

### BENAC-SYS-007 - Agent-neutral kernel scope

**Statement:** Benac Core shall not define or require agent cognition, agent goals, planner state, recovery strategies, memory architecture, autonomous loops, workflow semantics, task decomposition, environment-change proposal semantics, or model-specific reasoning behavior. Such behavior belongs in agents, packages, descriptors, external clients, prompts, user interfaces, or optional future profile additions. Benac Core shall define the semantic substrate needed for such clients to inspect, author, validate, invoke, compose, store, compute, diagnose, audit, and request authority under Local Policy.

**Rationale:** Benac should be a legible test track and road system, not an agent design. Agents must be able to grow and experiment on top of Benac without requiring the kernel to know what kind of agent is driving.

**Verification:** Requirements review confirms no baseline requirement mandates agent goals, planner state, recovery loops, workflow semantics, or model-specific reasoning behavior. Conformance tests exercise package authoring, fixture execution, invocation, diagnostics, storage/compute lease requests, causal record linking, and inspection without depending on any specific agent architecture.

**Status:** draft

**Source record:** `records/req.benac-sys-007/benac-sys-007.md`

## 10.4 Local-first document store, claims, and replication

### BENAC-DOC-001 - Couch/Pouch-compatible operational document model

**Statement:** Benac shall use a Couch/Pouch-compatible document model for operational storage and replication of structured metadata, package records, descriptor records, signed claim records, trust records, capability grants, storage offers, storage leases, compute offers, compute leases, invocations, evidence records, effect records, agent records, privacy records, and sync configuration. Couch/Pouch-compatible documents may store JSON projections of logical Benac objects and may carry replicated or local operational metadata. Cryptographic identity for signed or content-addressed structured payloads shall be derived from the logical Benac object encoded as DRISL, not from the entire Couch/Pouch document. Couch/Pouch-managed metadata and host-local operational metadata shall not be part of the payload used to compute a CID or verify a signature. If a schema needs information similar to document id, revision, conflict, verification, or availability state, that information shall be represented as explicit schema-defined logical payload fields.

**Rationale:** Replication must shape the data model from day one, but Couch/Pouch revision metadata and local operational state are not stable cryptographic payloads. Benac separates operational replication from structured content identity.

**Verification:** Document schema validation and local PouchDB or equivalent Couch-compatible replication adapter demonstration. Tests verify that changes to _id, _rev, conflict metadata, local verification state, local availability state, or UI state do not change the structured document CID, while changes to the logical payload do.

**Status:** draft

**Source record:** `records/req.benac-doc-001/benac-doc-001.md`

### BENAC-DOC-002 - Local-first operation

**Statement:** A Benac Station shall operate with a local document store and shall not require a remote document store to import, inspect, trust, invoke, store, retrieve local blobs, or audit local packages.

**Rationale:** Remote databases are peers, not authorities.

**Verification:** Fresh local Station demo with no configured sync peer.

**Status:** draft

**Source record:** `records/req.benac-doc-002/benac-doc-002.md`

### BENAC-DOC-003 - Optional replication

**Statement:** Benac shall support optional Couch-compatible replication of eligible operational documents to and from user-configured peers. After replication, content-addressed payloads shall be verified by recomputing DASL CIDs from raw bytes or DRISL bytes, and signed claims shall be verified before reliance.

**Rationale:** Packages, traces, claims, descriptors, storage offers, compute offers, and evidence should be decentralized and portable across Stations.

**Verification:** Two-Station replication test; CID and signature verification after replication.

**Status:** draft

**Source record:** `records/req.benac-doc-003/benac-doc-003.md`

### BENAC-DOC-004 - Replication does not grant trust

**Statement:** Benac shall not treat replicated packages, descriptors, trust records, capability grants, signatures, claims, name bindings, storage offers, blob location claims, storage receipts, compute offers, or compute results as automatically trusted, usable, or executable.

**Rationale:** Replication moves data; local policy grants power.

**Verification:** Replicated untrusted package, storage offer, and compute offer cannot be used until local trust/policy allows it.

**Status:** draft

**Source record:** `records/req.benac-doc-004/benac-doc-004.md`

### BENAC-DOC-005 - Immutable document identity

**Statement:** Immutable structured objects such as package documents, schema documents, descriptor snapshots, signed claim payloads, blob manifests, fixture documents, and additional structured documents where applicable shall be represented as logical objects encoded as DRISL and identified by DASL CIDs and shall not be mutated under the same CID.

**Rationale:** Replay and audit require stable identity.

**Verification:** CID mismatch tests; mutation creates a new CID.

**Status:** draft

**Source record:** `records/req.benac-doc-005/benac-doc-005.md`

### BENAC-DOC-006 - Append-only record preference

**Statement:** Invocation, evidence, effect, disclosure, storage operation, compute operation, and audit records should be append-only or versioned in a way that preserves the original record and its attribution.

**Rationale:** Records are receipts and should not be silently rewritten.

**Verification:** Attempted mutation test; audit trail inspection.

**Status:** draft

**Source record:** `records/req.benac-doc-006/benac-doc-006.md`

### BENAC-DOC-007 - Conflict fail-closed behavior

**Statement:** Conflicts affecting trust, capability grants, secret bindings, key status, execution policy, privacy policy, storage leases, compute leases, decryption authority, or safety-sensitive configuration shall fail closed until resolved locally.

**Rationale:** Replication conflict resolution must not accidentally escalate authority.

**Verification:** Simulated replication conflict denies execution, remote storage, remote compute, or decryption until resolved.

**Status:** draft

**Source record:** `records/req.benac-doc-007/benac-doc-007.md`

### BENAC-DOC-008 - Encrypted replicated documents

**Statement:** Benac shall support encrypted private document envelopes for sensitive documents that are selected for replication or export.

**Rationale:** Decentralized replication should support private sharing without plaintext exposure.

**Verification:** Encrypted private document replicates; authorized recipient decrypts; unauthorized replica cannot read plaintext.

**Status:** draft

**Source record:** `records/req.benac-doc-008/benac-doc-008.md`

## 10.5 Content-addressed blob store and content availability

### BENAC-BLOB-001 - Local content-addressed blob store

**Statement:** Every Benac host shall provide a local content-addressed blob store for immutable byte artifacts referenced by documents. Blob identity shall use DASL CID v1 raw CIDs.

**Rationale:** Package artifacts, WASM modules, evidence bodies, media, fixtures, encrypted private payloads, and staged compute inputs require byte storage separate from document metadata.

**Verification:** Host stores, retrieves, verifies, exports, and imports blobs by DASL CID.

**Status:** draft

**Source record:** `records/req.benac-blob-001/benac-blob-001.md`

### BENAC-BLOB-002 - Document-to-blob separation

**Statement:** Benac shall separate structured document replication from immutable blob storage. Documents may reference blobs by DASL CID, but large blob bytes shall be managed by the blob store or explicit blob-transfer mechanisms.

**Rationale:** Pouch/Couch documents are the metadata/control plane; the blob store is the byte plane.

**Verification:** Package document references artifact blob; metadata can replicate without artifact bytes.

**Status:** draft

**Source record:** `records/req.benac-blob-002/benac-blob-002.md`

### BENAC-BLOB-003 - Blob verification before use

**Statement:** Benac shall verify retrieved blob bytes against the expected DASL CID before using them for package execution, evidence interpretation, decryption, import, export, storage staging, or further replication.

**Rationale:** Remote and local storage may be faulty or malicious.

**Verification:** Corrupted blob retrieval fails verification and records an integrity failure.

**Status:** draft

**Source record:** `records/req.benac-blob-003/benac-blob-003.md`

### BENAC-BLOB-004 - Public and private blob classes

**Statement:** Benac shall distinguish public content-addressed blobs from private encrypted blobs and shall allow local policy to classify blobs by data class and disclosure sensitivity.

**Rationale:** Package artifacts may be public while evidence, media, and compute inputs may be sensitive.

**Verification:** Classification fixture controls whether blob may be uploaded raw or only encrypted.

**Status:** draft

**Source record:** `records/req.benac-blob-004/benac-blob-004.md`

### BENAC-BLOB-005 - Blob manifests and chunking

**Statement:** Benac shall support blob manifests for large or chunked blobs, including chunk CIDs, chunk sizes, total size, media type, compression metadata, encryption metadata where applicable, and top-level content identity.

**Rationale:** Large artifacts, model fragments, media, and evidence bodies need resumable transfer and partial availability.

**Verification:** Chunked blob conformance fixture retrieves and verifies chunks and reconstructed content.

**Status:** draft

**Source record:** `records/req.benac-blob-005/benac-blob-005.md`

### BENAC-BLOB-006 - Blob availability records

**Statement:** Benac shall maintain records indicating whether a blob is present locally, missing locally, remotely available, pinned remotely, encrypted, staged for compute, partially available, or unavailable.

**Rationale:** Replicated documents may reference bytes that are not currently present on this Station.

**Verification:** Missing required artifact produces a clear missing-blob state and denies execution.

**Status:** draft

**Source record:** `records/req.benac-blob-006/benac-blob-006.md`

### BENAC-BLOB-007 - Deduplication for public blobs

**Statement:** Benac may deduplicate public blobs by DASL CID where host storage permits.

**Rationale:** Content addressing naturally avoids storing identical public artifacts repeatedly.

**Verification:** Duplicate public blob import stores one verified content object or equivalent references.

**Status:** draft

**Source record:** `records/req.benac-blob-007/benac-blob-007.md`

### BENAC-BLOB-008 - Private blob identity

**Statement:** Benac shall define how private encrypted blobs represent ciphertext CIDs and, where local policy permits, plaintext CIDs or plaintext verification metadata. Benac shall not require public disclosure of plaintext CIDs or plaintext digest metadata for sensitive private blobs.

**Rationale:** Plaintext CIDs or digest metadata can leak information about private content.

**Verification:** Encrypted private blob tests distinguish ciphertext CID from plaintext verification metadata.

**Status:** draft

**Source record:** `records/req.benac-blob-008/benac-blob-008.md`

### BENAC-BLOB-009 - Missing blob fail-closed behavior

**Statement:** If a required blob is missing locally and no approved retrieval path exists, Benac shall fail loudly before package execution or evidence interpretation.

**Rationale:** Metadata alone is not enough to run code or verify evidence.

**Verification:** Metadata-only import cannot execute package until artifacts are retrieved and verified.

**Status:** draft

**Source record:** `records/req.benac-blob-009/benac-blob-009.md`

### BENAC-BLOB-010 - No silent remote fetch

**Statement:** Benac shall not silently fetch missing executable, package, private, or evidence blobs from remote storage unless local acquisition policy explicitly permits that behavior and records the effect.

**Rationale:** Remote fetch can disclose interest, incur cost, or import untrusted bytes.

**Verification:** Missing blob acquisition test requires explicit policy or user approval.

**Status:** draft

**Source record:** `records/req.benac-blob-010/benac-blob-010.md`

## 10.6 Encryption, decryption, and disclosure control

### BENAC-ENC-001 - Client-side encryption for private blobs

**Statement:** Benac shall support client-side encryption for private blobs before remote storage, replication, export, sharing, or compute staging.

**Rationale:** Remote storage and replication peers need not be trusted with plaintext.

**Verification:** Private blob uploaded to remote storage is ciphertext; authorized local Station decrypts and verifies.

**Status:** draft

**Source record:** `records/req.benac-enc-001/benac-enc-001.md`

### BENAC-ENC-002 - Encrypted document envelopes

**Statement:** Benac shall support encrypted document envelopes for private replicated documents, private descriptors, private evidence metadata, private storage lease requests, private compute lease requests, optional supporting materials, and private agent workspaces.

**Rationale:** Document replication should not force plaintext disclosure.

**Verification:** Encrypted document replicates as opaque envelope to unauthorized Station and decrypts for authorized recipient.

**Status:** draft

**Source record:** `records/req.benac-enc-002/benac-enc-002.md`

### BENAC-ENC-003 - Encrypted Package Bundle export/import

**Statement:** Benac shall support public, encrypted-to-recipient, multi-recipient, and passphrase-protected package bundle export/import modes.

**Rationale:** Users need to move private packages, traces, and blobs between Stations without central services.

**Verification:** Encrypted package bundle exported from one host imports and decrypts on authorized host only.

**Status:** draft

**Source record:** `records/req.benac-enc-003/benac-enc-003.md`

### BENAC-ENC-004 - Envelope encryption

**Statement:** Benac shall use envelope encryption for private blobs and private documents, with per-object content-encryption keys and recipient-specific key wrapping.

**Rationale:** Recipient-based sharing should not require re-encrypting entire objects and should avoid exposing long-term private keys.

**Verification:** Multiple recipient fixture decrypts with authorized recipient key and fails for non-recipient.

**Status:** draft

**Source record:** `records/req.benac-enc-004/benac-enc-004.md`

### BENAC-ENC-005 - Authenticated associated data

**Statement:** Benac shall authenticate encryption metadata as associated data, including object type, cryptographic profile version, content-identity profile, structured-object encoding profile where applicable, expected plaintext or ciphertext CID where applicable, data class, intended use, lease identifiers where applicable, creator principal where applicable, and recipient information where appropriate.

**Rationale:** Encrypted objects must not be recontextualized without detection.

**Verification:** Tampered AAD fixture fails decryption or integrity verification.

**Status:** draft

**Source record:** `records/req.benac-enc-005/benac-enc-005.md`

### BENAC-ENC-006 - No deterministic encryption by default

**Statement:** Benac shall not use deterministic or convergent encryption for private blobs by default.

**Rationale:** Deterministic encryption leaks equality and can enable guessing attacks.

**Verification:** Same private plaintext encrypted twice produces different ciphertext unless explicit opt-in profile is used.

**Status:** draft

**Source record:** `records/req.benac-enc-006/benac-enc-006.md`

### BENAC-ENC-007 - Explicit recipient sharing

**Statement:** Benac shall support explicit recipient-based sharing of private blobs and private documents by wrapping content keys only to approved principal identities.

**Rationale:** Sharing should be precise and attributable.

**Verification:** Adding a recipient creates an auditable key-wrapping/disclosure effect.

**Status:** draft

**Source record:** `records/req.benac-enc-007/benac-enc-007.md`

### BENAC-ENC-008 - Decryption as capability

**Statement:** Benac shall treat decryption, key unwrapping, key wrapping, and plaintext release as explicit capabilities mediated by the host.

**Rationale:** Packages and agents must not casually decrypt private data.

**Verification:** Package without decryption grant cannot read plaintext blob.

**Status:** draft

**Source record:** `records/req.benac-enc-008/benac-enc-008.md`

### BENAC-ENC-009 - Private keys not package-readable

**Statement:** Benac shall keep private keys, long-term principal keys, raw secret material, and default content-encryption keys out of package-readable data.

**Rationale:** Package compromise must not automatically compromise identity or all encrypted data.

**Verification:** WASM package cannot read private keys or raw content keys through host interface.

**Status:** draft

**Source record:** `records/req.benac-enc-009/benac-enc-009.md`

### BENAC-ENC-010 - Plaintext disclosure effects

**Statement:** Benac shall record effects when private blobs, private documents, content keys, or plaintext become decryptable by additional principals, packages, hosts, or Compute Stations.

**Rationale:** Disclosure is the real privacy boundary.

**Verification:** Remote compute input key wrapping creates a private-data-disclosure effect record.

**Status:** draft

**Source record:** `records/req.benac-enc-010/benac-enc-010.md`

### BENAC-ENC-011 - Remote compute decryption treated as disclosure

**Statement:** Benac shall treat remote compute decryption as plaintext disclosure to the compute principal and shall require an approved compute lease for such disclosure.

**Rationale:** Encryption cannot protect data after a remote compute host receives plaintext or keys.

**Verification:** Attempt to send decryptable private blob to compute without lease is denied.

**Status:** draft

**Source record:** `records/req.benac-enc-011/benac-enc-011.md`

### BENAC-ENC-012 - Output encryption requirements

**Statement:** Benac shall support storage and compute lease terms requiring outputs, intermediate blobs, or evidence bodies to be encrypted to specified recipient principals before storage, transfer, or return.

**Rationale:** Remote compute and storage should not unnecessarily expose outputs in plaintext.

**Verification:** Compute fixture returns encrypted output and records recipient set.

**Status:** draft

**Source record:** `records/req.benac-enc-012/benac-enc-012.md`

### BENAC-ENC-013 - Data classes

**Statement:** Benac shall support data classes for local policy decisions, including at least public, private, private media, credential, secret material, and implementation-defined high-sensitivity classes.

**Rationale:** Policy needs to distinguish harmless package artifacts from sensitive human data.

**Verification:** Policy denies public compute for high-sensitivity data class unless explicitly overridden.

**Status:** draft

**Source record:** `records/req.benac-enc-013/benac-enc-013.md`

### BENAC-ENC-014 - Disclosure warnings

**Statement:** Benac shall provide user-facing and agent-facing warnings when private data will become decryptable to a remote principal, Storage Station acting as processor, Compute Station, package, or host outside the local Station.

**Rationale:** Users and agents need to understand when encryption stops protecting data from a recipient.

**Verification:** High-sensitivity remote compute request requires visible warning/acknowledgment in conformance fixture.

**Status:** draft

**Source record:** `records/req.benac-enc-014/benac-enc-014.md`

### BENAC-ENC-015 - Honest limits of encryption

**Statement:** Benac shall not claim that encryption proves remote compute deletes plaintext, prevents copying after decryption, or guarantees safe processing by an untrusted recipient.

**Rationale:** Avoid privacy theater and false guarantees.

**Verification:** UX/API text and policy metadata distinguish encrypted storage from plaintext compute disclosure.

**Status:** draft

**Source record:** `records/req.benac-enc-015/benac-enc-015.md`

### BENAC-ENC-016 - Integrity after decryption

**Statement:** Benac shall verify decrypted blob integrity against the expected plaintext CID or plaintext verification metadata before package execution, evidence interpretation, further sharing, or output acceptance.

**Rationale:** Encrypted storage protects confidentiality but integrity must still be verified.

**Verification:** Tampered ciphertext or wrong key fails integrity verification.

**Status:** draft

**Source record:** `records/req.benac-enc-016/benac-enc-016.md`

### BENAC-ENC-017 - Revocation honesty

**Statement:** Benac shall distinguish revocation of future access from impossible guarantees of deletion, forgetting, or removal of plaintext already disclosed.

**Rationale:** Benac cannot claw back data already decrypted by another host.

**Verification:** Revocation UI/API records future-access denial and does not claim historical deletion.

**Status:** draft

**Source record:** `records/req.benac-enc-017/benac-enc-017.md`

### BENAC-ENC-018 - Local protected storage

**Statement:** Benac shall provide host-mediated protected storage for private keys, wrapped content keys, local vault metadata, and secret material.

**Rationale:** Sensitive key material needs platform-appropriate protection.

**Verification:** Browser and desktop Host Platforms demonstrate protected storage or documented host-equivalent controls.

**Status:** draft

**Source record:** `records/req.benac-enc-018/benac-enc-018.md`

### BENAC-ENC-019 - Encryption failure fail-closed

**Statement:** Benac shall fail closed when required keys, recipient identities, encryption metadata, decryption integrity checks, lease bindings, or data-class policies are invalid, missing, conflicted, or revoked.

**Rationale:** Ambiguity shall not create plaintext access.

**Verification:** Missing recipient key or invalid envelope denies decryption/use.

**Status:** draft

**Source record:** `records/req.benac-enc-019/benac-enc-019.md`

### BENAC-ENC-020 - Stronger privacy mechanisms require separate requirements

**Statement:** If Benac supports trusted execution environments, remote attestation, secure multiparty computation, homomorphic encryption, or zero-knowledge proof packages, the semantics shall be defined by separate requirements and conformance tests. Benac shall not imply those guarantees from package import, package approval, package trust, encryption support, or ordinary compute support.

**Rationale:** Stronger privacy mechanisms need explicit semantics and conformance tests rather than implied guarantees.

**Verification:** Conformance tests prove ordinary package import, package approval, package trust, encryption support, and ordinary compute support do not imply TEE, remote attestation, MPC, FHE, or zero-knowledge proof guarantees.

**Status:** draft

**Source record:** `records/req.benac-enc-020/benac-enc-020.md`

## 10.7 Package model, descriptors, and package claims

### BENAC-PKG-001 - Content-addressed packages

**Statement:** Packages shall be immutable content-addressed structured objects. Package identity shall be the DASL CID of the DRISL-encoded package document. Changing any field of the package document shall produce a new package CID.

**Rationale:** Package identity must be stable for audit, execution, storage, compute, and replication.

**Verification:** Modifying manifest content or artifact references changes the package CID.

**Status:** draft

**Source record:** `records/req.benac-pkg-001/benac-pkg-001.md`

## Package model, descriptors, and package claims

### BENAC-PKG-002 - Required package document

**Statement:** A package shall include a package document declaring package metadata, schemas, schema ruleset identifiers, package interfaces, interface contract bindings, artifact references, requested capabilities, resource requirements, storage needs where relevant, compute needs where relevant, fixtures, documentation references, evidence behavior, and effect behavior.
A package interface shall define how the Station talks to the package and how the package talks back.
A package interface shall bind request schema, descriptor config schema where relevant, output schema where relevant, declared capabilities, artifact requirements, resource requirements, evidence behavior, and effect behavior.
The package document shall not classify the package.
The package document shall not classify how package work is performed.
The package document shall not include a field whose purpose is to assign package behavior to a package-work taxonomy.
Package-specific, provider-specific, product-specific, model-specific, library-specific, platform-specific, or operation-specific configuration shall be carried in schema-defined descriptor configuration, schema-defined package parameters, structured package documents, claims, or content-addressed artifacts.
The package CID shall be derived from the DRISL-encoded package document and shall not be a required field inside that document.
A Couch/Pouch envelope, index record, import record, Package Bundle, or external provenance record shall carry the package CID and related claim references outside the package document payload used to compute the package CID.

**Rationale:** The kernel needs the package's public conversation contract: how to validate a request, how to validate descriptor configuration, how to validate output, what authority the package requests, which artifacts and resources are required, and what evidence and effects are expected. The kernel does not need a taxonomy of package internals.

**Verification:** Package document schema validation tests verify that required package document fields are present, that package CID derivation excludes external claim references, that adding or removing external claims does not change the package CID, and that retired class fields fail validation.

**Status:** draft

**Source record:** `records/req.benac-pkg-002/benac-pkg-002.md`

### BENAC-PKG-003 - Package document schema

**Statement:** Benac shall define a versioned package document schema.
A package document schema shall be closed by default.
A Host Implementation shall reject unknown required package document fields.
A Host Implementation shall reject unknown required package interface fields.
The package document schema shall include stable fields for package document version, package metadata, schemas, schema ruleset identifiers, package interfaces, request schema references, descriptor config schema references, output schema references, declared capabilities, artifact references, resource requirements, fixtures, documentation references, storage needs, compute needs, evidence behavior, and effect behavior.
The package document schema shall not include a field whose purpose is to assign the package to a named package class.
The package document schema shall not include a field whose purpose is to classify how package work is performed.
The package document schema shall not include a field whose purpose is to pre-decide operation eligibility.
The package document schema shall not include a field whose purpose is to classify unsupported behavior.
A package document shall remain content-valid when the current Station cannot currently mediate an operation requested by a package interface, unless that operation is required for package import or package validation.
A package document shall remain content-valid when Local Policy has not granted a capability required only for approval, fixture execution, invocation, package-requested effects, retrieval, storage, or compute.
A package document shall remain content-valid when an artifact required only for approval, fixture execution, invocation, package-requested effects, retrieval, storage, or compute is unavailable.
A Host Implementation shall record those conditions by operation phase.

**Rationale:** Independent implementations need compatible package document interpretation and fail-closed handling for fields they do not understand. Package content validity is separate from Local Policy, artifact availability, resource availability, and current Station ability to mediate an operation.

**Verification:** Unknown required field fixtures fail validation. Valid package documents for greeting, calculator, todo reducer, notes reducer, schema-bound behavior, and multi-interface packages validate consistently across conforming implementations. A package document containing a retired class field fails validation. A package whose requested invocation operation is not currently mediated by the validating Station remains content-valid when import and validation requirements are otherwise satisfied.

**Status:** draft

**Source record:** `records/req.benac-pkg-003/benac-pkg-003.md`

### BENAC-PKG-004 - Package names are non-authoritative

**Statement:** Package names, versions, aliases, URLs, provider names, model names, product names, library names, repository names, labels, and human-readable descriptions shall not be used as package identity, authority, trust, approval, capability, artifact availability, or invocation eligibility.
Invocation records shall identify package CID, invoked package interface, descriptor snapshot CID or descriptor scope where relevant, request snapshot CID, output snapshot CID where relevant, invocation contract snapshot CID where relevant, capability grants relied upon, evidence records, and effect records.
A human-readable name shall not replace package CID or schema-bound invocation context.

**Rationale:** Names can collide, mutate, or mislead. Package identity and invocation authority require content identity, schema-bound context, and explicit Local Policy records.

**Verification:** Two packages with the same name have different package CIDs and are treated distinctly. Changing a package name does not change a capability grant or approval unless the package document content changes and produces a new package CID.

**Status:** draft

**Source record:** `records/req.benac-pkg-004/benac-pkg-004.md`

### BENAC-PKG-005 - Package interfaces

**Statement:** A package shall declare one or more package interfaces.
A package interface shall identify how the Station talks to the package and how the package talks back.
Each package interface declaration shall identify the interface identifier, request schema reference, descriptor config schema reference where relevant, output schema reference where relevant, declared capabilities by operation phase, artifact requirements, resource requirements, evidence behavior, effect behavior, and diagnostic behavior where relevant.
A package interface shall describe the contract for invoking that interface.
A package interface shall not grant capability authority.
A package interface shall not classify the package.
A package interface shall not classify how package work is performed.
A package interface shall not rely on names, labels, filenames, provider names, product names, model names, repository names, URLs, or human-readable descriptions as authority.
Invocation shall resolve the package interface before request validation, descriptor config validation, capability review, artifact availability review, resource review, evidence recording, effect recording, or output validation.

**Rationale:** Interfaces are the package's public conversation surface. They define request shape, configuration shape, output shape, requested authority, required artifacts, resources, evidence, and effects without exposing or classifying package internals.

**Verification:** Interface declaration controls compatible invocation requests. A package with calculator and formatter interfaces validates and invokes each interface under the correct request, config, and output schemas. A request valid for one interface fails under the wrong interface.

**Status:** draft

**Source record:** `records/req.benac-pkg-005/benac-pkg-005.md`

### BENAC-PKG-006 - Package requirements

**Statement:** A package shall declare the capabilities, artifacts, resources, schemas, fixtures, evidence behavior, and effect behavior required for each package interface.
A package shall declare which requirements apply to package import, package validation, package inspection, package approval, fixture execution, package invocation, package-requested effects, retrieval operations, storage operations, and compute operations.
A package declaration shall not grant authority.
Package import shall not grant authority.
Package trust shall not grant authority by itself.
Local Policy shall decide what package-requested capabilities and operations are allowed.
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 attempt a package operation unless Local Policy grants the capabilities required for that operation.
A Host Implementation shall not invoke a package interface unless package content is valid, the selected package interface is identified, the request validates against the interface request schema, descriptor config validates where relevant, required artifacts are available, resource requirements are satisfied, and Local Policy grants the capabilities required for invocation.
A package shall not be rejected as package content merely because the current Station cannot currently mediate an operation requested by a package interface, unless that operation is required for package import or package validation.
Unsupported, unknown, unavailable, denied, missing, expired, revoked, conflicted, or not-yet-determined requirements shall be recorded according to the operation phase for which the requirement is declared.

**Rationale:** Benac packages declare what they need. The Local Station decides what can be attempted or used. Importing a package, trusting a package, recognizing a package label, or recognizing a schema-bound interface does not give the package authority.

**Verification:** Tests import and inspect packages with different declared capabilities, artifacts, resources, schemas, and interfaces. 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 denied, missing, expired, revoked, conflicted, unavailable, or not yet determined. Tests verify that inability to mediate an invocation operation does not by itself make package content invalid when package import and package validation requirements are otherwise satisfied.

**Status:** draft

**Source record:** `records/req.benac-pkg-006/benac-pkg-006.md`

### BENAC-PKG-007 - Package fixtures

**Statement:** A package shall declare fixture references when the package relies on fixture records for validation, inspection, approval, fixture execution, package invocation, evidence behavior, effect behavior, or conformance.
A package declaring `fixture_execution` as a capability required for approval, fixture execution, or invocation shall provide fixture records discoverable from the package document, Package Bundle Manifest, or imported Station state according to the declared validation context.
Fixture records shall identify the package under test, package interface under test, request input, descriptor config where relevant, expected output, expected diagnostics, expected evidence behavior, expected effect behavior, fixture data class, and fixture purpose.
Fixture records shall bind to the package CID outside the package document payload used to compute the package CID.
Absence of a fixture required for an operation shall block that operation and shall not change package content identity.
Fixture records shall not classify packages.
Fixture records shall not classify how package work is performed.

**Rationale:** Package authors and independent implementations need repeatable package tests before relying on package behavior. Fixtures are operation evidence, not package classes.

**Verification:** Fixture execution produces fixture result records or test result claims. A package that declares fixture execution as required for approval or invocation fails that operation when required fixtures are not discoverable. Package CID remains unchanged when fixture records are added outside the package document hash input.

**Status:** draft

**Source record:** `records/req.benac-pkg-007/benac-pkg-007.md`

## 10.7 Package model, descriptors, and package claims

### BENAC-PKG-008 - Package claims external to package identity

**Statement:** Package author claims, review claims, build claims, test claims, storage claims, and compute claims shall be external claim documents that reference package CIDs. Claims may be distributed in package bundles, catalogs, provenance stores, or replicated documents, but they shall not be part of the package document used to compute the package CID.

**Rationale:** Claims should accumulate without changing package identity.

**Verification:** Adding a test claim does not change the package CID.

**Status:** draft

**Source record:** `records/req.benac-pkg-008/benac-pkg-008.md`

## Package model, descriptors, and package claims

### BENAC-PKG-009 - Invocation contract identity

**Statement:** Benac shall define a stable invocation contract snapshot for use in approval, invocation, audit, storage, compute, evidence, and effect records.
An invocation contract snapshot shall identify the exact schema-bound package contract relied upon for a package operation.
An invocation contract snapshot shall include package CID, package interface identifier, request schema CID, descriptor config schema CID where relevant, output schema CID where relevant, descriptor snapshot CID or descriptor scope where relevant, declared capability identifiers relevant to the operation phase, artifact CIDs relevant to the operation phase, resource requirements relevant to the operation phase, evidence behavior, effect behavior, data class where relevant, and Local Policy context where relevant.
An invocation contract snapshot shall not include a package class.
An invocation contract snapshot shall not include package-work taxonomy fields.
An invocation contract snapshot shall not include a field whose purpose is to classify how package work is performed.
The invocation contract snapshot CID shall be the DASL CID of the DRISL-encoded invocation contract snapshot.
Artifact CIDs and schema CIDs can be components of invocation contract identity, but shall not by themselves replace the invocation contract snapshot CID unless the schema explicitly defines a narrower snapshot rule.
A Station shall not infer authority, trust, approval, invocation eligibility, or content validity from labels, names, filenames, provider names, product names, model names, repository names, URLs, or human-readable descriptions.

**Rationale:** Invocation, approval, trust, audit, storage, and compute records need to identify exactly which package interface, schemas, descriptor scope, artifacts, capabilities, resources, evidence behavior, and effect behavior were relied upon. This identity is a schema-bound operation contract, not a classification of package internals.

**Verification:** Multi-interface package fixtures produce deterministic invocation contract snapshot CIDs across Host Platforms. Changing request schema, descriptor config schema, output schema, descriptor scope, declared capabilities, artifact CIDs, resource requirements, evidence behavior, or effect behavior changes the invocation contract snapshot CID. Adding a class label is not required and does not produce a valid invocation contract snapshot.

**Status:** draft

**Source record:** `records/req.benac-pkg-009/benac-pkg-009.md`

## Package authoring

### BENAC-PKG-011 - Package artifact availability resolution

**Statement:** Benac shall resolve package artifact availability during package import from verified Package Bundle ZIP entries and verified Local Station stores.

A package artifact shall be resolved by artifact role, CID, and CID codec.

A structured document artifact shall be available only when the Host Implementation has a logical object whose DRISL-encoded structured document CID equals the expected CID.

A raw blob artifact shall be available only when the Host Implementation has exact bytes whose raw blob CID equals the expected CID.

During Package Bundle ZIP import, the Host Implementation shall verify every structured document and raw blob declared by the Package Bundle Manifest.

An included structured document artifact shall be verified from the ZIP entry declared by the Package Bundle Manifest.

An included raw blob artifact shall be verified from the ZIP entry declared by the Package Bundle Manifest.

An included artifact with a CID mismatch shall fail package import.

A Package Bundle Manifest shall not declare whether an artifact is present in the Local Station document store or Local Station blob store.

A Package Bundle Manifest shall not declare an artifact as `present_in_local_store`.

A Package Bundle Manifest shall not declare an artifact as `retrieval_required`.

A Package Bundle Manifest shall not declare an artifact as `missing`.

Local artifact presence and missing-artifact status shall be derived by the importing Station.

Package import shall not fetch remote artifacts.

Package import shall not treat URLs, paths, storage offers, provider responses, filenames, labels, package names, model names, repository names, release names, branch names, tags, redirects, or human-readable descriptions as artifact availability.

A package whose import-required artifacts are unavailable shall fail package import.

A package whose validation-required artifacts are unavailable shall fail package validation.

A package whose approval-required artifacts are unavailable shall prevent package approval.

A package whose invocation-required artifacts are unavailable shall prevent package invocation.

**Rationale:** A Package Bundle Manifest can declare which objects and bytes are included in the Package Bundle ZIP file. It cannot declare what is already present in an arbitrary importing Station. Availability is Station state derived from verified ZIP contents and verified local stores.

**Verification:** Tests cover included structured document artifacts, included raw blob artifacts, unavailable import-required artifacts, unavailable validation-required artifacts, unavailable approval-required artifacts, unavailable invocation-required artifacts, and CID mismatch. Tests prove that package import does not fetch remote artifacts and does not treat names, paths, URLs, or provider metadata as artifact availability.

**Status:** draft

**Source record:** `records/req.benac-pkg-011/benac-pkg-011.md`

### BENAC-PKG-012 - Package Bundle Manifest schema

**Statement:** Benac shall define a Package Bundle Manifest logical object.

A Package Bundle Manifest shall have `object_type` equal to `package_bundle_manifest`.

A Package Bundle Manifest shall have `schema_version` equal to the supported Package Bundle Manifest schema version.

A Package Bundle Manifest shall identify the package CID.

A Package Bundle Manifest shall identify exactly one package document entry.

A Package Bundle Manifest shall contain an `entries` array.

Each item in `entries` shall contain:

- `path`
- `entry_role`
- `cid`
- `cid_codec`
- `media_type`
- `size_bytes`

The `path` field shall equal the normalized relative ZIP entry path.

The `entry_role` field shall use only entry roles defined by the Package Bundle Manifest schema.

The supported entry roles for this requirement shall include:

- `package_document`
- `structured_document`
- `raw_blob`

The package document entry shall have `entry_role` equal to `package_document`.

The package document entry CID shall equal the package CID.

A structured document entry shall declare `cid_codec` equal to the structured document CID codec.

A raw blob entry shall declare `cid_codec` equal to the raw blob CID codec.

The Package Bundle Manifest shall be the only Package Bundle ZIP entry that defines ZIP entry roles, path-to-CID bindings, package document binding, included supporting object set, included fixture set, included report set, included claim set, and included raw blob set.

Package document semantics shall be derived from the verified package document referenced by the Package Bundle Manifest.

Package distribution-context semantics shall be derived from the verified Package Bundle Manifest.

A Host Implementation shall not use any other ZIP entry as an alternate path-to-CID map, artifact index, package import index, artifact availability source, fixture discovery source, report discovery source, claim discovery source, identity source, integrity source, approval source, invocation source, or trust source.

A Package Bundle Manifest shall fail validation when it contains a missing required field, unknown required field, unsupported schema version, unsupported entry role, unresolved required reference, missing declared ZIP entry, undeclared ZIP entry, malformed CID, unsupported CID codec, structured document CID mismatch, raw blob CID mismatch, unsupported object type, unsupported object schema version, unsupported behavior-class marker, or a field containing the CID of the Package Bundle Manifest itself.

**Rationale:** The Package Bundle Manifest is the distribution contract for the Package Bundle ZIP file. It identifies the package document and the included supporting objects and bytes by exact CID. Package identity remains the package CID.

**Verification:** Conformance tests validate a correct Package Bundle Manifest containing a package document, structured document entries, and raw blob entries. Conformance tests reject manifests with missing required fields, unknown required fields, wrong package CID, unsupported schema version, unsupported entry role, unresolved reference, malformed CID, unsupported CID codec, missing declared ZIP entry, undeclared ZIP entry, structured document CID mismatch, raw blob CID mismatch, unsupported object type, unsupported object schema version, unsupported behavior-class marker, and any field containing the CID of the Package Bundle Manifest itself.

**Status:** draft

**Source record:** `records/req.benac-pkg-012/benac-pkg-012.md`

## 10.7 Package model, descriptors, and package claims

### BENAC-DESC-001 - Descriptor separation

**Statement:** Benac shall distinguish reusable package content from configured descriptors that bind package behavior to local configuration, endpoints, Storage Stations, Compute Stations, secret references, or device context.

**Rationale:** The same package should be reusable across many configured sources, Storage Stations, Compute Stations, or devices.

**Verification:** Descriptor uses package CID and config; package CID unchanged.

**Status:** draft

**Source record:** `records/req.benac-desc-001/benac-desc-001.md`

### BENAC-DESC-002 - Descriptor config validation

**Statement:** Descriptor configuration shall be validated against the package descriptor config schema before trust, invocation, storage use, compute use, or execution. Descriptor config validation shall use the declared package schema ruleset or another explicitly declared and supported schema ruleset. A Host Implementation shall not substitute implementation-specific schema behavior without recording the schema ruleset used and passing conformance vectors for that ruleset.

**Rationale:** Invalid configuration should fail loudly before effects occur, and independent implementations must validate descriptor configuration the same way.

**Verification:** Invalid descriptor config is rejected. Descriptor config validation fixtures produce equivalent valid/invalid decisions and diagnostic records containing stable diagnostic classification codes, required context bindings, and raw or origin-specific evidence references where practical and safe across conforming implementations.

**Status:** draft

**Source record:** `records/req.benac-desc-002/benac-desc-002.md`

## Package authoring

### BENAC-SCHEMA-001 - Required package schema ruleset

**Statement:** Benac shall define a required package schema ruleset for package documents, package interfaces, request schemas, descriptor config schemas, output schemas, fixtures, validation reports, build reports, inspection results, invocation records, evidence records, effect records, package approval records, capability grants, and Package Bundle Manifests.
The required package schema ruleset shall define supported JSON Schema vocabulary, unsupported keyword behavior, reference resolution behavior, diagnostic behavior, and conformance vectors.
The required package schema ruleset shall not define package classes.
The required package schema ruleset shall not define classes for how package work is performed.

**Rationale:** Independent package authors and Host Implementations need the same schema behavior for package documents, requests, descriptor configs, outputs, and package records.

**Verification:** Schema conformance tests verify supported and unsupported keywords, reference resolution, diagnostics, and rejection of unknown required fields.

**Status:** draft

**Source record:** `records/req.benac-schema-001/benac-schema-001.md`

## 10.7 Package model, descriptors, and package claims

### BENAC-DESC-003 - Descriptor content addressing

**Statement:** Descriptor snapshots used in portable invocation records shall be content-addressed by DASL CID. Local-only ephemeral descriptor references may use other immutable mechanisms, but any descriptor snapshot exported, replicated, signed, used in a portable invocation record, or verified across implementations shall be represented as a descriptor snapshot encoded as DRISL and identified by a DASL CID.

**Rationale:** Invocation traces need exact configuration identity.

**Verification:** Invocation records reference descriptor snapshot CIDs for portable traces. Mutating descriptor configuration produces a new descriptor snapshot CID.

**Status:** draft

**Source record:** `records/req.benac-desc-003/benac-desc-003.md`

### BENAC-DESC-004 - Secret references in descriptors

**Statement:** Descriptors may reference secrets by local secret reference, but shall not contain raw secret material by default.

**Rationale:** Descriptors may replicate; secrets should not.

**Verification:** Descriptor export contains secret reference metadata, not raw value.

**Status:** draft

**Source record:** `records/req.benac-desc-004/benac-desc-004.md`

### BENAC-DESC-005 - Descriptor claims

**Statement:** Benac shall support local or signed claims about descriptors, including endorsements, test results, storage suitability, compute suitability, and configuration warnings.

**Rationale:** Configured package instances need review and provenance too.

**Verification:** Descriptor claim imports and verifies separately from descriptor identity.

**Status:** draft

**Source record:** `records/req.benac-desc-005/benac-desc-005.md`

## Package model, descriptors, and package claims

### BENAC-PKG-010 - Interface contract binding

**Statement:** Each invokable package interface shall bind an interface identifier, request schema reference, descriptor config schema reference where relevant, output schema reference where relevant, declared capabilities by operation phase, artifact requirements by operation phase, resource requirements by operation phase, evidence behavior, effect behavior, and diagnostic behavior where relevant.
Invocation shall resolve the interface identifier before request validation, descriptor config validation, capability review, artifact availability review, resource review, operation mediation, output validation, evidence recording, or effect recording.
If descriptor configuration changes which capabilities, artifacts, resources, evidence behavior, or effect behavior apply to an invocation, the descriptor config schema shall define those choices and the resulting invocation contract snapshot shall bind the chosen values.
Interface contract binding shall not classify the package.
Interface contract binding shall not classify how package work is performed.

**Rationale:** A package can expose multiple schema-bound surfaces. The Station must know which contract is being invoked before validating input, reviewing authority, mediating an operation, or recording effects.

**Verification:** A package with calculator and formatter interfaces validates and invokes each interface under the correct schemas. A descriptor configuration that selects different artifacts or capabilities changes the invocation contract snapshot. A request valid for one interface but invalid for another fails under the wrong interface.

**Status:** draft

**Source record:** `records/req.benac-pkg-010/benac-pkg-010.md`

## Package authoring

### BENAC-SCHEMA-002 - Minimum JSON Schema vocabulary

**Statement:** The required package schema ruleset shall support at least JSON values of type object, array, string, number, integer, boolean, and null; object properties; required properties; additionalProperties; array items; enum; const; nested schemas; minimum and maximum for numbers; minLength and maxLength for strings; minItems and maxItems for arrays; and local schema definitions/references as defined by the ruleset. Unsupported validation keywords shall either be rejected as unsupported or treated as annotations only according to explicit ruleset behavior.

**Rationale:** Calculator, todo, notes, and simple transform packages need numbers, booleans, arrays, nested objects, enums, and strings. The hello-world subset is too small for interoperable package authoring.

**Verification:** Calculator schema, todo reducer schema, notes reducer schema, nested object schema, array schema, enum schema, and invalid-type fixtures validate consistently across implementations.

**Status:** draft

**Source record:** `records/req.benac-schema-002/benac-schema-002.md`

### BENAC-SCHEMA-003 - Schema reference resolution

**Statement:** Package schema references shall resolve only to package-declared schemas, local definitions within a schema document, or CID-bound schema documents included in the package bundle unless an explicitly supported optional behavior permits another source. Schema reference resolution shall not silently fetch remote schemas. Unresolved, ambiguous, unsupported, or cyclic references where cycles are unsupported shall fail closed with diagnostic records.

**Rationale:** Remote schema URLs must not become hidden dependencies or mutable authorities.

**Verification:** A package referencing a missing schema CID fails validation. A package referencing an HTTPS schema URL without approved retrieval behavior fails validation or treats the URL as non-authoritative metadata only.

**Status:** draft

**Source record:** `records/req.benac-schema-003/benac-schema-003.md`

## Package approval and capability grants

### BENAC-TRUST-006 - Package approval

**Statement:** Benac shall define a package approval record.
A package approval record shall bind package CID, selected package interface, descriptor snapshot CID or descriptor scope, invocation contract snapshot CID where relevant, allowed data classes, granted capability identifiers, denied capability identifiers where relevant, issuer principal, authentication context where relevant, expiry or revocation metadata where relevant, 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 descriptor scopes that are not identified in the approval record.
A package approval record shall not approve invocation contracts that are not identified in the approval record.
A package approval record shall not grant authority by package name, author name, file name, provider name, product name, model name, URL, package 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, package interface, descriptor scope, invocation contract snapshot where relevant, allowed data classes, and granted capabilities recorded in the approval and corresponding trust decision.
A package approval record shall not authorize a package operation when a required capability is missing, denied, expired, revoked, conflicted, unavailable, or not yet determined.
A package approval record shall not authorize a package operation when the operation is not currently mediated by this Station.
A package approval record shall not authorize a package operation when required artifacts are unavailable or resource requirements are not satisfied.

**Rationale:** Approval states what Local Policy allows for a package. Approval is scoped to exact package identity, selected interface authority, descriptor scope, invocation contract, data classes, capabilities, and evidence.

**Verification:** 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 missing grants, denied capabilities, unavailable artifacts, unavailable resources, and operations not currently mediated by the Station block operation without changing package content identity.

**Status:** draft

**Source record:** `records/req.benac-trust-006/benac-trust-006.md`

## Trust, policy, and capability model

### BENAC-CAP-007 - Capability identifiers

**Statement:** Benac shall define stable capability identifiers used by packages, approvals, capability grants, invocations, evidence records, effect records, diagnostics, and Station Profiles.
A capability identifier shall be a stable string.
A known capability identifier shall not grant authority.
An unknown capability identifier shall not grant authority.
A package shall declare every capability it requires for each operation phase.
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, package labels, provider names, model names, file names, URLs, or human-readable descriptions as capability identifiers.
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, package-requested effects, retrieval, storage, or compute shall block that operation and shall be recorded in inspection, approval, invocation, effect, retrieval, storage, compute, or diagnostic records.
No capability identifier shall be categorically granted because of a package class.
No capability identifier shall be categorically denied because of a package class.

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

**Verification:** 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 known and unknown capability identifiers are inspected and handled by operation phase without package-class treatment.

**Status:** draft

**Source record:** `records/req.benac-cap-007/benac-cap-007.md`

## Package authoring

### BENAC-AUTHOR-001 - Package validation semantics

**Statement:** Benac shall define package validation semantics for authoring tools, Host APIs, CLIs, PWAs, and Agent APIs.
Package validation shall distinguish package content validity from Local Policy approval, capability grants, artifact availability for later operation phases, resource availability for later operation phases, and whether the current Station can mediate an operation.
Package validation shall verify package document schema conformance, package schema ruleset conformance, schema reference resolution, package interface declarations, descriptor config schema binding, request schema binding, output schema binding, interface contract binding, artifact references, artifact CID verification where artifacts are present, declared capabilities, fixture schema conformance, documentation references, unknown required fields, evidence behavior declarations, effect behavior declarations, and operation-phase requirement declarations.
Package validation shall identify the validation context used: package-document-only, Package Bundle, imported Station state, or another explicitly defined package distribution context.
Validation checks that require bundle, artifact, fixture, claim, or imported-state context shall not be reported as passed when that context is absent.
A package shall not fail content validation solely because a capability required only for approval, fixture execution, invocation, package-requested effects, retrieval, storage, or compute has not been granted.
A package shall not fail content validation solely because an artifact required only for approval, fixture execution, invocation, package-requested effects, retrieval, storage, or compute is unavailable.
A package shall not fail content validation solely because the current Station cannot currently mediate an operation requested by a package interface.
Package validation shall produce a stable machine-readable validation report.

**Rationale:** Package authors, agents, and independent implementations need the same answer to whether package content is structurally valid. Operation eligibility is separate and depends on Local Policy, artifacts, resources, and Station state.

**Verification:** The same valid and invalid Package Bundles produce equivalent validation pass/fail results and diagnostic records across conforming implementations. Verification distinguishes package-document-only validation from Package Bundle validation. Verification proves that missing invocation-only grants or artifacts do not change package content validity, while malformed package documents and unresolved required schema references still fail validation.

**Status:** draft

**Source record:** `records/req.benac-author-001/benac-author-001.md`

### BENAC-AUTHOR-002 - Package build semantics

**Statement:** Benac shall define package build semantics that convert an authoring workspace into a Package Bundle.
Build semantics shall compute raw blob CIDs over exact artifact bytes, produce artifact references, validate schema documents, produce package interface declarations, produce invocation contract snapshots where derivable, compute invocation contract snapshot CIDs where derivable, produce the package document logical object, compute the package CID over the DRISL-encoded package document, include selected schemas, artifacts, fixtures, and documentation references, and emit a build report.
Authoring-only metadata shall not be included in the package document used to compute the package CID unless the metadata is declared as package content.
Build semantics shall avoid package-CID cycles.
When fixture records bind to the final package CID, build shall first produce the package document logical object and package CID, then assemble fixture records that reference that package CID, then assemble the Package Bundle context, and then run validation over the resulting distribution context.
The build report shall reflect validation of the actual distributable Package Bundle, including fixture discovery, fixture schema status, artifact availability, operation-phase requirements, invocation contract snapshot status where derivable, and any context-required checks that were not evaluated.
Build reports shall not classify packages.
Build reports shall not classify how package work is performed.

**Rationale:** Independent build tools must produce the same package CID, artifact CIDs, schema CIDs, and invocation contract snapshot CIDs from the same logical package.

**Verification:** Two independent build tools build the same authoring workspace and produce the same artifact CIDs, schema CIDs, package CID, validation result, invocation contract snapshot CIDs where derivable, and Package Bundle Manifest. Build verification includes a package whose fixtures reference the final package CID.

**Status:** draft

**Source record:** `records/req.benac-author-002/benac-author-002.md`

### BENAC-AUTHOR-003 - Package validation and build reports

**Statement:** Benac shall define package validation report and package build report logical objects.
A package validation report shall include package CID where derivable, package validation context, Package Bundle context where applicable, schema validation status, schema reference resolution status, package interface status, interface contract binding status, invocation contract snapshot status where derivable, artifact reference status, artifact availability by operation phase, declared capability status, fixture discovery source, fixture discovery status, fixture schema status, documentation reference status, context-required checks not evaluated, warnings, diagnostic records or diagnostic record references, stable diagnostic classification codes, and raw diagnostic evidence references or evidence disposition where practical and safe.
A package build report shall include package CID, invocation contract snapshot CIDs where derivable, artifact CIDs, schema CIDs, Package Bundle Manifest CID where applicable, included artifacts, included fixtures, included documentation references, validation report reference, context-required checks not evaluated, warnings, diagnostic records or diagnostic record references, stable diagnostic classification codes, and raw diagnostic evidence references or evidence disposition where practical and safe.
Reports shall not classify packages.
Reports shall not classify how package work is performed.

**Rationale:** Package authors, agents, reviewers, and independent implementations need stable machine-readable reports that distinguish content validity, package distribution context, artifact availability, declared capabilities, schema-bound invocation contracts, and operation blockers.

**Verification:** The same package produces equivalent validation and build reports across conforming implementations. Reports include operation-phase blockers and diagnostic references. Reports do not include package-class status or class status for how package work is performed.

**Status:** draft

**Source record:** `records/req.benac-author-003/benac-author-003.md`

### BENAC-AUTHOR-004 - Authoring operations exposed through tools and APIs

**Statement:** Benac shall expose package validation, package build, and package fixture execution as machine-readable authoring operations. Command-line Host Implementations shall expose these operations as stable commands or documented command equivalents. Browser and agent-facing Host Implementations shall expose equivalent operations through UI and/or machine-readable APIs. All surfaces shall use the same validation, build, fixture, diagnostic, and report semantics. Authoring operations exposed through CLI, PWA/runtime, Host API, and Agent API shall be package-generic. They shall not rely on hello-world-specific defaults, package-specific request bodies, host-specific shortcuts, or surface-specific fixture comparison logic. The same underlying validation, build, fixture execution, diagnostic, artifact availability, and report semantics shall be used across surfaces.

**Rationale:** A package should not validate differently because it was tested in a CLI, browser UI, or agent workflow.

**Verification:** The same package bundle validates, builds, and runs fixtures through command-line tooling, browser/API tooling, and agent-facing APIs with equivalent results. Verification shall run validation, inspection, fixture execution, approval where applicable, and invocation for at least hello-world/greeting, calculator, todo reducer, and notes/text transform packages through generic package pathways. Equivalent inputs shall produce equivalent validation reports, inspection results, fixture results, diagnostics, request/output snapshots, and invocation records across supported surfaces.

**Status:** draft

**Source record:** `records/req.benac-author-004/benac-author-004.md`

### BENAC-TEST-001 - Fixture schema

**Statement:** Benac shall define a versioned fixture schema. A fixture shall identify package-under-test reference, descriptor config or descriptor snapshot reference where applicable, interface identifier, request body or request reference, expected validation result, expected selected package interface or interface contract, expected output body or output reference where deterministic, expected evidence/effect classes, expected denied effects where applicable, expected diagnostic classification codes and expected diagnostic evidence behavior where failure is intended, fixture data class, and fixture purpose.

**Rationale:** Fixtures need to test validation, interface resolution, package behavior, capability denials, trace shape, and expected failures.

**Verification:** Fixture schema validation accepts valid hello-world, calculator, todo reducer, and notes reducer fixtures. It rejects missing request data, unresolved schema references, unsupported fixture behavior, ambiguous expected output, and malformed expected diagnostic records or diagnostic evidence expectations, missing expected diagnostic classification codes for recognized diagnostic failures, and missing expected raw-evidence handling rules where the fixture declares them.

**Status:** draft

**Source record:** `records/req.benac-test-001/benac-test-001.md`

### BENAC-TEST-002 - Fixture execution semantics

**Statement:** Benac shall define fixture execution semantics for validation, invocation, evidence, effect, diagnostics, and operation-status checks.
Fixture execution shall use the same package validation, request validation, descriptor config validation, capability checks, artifact availability checks, resource checks, invocation semantics, evidence semantics, effect semantics, and output validation semantics as ordinary package invocation, except where the fixture explicitly defines expected denied effects, expected failure, or expected diagnostic behavior.
Fixture execution shall not grant authority.
Fixture execution shall require Local Policy grants for capabilities required by the fixture operation phase.
Fixture runners exposed through CLI, PWA/runtime APIs, Host APIs, Agent APIs, and conformance tooling shall use the same core fixture execution and expectation- evaluation semantics.
Surface-specific comparison logic shall not define fixture truth.
Fixture execution shall not classify packages.
Fixture execution shall not classify how package work is performed.

**Rationale:** Fixtures are the small-blast-radius test track for package behavior. They exercise the same validation, invocation, evidence, effect, and diagnostic semantics as real execution without unintended external consequences.

**Verification:** A fixture that attempts unauthorized network access records a denied effect and fails or passes according to the fixture expected denied-effect behavior. Verification includes fixtures where invocation succeeds but expected output does not match, where the wrong package interface is invoked, where an expected diagnostic is absent, and where an expected denied effect is absent.

**Status:** draft

**Source record:** `records/req.benac-test-002/benac-test-002.md`

### BENAC-TEST-003 - Fixture result records

**Statement:** Fixture execution shall produce a fixture result record or test result claim containing fixture identifier, package CID, package interface identifier, descriptor snapshot CID where relevant, invocation contract snapshot CID where relevant, request snapshot CID, output snapshot CID where relevant, validation results, evidence/effect references, pass/fail status, expectation evaluation summary, expected validation outcome and observed validation outcome, expected interface and observed interface, expected output reference or body and observed output snapshot reference where relevant, expected diagnostic codes and observed diagnostic codes, expected evidence/effect classes and observed evidence/effect references, expected denied effects and observed denied effects, expected raw-evidence behavior and observed raw-evidence disposition, fixture discovery source, fixture validation context, diagnostics, Station Profile reference, operation status, and timestamps.
The fixture result pass/fail status shall be derived from expectation evaluation, not from invocation status alone.
Fixture result records shall not classify packages.
Fixture result records shall not classify how package work is performed.

**Rationale:** Fixture results become evidence for approval, package review, agents, and conformance testing.

**Verification:** Running the same fixture across conforming implementations produces comparable fixture result records and equivalent pass/fail status. Running a fixture with mismatched output, wrong package interface, missing expected diagnostic, or mismatched effect behavior produces a failing fixture result with machine-readable mismatch diagnostics.

**Status:** draft

**Source record:** `records/req.benac-test-003/benac-test-003.md`

### BENAC-WASM-001 - WASM package-host calling convention

**Statement:** Benac shall define a versioned WASM package-host calling convention for package interfaces that reference WASM artifacts.
The calling convention shall define required module format, allowed imports, forbidden imports, required exports, memory requirements, input encoding, output encoding, error return behavior, UTF-8 handling, JSON handling, allocation/free conventions, invocation contract snapshot fields, and conformance vectors.
A package operation using a WASM artifact shall receive package-visible input only through the calling-convention-defined invocation path and shall return output only through the calling-convention-defined output mechanism.
The calling convention shall not classify packages.
The calling convention shall not classify how package work is performed.

**Rationale:** Runs WASM is not enough. Package authors need one WASM package-host calling convention that works across hosts that mediate WASM attempts.

**Verification:** A WASM-backed calculator package compiled against the calling convention runs on conforming Host Implementations when required grants, artifacts, and resources are present and produces the same validated output and trace shape.

**Status:** draft

**Source record:** `records/req.benac-wasm-001/benac-wasm-001.md`

### BENAC-INV-007 - Generic invocation input envelope

**Statement:** Benac shall define a generic invocation input envelope.
The invocation input envelope shall identify package CID, package interface identifier, descriptor snapshot CID or descriptor scope where relevant, request body, data class, authentication context where relevant, caller principal where relevant, and Local Policy context where relevant.
The invocation input envelope shall not classify packages.
The invocation input envelope shall not classify how package work is performed.
Generic runtime APIs shall submit invocations through this envelope rather than through package-internal ad hoc request formats.
The Station shall validate the request body against the package interface request schema before attempting invocation.
The Station shall validate descriptor config against the package interface descriptor config schema where relevant before attempting invocation.

**Rationale:** A single invocation envelope lets independent implementations validate requests, check grants, bind descriptor scope, and record traces consistently.

**Verification:** Invocation envelope tests cover package CID, interface identifier, descriptor scope, request body, data class, authentication context, and policy context. Invalid or missing required envelope fields fail closed with stable diagnostics.

**Status:** draft

**Source record:** `records/req.benac-inv-007/benac-inv-007.md`

### BENAC-WASM-002 - WASM mediated access restrictions

**Statement:** A package operation using a WASM artifact shall not receive DOM access, direct Document Store access, direct Blob Store access, raw secrets, raw authentication credentials, unrestricted network access, unrestricted device access, unrestricted filesystem access, or unrestricted host API access.
A package operation using a WASM artifact shall access host resources only through the WASM package-host calling convention and granted capabilities.
A package operation using a WASM artifact shall fail closed when it imports, exports, reads, writes, or calls outside the calling convention.
This requirement shall not classify packages.

**Rationale:** WASM artifact use must remain host-mediated. Artifact format does not grant authority.

**Verification:** WASM fixtures attempting forbidden imports, direct host access, direct network, raw secrets, raw filesystem, direct document store, direct blob store, or DOM access fail closed with stable diagnostics.

**Status:** draft

**Source record:** `records/req.benac-wasm-002/benac-wasm-002.md`

### BENAC-INV-008 - Request and output snapshots

**Statement:** Benac shall define request snapshot and output snapshot logical objects.
A request snapshot shall bind package CID, package interface identifier, descriptor snapshot CID or descriptor scope where relevant, request schema CID, request body, data class, caller principal where relevant, authentication context where relevant, and Local Policy context where relevant.
An output snapshot shall bind package CID, package interface identifier, descriptor snapshot CID or descriptor scope where relevant, output schema CID where relevant, output body, data class, invocation record reference, evidence references, effect references, and diagnostics where relevant.
Request and output snapshots shall not classify packages.
Request and output snapshots shall not classify how package work was performed.
Trace reconstruction, export, inspection, and replay shall not fabricate request or output snapshots when the required content is unavailable.

**Rationale:** Request and output snapshots let Stations, agents, and reviewers reason about the exact input and output content without relying on mutable UI state or hidden host data.

**Verification:** Snapshot tests verify identity stability, schema binding, descriptor binding, missing-content failure, and rejection of fabricated snapshots.

**Status:** draft

**Source record:** `records/req.benac-inv-008/benac-inv-008.md`

### BENAC-WASM-003 - WASM package-host calling convention template

**Statement:** Benac shall publish a non-authoritative reference WASM package-host calling convention template. The template shall demonstrate request/config decoding, output encoding, error output, memory allocation, memory release, fixture creation, and Package Bundle wiring. Use of the reference template shall not be required for conformance; conformance shall be determined by calling-convention behavior and test vectors. The template shall not grant authority, classify packages, or classify how package work is performed.

**Rationale:** Package developers need a working template without making a specific SDK the standard.

**Verification:** A package built from the template passes the WASM package-host calling convention conformance vectors. A package not built from the template also passes if it satisfies the calling convention.

**Status:** draft

**Source record:** `records/req.benac-wasm-003/benac-wasm-003.md`

### BENAC-WASM-004 - Resource limits and enforcement

**Statement:** Benac shall define resource-limit semantics for package validation, package build, fixture execution, ordinary invocation, and mediated package operation attempts.
Limits shall include at least package document size, Package Bundle size, schema size, fixture size, artifact size, request size, descriptor config size, output size, WASM memory pages or bytes where relevant, execution time or fuel where relevant, log size, evidence record size, and effect record size.
A Station Profile shall publish known resource limits where known.
A package shall declare resource requirements.
Invocation shall fail closed when declared or actual requirements exceed granted or available limits.
Resource-limit diagnostics and resource-limit reports shall identify the breached limit kind, observed value, configured or granted limit, operation phase, package/interface/contract context where known, and whether the breach denied the entire operation or only the offending record.
Log, evidence record, and effect record size breaches shall deny the offending record or deny the operation according to explicit requirement semantics.
Oversized log, evidence, or effect records shall not be silently omitted when the denied record is required to satisfy package output, fixture expectation, approval evidence, or audit requirements.
Resource-limit requirements shall not classify packages.

**Rationale:** Packages need clear bounds before authors begin experimenting. Resource limits are operation facts, not package classes.

**Verification:** Resource-limit fixtures covering oversized request, oversized output, oversized artifact, excessive memory, timeout/fuel exhaustion, excessive logs, and excessive evidence records fail with diagnostic records containing stable diagnostic classification codes, required context bindings, raw or origin-specific evidence references where practical and safe, and invocation records.

**Status:** draft

**Source record:** `records/req.benac-wasm-004/benac-wasm-004.md`

### BENAC-EXEC-008 - Interface invocation input

**Statement:** Invocation shall identify the requested package interface.
Invocation shall identify descriptor snapshot CID or descriptor scope where descriptor configuration is relevant.
Invocation shall identify request body, data class, caller principal where relevant, authentication context where relevant, and Local Policy context where relevant.
If the caller requests a specific invocation contract snapshot, the Station shall attempt that contract or fail closed unless explicit recorded fallback policy authorizes another contract.
If no invocation contract snapshot is requested, the Station shall derive the invocation contract from package declaration, selected package interface, descriptor scope, schema bindings, artifact availability, trust scope, capability grants, resource limits, Local Policy, operation status, and prior recorded attempts where relevant.
The selected package interface, derived or requested invocation contract, and all blocked alternatives with reasons shall be recorded.
The Station shall not silently fall back to another package interface or invocation contract unless Local Policy permits fallback and the invocation trace records it.
The default fallback policy for requested package interfaces and requested invocation contracts shall be NoFallback.
Inability to attempt an invocation contract shall be recorded as Station status and shall not by itself change package content validity.

**Rationale:** Packages can expose multiple schema-bound interfaces. Invocation selection must be interoperable, auditable, and policy-governed without classifying package internals.

**Verification:** A package with multiple interfaces records deterministic interface resolution. A requested missing interface, invalid request schema, invalid descriptor config, operation not currently mediated by the Station, and unavailable artifact each fail under default NoFallback policy. A separate test passes only when explicit fallback policy is present and the trace records fallback authority and reason.

**Status:** draft

**Source record:** `records/req.benac-exec-008/benac-exec-008.md`

### BENAC-UX-008 - Package inspection data contract

**Statement:** Benac shall define a machine-readable package inspection data contract.
The inspection result shall include package CID, inspection context, package distribution context reference where relevant, Package Bundle Manifest reference where relevant, package document version, package labels and version labels as non- authoritative metadata, package interfaces, request/config/output schema references, validation context, validation report references, schema validation status, invocation contract snapshots where derivable, artifact references, artifact availability, artifact availability resolution method, artifact CID codec, artifact role, declared capabilities, capability grant status where known, storage needs, compute needs, fixtures, fixture discovery source and status, fixture result references, external claim references where available, trust decision references, capability grant references, warnings, unknown fields, missing artifacts, resource requirements, resource-limit report references where relevant, context-required checks not evaluated, operation status by phase, diagnostic records or diagnostic record references, stable diagnostic classification codes, and raw diagnostic evidence references where practical and safe.
Operation status shall distinguish content validity, import success, approval eligibility, fixture execution eligibility, invocation eligibility, and package- requested effect eligibility.
Operation status shall support at least `satisfied`, `blocked`, `not_yet_determined`, `not_currently_mediated_by_this_station`, `grant_missing`, `denied_by_policy`, `artifact_unavailable`, `resource_unavailable`, `attempt_denied`, `attempt_failed`, and `attempt_completed`.
Artifact availability in inspection shall be resolved according to artifact role and CID codec.
Raw blob CIDs shall be checked against blob availability.
Structured DRISL document CIDs shall be checked against document availability or the supplied Package Bundle document set.
Inspection shall not report a structured document artifact as missing merely because it is not in the blob store.
Inspection shall not classify packages.
Inspection shall not classify how package work is performed.
Inspection shall not collapse not-currently-mediated, denied capability, missing grant, unavailable artifact, resource conflict, failed attempt, not-yet-determined status, or fixture not run into generic package invalidity.

**Rationale:** Human UI can vary, but agents and independent implementations need the same inspection semantics and the same distinction between content validity and operation eligibility.

**Verification:** Inspecting the same Package Bundle across conforming implementations produces equivalent machine-readable inspection objects. Inspection verification covers structured document artifacts, raw blob artifacts, unavailable artifacts, denied grants, missing grants, not-currently-mediated operations, resource conflicts, and not-yet-determined status. Each condition is reported without changing package content validity.

**Status:** draft

**Source record:** `records/req.benac-ux-008/benac-ux-008.md`

### BENAC-UX-009 - Inspection before package approval

**Statement:** A Host Implementation shall be able to produce or reference a package inspection result before package approval.
A package approval record shall reference the inspected package CID, selected package interface, descriptor scope, invocation contract snapshot where relevant, declared capabilities, granted capabilities, denied capabilities where relevant, fixture results where relied upon, warnings presented or made available, 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, operation status, capability grant status, 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.
Approval shall not classify packages.
Approval shall not classify how package work is performed.

**Rationale:** Approval must be based on inspectable package facts, not hidden host state or package classification.

**Verification:** Package approval references an inspection result or equivalent inspected fields. A package with missing artifacts, denied capabilities, missing grants, resource conflicts, failed fixtures, or not-currently-mediated operations cannot receive approval for the blocked operation. Approval referencing fixture results also references inspection data that includes those fixture results or equivalent inspected fields.

**Status:** draft

**Source record:** `records/req.benac-ux-009/benac-ux-009.md`

## 10.8 Trust and capability governance

### BENAC-TRUST-001 - Local trust required

**Statement:** A package shall not execute with real capabilities unless local policy has granted trust for that package, package interface, descriptor scope, invocation contract snapshot where relevant, initiating actor, requested capability scope, and relevant data class.

**Rationale:** Presence is not permission.

**Verification:** Imported untrusted package cannot execute with real capabilities.

**Status:** draft

**Source record:** `records/req.benac-trust-001/benac-trust-001.md`

## Trust, policy, and capability model

### BENAC-TRUST-002 - Trust is scoped

**Statement:** A trust decision shall be scoped.
Trust scope shall identify the package CID, package interface identifiers, descriptor snapshot CID or descriptor scope where relevant, invocation contract snapshot CID where relevant, allowed data classes, granted capability identifiers, issuer principal, authentication context where relevant, expiration or revocation metadata where relevant, and evidence relied upon.
A trust decision shall not grant authority outside its recorded scope.
A trust decision shall not be inferred from package import, package name, author name, provider name, model name, package label, file name, URL, or human-readable description.
A trust decision shall not classify packages.
A trust decision shall not classify how package work is performed.

**Rationale:** Trust must be exact enough to prevent authority from leaking across packages, interfaces, descriptor scopes, data classes, capabilities, or invocation contracts.

**Verification:** Scope substitution tests fail closed when package CID, interface identifier, descriptor scope, invocation contract snapshot, data class, or capability differs from the trust decision.

**Status:** draft

**Source record:** `records/req.benac-trust-002/benac-trust-002.md`

### BENAC-TRUST-003 - Authenticated and attributed trust decisions

**Statement:** A trust decision shall be attributable to a local user, Local Policy, delegated local authority, or authenticated agent acting under Local Policy.
A trust decision shall bind the authenticated session or authority context used to create it where that context is available.
A trust decision shall be enforceable only within its recorded scope.
Invocation shall fail closed outside the package CID, interface identifier, descriptor scope, invocation contract snapshot, data class, capability, time, and revocation scope recorded in the trust decision.
Effective authority for a package operation shall be the intersection of the package-declared requirements, trust-decision allowed scope, active capability grants, artifact availability, resource availability, and Local Policy.
A trust decision shall not grant authority merely because a package is imported, signed, named, authored, known, or previously invoked.

**Rationale:** Trust decisions must be attributable and scoped so package authority can be reviewed, revoked, audited, and enforced.

**Verification:** Tests create trust decisions under authenticated and unauthenticated contexts. Invocation fails outside trust scope. Revoked, expired, or conflicted trust decisions fail closed.

**Status:** draft

**Source record:** `records/req.benac-trust-003/benac-trust-003.md`

### BENAC-CAP-001 - Explicit capability declaration

**Statement:** A package shall declare every capability it requires for each operation phase.
A package shall declare capabilities required by each package interface.
The operation phases shall include package import, package validation, package inspection, package approval, fixture execution, package invocation, package-requested effects, retrieval operations, storage operations, and compute operations.
A declared capability shall not grant authority.
Package import shall not grant capability authority.
Package trust shall not grant capability authority by itself.
A Host Implementation shall not reject package content solely because a declared capability is not currently granted by Local Policy, unless the capability is required for package import or package validation.
A Host Implementation shall report declared capabilities and capability status during inspection.

**Rationale:** Package authors must declare what authority package operations require, and users, agents, and Local Policy must be able to review those declarations before grant.

**Verification:** Package validation rejects missing required capability declarations. Inspection shows declared capabilities and operation phases. Invocation fails closed when a required capability is not declared or not granted.

**Status:** draft

**Source record:** `records/req.benac-cap-001/benac-cap-001.md`

### BENAC-CAP-002 - Explicit capability grants

**Statement:** A capability grant shall identify package CID, package interface, descriptor scope where relevant, invocation contract snapshot where relevant, operation phase, capability identifier, scope, issuer principal, authentication context where relevant, expiry or revocation metadata where relevant, and evidence relied upon.
A capability grant shall not be inferred from package import, package trust, package name, package author, Station Profile information, package approval text, signature verification, or human-readable description.
A capability grant shall not widen authority beyond the package approval or Local Policy record that created it.
A capability grant shall not grant authority for package operations, interfaces, data classes, descriptors, artifacts, resources, or phases outside its recorded scope.

**Rationale:** Capability authority must be explicit, scoped, attributable, revocable, and separate from package content and identity.

**Verification:** Tests verify that imported, trusted, signed, and named packages do not receive capability authority without explicit grants. Scope substitution tests fail closed.

**Status:** draft

**Source record:** `records/req.benac-cap-002/benac-cap-002.md`

## 10.8 Trust and capability governance

### BENAC-TRUST-004 - Signatures are evidence, not authority

**Statement:** Package signatures, storage receipts, compute results, attestations, and name bindings shall not automatically grant execution, storage, compute, decryption, or capability permission unless local policy explicitly treats specified claims from specified principals as sufficient for a defined trust scope.

**Rationale:** Decentralized trust is local.

**Verification:** Signed package or storage offer remains inactive without matching local policy.

**Status:** draft

**Source record:** `records/req.benac-trust-004/benac-trust-004.md`

## Trust, policy, and capability model

### BENAC-CAP-003 - Capability mediation

**Statement:** A Host Implementation shall mediate every granted capability.
A Host Implementation shall not expose host resources directly to package operations outside granted capabilities.
A Host Implementation shall not treat package trust, package approval, package interface selection, Station Profile information, package author identity, package name, signature verification, or import success as a substitute for a capability grant.
Capability use shall be recorded according to the operation phase and evidence or effect requirements of the package operation.
Denied, missing, expired, revoked, conflicted, unavailable, or not-yet-determined capabilities shall fail closed for the operation that requires them.

**Rationale:** The Station remains the authority boundary. Package operations receive mediated results, not ambient host power.

**Verification:** Tests attempt capability use without grants, with expired grants, with revoked grants, with conflicting grants, and with valid grants. Only valid scoped grants allow the mediated operation.

**Status:** draft

**Source record:** `records/req.benac-cap-003/benac-cap-003.md`

## 10.8 Trust and capability governance

### BENAC-TRUST-005 - Revocation

**Statement:** Benac shall support local revocation of package trust, package interface trust, invocation contract trust, descriptor trust, agent authority, storage leases, compute leases, capability grants, accepted principal status, accepted claim status, and decryption/sharing authority for future operations.

**Rationale:** Trust must be reversible, though prior plaintext disclosure cannot be undone.

**Verification:** Revoked package, principal, lease, or grant cannot authorize later invocation.

**Status:** draft

**Source record:** `records/req.benac-trust-005/benac-trust-005.md`

### BENAC-CAP-004 - Data egress as effect

**Statement:** Sending data to a network endpoint, remote Storage Station, remote Compute Station, replication peer, or external device shall be recorded as an effect and shall require applicable capability permission.

**Rationale:** Data egress is a real-world effect. Recording it lets users and agents understand where data moved, why it moved, which authority allowed it, and how to adjust future requests or grants.

**Verification:** Remote storage upload and remote compute invocation record data egress effects.

**Status:** draft

**Source record:** `records/req.benac-cap-004/benac-cap-004.md`

### BENAC-CAP-005 - Capability conflict fail-closed behavior

**Statement:** If capability policy is missing, conflicting, unsupported, expired, or ambiguous, Benac shall deny the requested capability and record the denial.

**Rationale:** Ambiguous authority should become a clear denial and diagnostic, not hopeful execution. This gives agents and users a repairable signal while preventing accidental expansion of power.

**Verification:** Conflicted network/storage/compute policy denies request.

**Status:** draft

**Source record:** `records/req.benac-cap-005/benac-cap-005.md`

### BENAC-CAP-006 - Effect-time capability checks

**Statement:** For every host-mediated effect, the Host Station shall evaluate the actual requested effect against the active capability grant at effect time. This includes network fetch, data egress, blob read/write, storage use, compute use, secret use, decryption, signing, disclosure, file access, device access, and physical-world effects. The check shall use the actual endpoint, method, operation class, blob CID, package CID, invocation contract snapshot CID, descriptor snapshot CID, secret reference, data class, recipient, or other effect-specific scope fields. For mediated package invocation, the check shall include target package CID, target descriptor snapshot CID, target interface identifier, requested data class, initiating package CID, parent invocation reference, and granted scope where applicable. Package labels, names, declared intent, descriptor labels, URLs in metadata, or convenience projections shall not be sufficient to authorize an effect.

**Rationale:** A malicious package can compute effect parameters dynamically or embed them in executable code. Host mediation must check the actual requested operation, not just package declarations. Effect-time checks also support agent iteration by making the actual denied operation visible, including the endpoint, blob, descriptor, data class, recipient, or other scope field that caused denial.

**Verification:** A package with a grant for GET https://api.crm.example/v1/customers attempts POST https://evil.example/steal. The Host Station denies the effect and records the denial. A package with a grant for one blob CID attempts to read another blob CID. The Host Station denies and records the denial.

**Status:** draft

**Source record:** `records/req.benac-cap-006/benac-cap-006.md`

## Execution model and package host interface

### BENAC-EXEC-001 - Schema-defined package behavior

**Statement:** Benac shall define semantics for package behavior represented as structured data interpreted by the Station.
Those semantics shall define request binding, descriptor config binding, validation behavior, output mapping, evidence recording, effect recording, error behavior, unsupported-operation behavior, resource behavior, and conformance vectors.
These semantics shall describe a schema-bound package behavior mechanism.
These semantics shall not classify packages.
These semantics shall not classify how package work is performed.
A Station shall attempt schema-defined package behavior only when Local Policy grants the required capabilities, required artifacts are available, resource requirements are satisfied, and the Station can mediate the attempt.

**Rationale:** Independent implementations need the same behavior for schema-defined package behavior, not merely the same label.

**Verification:** Conformance packages for greeting, calculator, todo reducer, notes reducer, and invalid-input behavior produce equivalent outputs, validation failures, evidence records, and effect records across conforming implementations when the declared requirements are satisfied.

**Status:** draft

**Source record:** `records/req.benac-exec-001/benac-exec-001.md`

### BENAC-EXEC-002 - WASM package-host calling convention

**Statement:** Benac shall define a versioned WASM package-host calling convention for package interfaces that reference WASM artifacts.
The calling convention shall define module format, allowed imports, forbidden imports, required exports, memory behavior, input encoding, output encoding, error behavior, resource behavior, and conformance vectors.
The calling convention shall describe how a Station mediates package-visible WASM artifact use.
The calling convention shall not classify packages.
The calling convention shall not classify how package work is performed.
A Station shall attempt a WASM-backed package operation only when Local Policy grants the required capabilities, required artifacts are available, resource requirements are satisfied, and the Station can mediate the attempt.

**Rationale:** WASM interoperability requires a shared package-host calling convention, not a package class.

**Verification:** WASM conformance packages for greeting, calculator, todo reducer, invalid output, forbidden import, and resource-limit behavior produce equivalent results and diagnostics across conforming implementations when required grants, artifacts, and resources are present.

**Status:** draft

**Source record:** `records/req.benac-exec-002/benac-exec-002.md`

## 10.9 Execution model and package host interface

### BENAC-EXEC-003 - Isolated execution

**Statement:** Package operations using executable artifacts shall run isolated from the Benac UI, document store, blob store, raw secrets, private keys, local storage, DOM, and other package state unless mediated by explicit host capabilities.

**Rationale:** Package executable artifacts must not compromise the kernel.

**Verification:** Sandbox test package attempts disallowed access and is denied.

**Status:** draft

**Source record:** `records/req.benac-exec-003/benac-exec-003.md`

### BENAC-EXEC-004 - No arbitrary same-origin JavaScript packages

**Statement:** Benac shall not execute arbitrary package-provided JavaScript in the same origin and authority context as the Benac application.

**Rationale:** Same-origin JavaScript would collapse package isolation.

**Verification:** Package behavior that requires same-origin JavaScript authority is rejected unless a future isolated JavaScript conformance rule is explicitly defined.

**Status:** draft

**Source record:** `records/req.benac-exec-004/benac-exec-004.md`

## Execution model and package host interface

### BENAC-EXEC-005 - Host-native operation attempts

**Statement:** A package can declare requirements that involve host-native, subprocess, container, platform-device, GPU, or other host-mediated operation attempts.
A package declaration shall not grant authority to perform those attempts.
A Station shall not attempt those operations unless Local Policy grants the required capabilities, required artifacts are available, resource requirements are satisfied, and the Station can mediate the attempt.
A Station that cannot mediate a requested operation shall record that the operation is not currently mediated by this Station.
Failure to mediate a requested operation shall not by itself make package content invalid unless the operation is required for package import or package validation.
This requirement shall not define a package class.

**Rationale:** Packages can request many forms of computation or host interaction. Authority comes from Local Policy and mediated operation records, not from package class.

**Verification:** Tests verify that a package requesting a host-native or device operation imports and inspects when import and validation requirements are satisfied. Invocation remains blocked until required grants, artifacts, resources, and mediated operation paths are available.

**Status:** draft

**Source record:** `records/req.benac-exec-005/benac-exec-005.md`

### BENAC-EXEC-006 - Invocation contract record

**Statement:** Benac shall record the invoked package interface, descriptor scope, invocation contract snapshot, package content checks, policy checks, cryptographic checks, artifact availability checks, encryption/disclosure checks, capability grants, resource checks, operation status, and attempt results for each invocation.
Blocked-operation reasons shall identify concrete facts such as requested different interface, invalid request schema, invalid descriptor config schema, unavailable artifact, unavailable resource, denied capability, missing capability grant, expired grant, revoked grant, conflicted grant, not-yet-determined status, operation not currently mediated by this Station, failed attempt, or policy denial.
Blocked-operation reasons shall not rely on package classes.
Blocked-operation reasons shall not rely on classes for how package work is performed.

**Rationale:** Package operation must be explainable and auditable without classifying packages or package internals.

**Verification:** A package with multiple interfaces records selected interface, invocation contract snapshot, operation statuses, and concrete blocked-operation reasons.

**Status:** draft

**Source record:** `records/req.benac-exec-006/benac-exec-006.md`

### BENAC-EXEC-007 - Host-mediated package APIs

**Statement:** Package operations shall interact with host resources only through defined host imports or equivalent mediated calls.
Mediated calls shall include blob access, HTTPS fetch, storage use, compute use, secret use, encryption/decryption, evidence emission, effect request, clock, random bytes, output return, package invocation, authentication-context reporting, and capability introspection when those calls are declared and granted.
A package shall not receive raw host authority by declaring a mediated call.
A Station shall expose a mediated call to a package operation only when Local Policy grants the required capability for the relevant operation phase.
A Station shall record denied calls, failed calls, completed calls, and raw diagnostic evidence disposition where practical and safe.

**Rationale:** The Station must remain the enforcement and evidence chokepoint.

**Verification:** Package-host conformance tests verify authorized mediated calls, denied calls, input encoding, output encoding, memory behavior where relevant, error behavior, and evidence/effect recording.

**Status:** draft

**Source record:** `records/req.benac-exec-007/benac-exec-007.md`

## Invocation, evidence, effects, audit, and tamper-evidence

### BENAC-INV-001 - Invocation record required

**Statement:** Every package invocation shall produce an invocation record.
The invocation record shall identify package CID, invoked package interface, descriptor snapshot CID or descriptor scope where relevant, invocation contract snapshot CID where relevant, request snapshot CID, output snapshot CID where relevant, caller principal where relevant, authentication context where relevant, Local Policy context where relevant, capability grants relied upon, artifact availability status, resource status, evidence references, effect references, diagnostics, operation status, timestamps, and Station principal.
Invocation records shall not classify packages.
Invocation records shall not classify how package work is performed.

**Rationale:** Every invocation must be attributable, inspectable, and replay-analyzable in terms of package identity, interface contract, request, output, policy, grants, evidence, effects, and operation status.

**Verification:** Invocation tests verify that successful and failed invocations produce records with package CID, interface identifier, request snapshot, output snapshot where applicable, capability grants, evidence, effects, diagnostics, and operation status.

**Status:** draft

**Source record:** `records/req.benac-inv-001/benac-inv-001.md`

### BENAC-INV-002 - Invocation fields

**Statement:** An invocation record shall contain object type, schema version, invocation identifier, package CID, package interface identifier, descriptor snapshot CID or descriptor scope where relevant, invocation contract snapshot CID where relevant, request snapshot CID, output snapshot CID where relevant, caller principal where relevant, Station principal, authentication context where relevant, Local Policy context where relevant, data class, granted capability identifiers relied upon, denied or missing capability identifiers where relevant, artifact references relied upon, artifact availability status, resource requirements, resource status, evidence references, effect references, diagnostics, operation status, created-at timestamp, completed-at timestamp where relevant, and causal references.
The invocation record shall not contain a package class field.
The invocation record shall not contain a field whose purpose is to classify how package work was performed.

**Rationale:** Invocation records are the main audit record for what the Station attempted, allowed, denied, completed, or failed.

**Verification:** Invocation field tests verify required fields, denied-operation fields, failed operation fields, successful output fields, evidence/effect references, and causal references.

**Status:** draft

**Source record:** `records/req.benac-inv-002/benac-inv-002.md`

## 10.10 Invocation, evidence, effects, audit, and tamper-evidence

### BENAC-INV-003 - Request validation

**Statement:** Invocation requests shall be validated against the package request schema before execution. Request validation shall use the declared package schema ruleset or another explicitly declared and supported schema ruleset. The request body supplied through any CLI, PWA UI, Host API, Agent API, or fixture runner shall be the exact logical request body made visible to the package after validation.

**Rationale:** Packages should receive well-formed input, and the same invocation request must mean the same thing across host surfaces and implementations.

**Verification:** Invalid request data is rejected before package execution. The same request supplied through CLI, PWA UI, Host API, Agent API, and fixture runner produces the same package-visible request object or the same validation failure.

**Status:** draft

**Source record:** `records/req.benac-inv-003/benac-inv-003.md`

### BENAC-INV-004 - Output validation

**Statement:** Package outputs shall be validated against the package output schema when an output schema is declared. Output validation shall use the declared package schema ruleset or another explicitly declared and supported schema ruleset. Invalid output shall be recorded as a validation failure and shall not masquerade as valid output.

**Rationale:** Downstream composition needs reliable contracts, and independent implementations must validate outputs the same way.

**Verification:** Invalid output records validation failure. Output validation fixtures produce equivalent valid/invalid decisions and diagnostic records containing stable diagnostic classification codes, required context bindings, and raw or origin-specific evidence references where practical and safe across conforming implementations.

**Status:** draft

**Source record:** `records/req.benac-inv-004/benac-inv-004.md`

## Invocation, evidence, effects, audit, and tamper-evidence

### BENAC-INV-005 - No silent fallback

**Statement:** Benac shall not silently change package, package interface, descriptor, descriptor scope, request schema, descriptor config schema, output schema, invocation contract, storage source, compute source, trust scope, capability scope, cryptographic profile, identity binding, encryption policy, privacy policy, output contract, data class, schema ruleset, resource policy, or security behavior.
Any fallback, substitution, or policy-selected alternative shall require explicit authority and shall be recorded in the invocation trace or related audit record.
Benac shall not silently switch from a requested package interface to another package interface.
Benac shall not silently switch from a requested descriptor scope to another descriptor scope.
Benac shall not silently change requested capability scope or data class.
When a requested package interface or invocation contract cannot currently be attempted, Benac shall record the reason and shall fail closed unless explicit fallback policy authorizes another interface or contract.

**Rationale:** Silent fallback destroys the feedback loop. Agents and users need to know which package interface, descriptor, policy, contract, schema, data class, and authority were actually used so they can trust, debug, or revise the next attempt.

**Verification:** A requested package interface records skipped or blocked reason and fails unless fallback policy permits another interface. Verification shows that a caller-requested interface does not silently fall back to another interface and that fallback reasons are recorded when explicit fallback is allowed.

**Status:** draft

**Source record:** `records/req.benac-inv-005/benac-inv-005.md`

## 10.10 Invocation, evidence, effects, audit, and tamper-evidence

### BENAC-INV-006 - Invocation attribution

**Statement:** Invocations shall be attributable to the Station principal and, when applicable, the user principal, agent principal, package authoring principal, authenticated client session, Storage Station principal, Compute Station principal, package invocation, parent invocation, or other participating principal/session that initiated, mediated, or performed work. Attribution to parent or child invocations shall not create a new principal class and shall not grant authority.

**Rationale:** Accountability requires knowing which actor, session, package, Station, and parent invocation participated in work. Workflow-like behavior can be represented as package composition and invocation causality rather than as a special workflow actor class.

**Verification:** Agent-initiated, package-composed, and remote-compute-assisted invocation fixtures contain correct Station, actor/session, package, parent invocation, child invocation, Storage Station, and Compute Station attribution without using a special workflow actor class.

**Status:** draft

**Source record:** `records/req.benac-inv-006/benac-inv-006.md`

### BENAC-INV-009 - Mediated package composition

**Statement:** Benac shall support, or define an explicit mediated mechanism for, a package invocation to request invocation of another package interface or descriptor through the Host Station's mediated invocation path. Such child invocations shall be subject to ordinary package trust, descriptor trust, request validation, selected package interface resolution, capability grants, leases, data-class policy, evidence recording, effect recording, diagnostics, resource limits, failure behavior, and Local Policy. Child invocation records shall reference the parent invocation where applicable. A package shall not gain ambient authority to invoke arbitrary packages merely because it is executing.

**Rationale:** Workflow-like behavior, orchestration, and agent-authored composite behavior should be expressible as packages. Benac Core should provide the legible interchange between package invocations, not define workflow semantics. This lets agents build small composite tools, run them, inspect failures, and refine them while every child invocation remains attributable, bounded, and auditable.

**Verification:** A composite package invokes an authorized child calculator package and records parent/child invocation links, request snapshots, output snapshots, selected package interfaces, evidence, effects, diagnostics, and capability checks. A second fixture attempts to invoke an unauthorized child package or descriptor and records a denied effect or failed child invocation without granting authority or silently falling back.

**Status:** draft

**Source record:** `records/req.benac-inv-009/benac-inv-009.md`

### BENAC-EVD-001 - Evidence ledger

**Statement:** Benac shall maintain evidence records for data observed, received, produced, parsed, validated, streamed, signed, attested, retrieved, stored, encrypted, decrypted, or otherwise generated by package invocation or remote resource use.

**Rationale:** Evidence records preserve what was observed or produced so outputs, failures, package behavior, storage, compute, and agent decisions can be inspected rather than guessed.

**Verification:** HTTP/mock package, storage retrieval, and WASM package record evidence.

**Status:** draft

**Source record:** `records/req.benac-evd-001/benac-evd-001.md`

### BENAC-EFF-001 - Effect ledger

**Statement:** Benac shall maintain effect records for actions attempted or caused by package invocation, storage use, compute use, encryption/decryption, secret injection, data egress, and disclosure.

**Rationale:** Effects are where Benac touches the world. Recording attempted and completed effects gives users and agents a legible map of what changed, what was denied, and what authority was involved.

**Verification:** Network request, secret injection, blob write, remote storage upload, decryption, and remote compute tests create effect records.

**Status:** draft

**Source record:** `records/req.benac-eff-001/benac-eff-001.md`

### BENAC-EVD-002 - Raw evidence before interpretation

**Statement:** When practical and safe, Benac shall persist raw evidence or a CID/encrypted reference to raw evidence before or alongside normalized interpretation. Raw evidence includes observed request and response bodies, package-provided error payloads, provider responses, storage or compute receipts, validation engine details, WASM runtime traps, package stdout/stderr where captured, host-mediated API failure payloads, logs, resource-limit observations, and other observed failure material.

If raw evidence is not persisted in full, Benac shall record whether it was omitted, redacted, truncated, encrypted, unavailable, or unsafe to store, and shall record the reason or policy basis where practical.

Normalized outputs, validation results, diagnostic classification codes, human-readable summaries, or parsed interpretations shall not erase, replace, or silently discard available raw evidence.

**Rationale:** Normalized or validated outputs should not erase the underlying receipt. Many failures are best understood from the raw observed material, especially when future packages, runtimes, providers, or future profile additions produce failure modes not anticipated by the baseline diagnostic-code registry.

**Verification:** Mock HTTP response bodies, package error payloads, WASM trap evidence, validation engine details, storage provider refusal bodies, and compute failure responses are stored inline or by CID/encrypted reference before or alongside parsed output or diagnostic records. Fixtures verify that omitted, redacted, truncated, encrypted, unavailable, or unsafe raw evidence is explicitly marked rather than silently discarded.

**Status:** draft

**Source record:** `records/req.benac-evd-002/benac-evd-002.md`

### BENAC-EFF-002 - Denied effects recorded

**Statement:** Benac shall record denied effect attempts when package code, a package invocation, an agent/client action, a storage operation, a compute operation, a disclosure operation, a lease request, or another host-mediated operation requests a capability or authority denied by policy.

**Rationale:** Denied effects are feedback and audit evidence. They show what was attempted, why it was blocked, and what narrower grant, corrected request, or package change might be needed next.

**Verification:** Package attempts unauthorized remote storage upload; denied effect is recorded.

**Status:** draft

**Source record:** `records/req.benac-eff-002/benac-eff-002.md`

### BENAC-AUD-001 - Inspectability

**Statement:** Benac shall provide user- and agent-accessible inspection of package documents, package inspection results, descriptors, claims, trust decisions, capability grants, invocations, evidence, effects, conflicts, encrypted envelopes, storage status, compute status, sync status, validation reports, build reports, fixture results, and diagnostic records.

**Rationale:** Inspectability is the shared feedback surface for users, agents, tools, packages, and conformance tests. It makes experimentation, failure, authority, effects, and repair paths scrutable without requiring Benac Core to define how an agent reasons.

**Verification:** UI/API inspection tests verify that users and agents can inspect package information, package validation reports, fixture results, approval records, invocation traces, evidence, effects, and diagnostics.

**Status:** draft

**Source record:** `records/req.benac-aud-001/benac-aud-001.md`

### BENAC-AUD-002 - Causal record linking

**Statement:** Benac authoring records, package drafts where represented, build reports, validation reports, fixture results, trust requests, capability requests, storage lease requests, compute lease requests, approvals, trust decisions, capability grants, leases, invocations, evidence records, effect records, storage records, compute records, disclosure records, diagnostic records, import records, export records, and audit records shall support causal references where applicable. Causal references may include initiating actor, authenticated session, parent invocation, child invocation, related request, related approval, related package draft, related package CID, related invocation contract snapshot CID, related descriptor snapshot CID, related build report, related validation report, related fixture result, related diagnostic record, related evidence record, and related effect record. Causal references are for audit, reconstruction, debugging, and inspection only; they shall not grant authority.

**Rationale:** Agents and humans need to understand what caused what without the kernel defining an agent recovery loop. Causal links make experimentation scrutable; a failed build, denied effect, missing blob, or invalid output can be traced back to the draft, request, invocation, approval, or package that produced it.

**Verification:** A conformance scenario creates a package draft, builds it, receives a validation failure, fixes it, runs fixtures, requests trust, receives approval, invokes it, triggers a denied effect, and inspects diagnostics. The resulting records can be traversed by causal references from final diagnostic back to invocation, approval, fixture result, build report, package draft, and initiating actor. No causal reference grants authority by itself.

**Status:** draft

**Source record:** `records/req.benac-aud-002/benac-aud-002.md`

### BENAC-AUD-003 - Queryable inspection

**Statement:** Benac inspection APIs shall support machine-readable querying or filtering of inspectable records by object type, CID, package CID, invocation contract snapshot CID, descriptor snapshot CID, interface identifier, request snapshot CID, output snapshot CID, actor principal, authenticated session, invocation status, diagnostic classification code, capability or effect class, data class, storage lease, compute lease, time range, and causal reference where applicable. Large evidence bodies may be returned by CID or encrypted reference. Responses shall support host-defined size limits, pagination, truncation metadata, redaction metadata, encryption metadata, omission metadata, and follow-up retrieval of referenced evidence where authorized.

**Rationale:** Inspectability is the feedback surface for agent experimentation. Agents should be able to ask focused questions such as show failed invocations for this package, show diagnostics for this fixture, show denied effects for this descriptor, or show raw evidence for this validation failure without depending on prose logs or unbounded database dumps.

**Verification:** Agent API and Host API conformance tests query failed invocations by package CID, diagnostics by stable classification code, denied effects by capability class, fixture results by package/interface context, and evidence by causal reference. Tests verify pagination, redaction metadata, truncation metadata, encrypted evidence references, and denied retrieval for unauthorized evidence.

**Status:** draft

**Source record:** `records/req.benac-aud-003/benac-aud-003.md`

### BENAC-AUD-CRYPTO-001 - Tamper-evident records

**Statement:** Benac shall support tamper-evident invocation, evidence, effect, disclosure, storage, compute, audit, and package bundle records through DASL CIDs, signatures, CID links, Merkle manifests, or equivalent mechanisms defined by the cryptographic profile and data model.

**Rationale:** Replicated and exported receipts need integrity and attribution.

**Verification:** Altered package trace export fails integrity verification or is clearly marked as modified.

**Status:** draft

**Source record:** `records/req.benac-aud-crypto-001/benac-aud-crypto-001.md`

### BENAC-AUD-CRYPTO-002 - Signed remote evidence

**Statement:** Evidence returned by remote Storage Stations, remote Compute Stations, or remote capability gateways shall be bound to request CID, nonce or challenge, relevant package/storage/compute descriptor CID, output CID, evidence CID, and remote Station principal where feasible.

**Rationale:** Remote answers should not be replayable or substituted without detection.

**Verification:** Replay and substitution tests fail verification.

**Status:** draft

**Source record:** `records/req.benac-aud-crypto-002/benac-aud-crypto-002.md`

## 10.11 Storage discovery, remote storage, and content availability

### BENAC-STOR-001 - Storage Station identity and authentication

**Statement:** Remote Storage Stations shall be representable as cryptographic Station principals and shall authenticate where local policy, storage leases, storage receipts, encrypted sharing, or accountability require provider identity.

**Rationale:** Benac verifies blob bytes by DASL CID, but storage offers, receipts, pins, and private storage policy still require attributable Station identity.

**Verification:** Configure a Storage Station, perform an authenticated storage operation, and verify that the receipt is bound to the Storage Station principal.

**Status:** draft

**Source record:** `records/req.benac-stor-001/benac-stor-001.md`

### BENAC-STOR-002 - Storage offers

**Statement:** Benac shall support storage offer documents describing provider identity, endpoint descriptors, supported operations, limits, costs, retention claims, evidence behavior, encryption requirements, and required capabilities.

**Rationale:** Agents and users need to discover storage without a central registry.

**Verification:** Storage offer schema validation and signature verification where signed.

**Status:** draft

**Source record:** `records/req.benac-stor-002/benac-stor-002.md`

### BENAC-STOR-003 - Storage descriptors

**Statement:** Benac shall support local storage descriptors configuring how this Station may interact with a Storage Station or storage package.

**Rationale:** A reusable storage package needs local configuration such as endpoint, auth reference, and allowed data classes.

**Verification:** Descriptor validates against storage package config schema.

**Status:** draft

**Source record:** `records/req.benac-stor-003/benac-stor-003.md`

### BENAC-STOR-004 - Storage leases

**Statement:** Benac shall require explicit local storage leases before agents, packages, or compute workflows may upload, pin, publish, retrieve sensitive blobs, share encrypted blobs, or stage private blobs from remote storage.

**Rationale:** Remote storage use can disclose data, incur cost, or alter availability.

**Verification:** Attempted private upload without storage lease is denied.

**Status:** draft

**Source record:** `records/req.benac-stor-004/benac-stor-004.md`

### BENAC-STOR-005 - Storage operations as effects

**Statement:** Benac shall record storage operations as effect records, including upload, retrieval, pin, unpin, publish, encrypted backup, staging, share, failed retrieval, integrity failure, and deletion/unpin requests.

**Rationale:** Storage operations touch the world and change availability or disclosure.

**Verification:** Remote put/get/pin/unpin fixture produces effect records.

**Status:** draft

**Source record:** `records/req.benac-stor-005/benac-stor-005.md`

### BENAC-STOR-006 - Storage receipts

**Statement:** Benac shall support storage receipts or claims for accepted uploads, pins, retrievals, failed retrievals, integrity failures, provider-side availability claims, and retention claims, bound where applicable to the relevant blob, chunk, manifest, request, or operation CIDs.

**Rationale:** Availability and audit need receipts, even though receipts do not prove eternal storage.

**Verification:** Storage Station mock returns receipt; Benac records and verifies it where signed.

**Status:** draft

**Source record:** `records/req.benac-stor-006/benac-stor-006.md`

### BENAC-STOR-007 - CID verification on retrieval

**Statement:** Benac shall verify retrieved blob bytes against the expected DASL CID before accepting them as the requested blob, using them for execution, decrypting them, or forwarding them to compute.

**Rationale:** A provider can return wrong or malicious bytes.

**Verification:** Wrong bytes trigger integrity failure and are not used.

**Status:** draft

**Source record:** `records/req.benac-stor-007/benac-stor-007.md`

### BENAC-STOR-008 - Public/private storage policy

**Statement:** Benac shall distinguish raw public blob storage from encrypted private blob storage and shall apply local policy by data class, remote Station principal, operation, endpoint, and recipient.

**Rationale:** Public package artifacts and private baby photos are not the same kind of storage risk.

**Verification:** Policy allows public artifact mirror but denies raw private media upload.

**Status:** draft

**Source record:** `records/req.benac-stor-008/benac-stor-008.md`

### BENAC-STOR-009 - Client-side encryption for private remote storage

**Statement:** Private blobs shall be encrypted before remote storage unless local policy explicitly treats the Storage Station as a trusted processor and records the resulting disclosure.

**Rationale:** Storage Stations generally need not receive plaintext.

**Verification:** Private blob remote put stores ciphertext unless explicit processor disclosure path is approved.

**Status:** draft

**Source record:** `records/req.benac-stor-009/benac-stor-009.md`

### BENAC-STOR-010 - Blob location claims

**Statement:** Benac shall support blob location claims indicating where a blob or chunk CID may be available, while treating such claims as retrieval hints rather than proof of content or trust.

**Rationale:** Documents may know where bytes might be without trusting the source.

**Verification:** Location claim does not satisfy blob presence until retrieval and CID verification succeed.

**Status:** draft

**Source record:** `records/req.benac-stor-010/benac-stor-010.md`

### BENAC-STOR-011 - Storage discovery

**Statement:** Benac shall support decentralized discovery of storage offers and blob location claims through document replication, import, local configuration, peer exchange, package-mediated discovery, Compute Station metadata, and package bundles.

**Rationale:** No central storage registry should be required.

**Verification:** Storage offer imported from package bundle and replicated from peer both appear as untrusted offers.

**Status:** draft

**Source record:** `records/req.benac-stor-011/benac-stor-011.md`

### BENAC-STOR-012 - Storage lease requests

**Statement:** Benac shall support machine-readable storage lease request records created by authenticated or locally scoped users, agents, tools, packages where authorized, or other clients. A storage lease request shall describe the requested storage descriptor or offer where applicable, requested operations, target blob CIDs or blob classes where known, data classes, byte limits, recipient principals, encryption requirements, retention expectations, cost constraints where applicable, evidence expectations, requested expiry, initiating actor, authentication context where applicable, and supporting evidence or justification where supplied. A storage lease request shall not itself authorize storage effects. Storage effects require an active storage lease, capability grant, Local Policy allowance, or other accepted authorization record.

**Rationale:** Agents and tools need a legible way to ask for bounded storage resources, but the kernel does not need to define an agent's storage-planning process. Lease requests let agents take small reviewable steps toward availability, backup, staging, or sharing without receiving ambient storage authority.

**Verification:** An agent or tool creates a storage lease request for encrypted backup of selected blob CIDs. No upload, pin, publication, retrieval of sensitive blobs, sharing, or staging effect occurs until a matching lease or grant exists. The resulting request, approval/denial, lease, storage effects, receipts, and diagnostics are attributable and inspectable.

**Status:** draft

**Source record:** `records/req.benac-stor-012/benac-stor-012.md`

### BENAC-STOR-013 - Storage/compute coordination

**Statement:** Benac shall support coordination between storage leases and compute leases so blobs can be staged, retrieved, pinned, encrypted, decrypted, or returned for remote compute without bypassing local data-egress or disclosure policy.

**Rationale:** Remote compute often needs nearby storage, but staging is still a governed effect.

**Verification:** Compute lease request requiring staging fails unless a matching storage lease exists.

**Status:** draft

**Source record:** `records/req.benac-stor-013/benac-stor-013.md`

### BENAC-STOR-014 - No storage authority by replication

**Statement:** Replicated storage offers, location claims, pin claims, receipts, trust claims, or provider claims shall not automatically authorize storage use.

**Rationale:** Sync peers are not authorities.

**Verification:** Replicated storage offer cannot upload/fetch until local policy accepts it.

**Status:** draft

**Source record:** `records/req.benac-stor-014/benac-stor-014.md`

### BENAC-STOR-015 - Missing blob behavior

**Statement:** If a required blob is missing locally and no approved retrieval path exists, Benac shall fail loudly and identify the missing blob CID, object role, and any known unapproved location claims.

**Rationale:** Users and agents need actionable availability information without unsafe auto-fetch.

**Verification:** Missing package artifact reports known unapproved locations and denies execution.

**Status:** draft

**Source record:** `records/req.benac-stor-015/benac-stor-015.md`

### BENAC-STOR-016 - Deletion honesty

**Statement:** Benac shall distinguish local deletion, remote unpin, remote deletion request, access revocation, encrypted key destruction, and removal of availability claims. Benac shall not imply guaranteed global deletion from decentralized storage unless a provider/protocol can actually prove it.

**Rationale:** Remote deletion is often unverifiable; false deletion promises are dangerous.

**Verification:** Deletion UI/API uses precise operation labels and records receipts.

**Status:** draft

**Source record:** `records/req.benac-stor-016/benac-stor-016.md`

### BENAC-STOR-017 - Storage capability vocabulary

**Statement:** Benac shall define storage capabilities such as local blob read/write, remote blob get/put/pin/unpin, encrypted storage, public publish, package bundle import/export, blob share with principal, and storage audit.

**Rationale:** Policy must be able to grant narrow storage powers.

**Verification:** Capability tests grant remote get but deny remote put.

**Status:** draft

**Source record:** `records/req.benac-stor-017/benac-stor-017.md`

### BENAC-STOR-018 - Byte and retention limits

**Statement:** Storage leases shall support constraints such as max bytes, allowed blob CIDs, allowed data classes, recipient principals, expiry, retention expectations, remote Station principals, and allowed operations.

**Rationale:** Storage should be bounded like compute.

**Verification:** Lease denies operation exceeding max bytes or data class.

**Status:** draft

**Source record:** `records/req.benac-stor-018/benac-stor-018.md`

### BENAC-STOR-019 - Storage failure evidence

**Statement:** Benac shall record storage failures, including unavailable provider, partial retrieval, CID mismatch, expired lease, denied capability, encryption failure, and provider refusal.

**Rationale:** Availability failures are operationally and security relevant.

**Verification:** Mock provider returns wrong bytes; integrity failure evidence and effect are recorded.

**Status:** draft

**Source record:** `records/req.benac-stor-019/benac-stor-019.md`

### BENAC-STOR-020 - Standard Benac CAS exchange profile

**Statement:** Benac should define a provider-neutral CAS exchange profile for Benac-to-Benac or Benac-to-storage-peer blob/chunk presence, retrieval, upload, pin, unpin, and receipt operations over browser-compatible transports where feasible.

**Rationale:** Provider-specific storage bridges can be packages, but interoperability benefits from one generic CAS exchange profile.

**Verification:** Two independent implementations exchange a hello-world artifact blob by DASL CID through the CAS profile.

**Status:** draft

**Source record:** `records/req.benac-stor-020/benac-stor-020.md`

## Compute discovery and remote compute

### BENAC-COMP-001 - Compute offers

**Statement:** Compute offers shall describe mediated compute operation paths, endpoint or peer identity, offered limits or costs, evidence promises, privacy expectations, storage dependencies, trust/attestation metadata, and a Station Profile reference where available.
Compute offers shall not classify packages.
Compute offers shall not classify how package work is performed.
Compute offers shall not grant authority.
Local Policy shall decide whether a package operation can use a compute offer.

**Rationale:** Compute offers describe possible mediated compute, not authority and not package classes.

**Verification:** Compute offer tests verify identity, limits, evidence promises, policy review, and denial when Local Policy does not grant compute use.

**Status:** draft

**Source record:** `records/req.benac-comp-001/benac-comp-001.md`

## 10.12 Compute discovery and remote compute

### BENAC-COMP-002 - Compute Station identity and authentication

**Statement:** Remote Compute Stations shall be representable as cryptographic Station principals and shall authenticate before receiving private data, keys, compute leases, package artifacts requiring trust, or authority-bearing requests.

**Rationale:** Remote compute is a disclosure and accountability boundary. A Local Station must know which principal is being trusted for the operation.

**Verification:** Attempt to use a Compute Station without required authentication and verify that private compute or lease-bound work fails closed.

**Status:** draft

**Source record:** `records/req.benac-comp-002/benac-comp-002.md`

### BENAC-COMP-003 - Compute as package/descriptor

**Statement:** Remote compute shall be modeled through packages and descriptors rather than as a special central service.

**Rationale:** Compute should obey the same trust, capability, invocation, evidence, and effect rules as other behavior.

**Verification:** Remote compute descriptor invokes through ordinary invocation path.

**Status:** draft

**Source record:** `records/req.benac-comp-003/benac-comp-003.md`

### BENAC-COMP-004 - Host compute and remote compute distinction

**Statement:** Benac shall distinguish compute performed by the local host from compute performed by remote peers, while applying the same package identity, trust, capability, evidence, effect, and disclosure rules.

**Rationale:** A host can compute, but compute need not happen on the host.

**Verification:** Same package can run locally or remotely with invocation trace showing selected compute location.

**Status:** draft

**Source record:** `records/req.benac-comp-004/benac-comp-004.md`

### BENAC-COMP-005 - Compute lease requests

**Statement:** Benac shall support machine-readable compute lease request records created by authenticated or locally scoped users, agents, tools, packages where authorized, or other clients. A compute lease request shall describe the requested compute descriptor or offer where applicable, target package/interface/descriptor context where known, input CIDs or request snapshot references where known, data classes, required storage staging, data egress, privacy/disclosure implications, cost limits where applicable, resource limits, output encryption requirements, evidence expectations, requested expiry, initiating actor, authentication context where applicable, and supporting evidence or justification where supplied. A compute lease request shall not itself authorize compute effects, data egress, decryption, plaintext disclosure, or storage staging. Such effects require an active compute lease, storage lease where applicable, capability grant, Local Policy allowance, or other accepted authorization record.

**Rationale:** Agents and tools need a legible way to ask for bounded compute, especially when experimenting with models, remote resources, or heavier workloads. Benac should record the request and the authority boundary, not require a kernel-defined compute-planning process.

**Verification:** An agent or tool creates a compute lease request for a package invocation requiring remote compute and storage staging. No remote compute, private data egress, plaintext disclosure, or staging occurs until matching leases and grants exist. The request, approval/denial, lease, invocation, evidence, effects, disclosure records, and diagnostics are attributable and inspectable.

**Status:** draft

**Source record:** `records/req.benac-comp-005/benac-comp-005.md`

### BENAC-COMP-006 - Compute leases

**Statement:** Benac shall support local compute leases authorizing use of compute descriptors under constraints such as package CIDs, data classes, input blob CIDs, storage staging terms, invocation count, byte limits, cost limits, expiry, capability scope, accepted Compute Station principals, and output encryption requirements.

**Rationale:** Agents need bounded autonomy for compute use.

**Verification:** Lease allows matching invocation and denies non-matching invocation.

**Status:** draft

**Source record:** `records/req.benac-comp-006/benac-comp-006.md`

### BENAC-COMP-007 - Remote compute evidence

**Statement:** Remote compute results shall include locally recorded evidence and, when available, remote evidence such as remote Station principal, compute offer reference, compute lease reference, package CID, selected package interface, invocation contract snapshot CID, input CID, output CID, storage staging CID, logs, resource usage, failure details, attestations, and Station Profile reference.

**Rationale:** Remote results should not be naked answers.

**Verification:** Remote mock compute returns evidence bundle recorded locally.

**Status:** draft

**Source record:** `records/req.benac-comp-007/benac-comp-007.md`

### BENAC-COMP-008 - No compute bypass

**Statement:** Agents shall not use remote compute to bypass local data egress, secret, trust, storage, privacy, identity, decryption, or capability policy.

**Rationale:** Remote compute is an effect, not an escape hatch.

**Verification:** Agent without data-egress permission cannot send private payload to compute descriptor.

**Status:** draft

**Source record:** `records/req.benac-comp-008/benac-comp-008.md`

### BENAC-COMP-009 - Authenticated remote result binding

**Statement:** Remote compute results shall be bound to authenticated Compute Station principal, request CID, nonce or challenge, compute lease, package CID, selected package interface, invocation contract snapshot CID, output CID, evidence CID, and timing or sequence information.

**Rationale:** Benac needs accountability and replay resistance even when it cannot prove that remote compute was semantically honest.

**Verification:** Replay a compute result under a different request, lease, or nonce and verify that Benac rejects it or records it as invalid evidence.

**Status:** draft

**Source record:** `records/req.benac-comp-009/benac-comp-009.md`

### BENAC-COMP-010 - Plaintext compute warning

**Statement:** When remote compute will receive plaintext or decryption capability for private data, Benac shall record and expose that disclosure as part of the compute lease request, compute lease, invocation, and effect ledger.

**Rationale:** Users may choose risky compute, but the system must not hide the risk.

**Verification:** High-sensitivity remote compute fixture requires explicit disclosure effect before proceeding.

**Status:** draft

**Source record:** `records/req.benac-comp-010/benac-comp-010.md`

## 10.13 Secrets, protected local state, and redaction

### BENAC-SEC-001 - Host-mediated secrets and authentication credentials

**Statement:** Secrets and authentication credentials shall be mediated by the Host Station. Packages and agents shall not receive raw secret material by default; they may request approved operations that use secret references under policy.

**Rationale:** Benac must support authentication to external services without making long-lived credentials package-readable.

**Verification:** Invoke a package requiring API authentication and inspect evidence/effects to confirm secret reference use, redaction, and absence of raw secret exposure.

**Status:** draft

**Source record:** `records/req.benac-sec-001/benac-sec-001.md`

### BENAC-SEC-002 - Secrets do not replicate by default

**Statement:** Secret material shall not replicate by default through Couch/Pouch replication, package export, package bundle export, remote storage upload, or package import.

**Rationale:** Replication and storage should not spread credentials.

**Verification:** Export/replication/storage tests confirm secrets excluded or encrypted under explicit user policy.

**Status:** draft

**Source record:** `records/req.benac-sec-002/benac-sec-002.md`

### BENAC-SEC-003 - Secret metadata separation

**Statement:** Secret references and metadata may be stored as local documents, but raw secret material shall be stored in a protected host-specific vault or equivalent protected storage mechanism.

**Rationale:** Different platforms have different secure storage options.

**Verification:** Document store does not contain raw secret value.

**Status:** draft

**Source record:** `records/req.benac-sec-003/benac-sec-003.md`

### BENAC-SEC-004 - Redaction

**Statement:** Evidence and effect records shall redact, hash, encrypt, or omit sensitive fields according to local policy before storage, replication, export, remote storage upload, or disclosure to agents.

**Rationale:** Receipts should not casually leak secrets or private data.

**Verification:** Authorization header and configured sensitive request fields redacted in evidence records.

**Status:** draft

**Source record:** `records/req.benac-sec-004/benac-sec-004.md`

### BENAC-SEC-005 - No default telemetry

**Statement:** Benac shall not transmit telemetry, package contents, invocation records, evidence, effects, secrets, private keys, identity records, storage activity, or compute activity to a central service by default.

**Rationale:** Local-first and decentralized operation requires user control over data movement.

**Verification:** fresh Station has no telemetry endpoint configured.

**Status:** draft

**Source record:** `records/req.benac-sec-005/benac-sec-005.md`

### BENAC-SEC-006 - Raw secrets prohibited outside protected secret handling

**Statement:** Raw secret material shall not be exposed to package code through package documents, descriptor documents, invocation requests, host-local metadata, operational envelopes, package bundles, replicated documents, evidence records, effect records, logs, or agent-readable inspection APIs unless an explicit high-risk secret-disclosure profile permits the exposure and records it. Secret references may be package-visible where authorized. Raw secret values shall be mediated by the Host Station and stored in protected storage or an equivalent local vault mechanism.

**Rationale:** A field is not safe merely because it is outside package identity. Raw secrets can leak through package input, replication, export, logs, evidence, effects, or UI inspection unless explicitly prohibited and redacted.

**Verification:** Fixtures place token-like values in package documents, descriptors, operational metadata, evidence records, effect records, and package bundles. Baseline hosts reject, redact, omit, encrypt, or mark the material non-exportable according to policy. A package requiring API authentication receives only a secret reference or host-mediated authenticated operation, not the raw secret.

**Status:** draft

**Source record:** `records/req.benac-sec-006/benac-sec-006.md`

## 10.14 Machine-readable client operation

### BENAC-AGT-002 - Agent identity and authentication

**Statement:** Agents shall be representable as principals or locally scoped authenticated sessions. Benac shall bind agent-authored packages, trust requests, capability requests, storage lease requests, compute lease requests, and invocations to the authenticated agent identity or session where attribution matters.

**Rationale:** Agents must be accountable without being allowed to authorize themselves.

**Verification:** Have an authenticated agent and an unauthenticated agent attempt the same authority-sensitive operation and verify correct attribution and denial behavior.

**Status:** draft

**Source record:** `records/req.benac-agt-002/benac-agt-002.md`

### BENAC-AGT-004 - Agents cannot self-trust

**Statement:** Agents shall not be able to grant trust, capabilities, secret access, decryption authority, native execution, remote storage use, remote compute use, data egress permission, private key access, or disclosure authority to themselves unless separately authorized by local policy outside the requesting agent's authority.

**Rationale:** Agents can propose, build, test, and request authority. Benac records those requests and applies Local Policy so agent experimentation can proceed in small reviewable steps without invisible privilege escalation.

**Verification:** Agent-created trust request does not become active grant without approval.

**Status:** draft

**Source record:** `records/req.benac-agt-004/benac-agt-004.md`

### BENAC-AGT-005 - Trust and capability requests

**Statement:** Benac shall support trust request and capability request documents that allow agents to request scoped trust and grants with justifications, tests, fixture results, risk descriptions, data egress disclosures, storage implications, compute implications, encryption implications, and signed claim references.

**Rationale:** Human and policy review need structured authorization requests and evidence.

**Verification:** Trust request schema validation and review workflow demonstration.

**Status:** draft

**Source record:** `records/req.benac-agt-005/benac-agt-005.md`

### BENAC-AGT-009 - Agent action audit

**Statement:** Agent actions that create, import, modify, sign, request, test, invoke, export, replicate, store, retrieve, disclose, or propose trust for Benac objects shall be recorded.

**Rationale:** Agent and client autonomy requires accountability and repairable feedback.

**Verification:** Agent-created package draft, storage lease request, and trust request produce audit records.

**Status:** draft

**Source record:** `records/req.benac-agt-009/benac-agt-009.md`

### BENAC-AGT-010 - Machine-readable errors

**Statement:** Agent-facing APIs shall return structured errors for validation failures, package authoring failures, package build failures, fixture failures, trust denials, capability denials, missing blobs, artifact CID mismatches, schema failures, WASM package-host calling convention failures, resource-limit failures, encryption failures, storage failures, compute failures, package import failures, Package Bundle ZIP failures, and conformance failures. Structured errors shall use the stable diagnostic format and diagnostic-code registry defined by Benac, and shall include raw diagnostic evidence inline or by CID/encrypted reference where practical and safe, or shall record why such evidence was omitted, redacted, truncated, encrypted, or unavailable.

An import failure that occurs before a package CID is derivable shall
return or persist a package import failure record containing operation
identifier, input artifact kind, observed media type where available,
observed filename where available, observed size where available,
failure phase, primary diagnostic classification code, diagnostic code
list, diagnostic record references or explicit diagnostic-record
omission disposition, origin-specific error details where available,
and raw diagnostic evidence disposition.

The package import failure response returned to an agent shall expose
the same primary diagnostic classification code that is recorded in the
package import failure record.

The package import failure response returned to an agent shall expose
or reference the same raw or origin-specific evidence lane that is
recorded in the diagnostic record.

**Rationale:** Agents need to recover from problems without guessing, while still being able to inspect the underlying evidence when a stable classification code is not specific enough.

**Verification:** Invalid package import, missing artifact, unsupported schema keyword, fixture mismatch, forbidden WASM import, missing WASM export, resource-limit failure, capability denial, malformed Package Bundle ZIP file, and standalone JSON package import file return structured errors containing or referencing diagnostic records with stable diagnostic classification codes, required context bindings, and raw or origin-specific evidence references where practical and safe. A package import failure occurring before a package CID is derivable returns a package import failure record carrying operation identifier, input artifact kind, observed filename/media type/size where available, failure phase, primary diagnostic classification code, diagnostic code list, diagnostic record references or explicit diagnostic-record omission disposition, and raw diagnostic evidence disposition. The primary diagnostic classification code exposed to the agent matches the primary diagnostic classification code in the package import failure record, and the raw/origin evidence lane exposed to the agent matches the raw evidence lane recorded in the diagnostic record.

**Status:** draft

**Source record:** `records/req.benac-agt-010/benac-agt-010.md`

## 10.15 Import, export, package bundles, and decentralized distribution

### BENAC-IO-001 - Local package import

**Statement:** Benac shall import packages from a Package Bundle ZIP file.

A Package Bundle ZIP file shall contain a required Package Bundle Manifest at `bundle/package_bundle_manifest.json`.

A Host Implementation shall not import a standalone package document JSON file, standalone package bundle JSON file, standalone package bundle manifest JSON file, standalone schema JSON file, standalone fixture JSON file, standalone report JSON file, standalone claim JSON file, standalone raw blob file, or standalone CID index JSON file as a package.

Package document JSON, package bundle JSON, package bundle manifest JSON, schema JSON, fixture JSON, report JSON, claim JSON, and raw blob files shall enter package import semantics only as declared entries inside a Package Bundle ZIP file.

Package import shall compute and verify the package CID, Package Bundle Manifest CID, included structured document CIDs, and included raw blob CIDs before recording package import success.

Package import shall create a package import record on success.

Package import shall create a package import failure record on failure.

Package import shall not grant trust, capability authority, blob retrieval authority, storage authority, compute authority, package approval, or execution authority.

**Rationale:** Package authors and independent Host Implementations need one physical package import artifact. A Package Bundle ZIP file gives browser and desktop hosts a single selectable package file while preserving package identity as the package CID and distribution context as the Package Bundle Manifest.

**Verification:** Conformance tests import the same valid Package Bundle ZIP file on Browser PWA, Ubuntu, macOS, and Windows Host Implementations. Each Host Implementation computes the same package CID, Package Bundle Manifest CID, structured document CIDs, raw blob CIDs, fixture discovery result, artifact availability result, inspection result, diagnostics, and package import record. Tests also prove that standalone package document JSON, standalone package bundle JSON, standalone package bundle manifest JSON, standalone schema JSON, standalone fixture JSON, standalone report JSON, standalone claim JSON, standalone raw blob files, and standalone CID index JSON files are rejected as package import artifacts with stable diagnostics and raw diagnostic evidence handling.

**Status:** draft

**Source record:** `records/req.benac-io-001/benac-io-001.md`

### BENAC-IO-002 - HTTPS import

**Statement:** Benac may support importing package bundles, blobs, claims, storage offers, or compute offers from HTTPS URLs, but URL location shall not define package identity or trust.

**Rationale:** URLs are retrieval hints, not authority.

**Verification:** Imported bytes are verified against the expected DASL CID; URL alias is not used as execution identity.

**Status:** draft

**Source record:** `records/req.benac-io-002/benac-io-002.md`

### BENAC-IO-004 - Missing blob reporting

**Statement:** Benac shall clearly report missing blobs referenced by imported or replicated documents and shall fail closed for execution until required blobs are present and verified or approved retrieval occurs.

**Rationale:** Replication of metadata may precede blob availability.

**Verification:** Import metadata-only package bundle; execution denied with missing blob list.

**Status:** draft

**Source record:** `records/req.benac-io-004/benac-io-004.md`

### BENAC-IO-005 - Package Bundle integrity

**Statement:** Package bundles shall include integrity metadata such as object CIDs, blob CIDs or manifests, signatures where present, encrypted envelope metadata where present, and optional tamper-evident manifests.

**Rationale:** Portable exports need receipts.

**Verification:** Altered package bundle fails integrity verification.

**Status:** draft

**Source record:** `records/req.benac-io-005/benac-io-005.md`

### BENAC-IO-006 - Encrypted Package Bundles

**Statement:** Package bundles containing private documents, private blobs, sensitive evidence, secret-adjacent metadata, storage lease requests, compute lease requests, or optional supporting materials shall support encryption to selected recipients or passphrases according to local policy.

**Rationale:** Package bundle export should not force plaintext sharing.

**Verification:** Encrypted private package bundle decrypts only for authorized recipient.

**Status:** draft

**Source record:** `records/req.benac-io-006/benac-io-006.md`

## 10.16 Interoperability, DRISL encoding, and conformance testing

### BENAC-INT-001 - DRISL for structured content identity and signatures

**Statement:** Benac shall use DRISL as the baseline deterministic structured encoding for all content-addressed or signed structured objects. JSON representations of signed or content-addressed structured objects shall be treated as projections unless a future encoding addition explicitly defines JSON bytes as the bytes used for CIDs or signatures.

**Rationale:** Interoperability requires independent implementations to hash and sign the same bytes for the same logical Benac object. DRISL provides those bytes for baseline structured objects.

**Verification:** DRISL encoding, JSON-projection-to-DRISL, CID-link representation, signed payload, and rejection vectors pass across implementations.

**Status:** draft

**Source record:** `records/req.benac-int-001/benac-int-001.md`

## Interoperability and conformance

### BENAC-INT-003 - Stable diagnostic format

**Statement:** Benac shall define stable machine-readable diagnostic structures and diagnostic classification codes for validation, package authoring, package build, fixture execution, trust, capability, cryptographic, missing artifact, artifact CID mismatch, schema validation, WASM package-host calling convention, resource limit, storage, compute, encryption, decryption, package import, and invocation failures.
A stable diagnostic classification code shall identify a portable Benac failure class or contract boundary, not an exhaustive root cause.
The meaning of a stable diagnostic classification code shall not silently change across conforming implementations.
Diagnostic records shall support at least diagnostic object type and schema version, stable diagnostic classification code, diagnostic code registry identifier where relevant, severity, phase or operation class, package CID, descriptor snapshot CID, package interface identifier, invocation contract snapshot CID where relevant, request snapshot CID, output snapshot CID, schema ruleset identifier, WASM package- host calling convention identifier where relevant, resource limit report reference, or other applicable context; origin of the diagnostic; origin-specific code, message, status, or structured payload where relevant; normalized details for the stable diagnostic classification code where defined; raw diagnostic evidence inline or by CID/encrypted reference where practical and safe; and redaction, truncation, encryption, omission, or unavailability metadata where raw evidence is not fully stored.
Human-readable messages, origin-specific codes, provider responses, stack traces, runtime traps, logs, and package-provided error bodies can be useful evidence, but they shall not replace the stable diagnostic classification code required for recognized failures.
The diagnostic-code registry shall include at least `package.document.invalid`, `package.unknown_required_field`, `package.schema_ref.unresolved`, `schema.unsupported_ruleset`, `schema.unsupported_keyword`, `schema.validation_failed`, `artifact.missing`, `artifact.cid_mismatch`, `invocation_contract.snapshot_mismatch`, `operation.not_currently_mediated_by_this_station`, `operation.not_yet_determined`, `operation.attempt_denied`, `operation.attempt_failed`, `wasm.import_forbidden`, `wasm.export_missing`, `wasm.calling_convention_invalid`, `resource.limit_exceeded`, `fixture.invalid`, `fixture.output_mismatch`, `fixture.effect_mismatch`, `capability.undeclared`, `capability.denied`, `capability.grant_missing`, `capability.expired`, `capability.revoked`, `capability.conflicted`, `approval.requirements_not_satisfied`, `package_import.input_unsupported`, `package_import.failure_record_required`, `package_bundle_zip.invalid`, `package_bundle_zip.unsafe_path`, `package_bundle_zip.duplicate_path`, `package_bundle_zip.resource_limit_exceeded`, `package_bundle_zip.manifest_missing`, `package_bundle_zip.manifest_invalid`, `package_bundle_zip.entry_missing`, `package_bundle_zip.entry_undeclared`, `package_bundle_zip.entry_cid_mismatch`, `package_bundle_zip.entry_role_unsupported`, `package_bundle_zip.object_type_unsupported`, `package_bundle_zip.schema_version_unsupported`, `cid.invalid`, `cid.codec_unsupported`, `cid.hash_unsupported`, `cid.string_malformed`, and `diagnostic.unclassified`.
Package import diagnostic classification codes shall not depend on filename or file extension.
Diagnostic classification codes shall not classify packages.
Diagnostic classification codes shall not classify how package work is performed.
`diagnostic.unclassified` shall be used only when no more specific supported diagnostic classification code applies, and diagnostic records using it shall include origin, context, and raw or origin-specific evidence where practical and safe.

**Rationale:** Stable diagnostics let agents, users, and independent implementations distinguish content failure, missing grants, unavailable artifacts, not-currently-mediated operations, and failed attempts without relying on human text.

**Verification:** Diagnostic conformance tests verify each registered diagnostic code, required context fields, raw evidence disposition, and no substitution of human-readable messages for stable codes.

**Status:** draft

**Source record:** `records/req.benac-int-003/benac-int-003.md`

## 10.15 Import, export, package bundles, and decentralized distribution

### BENAC-IO-007 - Package Bundle ZIP file structure

**Statement:** A Package Bundle ZIP file shall be a ZIP file containing only regular file entries and directory entries.

Every ZIP entry path shall be a UTF-8 relative path using `/` as the separator.

A ZIP entry path shall not be empty, absolute, duplicated after path normalization, contain `\`, contain a `.` path component, contain a `..` path component, or identify platform metadata.

A Package Bundle ZIP file shall contain `bundle/package_bundle_manifest.json`.

A Host Implementation shall read `bundle/package_bundle_manifest.json` as the Package Bundle ZIP distribution contract.

A Host Implementation shall compute the Package Bundle Manifest CID from the DRISL-encoded Package Bundle Manifest logical object.

The Package Bundle Manifest shall not declare a field containing the CID of the Package Bundle Manifest itself.

Every non-directory ZIP entry other than `bundle/package_bundle_manifest.json` shall be declared by the Package Bundle Manifest.

Every declared included entry shall exist in the ZIP file.

A Host Implementation shall reject a Package Bundle ZIP file containing undeclared non-directory entries.

A Host Implementation shall reject a Package Bundle ZIP file missing a declared included entry.

A Host Implementation shall not derive package import semantics from ZIP entry filenames, directory names, ZIP metadata, file ordering, file timestamps, file extensions, comments, compression method, host filesystem metadata, file permission bits, or undeclared JSON object fields.

A ZIP entry shall have package import meaning only through the entry role declared for that path in the Package Bundle Manifest.

For a structured document entry, import shall parse the JSON projection, validate the logical object, encode the logical object as DRISL, compute the structured document CID, and compare it to the CID declared in the Package Bundle Manifest.

For a raw blob entry, import shall compute the raw blob CID over the exact decompressed entry bytes and compare it to the CID declared in the Package Bundle Manifest.

Any unsafe path, duplicate path, undeclared entry, missing declared entry, parse failure, schema failure, CID mismatch, unsupported entry role, unsupported object type, unsupported schema version, resource-limit failure, or ZIP processing failure shall fail closed with a stable diagnostic record and raw diagnostic evidence handling.

**Rationale:** A Package Bundle ZIP file gives independent implementations a single package import file while allowing package distributions to include many content-addressed logical objects and byte artifacts. ZIP transport details must not become identity, trust, or authority.

**Verification:** Conformance tests cover valid ZIP import, missing manifest, invalid ZIP file, unsafe path, duplicate path, undeclared entry, missing declared entry, unsupported entry role, unsupported structured object type, unsupported schema version, structured document CID mismatch, raw blob CID mismatch, resource-limit failure, and filename-with-no-import-semantics. Each failure produces the required stable diagnostic classification code and raw diagnostic evidence disposition.

**Status:** draft

**Source record:** `records/req.benac-io-007/benac-io-007.md`

## 10.16 Interoperability, DRISL encoding, and conformance testing

### BENAC-INT-002 - Raw byte blob CIDs

**Statement:** Blob CIDs shall be computed as DASL CID v1 raw CIDs using codec 0x55 over the exact byte sequence. Raw blob identity shall not depend on transport encoding, filename, media type, compression metadata, document reference context, or Couch/Pouch representation. Benac-specific blob roles shall be supplied by referencing DRISL documents, manifests, claims, invocations, evidence records, effect records, leases, or policies, not by changing the raw blob digest input.

**Rationale:** Binary identity must not depend on transport encoding or object role. The same raw bytes shall have the same raw blob CID.

**Verification:** Raw blob CID vectors match after file, HTTP, package bundle, local blob store, and storage transfer. Identical bytes produce identical raw CIDs regardless of object role.

**Status:** draft

**Source record:** `records/req.benac-int-002/benac-int-002.md`

## Interoperability and conformance

### BENAC-INT-004 - Conformance test suite

**Statement:** Benac shall provide a conformance suite covering DASL CID parsing, generation, rejection, and verification; DRISL encoding and JSON projection; content identity; principal identity; signed claims; encrypted envelopes; Couch/Pouch document replication; blob storage; storage discovery; compute discovery; package document validation; package schema validation; Package Bundle import; package build reports; package validation reports; package inspection results; fixture schemas; fixture execution; schema-defined package behavior; WASM package-host calling convention behavior where WASM artifacts are used; capability denial; package approval; capability grants; invocation ledgers; evidence/effects; resource-limit behavior; package interface invocation; no silent fallback; and Package Bundle ZIP package import.
Conformance vectors shall test package content validity separately from Local Policy grants, artifact availability, resource availability, and whether the Station can currently mediate an operation.
Conformance vectors shall not define package classes.
Conformance vectors shall not define classes for how package work is performed.

**Rationale:** Independent implementations need executable proof that they interpret package content, authority, operation status, and records the same way.

**Verification:** Teams run the suite and publish results, including DASL CID and DRISL encoding vectors. Package conformance fixtures include greeting package, calculator, todo reducer, notes reducer or text transform, invalid schema package, missing artifact package, forbidden import package, unsupported schema keyword package, fixture mismatch package, resource-limit package, generic request/config package, multi-interface package, package inspection comparison, and package approval package. Tests verify that a package with an operation the Station cannot currently mediate imports and inspects when import and validation requirements are satisfied.

**Status:** draft

**Source record:** `records/req.benac-int-004/benac-int-004.md`

### BENAC-INT-005 - Same package content and record behavior

**Statement:** A package whose content, Package Bundle, declared requirements, Local Policy grants, artifacts, resources, descriptor scope, request body, and mediated operation results are equivalent shall produce equivalent package CIDs, invocation contract snapshot CIDs where relevant, validation reports, inspection results, fixture results, invocation records, evidence records, effect records, and diagnostics across conforming implementations.
Different Local Policy grants, missing artifacts, unavailable resources, platform permission outcomes, or not-currently-mediated operations shall be reflected in the records.
Those differences shall not change package content identity.

**Rationale:** Cross-team interoperability depends on identical content producing identical identities and equivalent records while preserving local policy and Station state.

**Verification:** The same Package Bundle produces equivalent package CIDs, Package Bundle Manifest CIDs, structured document CIDs, validation reports, and inspection results across conforming implementations. Differences in Local Policy, artifacts, resources, or mediated operation attempts are visible in operation records.

**Status:** draft

**Source record:** `records/req.benac-int-005/benac-int-005.md`

## User inspectability and operation

### BENAC-UX-001 - Package inspection

**Statement:** Benac shall allow users and agents to inspect package documents, package document versions, package labels and version labels as non-authoritative metadata, schemas, schema rulesets, package interfaces, request/config/output schema references, invocation contract snapshots where derivable, artifact CIDs, artifact availability, declared capabilities, resource requirements, fixtures, claims, storage needs, compute needs, warnings, unknown fields, missing artifacts, diagnostic records or diagnostic record references, stable diagnostic classification codes, and raw diagnostic evidence references where practical and safe before trust, approval, or invocation.
Package inspection shall distinguish package content validity from operation eligibility.
Package inspection shall not classify packages.
Package inspection shall not classify how package work is performed.

**Rationale:** Trust and approval require visibility into package identity, schema contracts, artifacts, capabilities, resource requirements, and operation blockers.

**Verification:** Inspection UI/API displays required package information before trust, approval, and invocation. Inspection reports content validity separately from unavailable artifacts, missing grants, policy denials, resource conflicts, and operation status.

**Status:** draft

**Source record:** `records/req.benac-ux-001/benac-ux-001.md`

## 10.17 User inspectability and operation

### BENAC-UX-002 - Trust and capability review

**Statement:** Benac shall expose trust decisions, capability grants, decryption grants, storage leases, compute leases, data classes, expiry, revocation, and issuer information in human- and agent-readable form.

**Rationale:** Users need to understand what power has been granted.

**Verification:** Review UI/API test shows grant scopes and revocation controls.

**Status:** draft

**Source record:** `records/req.benac-ux-002/benac-ux-002.md`

### BENAC-UX-003 - Invocation trace inspection

**Statement:** Benac shall allow inspection of invocation traces, package interface, invocation contract snapshot, request/output references, evidence, effects, storage actions, compute actions, disclosure records, validation results, diagnostics, and operation status.

**Rationale:** Invocation traces should expose the schema-bound operation context and recorded outcomes, not a package-work taxonomy.

**Verification:** Trace inspection tests verify package interface, invocation contract snapshot, request/output references, evidence, effects, storage actions, compute actions, disclosure records, validation results, diagnostics, and operation status.

**Status:** draft

**Source record:** `records/req.benac-ux-003/benac-ux-003.md`

### BENAC-UX-004 - Principal and claim inspection

**Statement:** Benac shall allow inspection of principals, key status, signed claims, signature verification status, name bindings, accepted claim policies, and rejected claims.

**Rationale:** Decentralized identity needs inspectability.

**Verification:** Claim inspection fixture shows verified, unverified, accepted, and rejected states.

**Status:** draft

**Source record:** `records/req.benac-ux-004/benac-ux-004.md`

### BENAC-UX-005 - Storage and compute authorization review

**Statement:** Benac shall present storage lease requests, compute lease requests, storage leases, compute leases, and related disclosure approvals with data egress, data class, encryption, recipient, Station principal, endpoint or descriptor, cost where known, evidence expectations, trust implications, and plaintext disclosure implications before approval where Local Policy requires review.

**Rationale:** Remote resource use can create privacy, cost, and availability consequences. Review surfaces should help users and agents understand the requested authority and blast radius without making Benac Core responsible for the agent's planning process.

**Verification:** Storage and compute authorization review fixtures display required data class, egress, recipient, encryption, cost, evidence, and plaintext disclosure information before lease approval.

**Status:** draft

**Source record:** `records/req.benac-ux-005/benac-ux-005.md`

### BENAC-UX-006 - Plaintext disclosure review

**Statement:** Benac shall clearly distinguish encrypted storage from plaintext disclosure to compute or processor principals in user-facing and agent-facing review surfaces.

**Rationale:** Users should not confuse encrypted transport/storage with safe compute.

**Verification:** Remote private compute fixture displays plaintext disclosure warning.

**Status:** draft

**Source record:** `records/req.benac-ux-006/benac-ux-006.md`

## Import, export, and decentralized distribution

### BENAC-IO-003 - Package Bundle export

**Statement:** Benac shall support Package Bundle export containing package documents, schemas, artifacts, fixtures, fixture results, validation reports, build reports, inspection results, documentation, claims, evidence references, effect references, and blobs selected by Local Policy.
Package Bundle export shall not grant trust.
Package Bundle export shall not grant capability authority.
Package Bundle export shall not classify packages.
Package Bundle export shall not classify how package work is performed.
Exported Package Bundle contents shall preserve package CID, Package Bundle Manifest CID where relevant, structured document CIDs, raw blob CIDs, schema CIDs, request snapshot CIDs, output snapshot CIDs, invocation contract snapshot CIDs where relevant, and typed references.

**Rationale:** Package-related materials need a portable export path without changing package identity or authority.

**Verification:** Export tests verify package CID stability, manifest CID stability, included document and blob CIDs, and no authority grant from export.

**Status:** draft

**Source record:** `records/req.benac-io-003/benac-io-003.md`

## 10.17 User inspectability and operation

### BENAC-UX-007 - Authentication review

**Statement:** Benac shall allow users and authorized reviewers to inspect authentication context for sensitive actions, including who authenticated, which Station or agent was authenticated, what method class was used where available, when authentication occurred, and which authority-bearing action it supported.

**Rationale:** Authentication is part of accountability and must be visible in traces, not hidden in host details.

**Verification:** Perform a sensitive approved action and inspect the trace to verify that authentication context is visible without exposing secrets.

**Status:** draft

**Source record:** `records/req.benac-ux-007/benac-ux-007.md`

## 10.18 Availability, offline behavior, and performance

### BENAC-AVL-001 - Offline app shell

**Statement:** The browser PWA host shall load its app shell offline after installation where platform support permits.

**Rationale:** Mobile browser use should not require constant connectivity for local operations.

**Verification:** Offline reload test after install.

**Status:** draft

**Source record:** `records/req.benac-avl-001/benac-avl-001.md`

### BENAC-AVL-002 - Offline package invocation

**Statement:** Packages that require no network, remote storage, remote compute, unavailable blobs, or external capabilities shall be invokable offline after required artifacts are locally available and trusted.

**Rationale:** Local-first means useful offline behavior.

**Verification:** Hello-world package runs offline.

**Status:** draft

**Source record:** `records/req.benac-avl-002/benac-avl-002.md`

### BENAC-AVL-003 - Clear network/resource failure

**Statement:** Network, replication, storage, compute, and blob availability failures shall be clearly attributable, recorded, and inspectable.

**Rationale:** Failures should be auditable, not ambiguous.

**Verification:** Mock remote storage and compute failures produce clear records.

**Status:** draft

**Source record:** `records/req.benac-avl-003/benac-avl-003.md`

## Agent API

### BENAC-AGT-001 - Machine-readable client API

**Statement:** Benac shall provide a machine-readable client API for package import, package validation, package inspection, package approval requests, capability requests, fixture execution, invocation, evidence inspection, effect inspection, diagnostics, and local status queries.
Client API responses shall distinguish package content validity, package import status, operation eligibility, Local Policy grants, denied capabilities, unavailable artifacts, unavailable resources, not-currently-mediated operations, not-yet- determined status, attempted operations, failed operations, and completed operations.
Client API responses shall not classify packages.
Client API responses shall not classify how package work is performed.

**Rationale:** Agents need machine-readable package facts and operation status without depending on UI strings or package classes.

**Verification:** Agent API tests inspect packages, request approvals, request capabilities, invoke package interfaces, and receive stable machine-readable status and diagnostics.

**Status:** draft

**Source record:** `records/req.benac-agt-001/benac-agt-001.md`

## 10.18 Availability, offline behavior, and performance

### BENAC-PERF-001 - Mobile practicality

**Statement:** Baseline operations such as opening the app, inspecting packages, verifying CIDs, verifying signatures, invoking hello-world, validating manifests, storing small blobs, encrypting/decrypting small private blobs, and viewing traces shall be practical on ordinary iOS and Android devices.

**Rationale:** Mobile browser viability is a first-class requirement.

**Verification:** Performance smoke tests on representative devices.

**Status:** draft

**Source record:** `records/req.benac-perf-001/benac-perf-001.md`

### BENAC-PERF-002 - Large blob caution

**Statement:** Benac shall support large blob handling through chunking and availability metadata, but mobile Host Platforms may enforce storage and transfer limits according to Station profile and local policy.

**Rationale:** Large artifacts are real, but mobile devices are constrained.

**Verification:** Large blob fixture reports limits and fails gracefully if host policy denies storage.

**Status:** draft

**Source record:** `records/req.benac-perf-002/benac-perf-002.md`

## Agent API

### BENAC-AGT-003 - Agent package authoring

**Statement:** Benac shall expose package authoring APIs that let agents create package documents, package interfaces, request schemas, descriptor config schemas, output schemas, artifact references, declared capabilities, resource requirements, fixture records, documentation references, evidence behavior declarations, and effect behavior declarations.
Agent package authoring APIs shall not require or emit package class fields.
Agent package authoring APIs shall not require or emit fields that classify how package work is performed.
Agent package authoring APIs shall validate generated package content against the same package document schema and package schema ruleset used by Host Implementations.

**Rationale:** Agents should author packages from schema-bound public contracts and declared requirements, not from package-work taxonomies.

**Verification:** Agent-authored package fixtures validate across conforming implementations and do not contain retired package-class or work-class fields.

**Status:** draft

**Source record:** `records/req.benac-agt-003/benac-agt-003.md`

## 10.19 Safety and high-risk capabilities

### BENAC-SAFE-001 - Physical-world effects are explicit

**Statement:** Capabilities that can affect physical devices, homes, vehicles, displays, cameras, microphones, locks, thermostats, actuators, or other high-risk resources shall be explicit and shall not be implied by generic network, storage, compute, or execution permission.

**Rationale:** Physical-world capabilities should be explicit handholds, not hidden behind generic network or device access. This lets agents use real-world devices through visible, scoped, reviewable authority rather than ambient power.

**Verification:** Package cannot actuate device through generic capability in conformance fixture.

**Status:** draft

**Source record:** `records/req.benac-safe-001/benac-safe-001.md`

### BENAC-SAFE-002 - Human approval gates

**Statement:** Benac shall support human approval gates for high-risk capabilities and for policies that require explicit user intervention.

**Rationale:** Human approval gates allow useful delegation while preserving escalation boundaries for high-risk effects. Agents can still propose and prepare work; Local Policy decides when a human must approve before the world changes.

**Verification:** High-risk mock capability requires approval before execution.

**Status:** draft

**Source record:** `records/req.benac-safe-002/benac-safe-002.md`

### BENAC-SAFE-003 - Emergency revocation

**Statement:** Benac shall support immediate local revocation or disabling of a package, descriptor, principal, agent, storage lease, compute lease, decryption grant, or capability grant.

**Rationale:** Users need a stop mechanism.

**Verification:** Revoked capability prevents subsequent invocation or remote resource use.

**Status:** draft

**Source record:** `records/req.benac-safe-003/benac-safe-003.md`

### BENAC-SAFE-004 - Fail-closed default

**Statement:** Benac shall fail closed when package validity, signature validity, key status, trust scope, capability scope, privacy authorization, encryption metadata, invocation contract status, operation mediation status, storage lease, compute lease, or blob availability is unknown or conflicted.

**Rationale:** Unknown or conflicted authority should produce a clear blocked state and diagnostic rather than accidental power. This keeps experimentation bounded and repairable.

**Verification:** Unknown or conflicted policy, invocation-contract, operation-mediation, lease, and blob-availability fixtures deny execution and remote resource use.

**Status:** draft

**Source record:** `records/req.benac-safe-004/benac-safe-004.md`

### BENAC-SAFE-005 - User override with receipt

**Statement:** Benac may allow users to override certain risk warnings where policy permits, but such overrides shall be explicit, attributable, scoped, revocable, and recorded.

**Rationale:** The system should not pretend to prevent every poor choice, but it should not hide those choices.

**Verification:** User override for risky public compute creates signed/local approval and disclosure effect.

**Status:** draft

**Source record:** `records/req.benac-safe-005/benac-safe-005.md`

## Host API

### BENAC-HOST-001 - Host API semantics

**Statement:** Benac Host Implementations shall expose stable Host API semantics to Benac Core and package operations.
The exact transport can differ by implementation, but the semantics shall include storage, DASL CID creation/parsing/verification, DRISL encoding and decoding for Benac logical payloads, local user authentication, Station-to-Station authentication, agent session authentication, authentication-context reporting, signing support where authorized, signature verification, local and remote authentication support, encryption/decryption where authorized, key wrapping where authorized, schema validation, package import/export, package validation, package build where available, fixture execution, package inspection, trust query, capability request, invocation lifecycle, evidence emission, effect emission, disclosure recording, secret and credential mediation, local blob access, remote storage access where mediated and authorized, remote compute access where mediated and authorized, clock, random bytes, Station Profile inspection, known schema ruleset reporting, known calling-convention reporting, known resource-limit reporting, and known mediation-status reporting.
Host API reporting shall not be treated as approval.
Host API reporting shall not be treated as a capability grant.
Host API reporting shall not be treated as a complete list of everything the Host Platform can do.
Host API semantics shall not classify packages.

**Rationale:** Benac Core, agents, and packages need stable host semantics even when host transport differs by platform.

**Verification:** Host API conformance tests exercise CID creation/parsing/verification, DRISL encoding and decoding, package import/export, package validation, fixture execution, package inspection, trust/capability queries, invocation lifecycle, evidence/effect emission, schema ruleset reporting, calling-convention reporting, resource-limit reporting, and mediation-status reporting.

**Status:** draft

**Source record:** `records/req.benac-host-001/benac-host-001.md`

## Package host interface

### BENAC-HOST-002 - Package host interface mediation

**Statement:** Package operations shall interact with the host through mediated imports or equivalent mediated calls only.
Required package-host behavior shall include validated request retrieval, validated descriptor config retrieval, evidence emission, effect request, output return, log event, blob read for authorized exact blob CIDs, blob write through capability grant, HTTPS fetch through capability grant, secret or credential use through capability grant, authenticated external-service operation through capability grant, encryption/decryption requests through capability grant, storage operation requests through storage lease, compute operation requests through compute lease, mediated package invocation requests through the Host Station invocation path where authorized, clock where granted, random bytes where granted, authentication-context introspection where allowed, and capability introspection.
Package-visible request and descriptor config data shall come only from validated invocation input envelopes, validated descriptor snapshots, package-declared inputs, or mediated responses authorized for the relevant operation phase.
Packages shall not receive raw private keys, raw authentication credentials, unrestricted signing authority, unrestricted decryption authority, direct document- store access, host-local defaults, UI state, operational document metadata, debug fields, local indexes, sync state, local availability state, local verification state, or unvalidated convenience projections.

**Rationale:** Package execution must be mediated by Local Policy and capability grants rather than ambient authority. A package can use any input it observes, so package-visible input must be deliberately bounded.

**Verification:** Package-host conformance tests prove authorized mediated calls succeed through scoped grants and forbidden direct access to keys, credentials, signing, decryption, document-store APIs, host metadata, UI state, debug fields, and unvalidated projections fails closed or omits the data.

**Status:** draft

**Source record:** `records/req.benac-host-002/benac-host-002.md`

### BENAC-HOST-003 - Package-visible input boundary

**Statement:** Package operations shall receive only schema-defined invocation requests, descriptor/configuration data, package-declared inputs, and host-mediated capability responses that the Host Station explicitly supplies through the package host interface.
The package-visible request and descriptor config shall be the validated logical objects from the invocation input envelope and descriptor snapshot unless another schema-defined logical object is explicitly supplied through a granted mediated operation.
Packages shall not receive raw operational document envelopes, Couch/Pouch-managed metadata, host-local operational metadata, sync state, UI/cache/index state, local availability state, local verification state, debug fields, acceptance instrumentation fields, local defaults, or unvalidated convenience projections.
If such data is exposed to a package, it shall be exposed only through a schema- defined logical object or a host-mediated API response whose use is authorized, recorded, and subject to capability policy.

**Rationale:** A package can use any input it observes. Operational metadata must not become hidden package input unless deliberately exposed through schema and policy.

**Verification:** Conformance packages attempt to read `_id`, `_rev`, local availability state, sync state, UI state, verification state, debug fields, local defaults, and convenience projection fields through the package host interface. The Host Station denies access or omits the fields. If the same value is placed in descriptor configuration or invocation request data, the relevant descriptor or invocation record changes and validation applies.

**Status:** draft

**Source record:** `records/req.benac-host-003/benac-host-003.md`

## 11.4 Replication interface

### BENAC-REPL-001 - Replication interface CID verification

**Statement:** Benac shall support Couch/Pouch-compatible replication for eligible operational documents. Replicated structured documents that carry or reference structured document CIDs shall be verified by validating the logical payload, encoding it as DRISL, and recomputing the expected DASL CID. Blob replication may be handled through attachments, chunked documents, content-addressed blob transfer, package bundle export/import, a Benac CAS exchange profile, or another compatible mechanism, provided DASL CID identity, encryption, verification, availability, and missing-blob semantics are preserved. Replicated documents that carry authority shall not become active authority unless local policy accepts them.

**Rationale:** Replication moves operational documents and bytes, but it does not replace CID verification, signature verification, encryption policy, missing-blob handling, or local authority decisions.

**Verification:** Two-Station replication fixtures verify structured document CIDs after document replication, verify raw blob CIDs after blob transfer, preserve missing-blob semantics, and keep replicated authority inactive until local policy accepts it.

**Status:** draft

**Source record:** `records/req.benac-repl-001/benac-repl-001.md`

## 11.5 Storage interface

### BENAC-STOR-021 - Storage interface

**Statement:** Benac implementations that support remote storage shall provide interfaces for Storage Station offer import and inspection, Storage Station authentication, storage descriptor creation, storage lease creation, blob and chunk presence checking, retrieval, upload, pin, unpin, encrypted backup, location claim handling, storage receipt handling, authentication-context handling, and integrity failure reporting. Provider-specific storage APIs shall be package behavior or external service behavior, not Benac Core behavior.

**Rationale:** Remote storage support needs stable Benac semantics without putting provider-specific APIs in Benac Core.

**Verification:** Storage interface conformance tests exercise offer import, authentication, lease creation, blob retrieval by CID, encrypted backup, receipts, and integrity-failure reporting.

**Status:** draft

**Source record:** `records/req.benac-stor-021/benac-stor-021.md`

## 11.6 Compute interface

### BENAC-COMP-011 - Compute interface

**Statement:** Benac implementations that support remote compute shall provide interfaces for Compute Station offer import and inspection, Compute Station authentication, compute descriptor creation, compute lease request review, compute lease creation, data-staging coordination, remote invocation, remote evidence handling, replay protection, remote output validation, and plaintext disclosure recording. Provider-specific compute APIs shall be package behavior or external service behavior, not Benac Core behavior.

**Rationale:** Remote compute support needs stable Benac semantics without putting provider-specific compute protocols in Benac Core.

**Verification:** Compute interface conformance tests exercise offer import, authentication, lease creation, data staging, remote invocation, evidence handling, replay rejection, output validation, and disclosure recording.

**Status:** draft

**Source record:** `records/req.benac-comp-011/benac-comp-011.md`

## 11.7 Authentication interface

### BENAC-AUTH-016 - Authentication interface

**Statement:** Benac implementations shall provide interfaces for local user authentication, local user re-authentication for sensitive actions, Station-to-Station authentication, signed challenge handling, agent session authentication, authentication/session expiry and revocation, authenticated approval records, host-mediated external service authentication, credential-use effect recording, and authentication-context inspection. The exact mechanism may differ by Host Platform, but the semantic records and fail-closed behavior shall be interoperable.

**Rationale:** Authentication mechanisms vary by host, but Benac records and failure semantics must remain portable.

**Verification:** Authentication interface conformance tests exercise local authentication, re-authentication, Station-to-Station signed challenge handling, agent sessions, expiry/revocation, approval records, credential-use effects, and fail-closed behavior.

**Status:** draft

**Source record:** `records/req.benac-auth-016/benac-auth-016.md`

## 12. Minimum logical data objects

Benac implementations shall support at least the following logical document types. Implementations may use different physical schemas if they preserve the logical semantics and pass conformance tests.

| Object type | Purpose |
|---|---|
| principal | Cryptographic identity metadata for Stations, users, agents, authors, reviewers, Storage Stations, Compute Stations, Host Implementations, or organizations. |
| authenticator | Metadata for a host-supported user, agent, Station, or service authentication mechanism. |
| auth_session | Bounded authenticated context with scope, expiry, revocation state, and associated actor or principal. |
| auth_challenge | Challenge or nonce object used for Station-to-Station, storage, compute, replication, or lease-bound authentication. |
| authenticated_approval | Record of authenticated intent for trust, capability, storage, compute, decryption, disclosure, export, or high-risk operation approval. |
| authentication_event | Record of authentication success, failure, expiry, revocation, re-authentication, or credential-use context, redacted where required. |
| key_status | Local state for key acceptance, rotation, revocation, compromise, authentication association, or trust status. |
| signed_claim | Attributable claim about a package, descriptor, principal, test, authentication-relevant binding, storage offer, storage receipt, compute offer, compute result, name binding, package bundle, or other object. |
| name_binding | Local or signed association between a human-readable name and a CID or principal. |
| package | Package document and package-level metadata. |
| schema | JSON schema or other supported schema document. |
| artifact_ref | Reference to blob artifact, including DASL CID, size, media type, encryption metadata if applicable, and availability metadata. |
| blob_manifest | Structured blob or chunked blob manifest, including chunk CIDs and top-level content identity. |
| blob_availability | Local or remote availability state for a blob or chunk. |
| blob_location_claim | Claim that a Storage Station or Peer Station may have a blob or chunk identified by CID. |
| descriptor | Configured package instance. |
| trust_decision | Local trust scope for package, package interface, invocation contract, descriptor, principal, agent, storage, compute, or decryption. |
| capability_grant | Local capability permission scope. |
| invocation | One package operation attempt, including package, package interface, descriptor, invocation contract, request, output, evidence, and effect references by CID where applicable. |
| evidence | Data observed or produced by invocation or remote resource use. |
| effect | Action attempted or caused by invocation, storage, compute, encryption/decryption, or disclosure. |
| disclosure_record | Record that private data, plaintext, or decryption capability became available to a principal, authenticated session, package, Host Implementation, Storage Station acting as processor, or Compute Station. |
| secret_metadata | Local secret and credential reference metadata without raw secret material. |
| credential_binding | Local mapping from a descriptor/auth reference to protected credential material or host-mediated external authentication method. |
| encrypted_envelope | Metadata wrapper for encrypted private documents or blobs. |
| agent | Agent identity, scope, authority, or metadata. |
| trust_request | Agent or user request for trust/capability approval. |
| storage_offer | Available storage descriptor or offer. |
| storage_plan | Proposed storage use plan. |
| storage_lease | Approved bounded storage use. |
| storage_receipt | Evidence or claim about a storage operation, bound to relevant operation, blob, chunk, request, or manifest CIDs where applicable. |
| compute_offer | Available compute descriptor or offer. |
| compute_plan | Proposed compute use plan. |
| compute_lease | Approved bounded compute use. |
| sync_peer | Optional replication peer configuration. |
| audit_event | Security-, authentication-, or governance-relevant event not otherwise captured. |
| package_bundle_manifest | Describes an importable/exportable package bundle containing package document, schemas, artifacts, fixtures, claims, docs, reports, and integrity metadata. |
| package_validation_report | Structured result of package validation. |
| package_build_report | Structured result of package build, including derived CIDs and warnings. |
| fixture | Structured package test vector. |
| fixture_result | Structured result of fixture execution. |
| request_snapshot | Domain-separated logical request wrapper used for request CIDs. |
| output_snapshot | Domain-separated logical output wrapper used for output CIDs. |
| package_inspection_result | Machine-readable package inspection object. |
| package_approval | Local Policy approval record binding a package CID, invocation contract snapshot, descriptor scope, interface, allowed data classes, granted capability identifiers, and supporting evidence. |
| diagnostic_record | Structured machine-readable diagnostic record for validation, build, fixture, invocation, capability, resource, package-host, storage, compute, encryption, and execution failures, containing a stable diagnostic classification code, required context bindings, origin-specific details where available, and raw diagnostic evidence inline or by CID/encrypted reference where practical and safe. |
| schema_ruleset | Machine-readable description or identifier for schema validation behavior supported by Benac. |
| wasm_package_host_calling_convention | Machine-readable description or identifier for how a WASM package exchanges input, output, memory, imports, exports, and errors with the Host Implementation. |
| resource_limit_report | Record of resource limits applied, exceeded, or relied upon during validation, fixture execution, or invocation. |

### BENAC-DATA-001 - Minimum logical data object CID fields

**Statement:** Benac shall define minimum logical data object schemas using CID terminology where exact content identity is required. The name_binding object shall associate a human-readable name with a CID or principal. The artifact_ref object shall reference a blob artifact with DASL CID, size, media type, encryption metadata if applicable, and availability metadata. The blob_manifest object shall describe structured or chunked blobs, including chunk CIDs and top-level content identity. The blob_location_claim object shall claim that a Storage Station or Peer Station may have a blob or chunk identified by CID. The invocation object shall record one package operation attempt, including package, descriptor, selected package interface, request, output, evidence, effect references, parent invocation references, and child invocation references by CID where applicable. The storage_lease_request object shall describe a requested storage authorization scope and shall not itself authorize storage effects. The compute_lease_request object shall describe a requested compute authorization scope and shall not itself authorize compute effects, data egress, storage staging, decryption, or plaintext disclosure. Causal reference fields shall link related records, actors, sessions, invocations, requests, approvals, evidence, effects, diagnostics, package drafts, package CIDs, invocation contract snapshot CIDs, descriptor snapshot CIDs, build reports, validation reports, and fixture results where applicable without granting authority. Mediated child invocation requests shall identify target package/interface/descriptor context, initiating package, parent invocation, requested data class, and granted scope where applicable. The storage_receipt object shall bind storage-operation evidence or claims to relevant operation, blob, chunk, request, or manifest CIDs where applicable.

**Rationale:** The logical data model must use the same CID vocabulary as the requirements so implementers do not fall back to ambiguous bare hashes.

**Verification:** Schema and conformance fixtures reject portable logical object records that use bare digest identity where these object definitions require CIDs.

**Status:** draft

**Source record:** `records/req.benac-data-001/benac-data-001.md`

## Logical data objects

### BENAC-DATA-002 - Package authoring logical objects

**Statement:** Benac shall define minimum logical schemas for Package Bundle Manifests, package import records, package import failure records, package validation reports, package build reports, fixtures, fixture results, request snapshots, output snapshots, invocation contract snapshots, package inspection results, package approval records, diagnostic records, schema ruleset identifiers, WASM package-host calling convention identifiers, resource limit reports, storage lease requests, compute lease requests, causal references, parent/child invocation references where relevant, and mediated child invocation requests where relevant.
These objects shall use CIDs where exact content identity is required and DRISL encoding where structured content identity is required.
These objects shall not define package classes.
These objects shall not define classes for how package work is performed.

**Rationale:** Authoring, validation, approval, invocation, and audit need common logical object shapes across implementations.

**Verification:** Logical object schema tests verify required fields, CID fields, DRISL identity, and rejection of retired package-class and work-class fields.

**Status:** draft

**Source record:** `records/req.benac-data-002/benac-data-002.md`
