Frequently asked questions

What’s KeepRight for? #

KeepRight (KR) is an open protocol to record and share instructions for keeping things long-term. You can create a Declaration, which is a set of questions and answers that might help future caretakers respect your wishes more easily. It’s not a legal thing, at least not yet, but it is a statement of intent. Declarations can be kept with the material it relates to, and when it’s passed to someone else, they can check what you’d like to have happen.

How do I use KeepRight? #

You can use it in two main ways: 1) on keepright.info (this website) you can make a declaration, or 2) if you’re into coding, you can check out the specification and figure out what’s required to integrate KR into your environment. We've also written a general introduction to rolling your own over here: Building your own KeepRight.

How is this different from copyright? #

Copyright is about property and describes who owns what. If you’re working on keeping something for a really long time, you have other things to consider that copyright doesn’t cover: privacy and perpetuity. You can make a KR declaration about something that’s copyrighted - that just becomes a factor to consider for the future keeper of the materials. The good thing is, it still allows the conversation about future access and conditions to happen, and the copyright status is noted in the declaration.

What should I do with my KeepRight declaration? #

The important thing is to make sure you make a note of it somewhere it won’t get lost. You could even add it to your password manager. (One of those comes in very handy here!) We like the idea of printing them out, too. When you finish making your declaration, there are a few ways you can take note - you can email it to yourself or copy the URL. We’ll make it so you can download a PDF version at some point soon. If the thing you’re making a declaration about is physical, making a print out or card with the URL on and putting it with the materials will be useful for people who need to know that information later. Basically, put the KR declaration near the materials, whether that’s in a physical or digital context.

Wait. What is this thing? #

KeepRight was invented in April 2025 over lunch on a sunny patio in Los Angeles, when George Oates, Joshua Christman, and Jim Bumgardner were talking about the gap between copyright and preservation. The conversation turned to the 95% of creative work that will probably never be commercially exploited but still deserves to be carefully kept, and to the cultural organisations that are perpetually stuck because rights management wasn't designed with stewardship in mind. The "No Known Copyright Restrictions" assertion had proved useful even without a full legal framework behind it. KeepRight started from that same instinct: that creators and keepers needed a simple, human way to say how their work should be looked after that’s separate from copyright, while being able to sit alongside it.

The first version of the protocol has been developed by Deep Keep, a small band of folks who work on software, archives, and ethics, and which includes George and Joshua, and Dan Catt (who designed and built the KeepRight spec), and Tori McKenna. The formal launch is June 1st, 2026 at the IIIF Summer Conference in Leiden, Netherlands.

How do I get involved in this? #

On the feedback page there’s a bunch of ways to connect, and we would love that. It’s an esoteric idea and we want to see if it’s any good.

How do I know my KeepRight Declaration will be available for the long term? #

Declarations made on keepright.info are stored permanently, or as permanently as possible. Each declaration gets its own URL that's designed to last. The Safe Harbor Network, currently in development, will distribute declarations across partner institutions so that no single point of failure can make them disappear. That's not fully in place yet, so in the meantime, keeping your own copy is a good idea. Print it out, email it to yourself, store the URL somewhere safe. The spirit of KeepRight is that declarations travel with materials, so the more places one lives, the better.

Do I need a particular language, framework, or database to use KeepRight? #

No. KeepRight is deliberately boring in the best way: a declaration is just JSON, and everything moves over plain HTTP. There's no SDK to install and no blessed stack; if your tools can read JSON and make a web request, they can speak KeepRight.

Our own tools happen to be small web apps, but you could implement a declaration maker as a static page, a command-line script, a spreadsheet macro (well, maybe, I'd like to see it), or a feature inside an existing system.

That also means storage is your call. We keep declarations in our own store on keepright.info, but a declaration is portable enough to live in a database row, a file on disk, a blob in your asset system or printed out and put into a storage box.

Which version of the spec should I build against, and what happens when it changes? #

Every spec carries a meta block with two version numbers: specVersion (the content; the questions, wording and logic) and schemaVersion (the shape that spec and declarations must conform to) (see below). Right now release is pre-alpha, so expect things to move. Our spec viewer and declaration maker always pull the latest from GitHub, which is great for staying current but risky if you need stability.

For anything production-like, you pin. The spec repo keeps frozen, exact copies under versions/, alongside moving latest copies, so you choose how much movement you're willing to accept.

Pin to an exact version (e.g. versions/spec.2.3.1.json) and nothing ever changes under you. Pin to versions/spec.2.3.latest.json to accept patch-level fixes (typos, clarified labels) but nothing bigger. Pin to versions/spec.2.latest.json to ride everything within major version 2, including new questions and options, while still being protected from a breaking major version change.

Or follow spec.json (or versions/spec.latest.json) for whatever we're throwing around right now. The same idea applies to the spec schema and declaration schema, which are tracked by schemaVersion rather than specVersion.

Whichever you follow, record the exact schemaVersion and specVersion in each declaration you create; that way a declaration always says which versions it was actually written against, even if your maker was following a latest file at the time. There's more on the versioning scheme in the spec README.

Wait! What's the actual difference between schemaVersion and specVersion? #

Think of a paper questionnaire. The schemaVersion is the rulebook for what a questionnaire is even allowed to contain: that there are things called questions, that a question has a label and an answer type, that an answer type can be text or a yes/no or a multiple choice, that questions can be shown or hidden by some logic. The specVersion is the actual sheet of paper; the specific questions we decided to print, in the specific wording, with the specific options.

So when we change the content, we bump the specVersion. Adding a question like "Does it live online?", removing a question, adding a new option to a multiple choice, rewording a label, adding a follow-up; that's all content. The shape of the thing hasn't changed, just what's written on it.

When we change the rules, we bump the schemaVersion. Inventing a brand new answer type like date, adding a new logic operator like notEquals, renaming answerType to something else, or dropping a whole kind of thing; that's grammar. It changes what a tool needs to understand in order to read any spec at all.

Why split them? Because most of the time we'll be fiddling with content, not grammar. A validator or viewer you wrote against one schemaVersion can keep happily reading newer specs that only changed their specVersion, because the shape it learned is still true. It's only when the schemaVersion moves (especially a major bump) that your code might need to learn something new. Keeping content churn off the schema number means tools don't have to be rewritten every time we tweak a question.

If the spec keeps changing, what happens to declarations I've already saved? #

The thing that keeps old declarations meaningful is the question id. Every question has a stable id (like m1 or a1), and a declaration stores each answer against that id, not against the wording of the question.

So a saved answer is really "the answer to m1"; to read it back you line the declaration up with the spec version it was made against and look up what m1 was asking.

The golden rule is that we never reuse an id. If we only fix a typo or clean up the grammar of a question, and the meaning is unchanged, the id stays the same; your old answer still makes perfect sense against the slightly tidier wording. That's a patch-level content change.

But if we fundamentally change what a question is asking, we don't quietly edit it in place. We retire the old id and mint a brand new one; in effect we delete the old question and add a different one. That avoids "drift", where an answer somebody gave to "Is this digital, physical, or both?" could end up attached to a question that now asks something different. Because the id changed, the old answer stays bound to the old (retired) question and its original meaning, rather than being read against the new one.

This is also why we suggest recording the exact specVersion on each declaration. Between the stable id and the version stamp, you can always trace any saved answer back to the precise question (and wording) it was actually answering, no matter how much the spec has moved on since.

Do I actually need your JSON Schemas, and what makes a declaration "valid"? #

No, you don't need the schemas to build a declaration maker; you can read spec.json and run with it. The schemas matter for interoperability.

There are two. The spec schema checks that the spec itself is well-formed; the declaration schema checks that a finished declaration is well-formed. These are the names we'll use from here on.

On GitHub they're the files keepright-spec.*.schema.json and keepright-declaration.*.schema.json. Both follow the schemaVersion number (the grammar, explained above), not specVersion.

A declaration is "a KeepRight declaration" (usable anywhere one is expected) when it validates against the declaration schema. Store declarations in your own format if you like; they just won't be portable to the wider ecosystem. This is covered on the building page.

How do I turn the spec into a form (or any other UI)? #

You walk the items tree. Each item announces its kind, so you switch on that: a section (titled block) and a group (untitled grouping) both contain their own items, so you recurse; a note is read-only text; a question is the thing you actually render an input for.

For questions, map the answerType to a control. The current set is text, email, textarea, radio, checkboxes and select; anything you don't recognise should degrade gracefully rather than break.

Layout, styling, help text and placeholders are entirely yours to decide; the spec only says what to ask, not how it should look. The one thing you must honour is the show/hide logic (visibleWhen and followups), covered just below. There's a worked walk-through with screenshots on the building page.

How do I correctly evaluate the conditional logic (logic.conditions, visibleWhen, followups)? #

This is the part you can't skip if you want to honour the spec. Near the top of the spec, logic.conditions is a named map of boolean expressions over answers; for example material_is_digital_or_both is true when field m1 equals digital or both (an any of equals checks).

Any item with visibleWhen referencing a condition name should only be shown (and answered) when that condition evaluates true. followups are nested questions revealed by a specific option selection on their parent question.

Presentation is yours to design, but the show/hide semantics are part of conformance. A sensible default: don't emit answers for questions that were hidden at submission time. See the worked example on the building page.

What's actually inside a declaration file? #

A declaration is a small JSON object with four top-level parts: an id, a createdAt timestamp, a spec snapshot, and the answers.

The spec snapshot is the clever bit. It records the exact schemaVersion, specVersion and release the declaration was made against, the locale used, and a repo block (owner, name, ref, path and source URL) saying precisely which spec file it pulled from and when. That's what lets you trace any answer back to the exact question it was answering, however far the spec has since moved.

The answers are keyed by question id. Each answer carries not just the value but a snapshot of the question's label, its answerType, and human-readable answerLabels for whatever was chosen. So a declaration is self-describing; you can read it sensibly even without fetching the original spec. The authoritative shape is the declaration schema on GitHub.

Can I mint my own declaration IDs, and how should I store declarations? #

Yes. On keepright.info we generate the ID, persist the declaration, and serve it back from the API by ID. If you self-host (say inside a CMS or DAM), you own the ID space and storage entirely, and can assign IDs in bulk. We suggest using stable, unique, URL-safe IDs since they may end up in URLs and API paths.

Whatever you store, keep a declaration-schema-conformant declaration.json if you want it to travel. There's background on running your own maker on the building page.

How do I attach my declaration to ... stuff? #

George has already answered this a bit here: what to do with your declaration once you've made it, and how we try to keep it available for the long term. This answer is for the metadata-and-systems crowd; how you wire a declaration into the catalogue record, manifest, or package that describes the work.

At minimum, anything that can hold a URL can reference your declaration by id (e.g. /declaration/your-id for humans, /declaration/your-id/json for machines). A sidecar keepright.json next to a digital file works too; the declaration travels even if the link rots.

For structured metadata we've written up concrete patterns on the integrating page: a IIIF Presentation manifest seeAlso pointing at the JSON; Dublin Core dcterms:rights for the human-readable URL and dcterms:hasFormat for the machine-readable record; a keepright.json payload plus KeepRight-Declaration tag in a BagIt bag. The API serves json, txt, md, html, xml and pdf on demand, so your system can fetch the format that fits.

We'd genuinely love more of these. If there's a metadata standard, packaging format, or system you'd like to see a declaration attached to, tell us (or send a pattern you've worked out) via the feedback page.

How does localisation work, and how do I add a language? #

Every human-facing string (titles, descriptions, labels, notes) is an object keyed by a locale code (a BCP 47 language tag), for example { "en-GB": "Name" }. The meta block declares defaultLocale and supportedLocales; today that's just en-GB.

The spec viewer renders per locale (you can see this in the URLs, e.g. /spec-viewer/view/en-GB/text). Some option lists come from external sources rather than the spec text (countries use ISO 3166-1, declared under meta.optionSources).

Mechanically, adding a language just means adding a key alongside the existing one on each string and listing it in supportedLocales. But the spec is new and we're still actively taking feedback, so we're deliberately holding off on translations until the wording and questions have settled.

We're very open to translation feedback and suggestions in the meantime (and we know that making en-GB the initial primary language carries its own assumptions and problems). If you can't wait, you're welcome to fork and maintain a translated version, or keep your translations as patches you apply on top of the latest spec. Once things are more settled we'll start folding additional languages in properly. Do get in touch if you'd like to help.

Can I extend or fork the spec with my own questions without breaking compatibility? #

Yes; the spec is on GitHub precisely so you can fork or extend it. items are arrays of typed things (you walk them by kind), so adding your own questions, groups or sections is straightforward.

The trade-off: declarations produced from an extended spec describe your shape, so they may stop validating against the canonical declaration schema and lose interoperability.

If your additions would be useful to others, propose them upstream via issues or email; we take suggestions for the core, though we can't be all things to all people.