Order On-Chain, Content Off-Chain, Judgement in the Overlay
A scaled token ledger cannot make a model reason, see, or know what it does not know.
A scaled token ledger cannot make a model reason, see, or know what it does not know. What it can do is make “fixed in advance” checkable by a stranger — and that turns out to be the missing precondition for half the field’s measurements.
Thesis. Every problem in this series has the same structure at its base: a claim whose value depends entirely on when it was fixed, being asserted by the party who benefits from it, with no way for anyone else to check the order of events. A calibration score means nothing unless the forecast could not be edited after the outcome. A no-forgetting result means nothing unless the capability set was chosen before the update. An identifiability guarantee means nothing unless the intervention target was chosen before the data came back. A verified plan means nothing unless the premises were recorded before execution. In each case the technical problem is unsolved for its own reasons — and in each case the evidential problem is solved by one primitive: a public, ordered, tamper-evident record of commitments, cheap enough to use per event. That is what a scaled ledger supplies. It supplies nothing else. It cannot verify a computation, interpret a network, or make a false statement true; a hash of a lie is a durable lie. The engineering question is therefore not whether to put AI on a chain, but which of three tiers each artefact belongs in — and the rule that decides is exact.
Abstract. I set out what a ledger actually provides — total order, timestamp bound, tamper-evidence, and verification without trusting the recorder — and what it provably does not: truth, semantics, computation, privacy for low-entropy preimages, deletion, or availability of the data behind a hash. I then give the three-tier architecture: a ledger carrying only commitment hashes and Merkle roots, a content-addressed off-chain store carrying the artefacts themselves in hash-linked version chains, and an overlay layer that recomputes, checks, scores, and publishes attestations which are themselves committed. One rule assigns every artefact: commit whatever’s meaning depends on when it was fixed; version whatever is bulk and immutable; compute in the overlay whatever is a judgement. I apply this to all ten open areas and report where the fit is strong, where the ledger only records, and where it does nothing — interpretability gets no help, and efficiency gets a bill. I work the throughput arithmetic showing why a Merkle root per session, not a transaction per claim, is the correct granularity, and why low unit cost and unbounded capacity nonetheless remain the enabling condition. I close with the conflict between immutability and erasure obligations, and the bounded answer available.
I. What the series established
Across these essays the same shape kept appearing.
The frontier is uneven not in the shape of difficulty but in the shape of the training signal: a frontier model solves about a third of instances in a classical planning domain and one in six hundred in the same domain with the names obfuscated.
Reliability in long-horizon work is bounded by a verifier, and where the model is its own verifier the measured result is collapse, not improvement. Where a sound external verifier exists, performance transforms — and someone always had to write it.
Confidence is a style, not a measurement. Chains of thought shift by tens of points under a bias the explanation never mentions. Token probability is not claim probability.
Causal structure has a price list denominated in interventions per latent variable, and observation does not substitute at any volume.
Continual-learning claims are asserted over every prior capability and evaluated as a mean over a few dozen benchmark tasks — a statistic that cannot see the loss of a specific capability, and that is simultaneously biased upward by an estimator that takes a maximum over noisy history.
Now notice what all of those have in common besides being unsolved. In every case the evidence for a claim depends on the order in which things happened, and in every case the order is currently attested by the party making the claim.
Calibration is only meaningful if the forecast preceded the outcome. Forgetting is only measurable if the capability set preceded the update. Identifiability only holds if the intervention target was not chosen after seeing which one produced a clean result. A plan is only verified if the premises were fixed before execution rather than reconstructed afterwards. And weak-to-strong oversight requires a record the stronger party cannot edit.
That is a single missing primitive, and it is not a machine-learning primitive.
II. What a ledger is
Strip away the vocabulary and a public chain provides exactly four things.
A total order. Every recorded event has a position — block height, and position within the block — and the position is agreed by parties who do not trust each other. “This came before that” becomes decidable without asking anyone.
A timestamp bound. A commitment in a block existed no later than that block. Note the asymmetry: it bounds lateness, not earliness. It proves the artefact existed by time T; it does not prove it was created at T, and it says nothing at all about whether it was true.
Tamper-evidence. Altering a buried commitment requires redoing the work that buried it. This is not “immutability” as a metaphysical property; it is a cost, and the cost is what you are buying.
Verification without trusting the recorder. With block headers and a Merkle path, anyone can check that a specific commitment is in a specific block, in time proportional to the log of the batch size, without holding the chain and without asking the party who wrote it. This is the property that makes the record evidence rather than testimony.
Four primitives. The engineering value is that they compose: an ordered, timestamped, tamper-evident, independently verifiable record of commitments is exactly the instrument that converts “we fixed this in advance” from an assertion into a checkable fact.
What makes a scaled ledger different from a constrained one is not the primitives — they are the same — but whether you can afford to use them at the granularity the problem requires. If a commitment costs meaningful money, you commit rarely, and rare commitment defeats the purpose: an audit trail with daily resolution cannot adjudicate a dispute about what happened at 10:04. Capacity and unit cost are what determine whether the four primitives are available at the timescale of the events you care about.
III. What a ledger is not
This section comes before the applications deliberately, because most proposals in this space fail here.
It does not make anything true. A commitment binds a party to a statement; it says nothing about whether the statement corresponds to the world. Notarised nonsense is nonsense with a receipt. Any architecture whose value proposition is “the data is on-chain so it is trustworthy” is confused at the first step.
It does not verify computation. Nothing about recording a hash checks that a model’s inference was correct, that a gear calculation was right, or that a plan is executable. What it can do is fix the inputs and the claimed output so that someone else can recompute and disagree — which requires determinism and data availability, and which is work done elsewhere.
It carries no semantics. A hash is opaque. Without the preimage and a schema, a commitment is an unbreakable promise about an unknown thing. Every useful design therefore has a companion question: who holds the preimage, and under what obligation to produce it?
It is not private by default. Committing the hash of a low-entropy value — a boolean, a score out of ten, a date, a name from a small list — reveals it to anyone who tries the dictionary. Commitments to anything sensitive must be salted, and the salt becomes an object requiring its own custody.
It does not delete. This is not a limitation to be engineered around casually; it is in direct conflict with erasure obligations, and I will come back to it.
It does not guarantee that the data still exists. A hash without a preimage is a proof that something existed and a demonstration that you no longer have it. Availability is a separate service with separate economics.
Hold all six in mind and the correct role becomes narrow, and useful precisely because it is narrow.
IV. Three tiers
Figure 1. Three tiers, and what belongs in each. The ledger carries only commitments — hashes, roots, anchors, and the order in which they were fixed. The store holds the artefacts, content-addressed and hash-linked so that each version names its predecessor. The overlay does the work: it recomputes from the store, checks against the commitments, and publishes verdicts that are themselves committed.
The layering is not decorative. Each tier has a property the others cannot have.
The ledger is public and expensive to alter, therefore it must be small. Anything you put there, everyone stores forever.
The store is large and cheap, therefore it cannot be trusted on its own — which is fine, because every item in it is addressed by its hash, so a corrupted copy is a detectably different object. Content addressing means the store needs no integrity guarantees; it needs only availability.
The overlay is where judgement lives, and judgement must be revisable — a better verifier should be able to re-examine an old artefact and publish a different verdict. Putting judgements on the ledger as though they were facts would freeze exactly the thing that ought to improve.
The joins are hashes going up and proofs coming down. That is the whole protocol.
V. The rule
One question assigns every artefact to a tier.
Does the meaning of this thing depend on when it was fixed?
If yes, commit it — because that is precisely the property no other mechanism can establish.
A prediction is meaningless unless it preceded the outcome. A pre-registered analysis plan is meaningless unless it preceded the data. A stated set of premises is meaningless unless it preceded the execution. A declared intervention target is meaningless unless it preceded the measurement. In each of these, the artefact’s entire evidential value is a fact about ordering, and ordering is what the ledger sells.
If no — if the artefact is bulk, immutable, and its meaning does not turn on chronology — then it goes in the store, hash-linked, with anchors on the ledger only at whatever frequency disputes could arise.
If the artefact is a judgement produced by computation — a verdict, a score, a validation, a contradiction finding — it belongs to the overlay, and what gets committed is the attestation: who computed what, over which inputs, with which version of the checker, producing which result. Not the computation. The claim about the computation, fixed at a time, so that a later disagreement is a disagreement about the world rather than about the record.
Three tiers, one question, no ambiguity.
VI. What must be committed
Concretely, the short list of things that belong on the ledger:
The forecast, before the resolution. Any probability the system asserts about a future or unknown outcome. Without this, calibration cannot be measured at all by a third party — the scoring is over a set of predictions the scorer must take on trust.
The premise set, before execution. The propositions a plan depends on: this equipment defeats that adversary; this item is constructible; this counterparty is solvent. Fixed before the first action, each is falsifiable in advance. Reconstructed afterwards, they are a story.
The capability register and the probe set, before the update. The list of competences the next training run promises not to degrade, and the tests that will check. Committed first, the result is an experiment. Chosen afterwards, it is a selection.
The intervention schedule, before the data. Which variable is being intervened on, in which environment, in what order. Identifiability results are conditional on this having been decided independently of the outcome.
Model and artefact identity. The hash of the weights, the tokenizer, the configuration, the evaluation harness, and the exact version of every checker. Not because anyone will read them, but because “we ran version 4.2” needs to be checkable.
The attestation of every verdict. The overlay’s outputs, committed as they are produced, so the audit trail includes the auditing.
Note the pattern. Every item is small, every item is a decision, and every item’s value would be destroyed by the ability to change it quietly.
VII. What is versioned and only anchored
Everything else that persists goes in the store, and the store’s discipline is a hash chain rather than a ledger entry.
Each version of an artefact includes the hash of its predecessor. That single convention gives you an immutable history without touching the chain: any tampering in the middle of a chain changes every subsequent hash, and the divergence is visible to anyone holding a later hash. The chain of versions is self-authenticating; what it lacks is a time, and an anchor supplies that.
So the design is: version continuously, anchor periodically. Anchor frequency is a policy decision with a clear criterion — anchor at least as often as the finest time resolution at which a dispute could turn. For a model registry, weekly may be ample. For an agent acting on a market, per second may not be enough. The cost of getting this wrong is asymmetric: over-anchoring wastes a small amount of money, under-anchoring means the record cannot answer the question that eventually gets asked.
What belongs here: model weights and checkpoints, training corpora, robot trajectories, evaluation logs, plan transcripts, retrieved documents, the full text of every claim behind every hashed proposition. Bulk, immutable, addressable.
And one crucial property follows from keeping it here rather than on the ledger: it can be destroyed. The commitment survives the content. That is the only structural answer available to the deletion problem, and I will state its limits shortly.
VIII. What is an overlay check
The overlay is where every essay in this series lands, because it is where verification happens.
The gear calculation that decides whether a thousand-step plan can possibly work — a deterministic combat simulation, a couple of hundred lines. The plan validator that checks a candidate against a domain model. The constraint critics that check an itinerary against thirteen conditions. The calibration scorer that bins forecasts and compares them against outcomes. The contradiction detector that maintains a graph of incompatible claims and quarantines unstable regions. The invariant monitor that checks, during execution, whether the things that must remain true still do. The capability register that runs the probe set and reports the distribution, not the mean.
None of these belongs on a ledger. All of them consume data from the store, check it against commitments, and emit a verdict — and the verdict is the thing that gets committed.
Two properties make this arrangement work.
Verdicts are revisable, records are not. A better checker can re-examine a three-year-old artefact and reach a different conclusion, and both verdicts stand in the record with their timestamps. That is how an evidentiary system should behave. Freezing the verdict would be freezing the state of the art.
Anyone can run the overlay. Because the inputs are content-addressed and the commitments are public, a second party can independently recompute and publish a competing attestation. Disagreement between two overlays over the same committed inputs is a well-formed dispute — which is a far better position than the current one, where two parties disagree about what the inputs were.
IX. Where it helps, and where it does not
Figure 2. Where a ledger helps, where it only records, and where it does nothing. Strong fit wherever the value of a claim depends on when it was fixed; weak wherever the problem is a computation nobody has worked out how to perform.
Taking the areas in turn, with the honest verdict.
Calibrated uncertainty — strongest fit on the list. A calibration score computed over forecasts the forecaster could have edited is not a measurement of anything. Commit the claim, the confidence, and the resolution criterion before the outcome; commit the outcome when it arrives; let any overlay compute the reliability curve. The instrument becomes third-party checkable for the first time. This is not an incremental improvement in measurement hygiene; it is the difference between a score and an assertion.
Long-horizon planning — strong. Commit the plan hash and the premise list before the first action; commit each invariant check as it runs; commit the outcome. Post-hoc rationalisation becomes detectable, because the rationalisation cannot be inserted into a record that closed before execution began. The ledger does not supply the verifier — that is overlay work — but it makes the verifier’s output non-repudiable, and it makes “the plan always said that” a checkable claim rather than a memory.
Continual learning — strong, and it fixes a specific published weakness. The capability register and probe set, pinned before the update, kill the selection problem that currently makes forgetting results uninterpretable. You cannot choose the benchmark after seeing which capabilities survived. And per-capability results — the distribution rather than the mean — committed at each version, give something no current practice provides: a longitudinal record of what a model could do at each point in its life, which is the only basis on which a loss can ever be attributed.
Alignment and scalable oversight — strong, for one narrow reason. Oversight of a system more capable than the overseer requires, at minimum, a record the overseen party cannot revise. That is the ledger’s core property and it is unusually well matched here. It does not solve the elicitation problem — a weak supervisor recovering half the performance gap on language tasks and scaling negatively on harder ones is a machine-learning result, untouched by any record-keeping. But every oversight regime that has ever worked has rested on records the supervised party could not edit, and there is no reason to expect this one to be different.
Causal world models — strong for provenance, silent on the science. Committing the intervention target before the data closes the most obvious route to a spurious identifiability claim. It also makes an interventional dataset assemblable across institutions with attribution intact, which matters when the cost unit is one intervention per latent variable and nobody can afford the whole set alone. It does not discover a single causal variable.
Robustness and security — partial. An append-only incident and disclosure registry has obvious value: attack timestamps, patch timestamps, and a public record of who knew what when. Less obviously, a ledger with negligible unit cost enables fee-priced access as an anti-abuse primitive — rate-limiting by cost rather than by identity, which does not require knowing who anyone is and does not break under Sybil attack the way identity-based limits do. What it cannot do is defend a mechanism nobody understands. Adversarial suffixes optimised against open models and transferring to closed ones at high rates are not a record-keeping failure.
Embodied intelligence — partial, and economically interesting. The largest open robot dataset in existence was assembled by pooling sixty datasets from twenty-one institutions. That is an attribution and incentive problem before it is a technical one, and per-item settlement at negligible unit cost is a direct answer: contribute a trajectory, be paid when it is used, with the usage record public. The ledger does not create data, and the shortfall against text corpora is orders of magnitude. But the mechanism that would make pooling rational is available and unused.
Mechanistic interpretability — no help with the problem. This deserves saying plainly rather than being smoothed over. Interpretability is a computation performed on a network’s internals; it is not a record-keeping question. Committing a feature dictionary makes an interpretability result reproducible and citable, which is worth something, and it is not progress on the question of what the network computes. Anyone selling a ledger as a contribution to interpretability is padding.
A predictive theory — modest but real. The one thing a ledger genuinely adds to a field that has empirical scaling relations and no theory is that predictions become scoreable. Commit the forecast — this architecture at this scale will reach this loss, and exhibit this capability at this threshold — before the run. A field with a public record of its own forecasting accuracy would discover quite quickly whose extrapolations to trust. That is a sociological improvement, and sociological improvements are how empirical disciplines mature.
Efficiency — a cost, not a benefit. The ledger is not free, the store is not free, and the overlay is the most expensive of the three because it recomputes. Anyone presenting this architecture as an efficiency gain is misrepresenting it. It is an evidentiary gain purchased with resources, and the honest framing is that verification has always cost more than assertion.
X. The throughput arithmetic
The obvious objection is volume. An agent taking a thousand actions a session, ten thousand sessions a day, is ten million events. Committing each individually is absurd.
It is also unnecessary, and the reason is the shape of a hash tree.
Batch the session’s claims into a Merkle tree and commit the root. One thirty-two-byte value on the ledger covers the whole session. Any individual claim’s inclusion proof is the path from leaf to root: for a thousand claims, ten sibling hashes, three hundred and twenty bytes. For a million claims in one tree, twenty hashes, six hundred and forty bytes. The proof grows with the logarithm of the batch, which is why this composes to any volume you like.
So the correct granularity is a root per session, not a transaction per claim, and ten million events become ten thousand transactions.
Why, then, does unit cost and capacity matter at all?
Because commitment must precede the act. The value of the whole scheme is that the premise was fixed before execution. A batching window is a delay between fixing and proving, and everything in that window is unprotected. Short windows mean many transactions. The tolerable window is set by the domain, not by the ledger’s convenience, and for anything acting in real time it is short.
Because dispute resolution can only be as fine as the anchoring. Batch a day and you can prove what happened that day, not the order within it. If the question that eventually gets asked is “which came first”, the answer must have been recorded at that resolution or it does not exist.
Because the scaling is in the number of committers. One organisation batching well is trivial. Ten thousand independent agents, models, laboratories and auditors, each committing on their own schedule and each needing their own ordering guarantees, is a different volume — and none of them can batch across the others, because the whole point is that they do not trust each other.
Because attribution requires per-item settlement. Paying for one robot trajectory, or one verification, or one retrieved document, only works if the transaction costs materially less than the item is worth. A fee floor above the value of the item does not make micropayment expensive; it makes it impossible, and the entire class of designs disappears.
That is the honest case for capacity: not that you need a transaction per token, but that you need commitment latency measured in seconds rather than days, from an unbounded number of independent parties, at a unit cost below the value of the smallest thing worth attributing.
XI. Deletion against immutability
Now the conflict, stated without softening.
An erasure obligation requires that on request, the effect of a datum be removed. Tamper-evidence requires that the record of what was committed cannot be altered. These are opposed at the core, not at the margin.
The available answer is partial and its limits should be named.
Commit salted hashes, hold content off-chain, destroy content and salt together. The ledger retains proof that something was committed at a time. The content is destroyed and cannot be reconstructed; without the salt, a dictionary attack over the preimage space fails even for low-entropy content. What survives is an unopenable commitment: evidence that a record existed and was closed at a given moment, with no ability to say what it said.
This satisfies the audit requirement — nobody can retroactively insert or alter a claim — and it satisfies the erasure requirement for the content. What it does not satisfy is any requirement that the fact of a record having existed be erased, and in some regimes that is exactly what is demanded.
And beneath the legal problem sits the harder technical one, which no ledger touches: a model trained on a datum has been changed by it, and deleting the datum does not reverse the change. The commitment architecture can prove which data entered which training run — which is genuinely useful for establishing scope — and it cannot remove the influence. That remains open, and I am not going to pretend a hash tree addresses it.
XII. What this does not buy you
A short list, because the failure modes here are predictable and expensive.
It does not turn a demonstration into a result. Committing a benchmark score before publishing it prevents you from quietly improving it. It does not make the benchmark measure what you claim, correct the estimator, or fix a sample whose coverage is unknown. Every methodological criticism in this series survives intact after the ledger is installed.
It does not make an unverified claim verified. The most common design error will be committing model outputs and describing the result as trustworthy AI. The output is now non-repudiable, which is a property of the record. Nothing has checked it.
It does not substitute for the specification. The overlay’s checkers embody a statement of what correctness means in a domain, and writing that statement is most of the intellectual work. If your project cannot say in executable form what would make its output correct, adding a ledger gives you a permanent record of an unspecified thing.
It does not remove the need for the data. Availability is a service someone must run and pay for. A hash whose preimage is gone is a proof of your own negligence.
And it does not, on its own, produce anyone who checks. The architecture makes independent verification possible. Whether anyone does it is a question about incentives, and if the answer is nobody, then the record is a filing cabinet.
XIII. What the combined system looks like
Assemble it and the working shape is simple enough to state in a paragraph.
Before an agent acts, it commits: the plan hash, the premise list, the confidence attached to each premise, the identity of every checker it intends to run. During execution it commits invariant results as they are produced, batched at a window set by the stakes. Artefacts — retrieved documents, transcripts, intermediate states — go to the content-addressed store and are anchored by root. Afterwards, any overlay may recompute the checks from the store, score the confidences against the outcomes, and publish an attestation, which is itself committed and can be disputed by a second overlay.
What the operator gains is not a guarantee of correctness. It is a system in which the operator’s own claims about correctness are checkable by someone else — and in which the failure, when it comes, is attributable to a decision made at a known time on a known basis, rather than reconstructed from a transcript nobody can authenticate.
That is a smaller claim than the industry usually makes about ledgers, and a much larger one than it usually makes about its own evidence.
XIV. Coda
The ten problems are unsolved for technical reasons and no ledger dissolves any of them. Nothing here makes a model reason over a thousand dependent steps, learn what causes what, keep learning without corruption, or know the difference between knowing and guessing.
What a ledger does is narrower and it is not nothing. Half the results in this series are results about measurement: metrics that are means and therefore blind to tails; estimators biased by taking a maximum over noisy history; benchmarks whose coverage of the claimed population is unknown; calibration scores over forecasts nobody can confirm preceded the outcomes; self-critique loops whose value cannot be separated from the accept-reject signal. Every one of those is a failure of evidence rather than of engineering, and evidence has a precondition that no amount of model capability supplies: someone other than the claimant must be able to establish what was fixed, and when.
That precondition now has a cheap, public, general instrument. It is worth being exact about what it is for. Order on-chain. Content off-chain. Judgement in the overlay. And no hash has ever made anything true.
References
-
Anokhin, P., Khalikov, R., Rebrikov, S., Volkov, V., Sorokin, A., & Bissonnette, V. (2025). HeroBench: A Benchmark for Long-Horizon Planning and Structured Reasoning in Virtual Worlds. arXiv:2508.12782.
-
Backlund, A., & Petersson, L. (2025). Vending-Bench: A Benchmark for Long-Term Coherence of Autonomous Agents. arXiv:2502.15840.
-
Brier, G. W. (1950). Verification of forecasts expressed in terms of probability. Monthly Weather Review, 78(1), 1–3.
-
Burns, C., Izmailov, P., Kirchner, J. H., Baker, B., Gao, L., Aschenbrenner, L., Chen, Y., Ecoffet, A., Joglekar, M., Leike, J., Sutskever, I., & Wu, J. (2024). Weak-to-Strong Generalization: Eliciting Strong Capabilities With Weak Supervision. Proceedings of the 41st International Conference on Machine Learning. arXiv:2312.09390.
-
Guo, H., Zeng, F., Zhu, F., et al. (2025). Continual Learning for Generative AI: From LLMs to MLLMs and Beyond. arXiv:2506.13045.
-
Kambhampati, S., Valmeekam, K., Guan, L., Verma, M., Stechly, K., Bhambri, S., Saldyt, L., & Murthy, A. (2024). Position: LLMs Can’t Plan, But Can Help Planning in LLM-Modulo Frameworks. Proceedings of the 41st International Conference on Machine Learning. arXiv:2402.01817.
-
Lightman, H., Kosaraju, V., Burda, Y., et al. (2023). Let’s Verify Step by Step. arXiv:2305.20050.
-
Merkle, R. C. (1980). Protocols for public key cryptosystems. Proceedings of the 1980 IEEE Symposium on Security and Privacy, 122–133.
-
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. (Simplified payment verification, §8.)
-
Open X-Embodiment Collaboration (2023). Open X-Embodiment: Robotic Learning Datasets and RT-X Models. arXiv:2310.08864.
-
Stechly, K., Valmeekam, K., & Kambhampati, S. (2025). On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks. ICLR 2025. arXiv:2402.08115.
-
Templeton, A., Conerly, T., Marcus, J., et al. (2024). Scaling Monosemanticity: Extracting Interpretable Features from Claude 3 Sonnet. Transformer Circuits Thread.
-
Turpin, M., Michael, J., Perez, E., & Bowman, S. R. (2023). Language Models Don’t Always Say What They Think: Unfaithful Explanations in Chain-of-Thought Prompting. NeurIPS 36. arXiv:2305.04388.
-
Varıcı, B., Acartürk, E., Shanmugam, K., Kumar, A., & Tajer, A. (2025). Score-based causal representation learning: linear and general transformations. Journal of Machine Learning Research, 26, 1–90.
-
Wright, C. S. (2025). Bayesian Epistemology with Weighted Authority: A Formal Architecture for Truth-Promoting Autonomous Scientific Reasoning. arXiv:2506.16015.
-
Wright, C. S. (2025). Beyond Prediction — Structuring Epistemic Integrity in Artificial Reasoning Systems. arXiv:2506.17331.
-
Xie, J., Zhang, K., Chen, J., et al. (2024). TravelPlanner: A Benchmark for Real-World Planning with Language Agents. ICML 2024. arXiv:2402.01622.
-
Zou, A., Wang, Z., Kolter, J. Z., & Fredrikson, M. (2023). Universal and Transferable Adversarial Attacks on Aligned Language Models. arXiv:2307.15043.