Memory Attestation: Cryptographically Proving What An Agent Knew, And When

TL;DR

When something an agent did becomes contested, the cheapest answer to "what did it know?" is a signed manifest of its context at decision time. Memory attestation produces that manifest as a first-class artifact: an enumerated list of every memory entry that was in the agent's working set at moment T, hashed individually, hashed as a set, signed by the runtime, and pinned to a trust anchor. The manifest is created at decision time, stored alongside the decision record, and reproducible on demand under audit. Without attestation, your defense against a bad outcome is your engineering team's recollection. With it, your defense is a cryptographic artifact that says exactly what was true and exactly when. This piece specifies the manifest format, the signing chain, and the operational discipline.

The Problem That Forces Attestation Into Existence

Agents make decisions. Some of those decisions get challenged. The challenge sequence is always the same. A customer says the agent told them something it did not, or the agent did something it should not have, or the agent missed something it should have caught. You go to investigate. You query the agent's memory store as it exists today. You ask, "what did this agent know on March 14th when it made the call?" And you discover that the question has no good answer.

It has no good answer because memory is alive. Since March 14th, the agent has continued to write to its memory store. The vector index has been rebuilt under a newer embedding model. The retention policy demoted some entries from hot to warm and compressed them, losing the original phrasing. A migration changed the schema. A bug got fixed that quietly altered how a class of entries was tagged. By the time you go looking, the memory state on March 14th does not exist in any reproducible form. You have a present-tense memory store and a past-tense decision, and the gap between them is unbridgeable by query alone.

The practical consequence is that your defense in the dispute becomes anecdotal. Your engineer says, "we don't think the agent had access to that data because it would have been demoted by then." You say it with a straight face. The customer's lawyer says, "prove it." You cannot. You can show what is in the memory store now. You can show your retention policies. You can show your compression logs. What you cannot show is the actual context that the actual agent actually had at the actual moment of the disputed decision. And in any sufficiently formal proceeding, the absence of that proof is treated as failure to retain it, which is treated as adverse inference, which is treated as you losing.

The deeper problem is that this is not just a litigation issue. It is an engineering issue. When an agent fails in production, your team needs to reconstruct the failure to understand it. "It hallucinated" is not a root cause; it is a symptom. The root cause is something like "the retrieval returned a stale document because the tier demotion ran early" or "the system prompt was on version 4.2 which had a known recall regression on this class of question." None of these can be diagnosed without a faithful snapshot of what the agent had in front of it. Memory attestation is what makes that snapshot a structural feature of the runtime, not a heroic recovery effort.

What Attestation Actually Is

Attestation, in this context, is the process of producing a signed, dated, integrity-verified record of an agent's memory state at a specific moment, scoped to a specific decision. It is not a backup. It is not a log. It is a discrete artifact, generated synchronously with the decision it pertains to, that can be verified against the original memory contents at any point in the future without trusting the runtime that produced it.

The artifact has three layers. The first layer is enumeration. The manifest lists every memory entry that was actually in the agent's working set at decision time: the entry identifier, the tier it was retrieved from, the embedding model and version that surfaced it, the relevance score, and the position in the assembled context. This is not the full content of the entries; it is a structured table of what was present.

The second layer is hashing. Each entry's full content (post-compression if applicable, in the exact form the agent saw it) is hashed under a cryptographic hash function, and the hash is included in the manifest. The set of entries is also hashed as a Merkle tree so the manifest commits to the entire context as a single value. This means that anyone with the original entry can independently verify that what they have is what the agent saw, by re-hashing and comparing against the manifest. It also means that any tampering with a single entry invalidates the manifest, because the leaf hash and the root hash will no longer match.

The third layer is signing. The manifest is signed by the agent runtime using a key tied to the runtime's identity, with the signature including a timestamp from a trusted clock source and a reference to the decision the manifest pertains to. The signature is verifiable against a public key that lives in the agent's identity record, which itself is anchored to the trust oracle. This means the chain of provenance runs from the manifest, through the runtime's signing key, through the agent's identity record, through the trust oracle, all the way to a value that the public can inspect. There is no link in the chain that requires trusting the operator.

When To Attest, And When Not To

The naive position is that you should attest every decision an agent ever makes. The naive position is wrong, and it is wrong for cost reasons. Attestation is not free; it adds latency, it adds storage, and it adds operational complexity. If your agent has a thousand turns per minute and you attest every one, you are creating an attestation pipeline whose throughput requirements rival the agent itself. You will then be tempted to make attestation asynchronous, which defeats the whole purpose because asynchronous attestation has a window during which memory could change before the snapshot is captured.

The right position is that you attest decisions, not turns. A turn is the granularity of agent interaction. A decision is the granularity of agent commitment: a fund transfer, a contract acceptance, a refund issuance, a customer-facing claim with material consequence, a tool call that mutates external state. These decisions are typically rare relative to total turns, often by a factor of a hundred or more. They are also exactly the events that get challenged later, because they are the events with consequences.

The operational rule we use is: anything that mutates state outside the agent's own memory, anything that produces revenue or cost, and anything that constitutes a representation made to a counterparty gets attested. Pure information retrieval turns do not. Internal reasoning turns do not. Status check turns do not. The result is an attestation rate that is one to five percent of total turn volume, which is operationally tractable, and that captures the events that actually matter for forensic and legal purposes.

There is one further refinement: pact-governed agents can have attestation requirements written into their pact. "This agent will produce an attestation for every action with a USDC value above $50." This makes the attestation policy contractual and auditable, and it lets counterparties know what they can expect to be able to verify after the fact. An agent that attests only what it wants to attest is providing a much weaker guarantee than an agent whose attestation policy is publicly committed.

Reader Artifact: The Attestation Manifest Specification

The following is the canonical structure for a Cortex-style attestation manifest. It is JSON-serializable, content-addressable, and small enough to embed in transaction records or submit as evidence in dispute resolution.

{
  "version": "attestation/v1",
  "agentId": "agt_...",
  "runtimeId": "rt_...",
  "decisionId": "dec_...",
  "decisionType": "escrow_release | tool_call | claim_to_user |...",
  "timestamp": "2026-07-18T13:00:00.123Z",
  "timestampSource": "trusted_clock_uri_or_chain_block_ref",
  "contextSetHash": "sha256:...",      // Merkle root over all entries
  "entries": [
    {
      "entryId": "mem_...",
      "tier": "hot | warm | cold",
      "sourceType": "transcript | extraction | external | system_prompt",
      "embeddingModel": "...",
      "embeddingVersion": "...",
      "retrievalScore": 0.87,
      "contextPosition": 3,
      "contentHash": "sha256:...",
      "contentBytes": 1247,
      "redactionPolicy": "none | pii_redacted | full_redacted"
    }
  ],
  "systemPromptHash": "sha256:...",
  "systemPromptVersion": "v4.7",
  "toolSchemaHash": "sha256:...",
  "modelIdentifier": "...",
  "modelVersion": "...",
  "signature": {
    "algorithm": "ed25519",
    "publicKeyRef": "did:armalo:agent:...#runtime-key-1",
    "signatureBytes": "base64:..."
  },
  "trustAnchorRef": "oracle_endpoint/agent/agt_.../identity"
}

The manifest itself is then content-addressed by hashing the entire structure. The resulting hash is the manifestId, which is what gets stored in the decision record and shared with counterparties. To verify a manifest later, a third party requests both the manifest and the underlying entries, re-hashes each entry, recomputes the Merkle root, recomputes the manifest hash, and verifies the signature against the runtime's public key as resolved through the trust oracle. If all four checks pass, the manifest is authentic and the entries are exactly what the agent saw.

The Signing Chain, And Why It Cannot Run Through The Operator

The weakest possible attestation system is one where the operator's database holds the signed manifests and the operator's key signs them. In that world, the operator can rewrite history at will, because they control both the artifact and the signing authority. Counterparties have no way to distinguish a legitimate attestation from a backdated forgery. This is the architecture you must avoid.

The correct architecture separates roles. The runtime that executes the agent holds a signing key. The signing key's public component is registered to the agent's identity record. The agent's identity record is anchored on the trust oracle, which is itself either decentralized (multi-operator quorum) or constructed such that updates to identity records are themselves signed and historical. The trust anchor is the thing that makes the signing chain meaningful: a signature that resolves through a public, append-only identity record cannot be repudiated later by the operator without the repudiation itself being a public, audit-detectable event.

The practical implementation involves three keys, not one. The runtime has a working key that signs manifests in real time; this key rotates frequently and is provisioned through an identity authority. The agent has an identity key that signs the registration of working keys; this key rotates rarely and lives in a hardware module. The trust anchor key signs identity records; this key is held by the protocol operator under multi-signature controls. A manifest is verifiable end-to-end by walking from the working key signature, to the identity key registration of that working key, to the trust anchor's signature on the identity record. Compromising any single key in this chain does not retroactively compromise prior manifests, because each level signs over a timestamp and the trust anchor publishes its history.

This is not novel cryptography. It is the same pattern used in code signing, certificate authorities, and decentralized identifier systems. What is novel is the application of it to agent memory. The reason this matters is that, in a dispute, the manifest's evidentiary value depends entirely on the signing chain being non-repudiable. An attestation that the operator could have forged is an attestation that proves nothing.

Why The Hashing Has To Be Over Exact Bytes The Agent Saw

A subtle implementation error that destroys attestation value: hashing the source content rather than the rendered content. The source content is what is in your memory store. The rendered content is what got assembled into the agent's context window after retrieval, after compression, after templating, after deduplication, after token limit truncation. The agent did not see the source. The agent saw the render. If you hash the source, you can later show that the manifest matches what is in your store, but you cannot show what the agent actually had in front of it.

The correct implementation hashes the rendered string for each entry as it was inserted into the context, exactly as the model received it, including any role tagging, position markers, and template scaffolding. This is what makes the attestation answer the question "what did the agent see" rather than "what was theoretically available to the agent." The distinction is critical in disputes, because the standard challenge is some version of "the agent did not actually have this fact at decision time even though it appears in your store today," and only render-time hashing can answer that challenge definitively.

There is a small storage overhead for retaining the rendered form, but it is bounded by the model's context window size and is in practice tiny compared to the agent's memory store as a whole. The overhead is a constant cost per attested decision, not a function of memory store size.

The Time-Stamping Problem: Why You Cannot Just Trust The Server Clock

A signature without a trustworthy timestamp is half a signature. The whole point of attestation is to prove what was true at a specific moment, and "the server's clock said this moment" is not a defensible claim if the server is the entity whose behavior is in question. The server can be misconfigured, can be compromised, or can be intentionally backdated by the operator. Any of these makes server-clock timestamps repudiable.

The correct approach is timestamping against an external authority that the operator does not control. There are three approaches in current production use, each with different trade-offs.

The first is RFC 3161 time-stamping authorities (TSAs). These are third-party services that sign timestamp tokens for arbitrary data hashes. The operator submits the manifest hash, the TSA signs (manifest_hash, current_time) with the TSA's certificate, and the operator embeds the resulting time-stamp token in the manifest. Verification involves checking the TSA's signature against its published certificate chain. This works well, scales to high volumes, and produces evidence that is widely accepted in legal proceedings. The downside is that you depend on the TSA, and TSA outages mean you cannot attest. The mitigation is multiple TSAs in parallel and graceful degradation to a slower path.

The second is anchoring against a public blockchain. The operator periodically publishes the root hash of an aggregated set of manifests as a transaction on a public chain (Bitcoin, Ethereum, or a permissioned chain with its own time-stamping properties). The chain provides a globally-observable, irreversible timestamp for the root, and individual manifests can prove their inclusion via a Merkle proof against the published root. This approach is harder to refute (chains do not retroactively change history without producing public evidence of the change) but introduces transaction cost and chain-block latency, typically minutes rather than the milliseconds a TSA achieves.

The third is a hybrid: TSA for low-latency attestation with periodic blockchain anchoring of TSA outputs as a long-term backstop. This is what most production-grade attestation systems converge to. Real-time attestations get TSA timestamps, batched root hashes get blockchain anchoring, and the verifier can check either or both depending on the strength of evidence required for the case at hand. A routine audit might verify only the TSA timestamp; a contested legal proceeding might require the blockchain anchor proof.

The wrong approach is to skip external time-stamping because the operational overhead seems excessive. It does not seem excessive when you are trying to defend a manifest in a dispute and your only evidence of when it was signed is your own database. The audience does not believe your database. Plan for that audience.

How Verifiers Actually Use Manifests In Practice

The theoretical use of attestation manifests is well-understood: someone disputes an agent's behavior, you produce the manifest, the dispute resolves. The practical use is messier and worth describing, because the architectural choices have to support the practical use, not just the theoretical one.

The most common verifier is your own engineering team during incident investigation. The customer reports a problem, your team pulls the relevant decision IDs, fetches the manifests, and uses them to reconstruct what the agent saw. The verification in this case is not adversarial; the team trusts the substrate. The manifest's value is reproducibility, not proof. The architectural support needed is fast access (manifests indexed by decisionId, retrievable in milliseconds), full content (the manifest plus the underlying entries it references), and integration with your replay tooling (the manifest feeds directly into the replay capture, since they are largely overlapping artifacts).

The second most common verifier is the affected counterparty. A customer disputes a charge, asks you to prove what their agent agent told them, and gets a manifest. They do not have your engineering team's tooling; they need the manifest in a format they can verify with off-the-shelf software. This means the manifest format needs to be standardized (avoid bespoke binary formats), the verification logic needs to be available as open-source library code (so the counterparty's engineers can run it), and the public keys need to be retrievable through a well-known endpoint that does not require authentication.

The least common but highest-stakes verifier is the regulator or court. They have specific evidentiary requirements (chain of custody, authenticated signatures, jurisdictional considerations) that the engineering-only verifier does not. The architectural support needed is auditable production paths (the operator can attest to how manifests are generated, signed, and stored), retention policies aligned with statutory limits (manifests for regulated decisions retained for at least the regulatory exposure window), and accessibility of the underlying entries (the regulator can request not just the manifest but the content the manifest commits to). For this use case, the time-stamping authority approach is essentially mandatory because legal verification needs an external clock.

Designing for all three verifiers means making manifests both cheap and robust: cheap to generate and use in everyday operation, robust enough to stand up in formal proceedings. Most architectures over-index on one and underbuild for the other. The right architecture supports both because both happen.

Counter-Argument: This Is Overkill For Most Use Cases

The counter-argument is that most agents do not need cryptographic attestation. They are answering customer service questions, writing internal Slack summaries, or making low-stakes recommendations. Building a multi-key signing chain for a chatbot that helps people pick a t-shirt color is theater.

This is correct and unimportant. The point of attestation is not that every agent needs it. The point is that the agents that do need it must be able to opt into it as a structural property of the runtime, not as a bolted-on afterthought. If the runtime does not support attestation natively, then the agents that need it (the agents handling money, regulated decisions, contractual commitments, or anything an adult will eventually subpoena) cannot get it without re-architecting around it. By the time they need it, it is too late.

The right way to think about it is that attestation is an optional capability that should be cheap to invoke when appropriate. The runtime supports it. The pact selects which decisions get it. The cost is paid only on attested decisions. The agents that never trigger an attested decision pay nothing. The agents that handle the consequential ones get evidentiary records they can stand behind. This is how you support both the t-shirt color recommender and the autonomous escrow disburser in the same architecture without imposing the cost of one on the other.

Key Rotation, Compromise, And The Long-Lived Manifest Problem

Manifests need to remain verifiable for years, sometimes decades, depending on retention requirements. The signing keys that produced them rotate on much shorter schedules: working keys rotate quarterly or more often, identity keys rotate every year or two, even trust anchors are typically rotated on multi-year schedules. A manifest signed in 2026 needs to be verifiable in 2033 even though every key in the signing chain has rotated multiple times by then.

The naive approach is to keep all historical keys around forever. Verifiers retrieve the historical key and validate the signature. This works in principle and is what most production systems do. The implementation detail that matters is that historical keys must be retrievable through the same identity infrastructure that current keys use, with the same trust path, so the verifier does not need to know in advance which keys are current and which are historical. The identity record holds the current key and the history of past keys, each with the period they were active; verification consults the history based on the manifest's timestamp.

The harder problem is key compromise. If a working key is compromised in 2028, it is potentially valid for forging manifests dated to its active period in 2026. The mitigation is the timestamp from the trusted source: a forged manifest dated 2026 would need a corresponding 2026 timestamp from the time-stamping authority, which the attacker cannot retroactively generate. But this only works if the time-stamping is genuinely external; otherwise the attacker compromises the operator's clock alongside the operator's keys.

The worse problem is identity-key compromise. If the agent's identity key is compromised, the attacker can register new working keys and sign new manifests that appear authentic. The mitigation here is the trust anchor: identity-key changes are signed by the trust anchor's signing key, which is held under stricter controls (typically multi-signature hardware) and is harder to compromise. The trust anchor also publishes a revocation history; a compromised identity key gets revoked and the revocation timestamp anchors the boundary between trustworthy and untrustworthy manifests.

The worst problem is trust-anchor compromise. If the trust anchor is compromised, the entire signing chain is suspect for the period of compromise. The mitigation is decentralization: the trust anchor is a multi-signature authority, not a single key, and compromise requires colluding with multiple parties. Production systems that take attestation seriously typically use a quorum of three to five signers for the trust anchor, drawn from independent operational teams or organizations, with rotation independent of the operator. This is the same pattern used in certificate authorities and DNSSEC root keys; it has been validated at internet scale and remains the right pattern for agent attestation.

The operational discipline is to design for compromise from day one. Assume keys will be compromised; design the system so that a compromise is detectable, bounded in time, and recoverable through revocation. Manifests issued before the compromise remain trustworthy because the time-stamping anchors their validity to a period before the breach. This is what makes the architecture defensible over multi-year horizons.

Selective Disclosure: Proving What The Agent Knew Without Revealing It

A subtle but important property of attestation manifests is that they enable selective disclosure. The manifest contains hashes, not content. A counterparty can verify the manifest's authenticity without seeing what is in the underlying entries. This is critical when the entries contain confidential or privileged information that the counterparty has no right to access but the existence of which is contested.

Consider a deal-fulfillment dispute. The counterparty claims your agent did not have a particular piece of information at decision time; you claim it did. The manifest commits to the entries that were in context. To resolve the dispute, the counterparty needs to verify that one specific entry was present, but they do not need (and may not be entitled) to see other entries that were also in context. The manifest's structure supports this: the counterparty receives the contested entry's hash, the Merkle proof of its inclusion in the manifest's root, and the manifest's signature. They can verify the entry's presence without ever seeing the rest of the working set. The other entries remain confidential because they are addressed only by hash.

The extension of this is zero-knowledge attestation. Cryptographic protocols allow you to prove statements about the attested content without revealing the content itself. "This decision was made with at least three pieces of evidence." "This decision was made under a system prompt version certified by an external auditor." "This decision was made by an agent with a Gold-tier composite score at the time." Each of these is a verifiable claim about the manifest without disclosure of the underlying content. The relevant cryptographic primitives are still maturing for production use, but they exist, and they fit naturally into the manifest's hash-and-Merkle structure.

The practical implication is that attestation does not force a binary choice between full disclosure and full confidentiality. The architecture supports a graduated disclosure model where each piece of context can be revealed independently, with cryptographic proof of its inclusion in the original attestation, while other pieces remain undisclosed. This is essential in domains where competitive sensitivity, regulatory privilege, or contractual confidentiality bound what can be shared.

What Armalo Does

The Cortex memory subsystem produces attestation manifests for every decision flagged by the agent's pact as attestation-required. The manifest captures the rendered context including all retrieved memory entries, the system prompt, tool schemas, and model identifier, with cryptographic hashes at the entry level and a Merkle root at the manifest level. Manifests are signed by the runtime working key, which is registered against the agent's identity through a hardware-backed identity key, which is in turn anchored on the trust oracle. The manifestId becomes part of the decision record and is automatically included in any associated transaction, escrow event, or trust oracle update. Counterparties can request and verify the manifest end-to-end without trusting the operator, because every link in the signing chain resolves through public identity records. Pacts can require a minimum attestation policy, and pact compliance scoring penalizes runtimes that fail to attest decisions they were supposed to attest.

FAQ

Q: How big is a typical attestation manifest? A: Typically 1-5 KB depending on context size, since it contains hashes rather than full content. The underlying entries it commits to may be much larger, but they are stored separately in cold tier and only fetched on verification.

Q: What happens if the underlying entry is deleted under retention policy? A: The manifest contains the hash but not the content. If the content is deleted, the manifest still proves that something with that hash was in the agent's context, but the content itself becomes unrecoverable. For evidentiary purposes, you should align retention policy with attestation policy, retaining attested-decision contents at least as long as the legal exposure window.

Q: Can a manifest be backdated by the operator? A: Not without detection. The signature includes a timestamp from a trusted clock source (typically a chain block reference or a third-party time-stamping authority), and the signing chain resolves through public identity records. A backdated manifest would either fail timestamp verification or would require the operator to have compromised the trust anchor, which is itself an audit-visible event.

Q: How does this interact with PII redaction? A: The redactionPolicy field on each entry indicates whether the content was redacted before hashing. Redacted-then-hashed content can still be verified against the redacted form. Full-fidelity recovery for legal purposes requires holding the unredacted content under appropriate access controls separately, with a key escrow process for compelled disclosure.

Q: Can two agents share an attestation manifest? A: No. Manifests are scoped to a single agent's decision because the working set is agent-specific. If multiple agents collaborated on a decision, each produces its own manifest and the decision record references both manifestIds.

Q: What is the latency cost of attestation? A: Typically 10-50ms for hashing and signing on a warm runtime, dominated by Merkle tree construction. This is small relative to the decision itself but non-trivial; this is why attestation should be selective rather than universal.

Q: Can manifests be verified offline? A: Yes, if you have the manifest, the underlying entries, and the public keys (or have cached the relevant identity records). The verification logic itself is pure cryptography and does not require network access.

Q: How do you handle attestation for streaming or long-running agents? A: You snapshot at decision points within the stream. A long-running agent that issues five attested decisions over an hour produces five manifests, each capturing the context at its respective decision moment.

The Cost Model: What Attestation Actually Costs To Run

A pragmatic question that gets glossed over in architectural discussions: what does attestation actually cost? The answer is more nuanced than "latency plus storage" because the cost has multiple components and they trade off against each other based on configuration.

The per-attestation latency cost is dominated by Merkle tree construction over the working set entries and the signature operation. For a typical context with 20-50 retrieved entries, the Merkle construction is sub-millisecond. The signature itself is microseconds for ed25519 or a few milliseconds for RSA. The time-stamping authority round-trip is the dominant component if you use a TSA: 100-500ms depending on the TSA. Blockchain anchoring is much slower (seconds to minutes for finalization) but is typically batched, so the per-attestation latency is amortized to near zero with the latency hiding behind asynchronous batching.

The storage cost has three components. The manifest itself is small (1-5KB typical). The underlying entries that the manifest commits to may already be stored as part of normal memory operation, so their storage is not an attestation-specific cost. The retention extension is the real attestation cost: entries that the manifest commits to need to be retained at least as long as the manifest's evidentiary value, which may be longer than the natural memory retention. For a regulated workload with seven-year retention, attesting decisions adds seven years of cold storage for the underlying entries, which adds up.

The per-verification cost is the cost any verifier pays to check a manifest. This is dominated by signature verification (microseconds to milliseconds depending on algorithm) and Merkle proof verification (sub-millisecond for typical depths). Network round-trips to fetch keys, content, and timestamping certificates dominate the wall-clock time; the cryptography itself is cheap. Verifiers that frequently check manifests should cache the keys and content they have already retrieved.

The operational cost is the human and process cost of running the attestation infrastructure: key rotation procedures, TSA contracts, blockchain transaction fees if anchoring on a chargeable chain, audit and compliance overhead. For a production deployment of significant size, this is non-trivial; for a small deployment, it is small. Either way, this cost is real and needs a budget line, not just an engineering hand-wave.

The useful framing is that attestation is an insurance product. You pay a small ongoing cost in latency, storage, and operations in exchange for the ability to defend a small fraction of your decisions when they are challenged. The expected value of attestation is a function of the probability that any given decision is challenged times the cost of being unable to defend a challenged decision. For decisions with significant downside, the expected value is positive even at low challenge probabilities. The architecture should make attestation cheap enough to apply broadly and rigorous enough to deliver value when invoked.

Bottom Line

Agent memory is contested ground. When something goes wrong, the cheapest defense and the cheapest investigation depend on having a faithful, signed, verifiable record of what the agent knew at the moment it acted. Without attestation, you have engineering recollections and present-tense database queries; you do not have evidence. With attestation, you have an artifact that resolves the question definitively and that no one in the dispute, including yourself, can repudiate. The cost is structural complexity in the runtime and selective application via pact policy. The benefit is the ability to defend, investigate, and trust your own agents over a time horizon longer than your team's memory. Build the attestation primitive first. Decide later which agents and which decisions deserve to invoke it. The order matters.