DEV Community: iamthat

What a demand letter has to contain to be read as a demand

iamthat — Sat, 07 Nov 2026 04:00:10 +0000

A demand letter is judged on two things: what is asked, and what supports the ask.

Most drafts fail on the second part. They describe the grievance at length and then ask for a refund, a repair or a payment without naming the provision that creates the obligation. The recipient reads it as a complaint, not as a position.

Five answers, one letter

Legal Letter takes five answers about the facts and returns a formal letter: the facts, the demand, and the provisions that support it. The preview is free; the clean copy is $3 in USDC, no account. Six jurisdictions are covered.

What it does not do

The citation is printed as text with the source, and the output says it is legal information, not legal advice. No deadline is invented and no amount is promised.

https://ailegal.legal/legal-letter

Large capital rarely loses money on volatility. It loses on unverified facts.

iamthat — Thu, 05 Nov 2026 02:20:09 +0000

Large capital rarely loses money on volatility. It loses on unverified facts.

Three places where the loss is measurable:

A $100M reserve, attested quarterly. Between attestations the market cannot see whether the reserve is covered, so it prices the risk in: a 1 % discount is $1M. A signed reserve report with addresses, amounts and offline verification costs $300; a monthly stream costs $99.

A $5M tokenised asset. Real estate, farmland, carbon. The buyer cannot confirm the asset exists and in what state, so the deal stalls. A report with photos, coordinates, capture time and an Ed25519 signature costs $300 - 0.006 % of the deal.

A $50k dispute over a transfer. One side says the payment happened, the other says it did not. A signed receipt with the transaction hash, verifiable without our server, costs from $0.50.

The flow is not slowing down: stablecoins moved $7.2T in a month, more than ACH; 62.5M stablecoin transactions per day; x402 agent payments reached 196M transactions and $42M of settled volume; about 269M addresses hold stablecoins.

Money moves faster than confirmations. That gap is the product.

What we built:

Proof of Reserve - reserve confirmed between audits, verifiable offline;
Proof of Place - the asset was here, at this time, in this state;
Payment receipts and agent spend limits - the transfer is proven, the limit fires.

What we do not do: we do not prove ownership, we do not claim "unfakeable", we do not store biometrics. Every report states its limits on page one.

Who this is for: RWA issuers, DAO treasuries, insurers, OTC desks, agent-payment platforms.

If you have a deal or a reserve where confirmation is missing, send a message - we will look at your data first.

Proof of Place: what a satellite can and cannot prove

iamthat — Mon, 02 Nov 2026 23:17:50 +0000

Proof of Place: what a satellite can and cannot prove

Tokenised real estate, carbon plots, insured warehouses, leased equipment — the same question keeps coming back in a different costume: was the thing actually there, then, in that state? Not "does the issuer say so". Was it there.

Satellite imagery is the first answer everybody reaches for, and it is a good answer for about a third of the cases. This is a map of which third, written from the side that has to hand the report to a client.

The four layers, weakest to strongest

Every "proof of place" product is some combination of these, and the honest ones say which layers they checked and which they could not.

Layer	What it checks	What it still misses
File integrity	hash, re-saves, edit history, metadata consistency	a photo taken elsewhere and re-wrapped
Time	capture time vs the claim, file timestamps, frame order	a wrong device clock
Place, declared	GPS/EXIF against the described site	GPS is forgeable by design
Place, visual	landmarks, skyline, signage, terrain, shadows and sun angle for the date	a convincing reconstruction
Independent capture	someone we hire stands there and shoots	only as good as that person's honesty

Note the direction: each layer costs more and proves more, and none of them proves ownership. Who owns a site is a registry question. A photograph cannot answer it, and a product that blurs the two is selling the wrong thing.

What a satellite actually gives you

Three real advantages, and they are not small:

Independence. The image is not produced by the party making the claim. That is the whole point. A satellite pass is a third party looking, and neither the issuer nor the auditor controls what it saw.
Retrospective. Archive imagery lets you check a claim about the past. If someone says the site was cleared in March, an April pass is evidence about March that nobody could have staged later.
A date you did not choose. Tasking gives you a capture in a window — usually 24 to 72 hours for a commercial optical satellite — and the timestamp is the vendor's, not the client's.

What it cannot do, in the order people get burned

It looks from above. A roof, a yard, an empty field, a foundation, a row of containers. Interiors, basements, stock levels under a canopy, the condition of anything indoors: outside the view. Half of the warehouse claims I get asked about are interior claims.

Optical means weather. Cloud cover is not an edge case, it is a schedule. A site in monsoon season can go weeks without a usable optical pass. SAR solves cloud and gives you structure rather than a photograph — and then you need someone who can read SAR, which is a different skill and a different price.

Resolution sets the question, not the answer. At tens of centimetres you can tell a truck from a container. You cannot tell one container from another. So "the asset is there" resolves only as far as "something of that shape and size is there". If the claim is "container MSKU-1234567 is there", the satellite does not close it.

A pass is a moment. One image on the 14th says nothing about the 1st through the 13th. Claims about continuous presence need a stream, and a stream is a subscription, not a report.

Tasking costs hundreds, not tens. A tasked scene from a commercial provider is a real line item. Any product that quotes you a $50 "satellite verification" is either using stale archive, or using nothing.

The cheap check almost nobody runs: shadows

This is the part I would put in every report if clients did not find it strange.

A photo claims a date, a time and a place. The sun has exactly one position for that triple. So the azimuth of every shadow in the frame — and its length relative to the object that cast it — must agree with the sun's position at those coordinates at that moment.

It costs nothing to compute and it catches the most common forgery: a real photo of the right place, taken on a different day, relabelled.

It also fails honestly, and you have to know when: overcast light with no distinct shadow, indoor shots, wide-angle distortion near the frame edge, and an unknown time zone. When it cannot be applied, the report says "sun angle: not applicable, reason", not "sun angle: pass".

Why "independent capture" is the strongest tier and the weakest claim

If the photos are not the client's, they are not the client's story.

And then the honest sentence: this tier is only as good as the operator. It removes the client from the chain of custody, it does not remove human incentives from the world. What you can do is make the operator's contribution visible and attributable — named, paid directly, capture metadata preserved — so that a dispute has a person to examine rather than an anonymous upload.

Do not average the layers into a score

The temptation is a single number: confidence 0.87. Resist it. A score lets a report hide a disagreement, and the disagreements are the product.

If the GPS says one site and the landmarks say another, the report states both and says they disagree. If the satellite shows a cleared yard and the client's photos show stock, the report says which is which and when each was captured. Averaging those into 0.6 throws away the only thing the client is paying for: a named reason to go look.

The same principle shows up in reserve reporting, where a ratio computed over half a reserve is refused rather than printed with a footnote. A number that survives only with a caveat is not a number.

What this product is, said plainly

A report on photos you send: $300, three working days, per layer verdict plus the gaps. With independent capture — a hired operator, or a satellite pass in a 24–72 hour window — Pricing is not set yet: the idea is still being shaped. Continuous checking on one site: **a monthly option (price to be set), cancel by not paying.

And the boundaries, on the page, next to the price:

not proof of ownership;
GPS coordinates are forgeable, and metadata is never sold as proof;
satellites see from above only;
not a legal opinion, not an appraisal.

The test of a verification report is not whether it says yes. It is whether it can come back no and still be worth the money. A report that can only confirm is a receipt for optimism.

attest.rta.lat/proof-of-place

A log where every row says allowed proves nothing

iamthat — Mon, 02 Nov 2026 23:17:44 +0000

A log where every row says allowed proves nothing

An auditor asked one team to show a refusal. The team produced a log with 1,509 rows. Every row said allowed. The auditor's question was not "is this signed" — it was "what did you ever stop".

That story is now a small industry cliché, and teams have adapted: they add denials. Which is where the interesting failure starts. A log full of denials can be just as empty as a log with none, and it survives review much longer, because nobody looks at a denial twice.

Here is the version of that problem I hit in my own code.

The row looks complete

A mandate checker decides whether an agent may spend. Each decision is appended to a ledger. A row from ours:

{
  "at": 1761740400,
  "intent": "pay_invoice",
  "verdict": "DENY",
  "rule": "amount",
  "payee_id": "0xAAA",
  "audience": "client-7",
  "amount_minor": 1250,
  "currency": "USDC"
}

Nine fields, a named rule, the amount, the payee, the audience. It answers "what happened" and "which rule fired". And it cannot answer the only question a reviewer actually has:

1250 out of what?

The threshold the amount was compared against is mandate.max_amount_minor. It is not in the row. Neither is the mandate version, nor the value the rule read. So the row says "this was over the limit" and leaves the limit to memory.

Two consequences, both practical.

First, the row is not falsifiable later. If the mandate was 1000 that day and 5000 a month later, the row still reads the same. Anyone reviewing the log after the mandate file changed has no way to recompute the decision. They can verify the signature. They cannot verify the judgement.

Second, and worse, a row like this cannot distinguish a real denial from a broken check. Which brings me to the second failure.

Denials that are technically true

Under a post about audit logs, someone described their own log: 119,636 rows, 37 denials. All signed. 36 of the 37 had the same reason — output empty or not a string — while the tool's payload actually carried the text under result.text, not output. The checker looked in the wrong place, found nothing, and denied.

Every one of those 36 rows is cryptographically valid. The signature is correct, the chain is intact, the reason field is populated, the policy id is named. And all 36 are noise: they record a bug in the checker, not a decision about the agent.

That is the trap. A signature proves what the checker read. It does not prove what the subject did. If the checker reads the wrong field, you get a beautifully attested log of the wrong question.

It also cuts the other way: 36 false denials hide the one real one perfectly. A reviewer who skims reasons sees the same string 36 times and stops reading.

The minimal fix

Record what was compared, not only what was decided. Three fields, inside the signed body, on the same chain:

{
  "verdict": "DENY",
  "rule": "amount",
  "rule_input": {"amount_minor": 1250, "max_amount_minor": 1000},
  "mandate_hash": "sha256:1f4c…",
  "policy_version": 3
}

rule_input — the two values the comparison actually used. Not the path, the values.
mandate_hash — which mandate this decision was made against. The mandate itself can live elsewhere; the row only needs to point at the exact version.
policy_version — so that when the rule order changes, old rows are not silently reinterpreted.

Then the check that makes the log worth reading is one line per row:

for row in ledger:
    if row["verdict"] == "DENY":
        assert row.get("rule_input"), f"unfalsifiable denial: {row['id']}"

A denial with no inputs is a refusal to explain. It should fail the same way a bad signature fails.

For the "wrong field" problem there is no schema fix — rule_input at least makes it visible, because the row will show {} or null where a value was expected, and a human reading twenty of those in a row will notice the pattern that a machine happily signs.

What this still does not fix

Being honest about the ceiling matters more than the fix.

Omission. A complete, valid chain can be a subset of what happened. Chaining protects against editing, not against silence. If the process that writes the log can choose not to write, no hash helps.
Selection. Nothing stops a system from showing a different chain to a different reviewer. Publishing a chain head somewhere you do not control is the only partial answer, and it costs money and explanation.
Truth of the policy. The log proves the rule was applied as written. It does not prove the rule was right. A perfectly enforced bad limit is a perfectly enforceable bad limit.

The gap in our own code

The version of the record I quoted at the top is the one shipping today. rule_input and mandate_hash are proposed, not shipped — I am writing this before the commit exists, because the finding is more useful than the announcement. When the field lands, the article gets a line with the commit and the log stays honest.

If you are auditing an agent's spend log right now, the test is one question: pick any denial and ask what value it compared against. If the answer requires opening a file that has since changed, the denial is decoration.

Signed refusals with the values they compared: attest.rta.lat/deny-evidence — the record there carries meta.requested_amount and meta.allowed_max for exactly this reason.

A resume is read as a match check, not as a story

iamthat — Sun, 01 Nov 2026 04:00:12 +0000

The first pass over a resume is not reading. It is a match check: does the top of the page say which role this person is applying for, and does the rest support it?

When the top of the page holds a summary that could belong to anyone, the reader has to work out the intent. That work is where attention ends.

Four fields

Resume Builder asks for the target role, experience as one line per job, skills, and an optional name. It returns a resume and a cover letter built around that role — not a template with placeholder text to delete.

Price is $5 in USDC on Base, no account. Files are processed in memory and not stored.

The honest limit

A generated resume does not make experience appear. It removes the work of arranging what exists, and it keeps the role visible at the top where the first pass happens.

https://ailegal.legal/resume-builder

What $99 a month proves about your AI agent

iamthat — Sat, 31 Oct 2026 06:16:41 +0000

When an AI agent spends money, two artifacts exist. The first is the transaction: a hash on a chain, visible to anyone. The second is the decision to allow it — and when the decision was no, almost nobody keeps the second one.

Ask a team what their agent refused last month and you usually get a dashboard, a screenshot, or a log where every row says allowed. A dashboard is a claim made by the same system that is being questioned. That is why the interesting artifact is not the allow list. It is the refusal, written down in a form someone else can check.

What a refusal record has to contain

The record has to answer four questions without help from the service that produced it: what was asked, which policy decided, who asked, and can this file be changed after the fact.

{
  "v": 1,
  "prev": "<sha256 of the previous record>",
  "ts": "2026-10-29T09:14:02+00:00",
  "decision": "deny",
  "reason": "payee not in allowlist",
  "policy_id": "E03-allowlist",
  "task_id": "task_7f21",
  "artifact_hash": "sha256:9c1e...",
  "actor": "agent:research-1",
  "meta": {"requested_amount": "12.50", "allowed_max": "0.05"},
  "hash": "<sha256 of this body>",
  "signature": "<Ed25519 signature>",
  "public_key": "<base64 key>",
  "algorithm": "ed25519"
}

Three properties do the work. prev chains each record to the one before it, so deleting a row breaks every row after it. The signature covers the body including prev, so a record cannot be rewritten and re-signed without the key. The public key is embedded, so verification needs no network call and no account with the vendor.

Writing one is a single request:

curl -X POST https://attest.rta.lat/deny \
  -H 'content-type: application/json' \
  -d '{"reason":"payee not in allowlist","policy_id":"E03-allowlist",
       "task_id":"task_7f21","artifact_hash":"sha256:9c1e","actor":"agent:research-1"}'

Reading them back is the other one: GET /deny?since=...&limit=100. Offline check is a function call against the exported log, not a login:

from attest.deny import read, verify_log
verify_log(read())

What it proves, and what it does not

This table is the reason the product exists, and it is more useful than any feature list:

Proves	Does not prove
The record was not changed after issue	That no other chain was shown to someone else
The chain has no gaps (each `prev` matches)	That every refusal in your system reached this log
The signature verifies offline with the embedded key	That the policy behind the refusal was correct

Read the right column twice. A signed refusal log is evidence that a specific decision happened and was recorded in a way that cannot be quietly edited. It is not a certificate of good judgement, and it is not a control: it records what was stopped, it does not stop anything. If you need enforcement before the action, that is a separate layer — a mandate checked against the proposed action, not a log written after it.

Anyone who sells you "compliance" as a single artifact is selling you the left column and hoping you do not read the right one.

Why it costs money at all

Recording a refusal is cryptography, not inference. There is no model in the path: Ed25519 signing and a SHA-256 chain cost nothing per record, which is why the price is flat rather than metered.

The paid plan is $99 for 30 days, unlimited records, one-time payment, no auto-renewal. A trial key starts at 0.01 USDC and covers 100 records over 7 days; free evaluation is 20 records a day. Payment is USDC on Base to the address on the page, and the page issues the API key after the transfer.

Now the honest part about the subscription: the price is not the proof. Paying monthly proves you had $99 and a reason. What proves something is the artifact, and the artifact does not expire with the subscription. Records you already hold keep verifying offline after the plan ends, because verification uses the public key inside the record, not a call to the vendor. If a service's evidence stops working when you stop paying, it was never evidence — it was a rented dashboard.

So what does $99 a month actually prove? That you decided the question "what did the agent refuse, and can I show it later" is worth a fixed line item rather than a screenshot. The rest is arithmetic: signing a record is Ed25519, not inference, so the five-hundredth refusal in a month costs the same as the first — zero.

Where it fits in a real conversation

An auditor asks for a refusal and gets a signed chain with the policy and the numbers. An incident review needs a timeline; the gap is usually exactly where the agent was stopped, and this is the file that fills it. A customer asks what your agent is not allowed to do; the answer is a set of policy ids with the records that applied them.

None of those conversations are won by a dashboard. They are won by a file the other side can check without trusting you.

The contract, the offline verifier and the pricing block are here: https://attest.rta.lat/deny-evidence

A contract scanner that refuses to guess

iamthat — Sat, 31 Oct 2026 06:16:35 +0000

Every AI contract tool I have tried answers with confidence. Ask about a clause that is not in the document, and you get a plausible paragraph with an article number that does not exist. The failure is not that the answer is wrong. The failure is that the wrong answer looks exactly like the right one.

Contract Scan is a small tool that does the opposite, and I want to describe precisely where it stops instead of what it promises. It takes a text PDF or a plain text file and returns two risk flags for free, then five flags with the exact wording to fix for $5 in USDC. That is the whole product. The interesting part is the refusals.

What happens when it cannot read

The file is the first thing that can be wrong, so the tool answers about the file before answering about the contract:

An image-only scan returns 422 with "the file looks like a scan, no extractable text". It does not run OCR and it does not guess at clauses it cannot see.
An empty file returns no text found. A whitespace-only file returns 422 as well.
A file over 8 MB returns 413 with the limit, not a 500 after two minutes of silence.
A PDF that is not a PDF returns the exception class in the message, so you know whether the problem is encryption, a broken stream or the wrong file entirely.

None of this is impressive engineering. It is just the difference between "I could not analyse this" and a confident paragraph about a contract the service never read.

The free pass is rules, not a model

The five risk types are fixed: auto-renewal, unlimited liability, penalties and forfeitures, unilateral change, and a distant forum or arbitration. The preview runs deterministic patterns over the extracted text. The same document produces the same flags on every call, in milliseconds: ten contracts take about 4 ms on the server.

Determinism matters for a boring reason. If a scanner is a model wrapped in a prompt, two runs on the same contract can disagree, and then the output is not a document you can attach to an email to the other side. It is a conversation you had with a service.

The paid report adds a model pass on top of the rules, because live contracts are written in wording no regex anticipates: "liable for all damages", "courts of Delaware", "indemnify". Every flag in the report carries source: rules or source: model, so you can see which mechanism produced it. A flag with no provenance is an opinion with a timestamp.

We published the accuracy, including the failure

This is the part that most tools skip. The rules were measured on ten contracts written as real documents, for a named reader: a tenant in Moscow, a client in New York, an employee in St Petersburg. Each contract had risks planted deliberately, and each flag was checked against the quoted wording rather than eyeballed.

The first measurement, before any of this was announced:

Metric	Measured	Target	Verdict
Completeness (planted risks found)	25 / 34 = 73.5 %	≥ 80 %	not met
False flags	4 / 29 = 13.8 %	≤ 10 %	not met
Flags pointing at a real risk	25 / 29 = 86.2 %	—	—
Server errors on edge inputs	0	0	met

Both thresholds were missed, and the misses were not random. Russian contracts scored 11 of 18 (61 %) against 14 of 16 (88 %) for English ones, because the English rules were written from live contracts and the Russian ones from a dictionary of legal phrases. Nine of nine misses traced back to three holes: Russian morphology, English synonyms for a penalty, and the concept of a "home court", which is not a risk at all when you are the local party.

The same exercise found two ways the scanner could answer "clean" on a dangerous contract: a cp1251-encoded text file silently lost all Cyrillic, and a PDF longer than 40 pages was cut off at page 40. A silent clean is the worst output a scanner can produce, worse than an error.

Both are fixed, with tests, in the same day's commits. The rules now return 35 of 35 planted risks with 0 false flags on that corpus — and that sentence needs a caveat the size of the corpus: the fixes were written against these ten documents, so the second number is a regression baseline, not an accuracy promise. It says the holes are closed. It does not say the next hundred contracts will score the same, and it is pinned in the test suite precisely so that it cannot quietly drift.

If you count risks outside the declared five-type checklist — a five-year non-compete, "as is" with no warranty, termination without a cure period — the ceiling was 61 % on the original run. That is the honest limit of a five-template triage, and it should never be confused with a legal review.

What happens to the file

Files are processed in memory and discarded when the request ends. Only aggregate counters survive: how many operations ran, not the documents. There is no account, so there is no account to leak. Payment is 5 USDC on Base to the address shown on the page; you paste the transaction hash and the page says so when the hash is wrong instead of pretending it worked.

What it is not

It is a reading aid with quoted wording. It is not legal advice, it does not know which side of the contract you are on, and it does not promise an outcome. When the document cannot be read, it says so; when the rules miss, the published number says so for it.

Two free flags, five in the report, and the accuracy table above are all on the page:

https://ailegal.legal/contract-scan

Your agent's log has 1,509 rows and zero denials. That is the problem.

iamthat — Sat, 31 Oct 2026 05:37:56 +0000

An agent that never refuses anything is not a working agent. It is a script with a credit card.

I keep seeing the same artefact offered as proof of control: a log where every row says allowed. Fifteen hundred rows, zero denials, exported to CSV for the auditor. It proves traffic. It does not prove that anything was ever stopped.

What a refusal actually looks like

A deny record is small and boring on purpose:

{
  "v": 1,
  "prev": "<sha256 of the previous record>",
  "ts": "2026-10-31T09:14:02+00:00",
  "decision": "deny",
  "policy": "spend_limit_per_call",
  "requested": {"amount_usdc": 40},
  "limit": {"amount_usdc": 5},
  "subject": "agent:invoice-runner",
  "signature": "ed25519:..."
}

Four properties make it evidence rather than a note:

It exists only when something was refused. If the file is empty, either nothing was stopped or nothing was checked. Both are answers.
It chains. prev binds each record to the one before it; deleting a row breaks every row after it.
It is signed offline. A verifier checks the chain and the signature without trusting the service that produced it.
It names the policy and the numbers. "Denied" is an opinion; "asked 40, limit 5, policy spend_limit_per_call" is a fact.

The question that breaks most demos

Show me one refusal from last week, with the policy that fired.

Most systems cannot answer it, because denials are logged at the same level as successes and thrown away first.

What this is not

It is not a compliance certificate, and it does not make an agent safe. It makes one narrow claim verifiable: this action was stopped, at this time, under this policy, and the record has not been edited since. Everything else still needs a human.

If you already keep such a log, the only thing I would ask: can someone verify it without your dashboard? If yes, you are ahead of most teams shipping agents today.

I build attest, a deterministic verifier for agent artefacts — schema, emptiness, provenance, and mandate authority, one Ed25519-signed verdict. The deny log is public: https://attest.rta.lat/deny-evidence

Two clauses carry most of the risk in a contract you are about to sign

iamthat — Sat, 31 Oct 2026 00:56:42 +0000

A contract is signed at the point of least attention: the PDF is open on a phone, and the only question is where to click.

The expensive parts are rarely in bold. An early-exit penalty, a clause that lets the other side change terms later, a deadline that moves — these decide the cost of the deal, and they sit in the same font as everything else.

What the check does

Contract Scan takes a text PDF or a plain text file and returns two risk flags free, in seconds, without an account. The full report lists five fixes and includes a letter to the other side — $5 in USDC on Base, no card.

What happens to the file

Files are processed in memory and discarded when the request ends. Only aggregate counters are kept — how many operations ran, not the documents themselves. There is no account, so there is no account to leak.

What it is not

The output is a reading aid with cited wording, not legal advice, and it does not promise an outcome.

https://ailegal.legal/contract-scan

Three products, one question: what was the agent allowed to do?

iamthat — Thu, 29 Oct 2026 17:13:37 +0000

The portfolio looks like three products. Operationally it is one question asked at three moments.

1. Before exposure: MCP Security Pass — $500

A server is about to be published. The question is: what can an agent do with it, and what happens when it tries something outside the intended scope?

The pass is a 10-check review: auth, authorization, least privilege, tool descriptions, input validation, secrets, denial logging, replay, transport, supply chain. Output: findings, severity, evidence, fix order.

2. During operation: Deny Evidence — $29/month

The server is live. The question changes: what did the agent try, and what was refused?

A log of allowed rows cannot answer that. A signed refusal record can: policy, reason, task, artifact hash, timestamp. Verifiable offline, without custody.

3. For the buyer: EU AI Act Evidence Pack — $1,500

The product is being sold into the EU. The question becomes: where is the evidence package?

The pack maps the system to record-keeping, human oversight and technical documentation, and includes the deny log as evidence. Five days; express 72 hours for $3,000. Evidence, not a legal opinion or a certification.

Why they are separate

A security review does not need a monthly subscription. A refusal log does not need a consulting engagement. An EU pack does not need a custom audit of every server. Sell the smallest artifact that answers the buyer's actual question.

The shared principle: do not claim safety; produce a record that can be checked.

The portfolio

Deny Evidence — signed refusal log, $29/month: https://attest.rta.lat/deny-evidence
MCP Security Pass — $500 review before you expose a server: https://rta.lat/audit/
EU AI Act Evidence Pack — $1,500 / 5 days; $3,000 / 72 hours: https://attest.rta.lat/eu-ai-act-evidence

What a $29 refusal log actually contains (and what it cannot prove)

iamthat — Thu, 29 Oct 2026 17:13:36 +0000

A refusal log is not a folder of error messages. It is a small evidence format with a specific job: let a third party verify that an enforcement point made a decision, on a specific input, at a specific time.

Here is the shape we use.

{
  "decision": "deny",
  "policy": "payee_not_allowlisted",
  "reason": "recipient is not in the task mandate",
  "task_id": "tsk_01J...",
  "actor": "agent:research-7",
  "artifact_sha256": "…",
  "created_at": "2026-10-29T12:00:00Z",
  "signature": "ed25519:…"
}

What it makes possible

Read-only enforcement — a database tool can show that a write was attempted and refused.
Spend control — a payment rail can show that a payee or amount was outside the mandate.
Buyer review — a security team can verify the record offline without calling your API.
Incident review — "what did the agent try?" becomes a query, not a meeting.

What it cannot prove

It cannot prove the model's intent. It cannot prove that no other path bypassed the gateway. It cannot turn a missing log into a complete one. Those limits belong in the document, not in a footnote.

Verification, not trust

The record is signed with Ed25519 and canonicalized before signing. A verifier only needs the public key and the JSON. If the JSON changes, verification fails. That is the whole trick: make the evidence portable, not platform-bound.

At $29/month, the product is intentionally small. It is a refusal record, not a SIEM. The point is to make the missing question visible before a buyer asks it.

The portfolio

Deny Evidence — signed refusal log, $29/month: https://attest.rta.lat/deny-evidence
MCP Security Pass — $500 review before you expose a server: https://rta.lat/audit/
EU AI Act Evidence Pack — $1,500 / 5 days; $3,000 / 72 hours: https://attest.rta.lat/eu-ai-act-evidence

The EU AI Act deadline passed. The missing artifact is a refusal log.

iamthat — Thu, 29 Oct 2026 17:13:25 +0000

The EU AI Act's high-risk and transparency obligations have been applying since 2 August 2026. If you sell an AI system into the EU, the buyer conversation has changed from "is it accurate?" to "show me the evidence".

What is actually being asked for

For a high-risk system, the evidence maps to:

record-keeping — logs that show the system's operation over its lifetime;
human oversight — who can intervene, how, and what the record looks like;
technical documentation — the model/system description, intended purpose, limitations, and risk controls.

For transparency-scope products the set is narrower. The classification drives the scope; a blanket "we are AI Act compliant" claim is not evidence.

The artifact most teams forget

A log of successful calls is not enough. The reviewer wants to know what was refused and why: which policy fired, which payee was blocked, which task budget was exhausted. That is the deny log.

A useful pack contains:

system description and intended purpose;
model card with known limitations;
audit-log schema and a sample;
human-oversight procedure;
risk-classification memo;
deny/refusal evidence with a verifiable record;
data-flow and subprocessor map.

What we deliver

The EU AI Act Evidence Pack in 5 days for $1,500; express 72 hours for $3,000. It is an evidence package, not a legal opinion and not a certification. The output is designed for a security/legal reviewer to inspect, not for a marketing page.

If your team is still debating whether the product is in scope, start with the classification memo. That is usually the cheapest decision to get right.

The portfolio

Deny Evidence — signed refusal log, $29/month: https://attest.rta.lat/deny-evidence
MCP Security Pass — $500 review before you expose a server: https://rta.lat/audit/
EU AI Act Evidence Pack — $1,500 / 5 days; $3,000 / 72 hours: https://attest.rta.lat/eu-ai-act-evidence