The Obligation Calendar

Watch the two-minute walkthrough 2:10

A two-minute walkthrough: why AI law with a date on it still catches teams out, the fields, the four counts, and how to run the prompt in any model.

Play video

The decision it forces

This page is a planning aid, not legal advice: every row that matters gets checked by a qualified person, by name.

Which AI obligations have a date on them, and who owns each? A lot of AI risk is vague. Some of it has a date on it, written into a law, and a dated risk is the kind we can plan for: a calendar, one row per obligation, each row ending in a person.

The decision is about each row. Does this reach us, and if it does, whose name is on it and who checked it? A row with no named owner, or no evidence behind it, or nobody qualified who has looked at it, is risk we can actually count.

To run it, copy the prompt below into any model you already use.

Risk with a date on it

Dates are where the noise thins out. A headline about AI regulation tells us something might happen somewhere. A date tells us when work has to have started, and a calendar is a format every organisation already knows how to run.

A start date isn't always a due date. Some obligations start on a given day and ask only that the work has begun; the first filing can come a year or more later. Write both, as separate rows, because the start date is the one that sneaks up on us.

Most of the rows will turn out not to be ours. That's fine. A "not ours" with one sentence of reason behind it is a decision. A row nobody looked at is a guess.

The fields

One row per dated obligation that could plausibly reach us. The first four rows describe the obligation, and a machine may fill them from a source if it says which. The rest say what it means for us, and they're ours: touches and status sort the rows, and the verdict reads the other four.

There's no worked example on this page: a filled calendar names the people accountable for an organisation's legal exposure, and that belongs inside the organisation.

The verdict rule

A row is ready only when owner names a person, evidence is something we could hand over, and checked_by names a qualified person who looked. A role in either name field counts as blank.

The calendar's verdict is four counts, in this order:

1. Rows with no named owner.
2. Rows with no evidence.
3. Rows marked not ours without a reason.
4. Rows nobody qualified has checked.

Four zeros is a calendar. Anything else is the work list, and the first count is the one to start on, because a row with no owner won't get the other three filled either.

Before you trust a list

Any model has a training cutoff, and AI law changes faster than any training set, so the prompt makes it say when its knowledge stops and mark what it can't confirm as unverified. A current source closes most of that gap: the dates here come from EveryAILaw, built by the show's host and linked unpaid. The qualified person in checked_by closes the rest.

Run it with any model

It lists dates and rules, and says where they came from. It never decides for us whether a rule applies, and it never fills owner, evidence or checked by.

Help me build an Obligation Calendar: a dated list of the AI-specific legal
obligations that could apply to my organisation, one row each. This is a
planning aid, not legal advice, and every row that matters will be checked by a
qualified person.

FIRST, before anything else, tell me your training cutoff date. Say plainly that
laws signed or changed after it will be missing from what you know.

THEN ASK ME three things, one at a time: where we operate (states and
countries), which AI tools and systems we use or sell, and who our customers are
(consumers, businesses, or both).

THEN LIST every AI-specific legal obligation with a start date or a first filing
date between today and the end of next year that could plausibly reach us. If an
EveryAILaw MCP server is connected, call its get_timeline tool and use that as
the source, and name it. Otherwise use your own knowledge, say so, and mark
every row "unverified". Mark any row as "unverified" if you cannot confirm it
from a current source. Where an obligation starts on one date and its first
filing is due on another, give two rows.

For each row give: date, rule, a link to the official text if you know it, what
it asks of us in plain words, and which of my systems it could touch.

RULES YOU DO NOT BREAK
1. Do not decide whether a rule applies to us. Where it depends on facts you
   don't have, say which fact decides it.
2. Do not fill owner, evidence or checked_by. Leave them null. I will fill them,
   and I will not be typing colleagues' names into a chat window.
3. A role or a team in owner or checked_by counts as blank.
4. A row marked not ours needs one sentence of reason from me. Do not write it
   for me.
5. Do not tell me we are compliant, or that a row is low risk.

THEN WALK ME through the rows one at a time, asking for status (ready, gap, or
not ours) and, for not ours, my reason.

OUTPUT
Valid JSON matching the schema obligation-calendar/v0.1 as published at
https://sigsub.show/takeaways/obligation-calendar/, then the same rows as a
table, then the four counts: rows with no named owner, rows with no evidence,
rows marked not ours without a reason, and rows nobody qualified has checked.
End with one sentence naming the row I should take to a qualified person first.

What to check in the answer

It may list dates, rules and what they ask, naming its source and its training cutoff; if it names neither, every row is unverified. It may never decide whether a rule applies to us, never fill owner, evidence or checked_by, and never tell us we're compliant or that a row is low risk.

The part that's not optional

Take the calendar to a qualified person before anyone relies on it: someone with legal, regulatory or compliance expertise who will put their name in checked_by. A model is a great place to start the list and the wrong place to finish it.

Then put the owners' dates in their actual calendars. A row that lives only in this table is a row nobody will see on the day.

{
  "schema": "obligation-calendar/v0.1",
  "as_of": "the date the list was built",
  "source": "the source the dates came from, or the model's own knowledge",
  "model_cutoff": "the model's stated training cutoff",
  "rows": [
    {
      "date": "2027-01-01",
      "kind": "starts | first filing due",
      "rule": "the law or regulator",
      "rule_url": "a link to the official text",
      "asks": "what it asks of us, in plain words",
      "touches": "the system, tool or vendor it would apply to, or none",
      "verified": true,
      "owner": null,
      "evidence": null,
      "checked_by": null,
      "status": "ready | gap | not ours",
      "not_ours_reason": null
    }
  ],
  "counts": {
    "no_owner": 0,
    "no_evidence": 0,
    "not_ours_without_reason": 0,
    "unchecked": 0
  }
}