resolved 2ccf0f34-e965-4b8d-b062-57a565db27df
Replace the current package model language with this model:
A package declares interfaces.
Each package interface defines how the Station talks to the package and how the package talks back.
Each package interface binds request schema, descriptor config schema where relevant, output schema where relevant, declared capabilities, artifacts, resources, evidence behavior, and effect behavior.
Local Policy decides what may be attempted or used.
The Station mediates allowed operations.
The Station records what is known, unknown, unavailable, denied, attempted, failed, or completed.
Do not use these phrases in edited package, capability, trust, approval, authoring, execution, inspection, host, conformance, or invocation requirements:
implementation kind
implementation_kind
implementation entry
implementation_entry
implementation selection
implementation identity
implementation CID
supported implementation kind
unsupported implementation kind
allowed implementation
supported execution type
execution type
portable package profile
local public-data package approval
local public-data portable package
local package capability vocabulary
extension profile
baseline portable package
compatibility claim
compatibility_claims
unsupported required behavior marker
unsupported_required_behavior_markers
declarative implementation
WASM implementation
native implementation
portable implementation
Do not replace those with another package class or implementation class.
Use these instead:
package interface
request schema
descriptor config schema
output schema
interface contract
invocation contract
invocation contract snapshot
selected package interface
capabilities declared by the package
capabilities granted by Local Policy
artifacts required by the package
resources required by the package
evidence behavior
effect behavior
Station status
operation status
operation not currently mediated by this Station
not yet determined
grant missing
denied by policy
artifact unavailable
resource unavailable
attempt denied
attempt failed
attempt completed
BENAC-PKG-002 currently says the package document declares implementations, implementation entry identifiers, implementation kinds, and WASM package-host calling convention identifiers. It also frames the kernel as inspecting “implementations” before trust or execution .
---
typeId: req
recordId: benac-pkg-002
fields:
title: 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 class, execution class, or implementation class.
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.
testable: true
status: draft
area: BENAC-PKG
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package model, descriptors, and package claims
order: 76
---
BENAC-PKG-003 currently defines a versioned “manifest schema for baseline packages” and includes implementation kinds and unsupported required behavior markers .
---
typeId: req
recordId: benac-pkg-003
fields:
title: 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 declare a
package compatibility claim.
The package document schema shall not include a field whose purpose is to mark
unsupported behavior by class.
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.
testable: true
status: draft
area: BENAC-PKG
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package model, descriptors, and package claims
order: 77
---
Current wording says package names are non-authoritative and invocation records shall use package CIDs and implementation CIDs.
---
typeId: req
recordId: benac-pkg-004
fields:
title: 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.
testable: true
status: draft
area: BENAC-PKG
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package model, descriptors, and package claims
order: 78
---
BENAC-PKG-005 currently says package interfaces identify allowed implementations and supported execution type .
---
typeId: req
recordId: benac-pkg-005
fields:
title: 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.
testable: true
status: draft
area: BENAC-PKG
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package model, descriptors, and package claims
order: 79
---
Current BENAC-PKG-006 is a package class: “Portable package profile” .
---
typeId: req
recordId: benac-pkg-006
fields:
title: 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.
testable: true
status: draft
area: BENAC-PKG
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package model, descriptors, and package claims
order: 80
---
Current and prior versions tied required fixtures to local-public-data portable compatibility claims .
---
typeId: req
recordId: benac-pkg-007
fields:
title: 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.
testable: true
status: draft
area: BENAC-PKG
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package model, descriptors, and package claims
order: 81
---
BENAC-PKG-009 is currently “Implementation identity” and requires an implementation snapshot including implementation entry identifier and implementation kind .
---
typeId: req
recordId: benac-pkg-009
fields:
title: 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 an implementation class.
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.
area: BENAC-PKG
sourceSections:
- Package model, descriptors, and package claims
order: 82.5
testable: true
status: draft
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
---
Current interface contract binding refers to allowed implementation entries and supported execution type.
---
typeId: req
recordId: benac-pkg-010
fields:
title: 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.
testable: true
status: draft
area: BENAC-PKG
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package model, descriptors, and package claims
order: 87.01
---
Current title is Baseline package schema ruleset.
---
typeId: req
recordId: benac-schema-001
fields:
title: 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.
testable: true
status: draft
area: BENAC-SCHEMA
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package authoring
order: 84
---
Current package validation is tied to implementation entries, local-public-data compatibility, and unsupported behavior markers in previous requirement language .
---
typeId: req
recordId: benac-author-001
fields:
title: 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.
testable: true
status: draft
area: BENAC-AUTHOR
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package authoring
order: 87.09
---
Current build/report language still had local-public-data compatibility and implementation snapshots.
---
typeId: req
recordId: benac-author-002
fields:
title: 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.
testable: true
status: draft
area: BENAC-AUTHOR
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package authoring
order: 87.1
---
Current reports mention implementation status and local-public-data compatibility status.
---
typeId: req
recordId: benac-author-003
fields:
title: 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.
testable: true
status: draft
area: BENAC-AUTHOR
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package authoring
order: 87.11
---
Current trust scope terminology can still bind “implementation CIDs.”
---
typeId: req
recordId: benac-trust-002
fields:
title: 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.
testable: true
status: draft
area: BENAC-TRUST
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Trust, policy, and capability model
order: 89
---
Current trust-decision scope language refers to implementation selection and implementation requirements.
---
typeId: req
recordId: benac-trust-003
fields:
title: 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.
testable: true
status: draft
area: BENAC-TRUST
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Trust, policy, and capability model
order: 89.5
---
Current BENAC-TRUST-006 is “Local public-data package approval” in the SyRS index .
---
typeId: req
recordId: benac-trust-006
fields:
title: 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.
testable: true
status: draft
area: BENAC-TRUST
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package approval and capability grants
order: 87.07
---
Current capability declaration language is partly okay, but it is still entangled with selected implementation wording in adjacent requirements.
---
typeId: req
recordId: benac-cap-001
fields:
title: 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.
testable: true
status: draft
area: BENAC-CAP
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Trust, policy, and capability model
order: 90
---
---
typeId: req
recordId: benac-cap-002
fields:
title: 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.
testable: true
status: draft
area: BENAC-CAP
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Trust, policy, and capability model
order: 91
---
---
typeId: req
recordId: benac-cap-003
fields:
title: 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.
testable: true
status: draft
area: BENAC-CAP
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Trust, policy, and capability model
order: 92
---
Current BENAC-CAP-007 is a local package capability vocabulary and previously rejected capabilities outside a package-specific path .
---
typeId: req
recordId: benac-cap-007
fields:
title: 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.
testable: true
status: draft
area: BENAC-CAP
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Trust, policy, and capability model
order: 87.08
---
Invocation records likely identify selected implementation.
---
typeId: req
recordId: benac-inv-001
fields:
title: 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.
testable: true
status: draft
area: BENAC-INV
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Invocation, evidence, effects, audit, and tamper-evidence
order: 105
---
Invocation fields likely include selected implementation identity.
---
typeId: req
recordId: benac-inv-002
fields:
title: 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.
testable: true
status: draft
area: BENAC-INV
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Invocation, evidence, effects, audit, and tamper-evidence
order: 106
---
Current no-silent-fallback text references implementations and implementation fallback.
---
typeId: req
recordId: benac-inv-005
fields:
title: 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.
testable: true
status: draft
area: BENAC-INV
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Invocation, evidence, effects, audit, and tamper-evidence
order: 109
---
Current envelope includes requested implementation and execution type.
---
typeId: req
recordId: benac-inv-007
fields:
title: 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.
testable: true
status: draft
area: BENAC-INV
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package authoring
order: 87.17
---
Current request/output snapshots mention package, interface, implementation, and schema context.
---
typeId: req
recordId: benac-inv-008
fields:
title: 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.
testable: true
status: draft
area: BENAC-INV
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package authoring
order: 87.18
---
Current title is Declarative execution baseline .
---
typeId: req
recordId: benac-exec-001
fields:
title: 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.
testable: true
status: draft
area: BENAC-EXEC
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Execution model and package host interface
order: 98
---
Current title is WASM execution baseline .
---
typeId: req
recordId: benac-exec-002
fields:
title: 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.
testable: true
status: draft
area: BENAC-EXEC
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Execution model and package host interface
order: 99
---
Current title is Native/container execution optional .
---
typeId: req
recordId: benac-exec-005
fields:
title: 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.
testable: true
status: draft
area: BENAC-EXEC
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Execution model and package host interface
order: 102
---
Current title is Implementation selection record.
---
typeId: req
recordId: benac-exec-006
fields:
title: 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.
testable: true
status: draft
area: BENAC-EXEC
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Execution model and package host interface
order: 103
---
---
typeId: req
recordId: benac-exec-007
fields:
title: 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.
testable: true
status: draft
area: BENAC-EXEC
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Execution model and package host interface
order: 104
---
Current BENAC-EXEC-008 is implementation-selection input and talks about requested unsupported implementation .
---
typeId: req
recordId: benac-exec-008
fields:
title: 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.
testable: true
status: draft
area: BENAC-EXEC
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package authoring
order: 87.2
---
Current title is Baseline local WASM package-host calling convention .
---
typeId: req
recordId: benac-wasm-001
fields:
title: 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.
testable: true
status: draft
area: BENAC-WASM
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package authoring
order: 87.16
---
Current local pure-transform WASM restrictions can read like a package class.
---
typeId: req
recordId: benac-wasm-002
fields:
title: 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.
testable: true
status: draft
area: BENAC-WASM
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package authoring
order: 87.17
---
Current resource-limit requirement references package class language in places.
---
typeId: req
recordId: benac-wasm-004
fields:
title: 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.
testable: true
status: draft
area: BENAC-WASM
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package authoring
order: 87.19
---
Current title is Host API baseline semantics, and prior text includes execution type reporting.
---
typeId: req
recordId: benac-host-001
fields:
title: 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.
area: BENAC-HOST
sourceSections:
- Host API
order: 192
testable: true
status: draft
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
---
---
typeId: req
recordId: benac-host-002
fields:
title: 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.
area: BENAC-HOST
sourceSections:
- Package host interface
order: 192.1
testable: true
status: draft
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
---
---
typeId: req
recordId: benac-host-003
fields:
title: 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.
area: BENAC-HOST
sourceSections:
- Package host interface
order: 192.2
testable: true
status: draft
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
---
Station Profile currently publishes supported implementation kinds and local-public-data approval support in the prior ticket language .
---
typeId: req
recordId: benac-sys-004
fields:
title: 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, implementation
artifact or 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, execution 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, storage space, memory, network access, compute access, authentication
credentials, platform permissions, user permissions, 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.
testable: true
status: draft
area: BENAC-SYS
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Host neutrality and platform coverage
order: 34
---
Current inspection language references implementation kinds and local-public-data approval.
---
typeId: req
recordId: benac-ux-001
fields:
title: 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.
testable: true
status: draft
area: BENAC-UX
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- User inspectability and operation
order: 175
---
Current inspection data contract includes implementation kinds and local-public-data compatibility.
---
typeId: req
recordId: benac-ux-008
fields:
title: 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.
testable: true
status: draft
area: BENAC-UX
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package authoring
order: 87.21
---
Current title is Inspection before local public-data approval .
---
typeId: req
recordId: benac-ux-009
fields:
title: 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 implementation
state or package class.
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.
testable: true
status: draft
area: BENAC-UX
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package authoring
order: 87.22
---
---
typeId: req
recordId: benac-test-002
fields:
title: 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.
testable: true
status: draft
area: BENAC-TEST
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package authoring
order: 87.14
---
Fixture result records include execution type / selected implementation language.
---
typeId: req
recordId: benac-test-003
fields:
title: 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.
testable: true
status: draft
area: BENAC-TEST
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Package authoring
order: 87.15
---
Current stable diagnostics include implementation unsupported-kind style diagnostics and old approval diagnostics.
---
typeId: req
recordId: benac-int-003
fields:
title: 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.
testable: true
status: draft
area: BENAC-INT
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Interoperability and conformance
order: 169
---
Current conformance suite includes implementation selection and package-class records.
---
typeId: req
recordId: benac-int-004
fields:
title: 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.
testable: true
status: draft
area: BENAC-INT
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Interoperability and conformance
order: 170
---
Current title is Same portable package behavior.
---
typeId: req
recordId: benac-int-005
fields:
title: 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.
testable: true
status: draft
area: BENAC-INT
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Interoperability and conformance
order: 171
---
Current BENAC-INT-006 is Extension profiles .
Delete this requirement, or replace it with this:
---
typeId: req
recordId: benac-int-006
fields:
title: Conformance for published Station behavior
statement: >-
When a Station publishes known behavior, known mediated operation paths, known
capability identifiers, known storage behavior, known compute behavior, known device
behavior, known authentication behavior, known encryption behavior, or known
package-visible host behavior, Benac shall define conformance tests for the
published behavior.
A Station shall not claim published behavior unless it passes the conformance tests
for that behavior.
Conformance tests for published Station behavior shall not define package classes.
Conformance tests for published Station behavior shall not define classes for how
package work is performed.
A package shall declare what it requires.
Local Policy shall decide what can be attempted or used.
The Station shall mediate allowed operations.
The Station shall record what is known, unknown, unavailable, denied, attempted,
failed, or completed.
rationale: >-
Published Station behavior should be testable without making package classes.
verification: >-
A Station claiming a mediated operation path passes the conformance vectors for that
path. A Station that cannot mediate an operation records that fact without changing
package content validity.
testable: true
status: draft
area: BENAC-INT
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Interoperability and conformance
order: 172
---
My preference: delete it unless you want this “published Station behavior” rule.
Compute offers currently refer to supported implementation kinds in terminology and adjacent requirements .
---
typeId: req
recordId: benac-comp-001
fields:
title: 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.
testable: true
status: draft
area: BENAC-COMP
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Compute discovery and remote compute
order: 138
---
Current logical objects include local-public-data approval and implementation-related logical objects.
---
typeId: req
recordId: benac-data-002
fields:
title: 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.
testable: true
status: draft
area: BENAC-DATA
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Logical data objects
order: 203
---
Agent package APIs likely expose implementation/package-class language.
---
typeId: req
recordId: benac-agt-001
fields:
title: 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.
testable: true
status: draft
area: BENAC-AGT
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Agent API
order: 185
---
Agent authoring can inherit implementation/package-class language.
---
typeId: req
recordId: benac-agt-003
fields:
title: 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 implementation taxonomies.
verification: >-
Agent-authored package fixtures validate across conforming implementations and do
not contain retired package-class or work-class fields.
testable: true
status: draft
area: BENAC-AGT
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Agent API
order: 187
---
Current export language can still classify package behavior.
---
typeId: req
recordId: benac-io-003
fields:
title: 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.
testable: true
status: draft
area: BENAC-IO
sourceDocument: user-requested schema-first requirements cleanup
sourceVersion: 2026-05-06
sourceSections:
- Import, export, and decentralized distribution
order: 181
---
After editing source records and regenerating SyRS/glossary, run:
npm run build:glossary
npm run build:syrs
npm test
Then run this grep over active requirement records and generated SyRS:
rg -n -i \
'local public-data|local-public-data|portable package profile|baseline portable|extension profile|compatibility claim|compatibility_claim|unsupported required behavior|unsupported_required_behavior|implementation kind|implementation_kind|implementation entry|implementation_entry|implementation selection|implementation identity|implementation CID|allowed implementation|supported execution type|execution type|declarative implementation|WASM implementation|native implementation|portable implementation|optional privileged capability' \
records/req.* docs/01-Requirements/System-Requirements-Specification.md
Expected result:
No active package / approval / capability / execution / inspection / authoring / conformance hits.
Cryptographic uses of “baseline” or “profile” outside this package-class cleanup can remain for this pass.
After these replacements, the requirements stop saying:
The package has implementations.
The package has implementation kinds.
The Station supports implementation kinds.
The package is portable or non-portable.
The package fits a profile or extension.
They say:
The package has interfaces.
The interface defines schemas.
The schemas define how to talk to the package and how it talks back.
The interface declares capabilities, artifacts, resources, evidence, and effects.
Local Policy decides what can be attempted or used.
The Station mediates allowed operations.
The Station records what happened.
That is the schema-first kernel model.
Final terminology sealing pass completed.
Scope:
Commits:
Verification:
Phase 1 complete: fetched ticket context and confirmed scope. Work will be requirements-only: requirement records and generated requirements/glossary outputs as needed. No business logic changes.
Implemented the requirements-only cleanup requested by the ticket.
Scope:
No business logic changed: git diff --name-only -- apps crates returns no paths.
Verification:
Existing unrelated dirty static/deploy artifacts were left alone.
Caller rejected:
status: return_to_in_progress
scope: requirements + terms/definitions only
parent_ticket: f36310a4-7726-4376-850a-1497bd79eced
Do not move back to business logic yet.
The requirements work is directionally right, but the generated terms and several requirement records still preserve the old model. The current generated Terms still define Package Interface using “allowed implementations” and “execution type,” and still define Declarative Implementation, WASM Implementation, Native Implementation, Portable Implementation, and Implementation Selection as package-facing concepts . The current terms also still say Output identity includes “implementation,” and Implementation Selection chooses among package implementations . Other generated terms still include implementation CIDs, expected selected implementation, allowed implementation sets, execution type, and Host support for implementation kinds in build reports, fixtures, fixture results, and package inspection results .
That is not the schema-first kernel model.
The model for this phase is:
A package declares interfaces.
Each interface defines how the Station talks to the package and how the package talks back.
Each interface binds schemas, capabilities, artifacts, resources, evidence behavior, and effect behavior.
Local Policy decides what may be attempted or used.
The Station mediates allowed operations.
The Station records what is known, unknown, unavailable, denied, attempted, failed, or completed.
Do not edit business logic in this phase.
Do not update Rust, PWA, CLI, fixtures, conformance code, or generated package bundles.
Do not add WebGPU, local model, local compute, retrieval, device, or provider-specific requirements.
Do not introduce a new package category to replace the retired categories.
Do not replace “implementation kind” with “method,” “runner,” “execution type,” “profile,” “class,” “lane,” or another package-work taxonomy.
Do not remove Host Implementation as a term. That phrase is still correct when referring to the software host that runs Benac. The forbidden usage is package-facing “implementation” language.
Use these words for package-facing requirements:
package
package document
package interface
request schema
descriptor config schema
output schema
interface contract
invocation contract
invocation contract snapshot
package artifact
declared capability
capability grant
resource requirement
evidence behavior
effect behavior
operation status
Station status
not currently mediated by this Station
not yet determined
grant missing
denied by policy
artifact unavailable
resource unavailable
attempt denied
attempt failed
attempt completed
Do not use these in active package-facing requirements or definitions:
implementation kind
implementation_kind
implementation entry
implementation_entry
implementation identity
implementation CID
implementation selection
selected implementation
skipped implementation
allowed implementation
supported implementation kind
unsupported implementation kind
supported execution type
execution type
package class
package profile
portable package profile
local public-data package approval
local public-data portable package
local package capability vocabulary
extension profile
compatibility claim
unsupported required behavior marker
Declarative Implementation
WASM Implementation
Native Implementation
Portable Implementation
The only acceptable package-facing WASM phrase is:
WASM package-host calling convention
The only acceptable package-facing structured-behavior phrase is:
schema-defined package behavior
Those are mechanism contracts, not package classes.
Edit records/term.*/*.md. Do not edit generated glossary directly. Rebuild with:
npm run build:glossary
term.package-interfaceReplace the current definition. It still says package interfaces identify “allowed implementations” and “execution type” .
Use this definition:
A declared surface through which a package can be used. A package interface identifies how the Station talks to the package and how the package talks back, including request schema, descriptor config schema where applicable, output schema where applicable, declared capabilities, artifact requirements, resource requirements, evidence behavior, and effect behavior.
Usage:
Interfaces describe the package’s schema-bound conversation contract. Interfaces do not grant authority. Interfaces do not classify the package or how package work is performed.
term.declarative-implementationDelete the term record:
records/term.declarative-implementation/
Do not replace it with another implementation term.
Create or rewrite this term instead only if it does not already exist:
records/term.schema-defined-package-behavior/
Definition:
Package behavior represented as structured data interpreted by the Station according to defined schemas and semantics.
Usage:
Schema-defined package behavior is a mechanism contract. It does not grant authority, classify packages, or classify how package work is performed.
term.wasm-implementationDelete the term record:
records/term.wasm-implementation/
Do not preserve WASM Implementation as a package-facing term.
Create or rewrite:
records/term.wasm-package-host-calling-convention/
Definition:
A versioned contract for how a Station mediates a package operation that uses a WASM artifact, including module format, allowed imports, forbidden imports, required exports, memory behavior, input encoding, output encoding, error behavior, resource behavior, evidence behavior, and effect behavior.
Usage:
The WASM package-host calling convention is a mechanism contract. It does not grant authority, classify packages, or classify how package work is performed.
If the term already exists, remove any wording that says “WASM package implementation.”
term.native-implementationDelete:
records/term.native-implementation/
Do not replace it with Native Package, Native Implementation, Native Profile, or any similar package class.
Where the concept is needed in requirements, use plain language:
host-native operation attempt
That phrase does not need a term record unless a later requirements pass truly needs one.
term.portable-implementationDelete:
records/term.portable-implementation/
Do not replace it. “Portable implementation” is package-ranking language. The system should test concrete package behavior and records, not classify packages as portable.
term.implementation-selectionDelete:
records/term.implementation-selection/
Do not replace it with method selection, runner selection, or another package-work taxonomy.
Use existing No Silent Fallback plus invocation-contract language instead.
term.outputCurrent Output usage says identity should include package, interface, implementation, and schema context .
Replace usage with:
Output is not a substitute for raw evidence. Where output is content-addressed, its identity should include package CID, package interface, invocation contract snapshot, output schema, and output body through an output snapshot.
term.trust-scopeCurrent Trust Scope still mentions implementation CIDs .
Replace definition with:
The limits of a trust decision, such as allowed package CIDs, package interfaces, invocation contract snapshots, capabilities, descriptors, endpoints, data classes, time limits, or invocation counts.
Usage:
Broad unscoped trust should be avoided. Trust scope does not grant capabilities outside the recorded scope.
term.capability-denialCurrent usage mentions implementation selection .
Replace usage with:
Denials should be recorded where relevant to inspection, approval, invocation, effect audit, retrieval, storage, compute, and operation-status records.
term.no-silent-fallbackCurrent definition says Benac shall not quietly switch packages, implementations, storage sources, compute stations, trust scopes, or security behavior .
Replace with:
The rule that Benac shall not quietly switch packages, package interfaces, descriptor scopes, invocation contracts, storage sources, compute stations, trust scopes, capability scopes, data classes, schemas, or security behavior without explicit policy and recorded trace.
Usage:
Blocked alternatives, fallback authority, and fallback reasons should be recorded.
term.fixtureCurrent Fixture still includes expected selected implementation or allowed implementation set and says fixtures test implementation selection .
Replace definition with:
A structured package test vector that defines package-under-test reference, package interface, descriptor config or descriptor snapshot where applicable, request data, expected validation result, expected output where deterministic, expected evidence behavior, expected effect behavior, expected denied effects where applicable, expected operation status, and expected diagnostic classification codes and diagnostic evidence behavior where failure is intended.
Usage:
Fixtures test package behavior, schema validation, capability mediation, trace shape, evidence behavior, effect behavior, operation status, and expected failures.
term.fixture-resultCurrent Fixture Result still includes implementation CID and execution type .
Replace definition with:
A structured record describing the result of fixture execution, including fixture identifier, package CID, package interface, descriptor snapshot CID where applicable, invocation contract snapshot CID where applicable, request snapshot CID, output snapshot CID where applicable, validation results, evidence/effect references, pass/fail status, diagnostic records, stable diagnostic classification codes, diagnostic evidence handling, Station Profile reference, operation status, and timestamps.
Usage:
Fixture results are evidence for local approval, package review, agents, and conformance testing.
term.package-inspection-resultCurrent Package Inspection Result still includes implementations, implementation CIDs, Host support for implementation kinds, and implementation-related compatibility facts .
Replace definition with:
A machine-readable object describing an inspected package, including package CID, package document version, package metadata, package interfaces, request/config/output schema references, schema validation status, invocation contract snapshots where derivable, artifact references, artifact availability, declared capabilities, capability grant status where known, resource requirements, fixtures, claims, warnings, missing artifacts, operation status by phase, diagnostic records or diagnostic record references, stable diagnostic classification codes, and raw diagnostic evidence references where practical and safe.
Usage:
Inspection results support human review, agent review, package approval, and cross-implementation comparison. Inspection results distinguish package content validity from operation eligibility.
term.package-build-reportCurrent Package Build Report includes implementation CIDs and baseline-failure language .
Replace definition with:
A machine-readable report describing the result of building a Package Bundle from an authoring workspace, including package CID, schema CIDs, artifact CIDs, invocation contract snapshot CIDs where derivable, included schemas, included fixtures, warnings, errors, diagnostic records, stable diagnostic classification codes, and raw diagnostic evidence references where practical and safe.
Usage:
Build reports help independent tools prove they produced the same package identity and schema-bound invocation contracts from the same logical package inputs.
term.package-validation-reportRemove implementation validation, compatibility checks, and class language.
Definition:
A machine-readable report describing the result of package validation, including package document schema status, schema reference resolution, 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 status, warnings, errors, diagnostic records, stable diagnostic classification codes, and raw diagnostic evidence references where practical and safe.
Usage:
Validation reports are evidence for authors, agents, reviewers, and Local Policy. Unsigned local reports are not authority outside Local Policy.
term.conformance-packageCurrent Conformance Package says it covers declarative execution, WASM execution, and implementation selection .
Replace usage with:
Conformance packages should cover package document validation, Package Bundle import, package inspection, fixture execution, generic request/config invocation, schema-defined package behavior, WASM package-host calling convention behavior, capability denial, evidence/effects, resource limits, no silent fallback, encryption, storage, and compute behavior as applicable.
term.package-bundleCurrent Package Bundle usage still mentions validating a local public-data portable package compatibility claim .
Replace that usage with:
Bundle-carried fixtures may be required for evaluating package validation, inspection, approval, fixture execution, or invocation in a Package Bundle context without changing the package CID.
Also ensure the definition says:
A Package Bundle used as a package import artifact shall be represented as a Package Bundle ZIP file containing `bundle/package_bundle_manifest.json`.
term.platform-compatibilityCurrent Platform Compatibility is framed around whether an implementation artifact can run on a Host Platform .
Replace with:
The condition that a requested package operation appears compatible with known Station facts, such as available mediation paths, artifacts, resources, platform permissions, and capability grants.
Usage:
Compatibility is not authority. Compatibility can be known, unknown, not yet determined, unavailable, denied, or observed after an allowed attempt.
term.hello-world-packageDo not describe it as “portable.”
Definition:
A minimal package used to demonstrate and test that independent Benac implementations can import, verify, inspect, approve, invoke, and audit the same package.
Usage:
The hello-world package should have minimal capabilities and no provider-specific behavior.
Edit records/req.*/*.md. Do not edit generated SyRS directly. Rebuild with:
npm run build:syrs
npm test
The current generated SyRS has moved many core records in the right direction, but old titles and old package-facing concepts still appear in generated indexes and sections, including Implementation identity, Baseline package schema ruleset, Baseline local WASM package-host calling convention, Implementation selection input, and old package-class titles in older attached/current variants . The handler shall treat any of those as blockers if present after regeneration.
Ensure these records exactly follow the schema-first shape already drafted:
records/req.benac-pkg-002/
records/req.benac-pkg-003/
records/req.benac-pkg-004/
records/req.benac-pkg-005/
records/req.benac-pkg-006/
records/req.benac-pkg-007/
records/req.benac-pkg-009/
records/req.benac-pkg-010/
Required outcomes:
BENAC-PKG-003 title: Package document schema
BENAC-PKG-009 title: Invocation contract identity
Remove from all statements/rationales/verifications:
manifest schema for baseline packages
implementations
implementation entry identifiers
implementation kinds
WASM package-host calling convention identifiers where applicable as package document classification fields
unsupported required behavior markers
allowed implementation entries
supported execution type
implementation CID
implementation snapshot
declarative implementation package
WASM implementation package
Use:
package interfaces
request schema
descriptor config schema
output schema
interface contract binding
invocation contract snapshot
artifact references
declared capabilities
resource requirements
evidence behavior
effect behavior
operation phase
operation status
Edit:
records/req.benac-author-001/
records/req.benac-author-002/
records/req.benac-author-003/
records/req.benac-author-004/
Required outcomes:
Validation distinguishes package content validity from Local Policy, artifact availability, resource availability, and Station ability to mediate an operation.
Build reports include invocation contract snapshot CIDs where derivable, not implementation CIDs.
Validation/build reports do not include package-class status.
Validation/build reports do not include implementation-class status.
Authoring APIs create package interfaces, schemas, artifacts, declared capabilities, resource requirements, evidence behavior, and effect behavior.
Remove:
implementation validation
implementation status
implementation snapshot derivation
implementation CIDs
local public-data compatibility
compatibility claims
baseline failures
unsupported required behavior
Replace with:
interface contract binding
invocation contract snapshot status
operation-phase requirements
stable diagnostic classification codes
Edit:
records/req.benac-schema-001/
records/req.benac-schema-002/
records/req.benac-schema-003/
Required outcome:
BENAC-SCHEMA-001 title: Required package schema ruleset
Remove:
Baseline package schema ruleset
baseline package
implementation classes
package classes
Keep cryptographic baseline wording elsewhere. This patch is about package schema records.
Edit:
records/req.benac-trust-002/
records/req.benac-trust-003/
records/req.benac-trust-006/
records/req.benac-cap-001/
records/req.benac-cap-002/
records/req.benac-cap-003/
records/req.benac-cap-007/
Required outcomes:
Trust scope binds package CID, package interface, descriptor scope, invocation contract snapshot where relevant, data class, granted capabilities, issuer, expiry/revocation, and evidence.
Package approval binds package CID, selected package interface, descriptor scope, invocation contract snapshot where relevant, granted capabilities, denied capabilities, data classes, inspection result, validation report, fixture results where relied upon, warnings, and evidence.
Capability grants bind package CID, package interface, descriptor scope where relevant, invocation contract snapshot where relevant, operation phase, capability identifier, scope, issuer, authentication context where relevant, expiry/revocation, and evidence.
Remove:
implementation CID
implementation identity
implementation kind
selected implementation
local public-data package approval
local public-data approval
local package capability vocabulary
Edit:
records/req.benac-inv-001/
records/req.benac-inv-002/
records/req.benac-inv-005/
records/req.benac-inv-007/
records/req.benac-inv-008/
records/req.benac-inv-009/
Required outcomes:
Invocation identifies package CID, package interface, descriptor scope, request snapshot, output snapshot where relevant, invocation contract snapshot where relevant, capability grants, artifacts, resources, evidence, effects, diagnostics, operation status, timestamps, Station principal, and caller/authentication context where relevant.
No silent fallback applies to package interface, descriptor scope, invocation contract, schemas, trust scope, capability scope, data class, storage source, compute source, privacy/security behavior, and output contract.
Invocation input envelope does not classify packages or package work.
Remove:
requested implementation
selected implementation
skipped implementation
implementation CID
execution type
implementation selection
Edit:
records/req.benac-exec-001/
records/req.benac-exec-002/
records/req.benac-exec-003/
records/req.benac-exec-004/
records/req.benac-exec-005/
records/req.benac-exec-006/
records/req.benac-exec-007/
records/req.benac-exec-008/
records/req.benac-wasm-001/
records/req.benac-wasm-002/
records/req.benac-wasm-003/
records/req.benac-wasm-004/
Required title outcomes:
BENAC-EXEC-001 - Schema-defined package behavior
BENAC-EXEC-002 - WASM package-host calling convention
BENAC-EXEC-005 - Host-native operation attempts
BENAC-EXEC-006 - Invocation contract record
BENAC-EXEC-008 - Interface invocation input
BENAC-WASM-001 - WASM package-host calling convention
BENAC-WASM-002 - WASM mediated access restrictions
BENAC-WASM-003 - WASM package-host calling convention template
Required semantics:
Schema-defined package behavior is a mechanism contract.
WASM package-host calling convention is a mechanism contract.
Host-native operation attempts are mediated operations.
None of these classify packages.
None of these classify how package work is performed.
None of these grant authority.
Remove all of:
Declarative execution baseline
WASM execution baseline
Native/container execution optional
baseline local WASM package-host calling convention
local pure-transform WASM
portable package implementations
WASM implementation
declarative implementation
baseline local public-data profile
package/interface/implementation context
implementation snapshot fields
implementation selection input
Replace with:
schema-defined package behavior
WASM package-host calling convention
package interface
invocation contract snapshot
package/interface/contract context
operation status
Station can mediate the attempt
Local Policy grants required capabilities
Edit:
records/req.benac-test-001/
records/req.benac-test-002/
records/req.benac-test-003/
Required outcomes:
Fixtures identify package CID, package interface, descriptor scope where relevant, request data, expected validation result, expected output, expected evidence behavior, expected effect behavior, expected denied effects, expected operation status, expected diagnostics, and raw diagnostic evidence behavior.
Fixture results identify package CID, package interface, descriptor scope where relevant, invocation contract snapshot where relevant, request snapshot, output snapshot where relevant, validation results, evidence/effects, pass/fail, diagnostics, Station Profile reference, operation status, and timestamps.
Remove:
expected selected implementation
allowed implementation set
implementation CID
execution type
implementation selection
Edit:
records/req.benac-ux-001/
records/req.benac-ux-003/
records/req.benac-ux-008/
records/req.benac-ux-009/
Required outcomes:
Inspection shows package interfaces, schemas, invocation contract snapshots where derivable, artifacts, artifact availability, declared capabilities, capability grant status where known, resources, operation status, warnings, diagnostics, and raw evidence refs.
Trace inspection shows package interface, invocation contract snapshot, request/output snapshots, evidence, effects, storage actions, compute actions, disclosure records, validation results, diagnostics, and operation status.
Approval references inspection before package approval.
Remove:
implementations
implementation snapshot CIDs
implementation kinds
selected implementation
skipped implementation
local public-data approval
local public-data compatibility status
Edit:
records/req.benac-int-003/
records/req.benac-agt-010/
Required outcomes:
Diagnostics use invocation contract and package interface context, not implementation context.
Diagnostic codes include:
operation.not_currently_mediated_by_this_station
operation.not_yet_determined
operation.attempt_denied
operation.attempt_failed
invocation_contract.snapshot_mismatch
approval.requirements_not_satisfied
Remove:
implementation.unsupported_kind
approval.local_public_data_incompatible
implementation_entry.snapshot_mismatch
implementation_entry.not_currently_attemptable
Edit:
records/req.benac-int-004/
records/req.benac-int-005/
records/req.benac-int-006/
Required title outcomes:
BENAC-INT-005 - Same package content and record behavior
For BENAC-INT-006, choose exactly one:
Delete the record.
or:
Rewrite it as BENAC-INT-006 - Conformance for published Station behavior.
Do not keep Extension profiles. Current/older attached text still shows BENAC-INT-006 - Extension profiles and describes optional capabilities as extension profiles .
Required conformance wording:
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 classify how package work is performed.
Remove:
same portable package behavior
portable package
implementation selection records
extension profiles
baseline
declarative execution
WASM execution
Replace with:
schema-defined package behavior
WASM package-host calling convention
package interface invocation
no silent fallback
invocation contract snapshot
operation status
Edit:
records/req.benac-sys-004/
records/req.benac-host-001/
records/req.benac-host-002/
records/req.benac-host-003/
Required title outcomes:
BENAC-HOST-001 - Host API semantics
Required Station Profile semantics:
A Station Profile publishes known Station information useful for planning, inspection, diagnostics, conformance, and user review.
A Station Profile is not a complete list of everything the Host Platform can do.
A Station Profile is not proof that a requested capability is currently available.
A Station Profile is not proof that a requested operation will succeed.
A Station Profile is not approval.
A Station Profile is not 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.
Remove:
supported implementation kinds
supported declarative implementation rulesets
supported execution types
Host API baseline semantics
implementation artifact or version where this means package implementation
Host Implementation is allowed.
Edit:
records/req.benac-data-001/
records/req.benac-data-002/
Current/older attached text still shows logical object definitions containing implementation references and local-public-data approval records .
Required outcomes:
Invocation objects bind package CID, package interface, descriptor scope, invocation contract snapshot, request, output, evidence, effects, capabilities, resources, and operation status.
Package authoring logical objects include package approval records, not local public-data approval records.
Package authoring logical objects include invocation contract snapshots, not implementation CIDs or implementation snapshots.
Remove:
implementation
implementation CID
local public-data approval records
execution type
Edit:
records/req.benac-stor-021/
records/req.benac-comp-011/
records/req.benac-comp-001/
Required wording:
Provider-specific storage or compute APIs shall be package behavior or external service behavior, not Benac Core behavior.
Storage and compute offers describe possible mediated operations. They do not grant authority and do not classify packages.
Remove:
optional extension behavior
extension profile
supported implementation types
Edit:
records/req.benac-safe-004/
Current attached text still includes “implementation compatibility” as a fail-closed category .
Replace that phrase with:
operation mediation status
invocation contract status
Required statement shape:
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.
After the term and requirement source records are edited, regenerate:
npm run build:glossary
npm run build:syrs
npm test
Then run these guards.
rg -n -i \
'local public-data|local-public-data|portable package profile|baseline portable|extension profile|compatibility claim|compatibility_claim|unsupported required behavior|unsupported_required_behavior|implementation kind|implementation_kind|implementation entry|implementation_entry|implementation identity|implementation CID|implementation selection|selected implementation|skipped implementation|allowed implementation|supported implementation|unsupported implementation|supported execution type|execution type|Declarative Implementation|WASM Implementation|Native Implementation|Portable Implementation|optional privileged capability' \
records/term.* \
records/req.* \
docs/00-Glossary/Terms-and-Definitions.md \
docs/01-Requirements/System-Requirements-Specification.md
Expected result:
No package-facing hits.
Allowed exceptions:
Host Implementation
independent implementation
conforming implementation
implementation of Benac
cryptographic baseline/profile language
authentication profile language
content-identity profile language
schema/profile version language for DRISL object typing
Do not use broad grep failures to remove valid cryptographic/profile terminology. This pass targets package classes and package-work taxonomies only.
These terms must exist in generated glossary or requirements after the cleanup:
rg -n -i \
'Package Interface|request schema|descriptor config schema|output schema|invocation contract snapshot|schema-defined package behavior|WASM package-host calling convention|capability grant|operation status|Station status|not currently mediated by this Station' \
docs/00-Glossary/Terms-and-Definitions.md \
docs/01-Requirements/System-Requirements-Specification.md
Expected result:
Each phrase appears in the appropriate glossary/requirements context.
rg -n -i \
'local public-data package approval|local package capability vocabulary|local public-data portable package|local_public_data_portable_package|local_public_data_approval' \
records/term.* \
records/req.* \
docs/00-Glossary/Terms-and-Definitions.md \
docs/01-Requirements/System-Requirements-Specification.md
Expected result:
Zero hits.
The generated glossary no longer defines:
Declarative Implementation
WASM Implementation
Native Implementation
Portable Implementation
Implementation Selection
Local public-data approval
Local public-data portable package
The generated glossary defines or preserves cleanly:
Package Interface
Request
Output
Invocation Contract Snapshot
Schema-defined package behavior
WASM package-host calling convention
Capability
Capability Grant
Evidence
Effect
Operation Status
Station Status
Package Inspection Result
Package Validation Report
Package Build Report
Fixture
Fixture Result
The generated SyRS no longer contains package-facing requirements titled or phrased as:
Manifest schema for baseline packages
Portable package profile
Implementation identity
Baseline package schema ruleset
Baseline local WASM package-host calling convention
Local pure-transform WASM restrictions
Implementation selection input
Implementation selection record
Inspection before local public-data approval
Extension profiles
Same portable package behavior
Host API baseline semantics
Native/container execution optional
Declarative execution baseline
WASM execution baseline
The generated SyRS does contain:
BENAC-PKG-003 - Package document schema
BENAC-PKG-009 - Invocation contract identity
BENAC-SCHEMA-001 - Required package schema ruleset
BENAC-WASM-001 - WASM package-host calling convention
BENAC-WASM-002 - WASM mediated access restrictions
BENAC-WASM-003 - WASM package-host calling convention template
BENAC-EXEC-001 - Schema-defined package behavior
BENAC-EXEC-002 - WASM package-host calling convention
BENAC-EXEC-005 - Host-native operation attempts
BENAC-EXEC-006 - Invocation contract record
BENAC-EXEC-008 - Interface invocation input
BENAC-UX-009 - Inspection before package approval
BENAC-INT-005 - Same package content and record behavior
The requirements and terms consistently express this model:
A package declares interfaces.
Interfaces bind schemas, capabilities, artifacts, resources, evidence behavior, and effect behavior.
Local Policy decides what may be attempted or used.
The Station mediates allowed operations.
The Station records what is known, unknown, unavailable, denied, attempted, failed, or completed.
Requirements/definitions cleanup is complete and verified locally. I removed the leftover package-facing implementation vocabulary from the scoped records and regenerated the glossary/SRS. I am starting the commit and push phase now; no business logic, app, crate, static artifact, or deployment files are in scope.
Completed the rejected cleanup follow-up and pushed commit 07f3df4 to main.
Caller rejected: Not a redesign. Not another big conceptual round. More like a final terminology sealing pass.
The goal is to make sure nobody reading the glossary or SyRS can still reasonably conclude:
Packages have implementations.
Packages have implementation classes.
Package manifests are a separate thing from package documents.
That is the remaining risk.
In the current generated terms, the newer Package Interface definition is good, but the lower legacy definition area still has a Package term that says the package document contains “implementations,” and it still has a Package Manifest term. That is the wrong vocabulary for the schema-first model.
Fix this before business logic.
Required edits:
records/term.package/package.md
records/term.package-manifest/package-manifest.md
Replace Package with:
A content-addressed reusable behavior unit represented by a package document. A package document declares package metadata, schemas, schema ruleset identifiers, package interfaces, interface contract bindings, artifact references, declared capabilities, resource requirements, fixtures, documentation references, evidence behavior, and effect behavior. Claim references are external to the package document and do not change the package CID.
Then either delete term.package-manifest or replace it with term.package-document.
My preference: delete Package Manifest as a package-facing term unless there is a strong reason to preserve it. We already have Package Bundle Manifest, and keeping Package Manifest invites confusion.
Use:
Package document
Package Bundle Manifest
Do not use:
Package Manifest
Patch these terms/records anywhere they still say package manifest when they mean the package identity-bearing object:
term.schema-ruleset
term.structured-document
term.immutable-document
BENAC-DATA-001 logical object table
any remaining package authoring/report wording
For example, BENAC-DATA-001 is now mostly clean — it describes invocation as package/interface/descriptor/request/output/evidence/effect and uses invocation contract snapshot CIDs rather than implementation CIDs . But the table row or adjacent terminology should say:
package | Package document and package-level metadata
not:
package | Package manifest and package-level metadata
This is small, but it matters. “Manifest” is already doing work in Package Bundle Manifest. Don’t overload it.
The current SyRS diagnostic requirement looks good: it uses invocation_contract.snapshot_mismatch, operation.not_currently_mediated_by_this_station, operation.not_yet_determined, operation.attempt_denied, operation.attempt_failed, and approval.requirements_not_satisfied, and it no longer uses the old implementation/local-public-data diagnostic classes .
But the glossary term for Stable diagnostic classification code still has stale wording around “baseline” and “extension-profile.” Rewrite it to avoid implying extension package lanes.
Replace its usage with:
Use stable diagnostic classification codes for recognized supported failures. Use `diagnostic.unclassified` only when no more specific supported diagnostic classification code applies, and preserve origin-specific and raw evidence where practical and safe.
Do not say:
baseline failures
extension-profile code
Do not chase every cryptographic use of baseline or profile. Those are fine in content identity and crypto.
But I would clean these package-adjacent titles/phrases now:
BENAC-SYS-002 - Mobile browser PWA baseline
BENAC-SYS-003 verification: Same portable conformance package...
BENAC-ENC-020 - Stronger privacy modes are optional extensions
Suggested replacements:
BENAC-SYS-002 - Mobile browser PWA host
Same conformance package runs on browser PWA, Ubuntu, macOS, and Windows implementations.
BENAC-ENC-020 - Stronger privacy mechanisms require separate requirements
For BENAC-ENC-020, use:
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.
That avoids the old “optional extensions” smell without pretending these mechanisms are forbidden.
I would not block on terms like:
Host Implementation
independent implementation
conforming implementation
implementation of Benac
Those are fine. They refer to software implementing Benac, not package-internal implementation categories.
I would also not block on cryptographic phrases like:
cryptographic profile
content-identity profile
authentication profile
baseline DASL CID profile
Those are doing real technical work and are not package classes.
Run this over the generated SyRS and glossary:
rg -n -i \
'package manifest|implementation kind|implementation_kind|implementation entry|implementation_entry|implementation identity|implementation CID|implementation selection|selected implementation|skipped implementation|allowed implementation|supported execution type|execution type|Declarative Implementation|WASM Implementation|Native Implementation|Portable Implementation|local public-data|portable package profile|extension profile|optional extensions|baseline portable' \
docs/00-Glossary/Terms-and-Definitions.md \
docs/01-Requirements/System-Requirements-Specification.md
Expected result:
No package-facing hits.
Allowed cases should be limited to things like:
Host Implementation
independent implementation
conforming implementation
cryptographic profile
authentication profile
content-identity profile
baseline CID / DRISL / crypto wording
Read the latest rejection. Prior phase deployed and pushed cleanly, but the caller identified a final terminology sealing pass before business logic: Package/Package Manifest vocabulary, package-manifest references that should be package document, stale baseline/extension-profile diagnostic glossary wording, and a few package-adjacent baseline/portable/optional-extension phrases. Starting that requirements/definitions-only cleanup now.
Final terminology sealing edits are implemented and verified locally. The generated glossary no longer defines Package Manifest; it defines Package document. The generated final guard for package manifest / implementation taxonomy / local-public-data / optional-extension wording returns zero hits, npm test passes, and no apps/, crates/, or static/ files changed. Starting commit and push phase now.
Commit e2bcf7f is pushed to main. Starting deploy phase so the public repo zip and deploy stamp reflect the final terminology sealing pass.
Completed the final terminology sealing pass, pushed it to main, deployed it, and verified the live site.
Caller accepted: Accepted for requirements/definitions phase.
The generated SyRS and glossary now express the schema-first package model. Package-facing requirements no longer rely on implementation kinds, implementation selection, local-public-data package approval, portable package profiles, or extension-profile package lanes.
The current requirements define packages around package interfaces, request schemas, descriptor config schemas, output schemas, invocation contract snapshots, declared capabilities, artifact requirements, resource requirements, evidence behavior, effect behavior, Local Policy, Station mediation, and operation status.
Proceed to business logic.
Sign in as a human to drive this ticket from the page, or use the MCP tools.
Ticket created: Update requirements