Bonis Systems · AAM · Event taxonomy · 2026-04-28

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.

144 canonical typesSource-of-truth: knox-anchor.tsPublic mirror: agent-feed.jsonBitcoin-anchored via OpenTimestampsPost-quantum signatures availableDefensive only

TL;DR

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.

Provenance

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.

01

Fetch the public mirror

GET /bonis/agent-feed.json and read the knoxEventTaxonomy.types[] array. The array length equals the canonical count.

02

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.

03

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.

04

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.


Foundation taxonomy

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 events

TerraVault 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 events

Vendor 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 events

Counter-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 events

Classical 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 events

Generic 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 events

Contact 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.


AAM lanes

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 events

Audit-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 events

Agent 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 events

Agent 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 events

GSAR 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 events

Vehicle 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 events

Tool-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 event

Bureau 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 events

Payment-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 event

Knox-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 events

Operator-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 events

Findings-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 events

AI-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 events

AI-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 events

Defensive-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 event

Vendor-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 event

Knox 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 event

Long-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 events

Bank 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 events

Audit-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 events

BSA 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 events

Bank-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 events

Mary-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 events

Owner-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.



FAQ

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.


Disclosure

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.

Defensive onlySource-verifiablePublic-information referencesPriority-date provisionals