Home · Resources · Glossary
Resources · Glossary

The AskLedger glossary, in plain English.

AI accountability comes with its own vocabulary: receipts, assurance levels, hash chains, canonicalization. Here's what each term actually means, translated so a smart non-technical reader gets it in a sentence or two. We're a design-partner-stage company, so these describe how the system is built to work, not claims of scale.

A C E F H I M O R S T V
A
Agent accountability
Being able to say, for an autonomous AI agent, who owns it, what it was allowed to do, what it actually did, and what it cost, with a signed record for each step. Every production agent has a named human owner and pre-approved limits, and its attempted and executed actions are recorded separately so a blocked action still leaves a trail.
AI Activity Graph
A connected map that joins the scattered pieces of AI usage (the person or agent, the app, the model, the data touched, the policy in force, the cost, and the outcome) into one queryable history. It turns disconnected logs into a picture of who did what, under what authority, at what cost, with which result.
AI Activity Ledger
AskLedger's core idea: an independent system of record for enterprise AI. Rather than another dashboard, it's a neutral layer that records who or what used AI, what happened, what it cost, and whether the organization can prove that record later to an auditor, regulator or customer.
Assurance levels (L0–L3)
A four-step scale describing how strongly a receipt's origin can be trusted. Higher isn't always better; the goal is matching the level of proof to the stakes of the record.
  • L0 · Declared: data supplied without any cryptographic identity. Fine for early discovery and imported legacy records, but it's a claim, not proof.
  • L1 · Signed: a known application signs the event, so you can tell which app produced it. The standard level for everyday application accountability.
  • L2 · Attested: the signer is bound to a verified workload identity or a hardware-backed key, raising confidence for regulated production systems and agents.
  • L3 · Anchored: a signed checkpoint is independently timestamped or logged outside AskLedger, for high-dispute, legal or cross-organization evidence.
C
Canonicalization (RFC 8785)
A fixed rule for writing a record out in exactly one standard form (same field order, same formatting) before it's hashed or signed. Because everyone follows the same rule (the RFC 8785 standard), two parties can independently reproduce the identical bytes and check that nothing changed, even a re-ordered key.
Confidential receipt
A receipt that proves an event happened without exposing the sensitive content inside it. It carries hashes and references instead of raw prompts or data, so it can be verified and shared while the private material stays sealed. See also Selective disclosure.
E
Ed25519 signature
A modern, fast digital-signature method. The signer holds a secret private key and publishes a matching public key; only the private key can produce a valid signature, and anyone with the public key can check it. It's how a receipt proves "this specific signer made this record" without revealing the secret.
F
Formal verification · an adjacent, complementary approach
A method that uses mathematical proof, often with a theorem prover such as Lean, to check that an AI's output necessarily follows from a set of encoded rules: a tax code, a clinical guideline, a regulation. It answers a different question from a receipt. Formal verification argues an answer is correct against the rules; an AskLedger receipt proves what actually happened and that the record hasn't changed since. The two layers fit together: a formal proof is only as good as the human encoding of the rules and says nothing about whether the answer was really used or tampered with later, while a receipt can carry a reference or hash of that proof as evidence, so "the answer was provably correct" and "here is the tamper-evident record of it" travel together. AskLedger does not itself perform formal verification; it is the independent record such proofs can live inside.
H
Hash chain
A sequence of records where each one includes a fingerprint (hash) of the one before it, like links in a chain. Change any earlier record and every later fingerprint stops matching, so the chain makes it evident if a record was inserted, removed or altered after the fact.
HSM / KMS signing
Signing receipts using keys held inside dedicated, hardened key-management hardware or services (an HSM or KMS) rather than in ordinary application memory. This means the private signing key never has to leave a protected boundary, raising the trust in the signature.
I
Independent verifier
An open, free tool that checks a receipt on its own (its signature, chain link and timestamp) without needing an AskLedger account or contacting our servers. Because a regulator, auditor or customer can run it themselves, the proof doesn't depend on trusting us or on us staying online.
M
MCP (Model Context Protocol)
An emerging open standard for how AI models and agents connect to tools and data sources. AskLedger is designed to capture the tool requests, policy decisions and results that flow over MCP, so agent actions taken through it become part of the accountable record.
Merkle tree / batching
A way to fold many records into a single short fingerprint by hashing them together in a tree. It lets AskLedger commit to a whole batch of receipts at once and later prove that one specific receipt was included in that batch: efficient evidence at scale without publishing everything.
O
Open core
AskLedger's business model: the trust layer is free and open source (the SDK, the verifier and a local usage-and-cost view, under Apache-2.0), while the enterprise platform (cross-system intelligence, discovery, workflows and support) is the paid product. The open pieces are genuinely useful on their own, not a crippled trial.
R
Receipt
A signed record of a single AI event: a model call, a tool use, or an agent action. It captures identity, what happened, cost, policy decisions and outcome, then signs the whole thing so the record can be checked later and shown not to have changed. Receipts are the atoms the ledger is built from.
RFC 3161 timestamp
A trusted "time-stamp" from an independent authority that proves a record existed no later than a certain moment. It's the standard (RFC 3161) that lets you show a receipt is not backdated, without relying on the clock of whoever created it.
S
Selective disclosure
Revealing only the parts of a receipt an auditor or customer needs to see, while keeping the rest sealed, while still allowing the disclosed parts to be verified. It's how you can prove a claim about an event without handing over the underlying prompt or sensitive data.
Shadow AI
AI tools employees use without the organization's knowledge or approval: personal chatbot accounts, unsanctioned copilots, browser extensions. It's a blind spot for cost, risk and data exposure. Discovering it relies on security and SaaS signals, and AskLedger labels how confident that discovery is rather than overclaiming.
Source confidence (verified vs. discovered)
An honest label on how the platform learned each fact. "Verified" data is cryptographically signed or provider-confirmed; "discovered" data is observed or inferred from network, billing or integration signals. Keeping the two clearly separate prevents inferred activity from being presented as if it were proven.
T
Transparency log
An append-only public log where signed checkpoints can be recorded so that the history can't be quietly rewritten. It's an optional way to anchor evidence externally, an alternative to a blockchain, used when a record needs to survive disputes across organizations.
V
Verified savings
A cost saving that has been measured and proven, not estimated. AskLedger runs a closed loop: establish a baseline, make the change, measure the result against that baseline, and publish the realized saving with its assumptions and signed evidence. That's how a saving survives a finance review instead of staying a "potential" number.
Two ways to read a fact

Verified is proven. Discovered is observed. We never blur them.

The single most important idea across this glossary is honesty about where a fact came from. A signed receipt is proof; a signal inferred from network or billing data is a lead. AskLedger is built to keep those apart, because coverage claimed as certainty is exactly how AI accountability tools lose trust.

Keep going

See the concepts in action.

The glossary describes the pieces; the rest of the site shows them working together. Try the open verifier on a real receipt, or read how a receipt is built and checked.

Try the open verifier Read the buyer FAQ