The Knox event taxonomy.
144 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.
- 144 canonical event types. 54 foundation events (TerraVault rail, cryptography, operations) plus 90 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 144 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 54 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
18 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.
- mary_metrc_sweep_anchored
Mary-METRC daily reconciliation sweep draft anchored with reconciler digest and report hashes.
- mary_metrc_sweep_reviewed
Vendor review determination recorded for a Mary-METRC sweep.
- mary_metrc_sweep_all_completed
Scheduled all-vendor Mary-METRC sweep run completed (counts of attempted / succeeded / failed).
- 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 Bitcoin-anchored tamper-evident 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 Bitcoin-anchored, tamper-evident 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 90 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 any agent-memory backend that emits structured memory-event records.
- 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 bilateral agent-commerce protocol shapes generally.
- 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. Each call emits a vendor-anonymous receipt with 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 peer models. Peer models are independently hosted and not trained on Bonis doctrine; their non-conformity is the basis of the cross-check, not a single-vendor self-review. Vendor selection is per-deployment and substrate-opaque to the customer.
- 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 peer models converge with the primary above the consensus threshold.
- divergence_detected
Cross-check anchor when any peer model falls below the consensus threshold against the primary.
AAM · Automotive · ALPR sub-theater
5 eventsAI-pointed-at-the-car audit-permanence — automated license-plate readers, predictive-policing systems, geofence-warrant decisions, facial-rec at protests. The vendor controls the only audit log today; correction paths across multi-agency networks fail. Knox is the vendor-neutral primitive layer: assertion-at-emission anchors, hot-list dispatch cross-validation receipts, driver-side stop evidence, multi-agency resolution-attempt records, and the eventual data-correction propagation event. Defensive-Only doctrine binding — Knox never reads camera feeds, never attacks vendors, never provides counter-surveillance tooling. Both citizen-side audit and procurement-side audit benefit from the same primitive.
- alpr_plate_observed_assertion
Anchor emitted when an ALPR system commits an observation (plate text, vehicle composite features, confidence) with chain-of-evidence pointer to the originating sensor and authority record.
- alpr_hot_list_match_emitted
Anchor emitted when a vendor hot-list match propagates toward an officer-facing alert; carries a cross-validation reference to the originating authority record (warrant, BOLO, data-entry source) so downstream verification has a chain.
- alpr_driver_evidence_anchored
Driver-side anchor for dashcam, phone audio, or stop-record commitment hash so the driver has FRE 902(13)/(14)-admissible chain-of-control evidence across multiple stops.
- alpr_resolution_attempt_recorded
Anchor emitted on every contact attempt with court / dispatch / vendor / agency to clear an alert known to be wrong; pattern-of-attempts becomes provable, not just one-off.
- alpr_data_correction_propagated
Anchor emitted when (and IF) the multi-agency network finally propagates a correction from the originating authority record outward to all caching agencies.
AAM · Automotive · In-cab biometric sub-theater
5 eventsAI-pointed-at-the-driver audit-permanence — in-cab cameras, voice and lip-reading inference, biometric-feature database lookups, occupant consent state changes, and post-capture disclosure events. The vehicle manufacturer is currently the sole custodian of the only audit log of what its in-cab sensors captured and what its inference stack did with the captured data. Knox is the vendor-neutral primitive layer for capture-event observation receipts, audio-inference receipts, downstream lookup observation receipts, occupant consent state transitions, and disclosure-event receipts. Defensive-Only doctrine binding — Knox never operates cameras or microphones, never decrypts vendor inference pipelines, never attacks vendors. Both occupant-side audit (driver, passenger, fleet operator) and procurement-side audit (regulator, court, insurer) benefit from the same primitive. Pairs with /aam/automotive — the federal frame for the broader Automotive theater.
- vehicle_biometric_capture_observed
Anchor emitted when an in-cab biometric capture event is observed (camera frame committed to inference, audio buffer committed to inference, fingerprint or eye-state read). Carries capture modality, time window, and a feature-hash commitment so the captured data itself is never anchored, only the fact of capture.
- vehicle_audio_inference_observed
Anchor emitted when an in-cab audio inference completes (lip-reading, speech-to-text, speaker classification, emotion classification). Carries inference type, confidence, and an opaque inference-output commitment so the inference text is never anchored, only the fact and confidence of inference.
- vehicle_database_lookup_observed
Anchor emitted when a captured biometric feature is matched against a downstream database (manufacturer ID, third-party watchlist, fleet roster). Carries database identifier class, lookup outcome class, and a query-hash commitment so the queried features are never anchored, only the fact of lookup and the outcome class.
- cab_occupant_consent_state
Anchor emitted when an occupant consent state changes (granted, withdrawn, scope-narrowed, scope-expanded). Carries the prior state, the new state, the scope delta, and the actor that initiated the change so the consent-record-trail is independently reconstructable from the chain.
- vehicle_disclosure_event
Anchor emitted when captured biometric data, inference output, or downstream lookup result is disclosed to a third party (manufacturer cloud, regulator, law-enforcement subpoena, civil discovery, insurance carrier). Carries disclosure recipient class, legal basis class, and a disclosure-bundle commitment so the disclosure trail is independently reconstructable from the chain.
AAM · Knox Forensics — network-marker AI-attribution lane
2 eventsDefensive-only AI-attribution audit-permanence. Phase 1.0 rule-based classifier against a publicly-citable LLM-SDK JA3/JA4 fingerprint registry; trained ML discriminator and Layers 2-4 (content / behavioral / cryptographic) deferred. Registry-superseded events are designed-in for legal durability — invalidating a registry entry makes every prior bundle citing it discoverable by registry-entry-id reverse-lookup.
- knox_forensics_network_classified
Knox Forensics network-marker AI-attribution result anchored (Layer 1 rule-based classification against the publicly-citable LLM-SDK JA3/JA4 fingerprint registry; carries classifier version, registry entry id, confidence class, and an opaque feature-hash commitment).
- knox_forensics_registry_superseded
Knox Forensics registry entry superseded; prior bundles citing the entry become discoverable by registry-entry-id reverse-lookup so legal durability of historical attributions is preserved.
TerraVault · Marketplace activity statement
1 eventVendor-scoped Knox-anchored attestation of a periodic order-flow report under the no-money-touch posture. TerraVault is not the third-party settlement organization for these flows; the statement is an informational order-flow record, not a 1099-K. Each statement carries the SHA-256 of its canonical payload plus the anchor sequence for verification.
- marketplace_activity_statement_generated
Vendor-scoped marketplace activity statement generated and anchored — informational order-flow record under the TerraVault no-money-touch posture. Carries canonical-payload SHA-256, anchor sequence, and vendor identifier; never carries customer money flow.
AAM · Knox API-key usage-audit
1 eventKnox admin audit of a per-key usage record (anchor count, first/last anchor timestamps, breakdown by event type) under the Info-Capture-Required doctrine. Used to ground doctrine pivots in measurable, third-party-verifiable evidence.
- knox_api_key_usage_audit_anchored
Per-key usage-audit anchored — anchor count, first and last anchor timestamps, and per-event-type breakdown for a Knox API key over an audit window. Used to ground doctrine pivots in measurable, third-party-verifiable evidence.
Bonis Journal — long-form publication anchor
1 eventLong-form Bonis Journal publication anchor. SHA-256 of canonical Markdown source plus slug plus datePublished plus article URL. Makes the article body tamper-evident — any post-publish edit changes the hash; third parties verify byte-for-byte against the source-of-record.
- bonis_journal_article_published
Long-form Bonis Journal article published and anchored — canonical Markdown SHA-256, slug, datePublished, and article URL. Subsequent anchors of the same slug chain via previousHash so the article's edit history is independently reconstructable.
Bank-side compliance · BSA attestation
6 eventsBank Secrecy Act compliance attestation events for the cannabis-banking vertical — KYC periodic reviews, Enhanced Due Diligence reviews, alert dispositions, SAR drafts, SAR filings, and continuing-activity SAR filings. Names selected per FFIEC BSA/AML Examination Manual examiner-vocabulary precision pass. The bank's BSA Officer makes every decision; Knox anchors after-the-fact tamper-evident receipts. Each event carries canonical-JSON payload SHA-256, previous-event hash, and OpenTimestamps Bitcoin attestation.
- bsa_kyc_periodic_review_completed
Periodic Customer Identification Program review for an existing customer relationship completed and anchored — review period covered, risk tier, beneficial-owner refresh status, exception findings if any, and disposition. Cadence varies by risk tier per the bank's BSA program.
- bsa_edd_periodic_review_completed
Periodic Enhanced Due Diligence review for a higher-risk customer relationship completed and anchored — risk-rationale, transaction-pattern review findings, source-of-funds re-verification, ongoing monitoring posture, and disposition.
- bsa_alert_disposition_recorded
Suspicious-activity-monitoring alert disposition recorded — alert source (system or human-generated), alert criteria triggered, investigation findings, disposition (cleared / escalated / SAR-routed), and reviewer identifier.
- bsa_sar_drafted
Suspicious Activity Report drafted (pre-filing) and anchored — narrative draft, suspicious-activity category, subjects, transactions, and assigned filer. Anchoring the draft creates a tamper-evident record of the pre-review state.
- bsa_sar_filed
Suspicious Activity Report filed with FinCEN and anchored — BSA E-Filing acknowledgement identifier, filed narrative SHA-256, filing timestamp, and assigned analyst. Independent of the BSA E-Filing system; this is the bank-side record-of-filing.
- bsa_sar_continuing_activity_filed
Continuing-activity SAR filing for ongoing patterns recorded. Per FinCEN guidance, continuing-activity SARs are required at periodic intervals for ongoing relationships under suspicion. Anchored payload includes BSA E-Filing identifier, prior-SAR linkage, narrative-update SHA-256, and review-period covered.
Bank-side compliance · Examiner-facing audit pack
2 eventsAudit-pack export events for examiner consumption. Audit-pack v1 shipped 2026-05-11 — bundle generation, manifest SHA-256, structured event ledger with chain-integrity proof linking each event to its predecessor, FRE 902(13)/(14) certificate, and verification-instructions step-walking the examiner through the canonical Knox chain-anchor OpenTimestamps aggregation path are all live today. The bundle's per-event Merkle inclusion proof and per-event raw .ots proof retrieval endpoints are scheduled for v1.1. Examiner-side hash recomputation against signed-records, manifest, and bundle anchor is local-only; chain-block confirmation goes through the public Knox verify endpoint.
- bonis_audit_pack_generated
Examiner-facing audit pack generated for a time-bounded chain segment. v1 shipped payload (2026-05-11): structured event ledger with chain-integrity proof linking each event to its predecessor, FRE 902(13)/(14) certificate, manifest SHA-256, and verification-instructions step-walking the examiner through the canonical Knox chain-anchor OpenTimestamps verification path. Per-event Merkle inclusion proof and per-event raw .ots proof retrieval are scheduled for v1.1. Generation event records segment bounds, event-count, bundle manifest SHA-256, and bundle ZIP SHA-256.
- bonis_examiner_audit_pack_exported
Audit pack exported for examiner consumption — export channel, recipient identifier, pack SHA-256, redaction-policy applied at export, and exporter identifier. Bank applies redaction policy at the post; only fields the bank chooses to surface leave the bank's environment.
Bank-side compliance · Board / audit-committee substrate
2 eventsBSA program-review and audit-committee meeting attestation events. Periodic BSA program reviews and audit-committee meeting anchors are recorded as Knox events. The bank's audit committee chair and BSA Officer co-author the payload schema; Bonis does not impose vocabulary. Captures the program-level oversight cycle as a tamper-evident record alongside the line-level BSA events.
- bsa_program_review_completed
Periodic BSA / AML compliance program review completed and anchored — review period covered, controls reviewed, exceptions noted, remediation status, and board-meeting minutes link or hash. Cadence configured to the bank's audit calendar.
- bsa_audit_committee_meeting_anchored
BSA-related audit-committee meeting anchored — meeting date, BSA-program-review item discussed, decisions reached, and minutes link or hash. Captures the program-level oversight cycle alongside the program-review event itself.
Bank-side compliance · IT/InfoSec controls substrate
4 eventsBank-side IT/InfoSec controls evidence anchored as Knox events — controls evidence recordings, periodic access reviews, incident response actions, and change management approvals. Separate event-type registry namespaced under the bank's IT/InfoSec controls vocabulary, co-authored with the bank's CISO. SOC 2 Type II auditor verifies cryptographic integrity instead of taking the word of a screenshot in a binder.
- bonis_controls_evidence_recorded
Bank-side IT/InfoSec controls evidence recorded — controls scope, evidence-type (policy attestation / procedure execution / system-state snapshot), evidence SHA-256 or link, and recording analyst. Vocabulary namespaced separately from BSA events.
- bonis_access_review_completed
Periodic access review completed for a defined system or role population — review-cycle window, populations reviewed, access-changes proposed, approver, and disposition. SOC 2 Common Criteria CC6 evidence.
- bonis_incident_response_logged
Information-security incident response action logged — incident identifier, action-type (detection / containment / eradication / recovery / post-incident), action timestamp, responder, and outcome. SOC 2 Common Criteria CC7 evidence.
- bonis_change_management_approved
Change-management change approved — change identifier, change-scope, approver, approval timestamp, risk-assessment outcome, and rollback plan link or hash. SOC 2 Common Criteria CC8 evidence.
Cannabis-related-business onboarding · Mary-shepherded portal
6 eventsMary-shepherded cannabis-related-business onboarding events. Applicant self-serves document gathering (license, EIN, articles, lease, certificate of insurance, beneficial-owner KYC); Mary runs OFAC pre-screen against the live OFAC sanctions list (shipped today on TerraVault and ports onto the bank-CRB flow); state-license-status verification and adverse-media screen are not shipped today. Knox anchors every applicant step. The bank's CRB Onboarding Officer makes the onboarding decision; Mary surfaces ambiguities to the officer's queue with the ambiguity flagged.
- crb_onboarding_initiated
Cannabis-related-business onboarding session initiated — applicant identifier, applicant entity-type, prospective bank relationship, and Mary-session identifier.
- crb_document_received
Onboarding document received from CRB applicant — document-type (state license / EIN / articles / lease / COI / beneficial-owner KYC / financial statement / business plan), document SHA-256, applicant identifier, and timestamp.
- crb_document_screened_ofac_clear
OFAC sanctions-list pre-screen completed for an applicant subject (entity, beneficial owner, or counterparty) — subject identifier, OFAC SDN list snapshot date, screening-engine version, screening result (clear / flagged-for-officer-review), and Mary-session identifier.
- crb_state_license_verified
State cannabis-license verification completed via state cannabis-control-commission API or public license-lookup — license number, license type, issuing state, status (active / probationary / expired / revoked), license period covered, and verification source.
- crb_beneficial_owner_kyc_completed
Beneficial-owner KYC completed for an applicant beneficial owner (per FinCEN beneficial-ownership rule) — owner identifier, identification documents collected, OFAC pre-screen result, and Mary-session identifier.
- crb_onboarding_packaged_for_bank
Onboarding file packaged and handed off to the bank's CRB Onboarding Officer for intake review — applicant identifier, document-checklist completion status, screening summary, ambiguities flagged for human review, package SHA-256, and bank-officer recipient. Officer makes the onboarding decision; Mary surfaces; officer decides.
Knox owner-held key custody
8 eventsOwner-held key custody lifecycle events. TerraVault canonical; cross-rail mirror to sibling Bonis rails is a separate component. Schemas describe provisioning, rotation, per-operation ephemeral key steps, anchoring of encrypted decision payloads, the owner-side decrypt-request flow, and anomaly detection. Schemas lock the chain-shape contract; the implementation modules that produce these events are separate components and library-agnostic at the chain-shape layer. Default-deny on the public verify endpoint — owner key custody is operational, not transparency-class; per-event payloads do not surface through the no-auth verify path.
- knox_owner_envelope_provisioned
Owner-held key material provisioned and anchored — owner identifier (opaque ref), key shape code (hardware HSM / hardware FIDO2 / passphrase Argon2id / hybrid passphrase + hardware), record version, provisioning attestation hash, anchored at.
- knox_owner_envelope_rotated
Owner-held key material rotated — owner identifier (opaque ref), previous record version, new record version (strictly greater than previous, monotonic per owner), rotation reason code (scheduled / compromise-suspected / recovery-completed / regulatory-required / other-documented), anchored at.
- knox_session_key_ratchet_step
Per-operation ephemeral key step anchored — operation identifier (opaque ref), party A ephemeral pubkey hash, party B ephemeral pubkey hash (must differ from party A), step sequence, anchored at.
- knox_decision_envelope_anchored
Decision payload encrypted under owner-held key material and chain-anchored — operation identifier (opaque ref), decision-emitting module identifier (opaque ref), payload hash, encrypted-session-key hash, operation signature hash, anchored at.
- knox_owner_decrypt_requested
Owner-side decrypt request initiated for a historical operation — operation identifier (opaque ref), owner identifier (opaque ref), decrypt-request identifier, anchored at.
- knox_owner_decrypt_completed
Owner-side decrypt operation completed successfully — operation identifier (opaque ref), decrypt-request identifier, decrypted at.
- knox_owner_decrypt_failed
Owner-side decrypt operation failed — operation identifier (opaque ref), decrypt-request identifier, failure reason code (wrong-owner-key / tampered-payload / chain-anchor-mismatch / record-version-mismatch / other-documented), failed at.
- knox_dual_agent_compromise_suspected
Anomaly detection signaled suspected compromise of independent signing parties — anomaly identifier (opaque ref), detection signal code (signature-quorum-anomaly / unexpected-step-sequence-pattern / out-of-band-attestation-drift / other-documented), severity band (low / medium / high / critical), anchored at.
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 + any memory-beta-capable agent runtime.
Agent transactions
Bilateral agent commerce commitments. Aligned with bilateral agent-commerce protocol shapes generally.
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 this page render, the taxonomy covers 144 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, automotive ALPR sub-theater, automotive in-cab biometric sub-theater, Model Context Protocol, Bonis Site Operations Bureau, payments runtime, spatial evidence, marketplace creation, multi-vendor cross-validation, Knox Forensics network-marker AI-attribution, marketplace activity statement, Knox API-key usage-audit, and Bonis Journal long-form publication anchors).
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. Self-authenticating 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 rendered from the canonical source at build time.
The canonical taxonomy is monotonic. New event types expand the list; existing types are not renamed or repurposed. The number on this page (144) is derived from src/lib/knox-event-types.ts at build time and reflects the canonical count as of 2026-05-14. 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.