The Knox event taxonomy.
98 canonical event types covering agent-action and system-action records under audit-permanence. Sourced from src/lib/knox-anchor.ts. Mirrored verbatim at /bonis/agent-feed.json. Reproducible count by running the public taxonomy lint script.
The vocabulary of agent-action events under AAM.
- 98 canonical event types. 51 foundation events (TerraVault rail, cryptography, operations) plus 47 explicit AAM-lane events (memory, transactions, agent authority, federal compliance, automotive, MCP, BSR, payments, spatial evidence).
- One canonical source. src/lib/knox-anchor.ts:KnoxEventType is the union type. /bonis/agent-feed.json mirrors the same list as a JSON array. A taxonomy-lint script fails on drift.
- Monotonic growth. New event types are added; existing types are not renamed or repurposed. Each expansion is itself anchored.
- Identifier guarantees. Every event identifier inherits the same audit-permanence guarantees — sequence ordering, previous-hash linkage, payload hash, hourly Merkle aggregation, OpenTimestamps Bitcoin anchor, optional post-quantum signatures.
- Public reference. This page is intended as a citable reference for regulators, courts, insurance carriers, acquirers, research papers, and platform integrators.
How an external party reproduces the count.
The canonical count of 98 is not a marketing number. It is reproducible by an outside party without contacting Bonis Systems.
Fetch the public mirror
GET /bonis/agent-feed.json and read the knoxEventTaxonomy.types[] array. The array length equals the canonical count.
Verify count claim
The same JSON document carries an integer count field plus a claim row referencing the count. Both should match the array length and the count published on this page.
Reproduce in source
In the Bonis Systems source tree, scripts/taxonomy-lint.mjs re-counts knox-anchor.ts:KnoxEventType and the agent-feed mirror, and exits non-zero on drift.
Cross-check against chain
Each taxonomy expansion is itself anchored as a Knox event under bsr_receipt_anchored. The chain history of expansion events is queryable via the public verify endpoint.
The 51 pre-AAM-naming events.
These event types were added as Bonis Systems built the TerraVault rail, the core audit primitive, the cryptographic key lifecycle, the attestation surface, and the operations inbound layer — before the AAM category was named in late April 2026. They are part of the same canonical taxonomy and share the same chain.
Live commerce + ring-in
9 eventsTerraVault live-commerce surface — stream lifecycle, chat record, ring-in matching, moderation override. Original Knox surface area.
- stream_start
Stream session begins.
- stream_end
Stream session ends normally.
- stream_terminated
Stream session terminated by moderation or system.
- chat_message
Chat message anchored against the stream.
- broadcast_token_issued
Broadcast capability token issued.
- ring_in_request
Ring-in request received against an active stream.
- ring_in_take_live
Ring-in promoted to live participant.
- ring_in_complete
Ring-in interaction completed.
- moderation_override
Moderator override applied to a stream or interaction.
Vendor + Mary lifecycle
15 eventsVendor signup through live commerce — Mary compliance shepherd's decisions plus fifteen-step storefront lifecycle from intent capture through transaction observation.
- mary_decision
Mary compliance shepherd renders an approve / hold / reject decision.
- vendor_signup
Vendor account creation.
- vendor_tos_accepted
Vendor accepts terms of service.
- vendor_event
Generic vendor lifecycle action with structured action field.
- sms_sent
Outbound SMS dispatched (magic-link or notification).
- vendor_slug_provisioned
Vendor subdomain slug provisioned.
- vendor_intent_captured
Vendor onboarding intent captured.
- vendor_coa_validated
Certificate-of-analysis document validated.
- vendor_license_validated
Vendor state-license record validated.
- vendor_mary_approved
Vendor approved by Mary compliance shepherd.
- vendor_storefront_generated
AI-generated vendor storefront configuration emitted.
- vendor_product_uploaded
Vendor product record uploaded.
- vendor_product_batch_published
Vendor product batch published to the catalog.
- vendor_gateway_connected
Vendor connects a payment gateway.
- vendor_transaction_observed
Vendor transaction observed for audit-permanence record.
Counterparty intelligence + monitoring
8 eventsCounter-party dossier, surveillance, monitoring baseline + delta + continuous reports, registry expansion, collusion detection, agent discovery — the audit surface above bilateral trade and agent-population observation.
- counterparty_dossier_report
Counter-party dossier report emitted.
- surveillance_report
Surveillance agent observation emitted.
- monitoring_baseline_registered
Continuous-monitoring baseline registered.
- monitoring_delta_detected
Delta from continuous-monitoring baseline detected.
- continuous_monitoring_report
Continuous-monitoring periodic report emitted.
- registry_expansion_report
Registry-discovery expansion report emitted.
- collusion_report
Collusion-detection agent report emitted.
- agent_discovery_observed
Agent-discovery observation against a public registry.
Cryptography + key lifecycle
9 eventsClassical and post-quantum signature verification, key revocation, key wipe, key scope, data-encryption-key issuance and rotation, AES-256-GCM data encryption / decryption with court-grade receipts (Knox Cipher Bridge B1).
- crypto_signature_verified
Classical or post-quantum detached signature verified and anchored.
- pqc_kem_encapsulated
Post-quantum key encapsulation operation anchored (FIPS 203 ML-KEM).
- key_revoked
Cryptographic key revoked.
- key_wipe_signaled
Cryptographic key wipe signaled to operator surface.
- key_scope_revoked
Specific scope of a cryptographic key revoked.
- knox_dek_issued
Knox data-encryption key issued.
- knox_key_rotated
Knox key rotated under scheduled or triggered policy.
- data_encrypted
Data-encryption operation anchored under AES-256-GCM.
- data_decrypted
Data-decryption operation anchored with court-grade receipt.
Attestation + boot integrity
3 eventsGeneric attestation surface, artifact seal under Bonis Attestation Protocol v1, measured-boot verification.
- attestation
Generic attestation record.
- artifact_sealed
Artifact sealed under Bonis Attestation Protocol v1.
- measured_boot_verified
Measured-boot integrity verification anchored.
Operations + inbound surface
7 eventsContact form receipt, licensee discovery and claim flows, fast-lane request, agent-run start / complete / failed lifecycle.
- contact_received
Inbound contact-form submission anchored.
- licensee_discovered
Licensee record discovered from a public registry.
- licensee_claimed
Licensee record claimed by the licensee.
- fast_lane_request
Enterprise fast-lane request anchored.
- agent_run_start
Knox agent run started.
- agent_run_complete
Knox agent run completed.
- agent_run_failed
Knox agent run failed.
The 47 explicit AAM-theater events.
These event types ship under explicit AAM theaters. Each lane has its own positioning page (linked at the bottom of this section) and its own per-event-type emit-path documentation for operators integrating Knox under their own agent surfaces.
AAM · Memory lane
6 eventsAudit-permanence over agent persistent memory — write, read, edit, redact, export, policy change. Pairs with the Anthropic memory beta surface and any agent-memory backend.
- agent_memory_write
Agent persistent-memory write.
- agent_memory_read
Agent persistent-memory read.
- agent_memory_edit
Agent persistent-memory edit.
- agent_memory_redact
Agent persistent-memory redaction.
- agent_memory_export
Agent persistent-memory export.
- agent_memory_policy_change
Agent persistent-memory policy change.
AAM · Transactions lane
6 eventsAgent commerce commitments under any bilateral protocol — offer, acceptance, settlement, dispute, reversal, policy change. Aligned with the Anthropic Project Deal use-case shape.
- agent_transaction_offer
Agent transaction offer.
- agent_transaction_acceptance
Agent transaction acceptance.
- agent_transaction_settlement
Agent transaction settlement.
- agent_transaction_dispute
Agent transaction dispute opened.
- agent_transaction_reversal
Agent transaction reversed.
- agent_transaction_policy_change
Agent transaction policy change.
AAM · Agent authority lifecycle
3 eventsAgent authority + key + policy revocation events under AITH-aligned identity primitives. Used when an agent's signing key, scope, or policy must be revoked with audit-permanence.
- agent_authority_revoked
Agent authority revoked.
- agent_key_rotation
Agent signing key rotated.
- agent_policy_revocation
Agent policy revoked.
AAM · Federal-compliance reporting
5 eventsGSAR 552.239-7001 Basic Safeguarding of AI Systems mapping — data-deletion certification, security incident reporting, government data access notice, material change notice.
- data_deletion_certified
Data-deletion certification record.
- security_incident_reported
Security incident reported (72-hour federal reporting clock).
- security_incident_status
Security incident status update.
- gov_data_access
Government data access record.
- material_change_notice
Material change notice to a federal counterparty.
AAM · Automotive theater
6 eventsVehicle agent audit — driver-vs-AI evidence layer. Handover, intervention, perception event, driving decision, policy change, attestation. Vendor-neutral chain-of-control log for AI driving assistance.
- agent_driving_handover
Driver-AI handover event (either direction).
- agent_driving_intervention
Driver intervention against AI control.
- agent_driving_perception
AI perception event recorded.
- agent_driving_decision
AI driving decision recorded.
- agent_driving_policy_change
AI driving policy change deployed.
- agent_driving_attestation
AI driving subsystem attestation.
AAM · Model Context Protocol theater
6 eventsTool-call records under the Model Context Protocol — tool call, tool response, resource fetch, prompt invocation, server attestation, policy change. Audit-permanence above any MCP server or client.
- agent_mcp_tool_call
Agent invokes an MCP tool.
- agent_mcp_tool_response
MCP tool returns a response to the agent.
- agent_mcp_resource_fetch
Agent fetches a resource from an MCP server.
- agent_mcp_prompt_invocation
Agent invokes a prompt template from an MCP server.
- agent_mcp_server_attestation
MCP server attestation recorded.
- agent_mcp_policy_change
MCP-side policy change recorded.
Bonis Site Operations Bureau (BSR)
1 eventBureau audit-receipt anchors. Each BSR sweep result — reliability, truth, stealth, Coachbuilt, SEO, content balance — produces a single audit-receipt event.
- bsr_receipt_anchored
Site Operations Bureau audit receipt anchored.
AAM · Payments theater
5 eventsPayment-gateway runtime audit-permanence — code fingerprint at execution moment, input commitment, output commitment, agent attestation, side-effect record. Distinct from PCI-DSS configuration audit, SRI static-script integrity, and statistical fraud detection.
- gateway_code_fingerprint
Gateway-side code fingerprint at execution moment.
- gateway_input_commitment
Gateway-side input commitment.
- gateway_output_commitment
Gateway-side output commitment.
- gateway_agent_attestation
Gateway agent attestation.
- gateway_side_effect_record
Gateway-side side-effect record.
AAM · Spatial Evidence theater
1 eventKnox-anchored facility scene captures — operator captures spatial scene of own facility via commodity capture apps, uploads scene file, Knox anchors capture file SHA-256 plus operator attestation plus capture metadata.
- spatial_evidence_anchored
Spatial-evidence scene capture anchored.
AAM · Marketplace creation
3 eventsOperator-face marketplace creation events — vendor product creation, certificate-of-analysis upload, order placement. Each event carries a structured payload commitment hash so a buyer, an operator, or a regulator can verify the event happened at the recorded time without reading the underlying record.
- vendor_product_created
Vendor creates a marketplace product listing.
- vendor_coa_uploaded
Vendor uploads a product certificate-of-analysis.
- order_placed
Buyer places an order against a vendor product.
AAM · Multi-vendor cross-validation
5 eventsFindings-level cross-validation across independent foundation models — Anthropic Claude, OpenAI GPT-5.5, and xAI Grok. Each call emits a vendor receipt with model name, content commitment hash, and latency. Findings cross-checks emit either a consensus anchor or a divergence anchor based on lexical agreement between the primary and shadow vendors. Shadow vendors are not trained on Bonis doctrine; their independent non-conformity is the basis of the cross-check, not a single-vendor self-review.
- vendor_call_attempted
Pre-call receipt for any vendor inference (vendor name, model, correlation id).
- vendor_call_succeeded
Post-call receipt with content commitment hash, latency, and token usage.
- vendor_call_failed
Vendor inference failure receipt with error message.
- multi_model_consensus_anchored
Cross-check anchor when shadow vendors converge with the primary above the consensus threshold.
- divergence_detected
Cross-check anchor when any shadow vendor falls below the consensus threshold against the primary.
Each AAM lane has a dedicated public page.
For deeper context on a specific lane, the theater pages below carry positioning, regulatory mapping, and worked examples.
Agent memory
Audit-permanence for agent persistent memory. Knox + Anthropic memory beta surface.
Agent transactions
Bilateral agent commerce commitments. Aligned with the Anthropic Project Deal use-case shape.
Automotive AI
Driver-vs-AI evidence layer. Vendor-neutral chain-of-control log for AI driving assistance.
Automotive regulatory
NHTSA + NTSB + EU R155/R156 + state-AG mapping for AI driving evidence.
Model Context Protocol
Tool-call audit-permanence above any MCP server or client.
Payments runtime
Per-execution gateway runtime fingerprinting. Distinct from PCI-DSS, SRI, and statistical fraud detection.
Payments regulatory
PCI-DSS / FTC / state-AG / GDPR / NIS2 / DORA mapping for payment-gateway audit-permanence.
Cannabis vertical
Federal-face positioning for cannabis MSO / regulator / court audience.
GSAR 552.239-7001
Federal AI safeguarding clause to Knox primitive mapping.
AITH alignment
Dated Formal Alignment Statement with AITH academic protocol (arXiv:2604.07695).
Control planes
Four-layer agent stack and the operational seam where AAM composes above any control plane.
Three-layer architecture
Cross-layer map of AAM, AI Production Discipline, and Continuity & Adversarial Resilience.
Common questions, answered.
What is the Knox event taxonomy?
The Knox event taxonomy is the canonical list of event types Bonis Systems anchors under Knox. Each event type names a specific agent or system action that produces an audit-permanence record. As of the publication date, the taxonomy covers 98 distinct event types spanning the foundation TerraVault rail (live commerce, vendor lifecycle, counterparty intelligence, cryptographic operations, attestation, operations) and the explicit AAM lanes (memory, transactions, agent authority lifecycle, federal-compliance reporting, automotive AI, Model Context Protocol, Bonis Site Operations Bureau, payments runtime, spatial evidence, marketplace creation, and multi-vendor cross-validation).
Where does the count come from?
The canonical source is src/lib/knox-anchor.ts in the Bonis Systems source tree — specifically, the KnoxEventType union type. The public mirror at /bonis/agent-feed.json carries the same list as a JSON array. A taxonomy-lint script (scripts/taxonomy-lint.mjs) re-counts both surfaces and fails on drift. Any external party can reproduce the count by fetching /bonis/agent-feed.json and counting knoxEventTaxonomy.types[].
Is the taxonomy fixed?
The taxonomy grows monotonically as new theaters ship. New event types are added; existing types are not renamed or repurposed. Every taxonomy expansion is itself anchored as a Knox event under bsr_receipt_anchored, so the lineage from any prior count to the current count is reconstructable from the chain. Court-grade verification of an event type that was canonical at time T does not depend on whether the taxonomy has expanded since.
What does an event identifier guarantee?
An event identifier names the kind of action being recorded. The audit-permanence guarantees — sequence ordering, previous-hash linkage, payload hash, hourly Merkle aggregation, and OpenTimestamps Bitcoin anchor — apply uniformly to every event regardless of identifier. The identifier disambiguates the action class for downstream consumers (regulators, courts, insurance carriers, acquirers, internal auditors) reading the chain. The identifier does not authorize, authenticate, or execute the action.
Why list the foundation taxonomy alongside the AAM lanes?
The foundation events were added as Bonis Systems built TerraVault, the core audit primitive, and the cryptographic key lifecycle before the AAM category was named in late April 2026. They are part of the same canonical taxonomy and share the same chain. Listing them on this page documents what Bonis was already doing under audit-permanence before AAM became the explicit category vocabulary. Operators evaluating AAM should know the full surface area, not only the post-naming lanes.
Are payload schemas published per event type?
Per-event payload schemas are part of the operator-facing emit-path documentation, not this public reference. This page lists identifiers and audit-permanence guarantees — the externally-citable layer. Operators integrating Knox under their own events receive the per-event payload schema as part of integration onboarding. The public verify endpoint accepts any anchor identifier or canonical commitment hash regardless of payload shape.
How do regulators or courts cite a Knox event in a filing?
By the canonical anchor identifier (sequence + chain link) and the OpenTimestamps proof for the hourly Merkle root that aggregates the event. The event identifier (for example, agent_driving_intervention) names the action class for the reader; the chain link and OpenTimestamps proof establish the record was committed at the recorded time. Both elements together establish the FRE 902(13)/(14) architectural shape — self-authenticating structure of a regularly conducted electronic activity, plus self-authenticating data copied from an electronic device.
What is the relationship between this taxonomy and the AITH academic protocol?
The AITH academic protocol (arXiv:2604.07695) specifies cryptographic primitives for agent-to-agent identity and message integrity, including ML-DSA-87 and SLH-DSA. Knox Layer-4 post-quantum signatures shipped on 2026-04-24 use the same NIST FIPS 204 / 205 parameter sets. The Knox event taxonomy carries those signatures as part of the canonical anchor row — every event type listed here can be signed under AITH-compatible primitives. The taxonomy and AITH compose; the taxonomy is the action vocabulary, AITH is one of the cryptographic-identity layers that signs each anchor.
Is the taxonomy proprietary?
The list of identifiers is public on this page and at /bonis/agent-feed.json. The implementation that produces, anchors, verifies, and chains records under those identifiers is the Bonis Systems source tree. Operators who instrument their own emit path under canonical identifiers and anchor through the public Knox endpoints participate in the same chain. The vocabulary is open for citation, alignment, and reference. Knox is the audit primitive; AAM is the category. The taxonomy is the schema of action types under both.
The taxonomy grows; this page is the snapshot at the publication date.
The canonical taxonomy is monotonic. New event types expand the list; existing types are not renamed or repurposed. The number on this page (98) is the count as of 2026-04-28. Subsequent expansions are published in the same canonical source and mirrored at /bonis/agent-feed.json. Court or regulatory citations should reference both the event identifier and the anchor sequence; verification does not depend on whether the taxonomy has expanded since.
USPTO provisional applications, inventor of record Jonis Aaron Fields: 64/038,359 (Knox · 2026-04-13), 64/012,440 (TerraVault · 2026-03-21), 64/036,498 (TrustAI · 2026-04-11), 64/002,221 (HealthAgent · 2026-03-11), 64/013,240 (DealMatcher · 2026-03-22). Provisionals are priority-date footnotes; the operating moat is shipping code, public anchors, and open-standard alignment. Bonis Systems LLC · UEI R2BPJDC5CBA3 · CAGE 1TSP2.