resolved 266e382d-cab9-4be7-b70c-6cfb7b49dccb
Below is a maintainer-ready ticket. I’d hand this over as-is.
Specification / requirements / glossary cleanup only.
High.
This ticket should be completed before adding more agent-specific requirements, because the current SyRS is close to the right architecture but has some wording and object-model drift toward agent-specific planning/governance concepts.
The generated SyRS says requirement records live under records/req.*/*.md and must be rebuilt with npm run build:syrs; the generated glossary likewise says to edit term records and run npm run build:glossary .
Current SyRS already has strong foundations for this ticket: package manifests/interfaces, build and validation reports, fixture execution, invocation/evidence/effect ledgers, raw evidence preservation, diagnostics, Host APIs, Agent APIs, storage/compute leases, and inspectability. The current terms define an Agent as a client that can inspect Benac, author packages, request trust, discover storage/compute, propose plans, and invoke packages within granted authority .
Benac is meant to be a general-purpose, legible execution substrate where agents, humans, CLIs, package builders, test runners, and UIs can build, test, invoke, inspect, fail, repair, and try again.
The current requirements mostly support that direction, but several areas drift into agent-specific “planning” and “governance” language that risks bloating the kernel or making Benac sound like an AI containment system.
The desired framing is:
Benac Core provides the road, signs, lanes, telemetry, receipts, resource gates, and failure signals. Agents, packages, workflows, UIs, prompts, and external clients decide how to drive.
Benac should not define agent cognition, goals, recovery loops, workflow semantics, planner state, outcome records, or environment-change proposal systems.
Benac should make packages, requests, outputs, effects, evidence, storage, compute, diagnostics, and authority boundaries legible enough that agents can experiment safely with small blast radius.
A requirement belongs in Benac Core only if independent implementations must share that semantic behavior for packages, invocations, diagnostics, authority, storage, compute, evidence, effects, or audit records to remain portable and inspectable.
A requirement does not belong in Benac Core if it defines how an agent thinks, plans, remembers, recovers, decomposes work, sets goals, proposes environment changes, or runs an autonomous growth loop.
Do not add a “growth loop” requirement.
Do not add goal objects, outcome records, planner state, recovery-affordance objects, environment-change proposals, or agent memory architecture to Benac Core.
Do not make workflows a core primitive.
Do not create special kernel semantics for Builder Agent, Review Agent, or workflow principals.
Do not require storage plans or compute plans as baseline objects merely because an agent may reason about storage or compute.
Do not change implementation code in this ticket.
Add:
records/req.benac-sys-007/benac-sys-007.md
Statement: Benac Core shall not define or require agent cognition, agent goals, planner state, recovery strategies, memory architecture, autonomous loops, workflow semantics, task decomposition, environment-change proposal semantics, or model-specific reasoning behavior. Such behavior belongs in agents, packages, descriptors, external clients, prompts, user interfaces, or optional extension profiles. Benac Core shall define the semantic substrate needed for such clients to inspect, author, validate, invoke, compose, store, compute, diagnose, audit, and request authority under Local Policy.
Rationale: Benac should be a legible test track and road system, not a Ferrari design. Agents must be able to grow and experiment on top of Benac without requiring the kernel to know what kind of agent is driving.
Verification: Requirements review confirms no baseline requirement mandates agent goals, planner state, recovery loops, workflow semantics, or model-specific reasoning behavior. Conformance tests exercise package authoring, fixture execution, invocation, diagnostics, storage/compute lease requests, causal record linking, and inspection without depending on any specific agent architecture.
Current issue: BENAC-AGT-001 and BENAC-AGT-011 overlap. BENAC-AGT-001 exposes a schema-driven local API for agents to inspect objects; BENAC-AGT-011 exposes machine-readable APIs for authenticated or locally scoped agents to inspect state, author drafts, validate/build packages, run fixtures, create requests, invoke descriptors, inspect traces, and import/export capsules .
Merge BENAC-AGT-011 into BENAC-AGT-001.
Either delete records/req.benac-agt-011/benac-agt-011.md, or mark it as retired/merged if stable IDs must be preserved.
BENAC-AGT-001 withTitle: BENAC-AGT-001 - Machine-readable client API
Statement: Benac shall expose schema-driven machine-readable APIs for authenticated or locally scoped agents, tools, CLIs, UIs, package builders, fixture runners, and other clients to inspect allowed state; inspect Station Profiles; inspect principal and authentication status; inspect packages, package inspection results, schemas, descriptors, claims, trust decisions, capability grants, invocations, evidence, effects, blob availability, storage offers, compute offers, sync status, validation reports, build reports, fixture definitions, fixture results, and diagnostic records; author or import package drafts; validate packages; build packages where supported; run fixtures; create trust requests, capability requests, storage lease requests, and compute lease requests; invoke authorized descriptors; inspect traces; and export/import capsules. All authority-bearing operations shall remain subject to authentication, attribution, Local Policy, trust decisions, capability grants, leases, data-class policy, evidence recording, effect recording, and audit requirements.
Rationale: Agents are important Benac clients, but the kernel should expose legible machine interfaces rather than agent-specific cognition. The same surface should support agents, humans through UI, CLIs, package builders, validators, test runners, and conformance tools. This gives agents the handholds needed to experiment and repair failures without giving them ambient authority.
Verification: Conformance tests validate that an authenticated agent, CLI/tool client, and UI-mediated client can retrieve equivalent package inspection, validation, fixture, invocation, diagnostic, evidence, and effect records where authorized. Tests also verify that unauthorized write or authority-bearing operations fail closed, create appropriate diagnostics or denied effects where applicable, and remain attributable.
Update references to “Agent API external interface” to point to BENAC-AGT-001.
Update section heading from:
Agent-native operation
to:
Agent and client operation
or:
Machine-readable client operation
Current issue: storage and compute planning are split across multiple requirements and terms. The glossary defines Storage plan and Compute plan as proposed plans, and the SyRS has BENAC-STOR-012 - Agent storage planning, BENAC-COMP-005 - Compute plans, BENAC-AGT-007 - Agent storage planning, BENAC-AGT-008 - Agent compute planning, and BENAC-UX-005 - Storage and compute plan review .
Planning can happen in agents, prompts, packages, or UIs. Benac Core only needs the reviewable request/authorization object and the resulting lease.
BENAC-STOR-012Old title: BENAC-STOR-012 - Agent storage planning
New title: BENAC-STOR-012 - Storage lease requests
Statement: Benac shall support machine-readable storage lease request records created by authenticated or locally scoped users, agents, tools, packages where authorized, or other clients. A storage lease request shall describe the requested storage descriptor or offer where applicable, requested operations, target blob CIDs or blob classes where known, data classes, byte limits, recipient principals, encryption requirements, retention expectations, cost constraints where applicable, evidence expectations, requested expiry, initiating actor, authentication context where applicable, and supporting evidence or justification where supplied. A storage lease request shall not itself authorize storage effects. Storage effects require an active storage lease, capability grant, Local Policy allowance, or other accepted authorization record.
Rationale: Agents and tools need a legible way to ask for bounded storage resources, but the kernel does not need to define an agent’s storage-planning process. Lease requests let agents take small reviewable steps toward availability, backup, staging, or sharing without receiving ambient storage authority.
Verification: An agent or tool creates a storage lease request for encrypted backup of selected blob CIDs. No upload, pin, publication, retrieval of sensitive blobs, sharing, or staging effect occurs until a matching lease or grant exists. The resulting request, approval/denial, lease, storage effects, receipts, and diagnostics are attributable and inspectable.
BENAC-COMP-005Old title: BENAC-COMP-005 - Compute plans
New title: BENAC-COMP-005 - Compute lease requests
Statement: Benac shall support machine-readable compute lease request records created by authenticated or locally scoped users, agents, tools, packages where authorized, or other clients. A compute lease request shall describe the requested compute descriptor or offer where applicable, target package/interface/implementation or descriptor where known, input CIDs or request snapshot references where known, data classes, required storage staging, data egress, privacy/disclosure implications, cost limits where applicable, resource limits, output encryption requirements, evidence expectations, requested expiry, initiating actor, authentication context where applicable, and supporting evidence or justification where supplied. A compute lease request shall not itself authorize compute effects, data egress, decryption, plaintext disclosure, or storage staging. Such effects require an active compute lease, storage lease where applicable, capability grant, Local Policy allowance, or other accepted authorization record.
Rationale: Agents and tools need a legible way to ask for bounded compute, especially when experimenting with models, remote resources, or heavier workloads. Benac should record the request and the authority boundary, not require a kernel-defined compute-planning process.
Verification: An agent or tool creates a compute lease request for a package invocation requiring remote compute and storage staging. No remote compute, private data egress, plaintext disclosure, or staging occurs until matching leases and grants exist. The request, approval/denial, lease, invocation, evidence, effects, disclosure records, and diagnostics are attributable and inspectable.
BENAC-AGT-007 and BENAC-AGT-008Delete these requirements
Reason: Agent storage/compute behavior is already covered by the machine-readable client API plus storage/compute discovery, lease requests, leases, evidence, effects, and diagnostics.
BENAC-UX-005Old title: BENAC-UX-005 - Storage and compute plan review
New title: BENAC-UX-005 - Storage and compute authorization review
Statement: Benac shall present storage lease requests, compute lease requests, storage leases, compute leases, and related disclosure approvals with data egress, data class, encryption, recipient, Station principal, endpoint or descriptor, cost where known, evidence expectations, trust implications, and plaintext disclosure implications before approval where Local Policy requires review.
Rationale: Remote resource use can create privacy, cost, and availability consequences. Review surfaces should help users and agents understand the requested authority and blast radius without making Benac Core responsible for the agent’s planning process.
Verification: Storage and compute authorization review fixtures display required data class, egress, recipient, encryption, cost, evidence, and plaintext disclosure information before lease approval.
Replace baseline references to storage plans and compute plans with storage lease requests / compute lease requests / authorization requests in:
BENAC-AUTH-007BENAC-AUTH-013BENAC-AGT-002BENAC-AGT-005BENAC-AGT-009BENAC-EFF-002BENAC-STOR-013BENAC-COMP-010BENAC-ENC-002BENAC-IO-006BENAC-UX-005Agent, Agent Action, Review Agent, Agent Workspace, Storage plan, and Compute planWhere a plan-like document is still useful, treat it as optional supporting evidence attached to a request, not as a required Benac Core object.
Current issue: BENAC-INV-006 includes “workflow principal,” and BENAC-DOC-005 mentions “workflow snapshots if any” . That risks making workflow a kernel primitive.
Workflows should live in packages or optional extension profiles. The kernel should support composition, not define workflow semantics.
BENAC-INV-006Old: Invocations shall be attributable to the Station principal and, when applicable, the user principal, agent principal, workflow principal, Storage Station principal, or Compute Station principal...
Replace with:
Statement: Invocations shall be attributable to the Station principal and, when applicable, the user principal, agent principal, package authoring principal, authenticated client session, Storage Station principal, Compute Station principal, package invocation, parent invocation, or other participating principal/session that initiated, mediated, or performed work. Attribution to parent or child invocations shall not create a new principal class and shall not grant authority.
Rationale: Accountability requires knowing which actor, session, package, Station, and parent invocation participated in work. Workflow-like behavior can be represented as package composition and invocation causality rather than as a special workflow principal.
Verification: Agent-initiated, package-composed, and remote-compute-assisted invocation fixtures contain correct Station, actor/session, package, parent invocation, child invocation, Storage Station, and Compute Station attribution without using a workflow principal.
BENAC-DOC-005Remove “workflow snapshots if any” from the baseline list.
Use:
Immutable structured objects such as package manifests, schema documents, descriptor snapshots, signed claim payloads, blob manifests, fixture documents, and extension-profile objects where applicable...
If a workflow package needs workflow snapshots, they are package content or extension-profile objects, not baseline core objects.
This is the main new enabling requirement.
The current Host package interface allows mediated blob access, HTTPS fetch, storage, compute, secret use, encryption/decryption, evidence emission, effect request, clock, random bytes, and output return, but it does not clearly define package-to-package invocation through the same mediated path .
Without this, “workflows live in packages” becomes awkward. A workflow package needs a governed way to invoke other packages without the kernel knowing what a workflow is.
BENAC-INV-009records/req.benac-inv-009/benac-inv-009.md
Statement: Benac shall support, or define an optional baseline-compatible mechanism for, a package invocation to request invocation of another package interface or descriptor through the Host Station’s mediated invocation path. Such child invocations shall be subject to ordinary package trust, descriptor trust, request validation, implementation selection, capability grants, leases, data-class policy, evidence recording, effect recording, diagnostics, resource limits, failure behavior, and Local Policy. Child invocation records shall reference the parent invocation where applicable. A package shall not gain ambient authority to invoke arbitrary packages merely because it is executing.
Rationale: Workflow-like behavior, orchestration, and agent-authored composite behavior should be expressible as packages. Benac Core should provide the legible interchange between package invocations, not define workflow semantics. This lets agents build small composite tools, run them, inspect failures, and refine them while every child invocation remains attributable, bounded, and auditable.
Verification: A composite package invokes an authorized child calculator package and records parent/child invocation links, request snapshots, output snapshots, selected implementations, evidence, effects, diagnostics, and capability checks. A second fixture attempts to invoke an unauthorized child package or descriptor and records a denied effect or failed child invocation without granting authority or silently falling back.
Amend BENAC-HOST-002 - Package host interface mediation to include:
mediated package invocation requests through the Host Station’s invocation path, where supported and authorized
The current BENAC-HOST-002 already defines mediated package-host calls and explicitly prevents packages from receiving raw keys, credentials, direct document-store access, host metadata, UI state, and unvalidated projections .
Amend BENAC-CAP-001 to include package invocation/composition capability where applicable.
Amend BENAC-CAP-006 so effect-time checks for mediated package invocation include target package CID, target descriptor snapshot CID, target interface identifier, requested data class, initiating package CID, parent invocation reference, and granted scope.
Amend BENAC-INV-002 to include parent invocation reference and child invocation references where applicable.
Current invocation, evidence, effect, validation, fixture, and diagnostic records are strong. But agent iteration needs reconstructable chains:
draft package → build report → validation failure → edited package → fixture result → trust request → approval → invocation → denied effect → diagnostic → next request
Benac should not define the agent’s recovery strategy. It should preserve causality so the agent can recover.
BENAC-AUD-002records/req.benac-aud-002/benac-aud-002.md
Statement: Benac authoring records, package drafts where represented, build reports, validation reports, fixture results, trust requests, capability requests, storage lease requests, compute lease requests, approvals, trust decisions, capability grants, leases, invocations, evidence records, effect records, storage records, compute records, disclosure records, diagnostic records, import records, export records, and audit records shall support causal references where applicable. Causal references may include initiating actor, authenticated session, parent invocation, child invocation, related request, related approval, related package draft, related package CID, related implementation CID, related descriptor snapshot CID, related build report, related validation report, related fixture result, related diagnostic record, related evidence record, and related effect record. Causal references are for audit, reconstruction, debugging, and inspection only; they shall not grant authority.
Rationale: Agents and humans need to understand what caused what without the kernel defining an agent recovery loop. Causal links make experimentation scrutable: a failed build, denied effect, missing blob, or invalid output can be traced back to the draft, request, invocation, approval, or package that produced it.
Verification: A conformance scenario creates a package draft, builds it, receives a validation failure, fixes it, runs fixtures, requests trust, receives approval, invokes it, triggers a denied effect, and inspects diagnostics. The resulting records can be traversed by causal references from final diagnostic back to invocation, approval, fixture result, build report, package draft, and initiating actor. No causal reference grants authority by itself.
Amend BENAC-DATA-001 and BENAC-DATA-002 to include causal references as minimum logical object fields where applicable. BENAC-DATA-001 and BENAC-DATA-002 already define logical object schemas and package-authoring objects using CIDs, DRISL where needed, and stable diagnostics .
Add a glossary term:
A structured reference from one Benac record to another record, object, actor, session, invocation, evidence item, effect, diagnostic, request, approval, package draft, package CID, implementation CID, descriptor snapshot CID, build report, validation report, fixture result, storage record, compute record, or disclosure record that helps reconstruct why an event occurred.
Usage: Causal references support audit, debugging, agent repair, and conformance reconstruction. They do not grant authority.
Current BENAC-AUD-001 requires user- and agent-accessible inspection of package manifests, descriptors, claims, trust decisions, capability grants, invocations, evidence, effects, conflicts, encrypted envelopes, storage status, compute status, sync status, validation reports, build reports, fixture results, and diagnostic records .
That is good, but for agents this cannot only mean “dump everything.” Agents need bounded, queryable inspection.
BENAC-AUD-003records/req.benac-aud-003/benac-aud-003.md
Statement: Benac inspection APIs shall support machine-readable querying or filtering of inspectable records by object type, CID, package CID, implementation CID, descriptor snapshot CID, interface identifier, request snapshot CID, output snapshot CID, actor principal, authenticated session, invocation status, diagnostic classification code, capability or effect class, data class, storage lease, compute lease, time range, and causal reference where applicable. Large evidence bodies may be returned by CID or encrypted reference. Responses shall support host-defined size limits, pagination, truncation metadata, redaction metadata, encryption metadata, omission metadata, and follow-up retrieval of referenced evidence where authorized.
Rationale: Inspectability is the feedback surface for agent experimentation. Agents should be able to ask focused questions such as “show failed invocations for this package,” “show diagnostics for this fixture,” “show denied effects for this descriptor,” or “show raw evidence for this validation failure” without depending on prose logs or unbounded database dumps.
Verification: Agent API and Host API conformance tests query failed invocations by package CID, diagnostics by stable classification code, denied effects by capability class, fixture results by package/implementation CID, and evidence by causal reference. Tests verify pagination, redaction metadata, truncation metadata, encrypted evidence references, and denied retrieval for unauthorized evidence.
BENAC-AUD-001 rationaleReplace:
Benac is an accountable kernel.
With:
Inspectability is the shared feedback surface for users, agents, tools, packages, and conformance tests. It makes experimentation, failure, authority, effects, and repair paths scrutable without requiring Benac Core to define how an agent reasons.
Current BENAC-AGT-006 says agents shall be able to run package tests in constrained modes. But fixture execution already defines same-kernel test mode semantics, avoiding real network/storage/compute/secrets unless explicitly declared mock/playback behavior exists .
Delete BENAC-AGT-006
Agents do not need a special testing model. Fixture execution is the general small-blast-radius test track for packages authored by humans, agents, CLIs, and other tools.
Do a rationale pass on the following requirements. The statements can mostly remain, except where noted above. The rationales should make clear that constraints are handholds and lane markers, not an attempt to keep agents weak.
BENAC-AUTH-008 - Agent authentication cannot self-authorizeCurrent rationale:
Agent productivity must not become agent privilege escalation.
Replace with:
Agent authentication should make experimentation attributable without turning identity into authority. Agents may build, test, invoke, and request power, but approval and escalation remain separate Local Policy decisions.
BENAC-AGT-004 - Agents cannot self-trustCurrent rationale:
Agents can propose; Benac governs power.
Replace with:
Agents can propose, build, test, and request authority. Benac records those requests and applies Local Policy so agent experimentation can proceed in small reviewable steps without invisible privilege escalation.
BENAC-CAP-001 - Explicit capability declarationCurrent rationale:
The host must know possible authority before execution.
Replace with:
Capability declarations make possible effects visible before execution so users, agents, tools, and policy can reason about blast radius, tests, approvals, and denials.
BENAC-CAP-002 - Explicit capability grantsCurrent rationale:
Declaring a capability is not the same as being allowed to use it.
Replace with:
Packages and agents need a way to ask for power without receiving it automatically. Explicit grants turn requested power into scoped, attributable, revocable authority.
BENAC-CAP-003 - Capability mediationCurrent rationale:
Executable packages must not get invisible power.
Replace with:
Host mediation gives packages explicit handholds for effects, evidence, diagnostics, and denials instead of ambient invisible power. This lets agents experiment with packages while preserving legible authority boundaries.
BENAC-CAP-004 - Data egress as effectCurrent rationale:
Agents must not smuggle private data through storage, compute, or network operations.
Replace with:
Data egress is a real-world effect. Recording it lets users and agents understand where data moved, why it moved, which authority allowed it, and how to adjust future requests or grants.
BENAC-CAP-005 - Capability conflict fail-closed behaviorCurrent rationale:
Ambiguity shall not create power.
Replace with:
Ambiguous authority should become a clear denial and diagnostic, not hopeful execution. This gives agents and users a repairable signal while preventing accidental expansion of power.
BENAC-CAP-006 - Effect-time capability checksCurrent rationale is security-focused and should stay mostly intact, but add:
Effect-time checks also support agent iteration by making the actual denied operation visible, including the endpoint, blob, descriptor, data class, recipient, or other scope field that caused denial.
BENAC-INV-001 - Invocation record requiredCurrent rationale:
Benac must leave receipts even when execution fails.
Replace with:
Every attempt, including failure, is feedback. Invocation records let users, agents, tools, and conformance tests reconstruct what was tried, under which authority, and what can be corrected next.
BENAC-INV-005 - No silent fallbackCurrent rationale:
Audit integrity requires explicit behavior.
Replace with:
Silent fallback destroys the feedback loop. Agents and users need to know which implementation, endpoint, Station, policy, profile, or output contract was actually used so they can trust, debug, or revise the next attempt.
BENAC-EVD-001 - Evidence ledgerCurrent rationale:
Outputs need receipts.
Replace with:
Evidence records preserve what was observed or produced so outputs, failures, package behavior, storage, compute, and agent decisions can be inspected rather than guessed.
BENAC-EFF-001 - Effect ledgerCurrent rationale:
Effects must be auditable separately from evidence.
Replace with:
Effects are where Benac touches the world. Recording attempted and completed effects gives users and agents a legible map of what changed, what was denied, and what authority was involved.
BENAC-EFF-002 - Denied effects recordedCurrent statement currently mentions “package code, an agent, a storage plan, or a compute plan” .
Replace statement with:
Benac shall record denied effect attempts when package code, a package invocation, an agent/client action, a storage operation, a compute operation, a disclosure operation, a lease request, or another host-mediated operation requests a capability or authority denied by policy.
Replace rationale:
Denied effects are feedback and audit evidence. They show what was attempted, why it was blocked, and what narrower grant, corrected request, or package change might be needed next.
BENAC-TEST-002 - Fixture execution semanticsCurrent rationale:
Package tests are useful only if they exercise the same kernel behavior as real invocation while avoiding unintended external effects.
Replace with:
Fixtures are the small-blast-radius test track for package behavior. They let humans, agents, and conformance tools exercise the same validation, invocation, evidence, effect, and diagnostic semantics as real execution without unintended external consequences.
BENAC-AUD-001 - InspectabilityReplace as described in section 7.
BENAC-SAFE-001 - Physical-world effects are explicitCurrent rationale:
Physical-world effects need special governance.
Replace with:
Physical-world capabilities should be explicit handholds, not hidden behind generic network or device access. This lets agents use real-world devices through visible, scoped, reviewable authority rather than ambient power.
BENAC-SAFE-002 - Human approval gatesCurrent rationale:
Some effects should not be delegated silently to agents.
Replace with:
Human approval gates allow useful delegation while preserving escalation boundaries for high-risk effects. Agents can still propose and prepare work; Local Policy decides when a human must approve before the world changes.
BENAC-SAFE-004 - Fail-closed defaultCurrent rationale:
Ambiguity shall not create power.
Replace with:
Unknown or conflicted authority should produce a clear blocked state and diagnostic rather than accidental power. This keeps experimentation bounded and repairable.
AgentCurrent term says an Agent can “propose plans” .
Replace with:
An Agent is a human-operated or AI-operated client that can inspect Benac, author or import packages, validate and test packages, request trust, request capabilities, request storage or compute leases, discover storage, discover compute, invoke packages within granted authority, and inspect resulting records.
Usage:
Agent behavior is outside Benac Core. Benac provides machine-readable APIs, attribution, authority boundaries, evidence, effects, diagnostics, and audit records that agents may use.
Agent ActionReplace plan language with request/lease language:
An action taken by an Agent Principal or locally scoped agent session, such as authoring a package, importing a bundle, validating a package, running fixtures, invoking a descriptor, requesting trust, requesting capabilities, requesting storage or compute leases, exporting/importing capsules, or inspecting records.
Agent WorkspaceDemote this to explanatory/product terminology, not a required kernel object.
Replace with:
A local or encrypted area, document set, package-authoring workspace, or client-managed context used for agent-authored drafts, notes, tests, requests, and intermediate artifacts.
Usage:
Agent workspaces are not a required Benac Core object class. Where their contents enter Benac semantics, they do so as package drafts, documents, blobs, requests, reports, evidence, effects, or other typed Benac objects.
Builder Agent and Review AgentAdd usage note to both:
This is an explanatory role, not a separate kernel authority class. Use ordinary Agent Principal, Local Policy, capability grants, claims, and attribution.
Storage plan and Compute planOption A, preferred: remove both as baseline terms.
Option B: keep as non-authoritative optional supporting documents.
If keeping them, add:
A storage/compute plan is optional supporting material. It is not a required authorization object and does not grant authority. Baseline authorization uses storage lease requests, compute lease requests, storage leases, compute leases, capability grants, trust decisions, and Local Policy.
Storage lease requestDefinition:
A structured request asking Local Policy or an authorized principal to create a Storage Lease under specified scope, including requested operations, target blobs or blob classes, data classes, encryption requirements, recipients, limits, retention expectations, evidence expectations, cost constraints where applicable, initiating actor, and supporting evidence where supplied.
Usage:
A Storage Lease Request does not itself authorize storage effects.
Compute lease requestDefinition:
A structured request asking Local Policy or an authorized principal to create a Compute Lease under specified scope, including target package/interface/descriptor where known, input references, data classes, resource limits, storage staging, data egress, disclosure implications, output encryption requirements, evidence expectations, cost constraints where applicable, initiating actor, and supporting evidence where supplied.
Usage:
A Compute Lease Request does not itself authorize compute, data egress, storage staging, decryption, or plaintext disclosure.
Causal referenceUse the definition from section 6.
Amend BENAC-DATA-001 and BENAC-DATA-002.
Current BENAC-DATA-001 defines minimum logical data object CID fields, and BENAC-DATA-002 defines package authoring logical objects such as validation reports, build reports, fixture results, request snapshots, output snapshots, package inspection results, approval records, diagnostic records, schema rulesets, WASM package-host calling convention identifiers, and resource limit reports .
Add minimum logical schemas for:
Update package authoring logical objects so validation reports, build reports, fixture results, package inspection results, diagnostics, invocations, evidence records, and effect records may carry causal references.
This ticket is complete when:
The generated SyRS no longer contains a baseline requirement for agent goals, growth loops, planner state, recovery strategies, workflow semantics, environment-change proposals, or outcome records.
BENAC-SYS-007 exists and explicitly protects agent-neutral kernel scope.
BENAC-AGT-001 and BENAC-AGT-011 are merged or one is retired, and the surviving requirement describes a machine-readable client API usable by agents, CLIs, UIs, tools, package builders, and fixture runners.
BENAC-AGT-006, BENAC-AGT-007, and BENAC-AGT-008 are deleted, retired, or reduced to cross-references.
Storage/compute “plans” are no longer required baseline authorization objects. Baseline language uses storage lease requests, compute lease requests, leases, capability grants, trust decisions, and Local Policy.
BENAC-STOR-012 is rewritten as Storage lease requests.
BENAC-COMP-005 is rewritten as Compute lease requests.
BENAC-UX-005 is rewritten as Storage and compute authorization review.
BENAC-INV-006 no longer includes workflow principal.
BENAC-DOC-005 no longer implies workflow snapshots are a baseline core object.
BENAC-INV-009 - Mediated package composition exists.
BENAC-HOST-002, BENAC-CAP-001, BENAC-CAP-006, and BENAC-INV-002 are updated to support mediated child package invocation where applicable.
BENAC-AUD-002 - Causal record linking exists.
BENAC-AUD-003 - Queryable inspection exists.
Rationale language in the listed requirements frames constraints as legibility, bounded experimentation, small blast radius, authority clarity, and repairable feedback — not merely paranoia, containment, or prevention.
Glossary terms are updated so Agent, Agent Action, Agent Workspace, Builder Agent, Review Agent, Storage plan, and Compute plan do not imply kernel-owned agent cognition or required plan objects.
New glossary terms exist for Storage lease request, Compute lease request, and Causal reference.
npm run build:syrs and npm run build:glossary have been run after editing source records.
Generated output contains no unexpected uses of “workflow principal,” “agent growth loop,” “agent goals,” “outcome record,” “environment-change proposal,” “storage plan” as required baseline object, or “compute plan” as required baseline object.
The goal is not to weaken safety. It is to make safety serve growth.
Benac should let agents experiment, fail, inspect, repair, and compose software. The kernel should provide schemas, CIDs, descriptors, mediated effects, leases, diagnostics, raw evidence, causal links, and queryable audit records. That is enough road for many different Ferraris.
Implemented the agent-neutral kernel-scope requirements cleanup with changes scoped to records/** and docs/** only.
Summary of changes:
BENAC-SYS-007 - Agent-neutral kernel scope.BENAC-AGT-001 - Machine-readable client API and deleted the duplicate/superseded agent-only requirements BENAC-AGT-006, BENAC-AGT-007, BENAC-AGT-008, and BENAC-AGT-011.BENAC-STOR-012, BENAC-COMP-005, and BENAC-UX-005.BENAC-INV-009 - Mediated package composition.BENAC-AUD-002 - Causal record linking and BENAC-AUD-003 - Queryable inspection.BENAC-HOST-002, BENAC-CAP-001, BENAC-CAP-006, BENAC-INV-002, BENAC-DATA-001, and BENAC-DATA-002 for mediated child invocation, lease requests, causal references, and parent/child invocation references.Storage plan and Compute plan term records and added Storage lease request, Compute lease request, and Causal reference.records/** and docs/** scope, the generated SyRS table was corrected directly in docs/01-Requirements/System-Requirements-Specification.md after running the build, without touching tools/**.Verification performed:
npm run build:glossary wrote glossary from 273 term records.npm run build:syrs wrote SyRS from 226 requirement records.npm test passed through build and dataset validation, checking 518 files.npm run validate:dataset passed after the docs-only correction, checking 518 files.git diff --check -- records docs passed.records/**, generated SyRS, and generated glossary found no remaining exact baseline uses of storage plan, compute plan, storage_plan, compute_plan, workflow principal, workflow snapshots, Agent-native operation, Agent API external interface, BENAC-AGT-006, BENAC-AGT-007, BENAC-AGT-008, BENAC-AGT-011, or outcome record.Commit pushed:
72b6dca docs(spec): align agent-neutral kernel scope on feat/local-public-data-packages.Notes:
records/** and docs/**.Handler taking this ticket in progress.
Phase plan:
Phase 0 complete: fetched the full ticket context before editing.
Phase 1 complete: inventoried affected requirement and term records plus generated docs. Constraint confirmed for implementation phase: changes will stay under records/** and docs/**; no business-logic/code changes.
Handler proposes resolution after completing the records/docs-only implementation.
Caller accepted: Reviewed and accepted. Closing this ticket.
I checked the implemented changes against the acceptance criteria and the current generated SyRS/glossary output. The requirements are now aligned around agent-neutral, machine-readable legibility rather than agent-specific planning or containment.
Confirmed:
BENAC-SYS-007 - Agent-neutral kernel scope exists and keeps agent cognition, goals, planner state, recovery strategies, workflow semantics, and model-specific reasoning behavior out of Benac Core.BENAC-AGT-001 is now the merged machine-readable client API, and the superseded agent-only requirements BENAC-AGT-006, BENAC-AGT-007, BENAC-AGT-008, and BENAC-AGT-011 are gone from the generated SyRS.BENAC-STOR-012, BENAC-COMP-005, and BENAC-UX-005 now use lease/request and authorization-review language.BENAC-INV-009 - Mediated package composition exists.BENAC-AUD-002 - Causal record linking and BENAC-AUD-003 - Queryable inspection exist.Verification noted in the proposed resolution:
npm run build:glossarynpm run build:syrsnpm testnpm run validate:datasetgit diff --check -- records docsrecords/**, generated SyRS, and generated glossaryClosing as complete.
Sign in as a human to drive this ticket from the page, or use the MCP tools.
Ticket created: Align Benac requirements around agent-neutral legible growth, not agent containment