Interactive report
A report where every figure can be opened to the numbers behind it, and every scenario can be tried.
The formatAvailable
An IDOP document combines content, interface, logic and data in one portable file. Any conforming reader can open it, check it, and run it safely — and what you enter is saved back into the file.
IDOP 1.0 at a glance
.idopapplication/vnd.idop+zipmimetype firstcode/ onlystorage/, as revisions§ 01What it is
Most documents are a record of something that was computed, decided or designed elsewhere. An IDOP document can contain the thing itself: the model behind a forecast, the rules behind a form, the exercise behind a lesson.
Technically, an .idop file is a ZIP archive with a small, strict structure: a manifest that says what the document is and what it may ask for, its interface and logic as ordinary web code, passive resources such as images and data, and its saved state. Because the structure is specified, a reader can check every byte of a file before anything in it runs.
The format is published as an open specification, with JSON Schemas and stable error codes, so that IDOP documents do not depend on any single application — including ours.
§ 02Why it exists
§ 03What makes it different
IDOP is not meant to replace every document format. It is meant for documents that are more useful when they can be operated.
| Aspect | Traditional document | IDOP document |
|---|---|---|
| Content | Primarily static text, tables and images | Content plus an interface that responds |
| Behaviour | Fixed presentation | Programmable behaviour, defined by the document |
| Logic | Lives in an external tool | Travels inside the file, next to the content it explains |
| Interaction | Reading, annotating, printing | Application-like interaction: inputs, views, workflows |
| Data | Exported, copied or re-keyed | Saved in the file as revisions; exportable as data |
| Safety | Mostly passive content; macros and scripts vary by format | Validated before execution; sandboxed; no network unless allowed |
§ 04What a document contains
Every entry in an IDOP package begins with one of these roots. Anything else is refused. Select an entry to see what it holds and who writes it.
budget.idop
mimetypeIdentificationThe first entry of every package, stored uncompressed. Its content puts the media type at byte offset 38, so software can recognise an IDOP file without unpacking it.
application/vnd.idop+zipidop.jsonManifestWhat the document is and what it may ask for: the application, the document’s identity and revision lineage, the entry point, and every network capability with the origins, methods and purpose it declares. It never contains a secret.
{
"format": "https://idoplabs.com/ns/idop/package",
"formatVersion": "1.0",
"entryPoint": "code/index.html",
"application": { "id": "com.example.budget",
"title": "Project budget" },
"requiredCapabilities": []
}code/Interface and logicHTML, CSS, JavaScript and JSON — the only part of a package that can run. It runs inside the reader’s sandbox, with no network and no access to the reader. Inline scripts, remote URLs and dynamic evaluation are refused before anything runs.
code/
├── index.html <script type="module" src="app.js">
├── app.js await idop.storage.write(…)
└── style.cssresources/Passive filesImages, fonts and data files the interface displays. The reader serves them to the document by path; nothing under resources/ is ever executed, and a script placed there causes the package to be refused.
resources/
├── icon.svg
├── fonts/inter.woff2
└── data/rates.csvstorage/Saved stateThe document’s data, saved in the file. The document reads and writes it only through the Runtime API; changes stay in a working copy until the user saves, and every Save produces a new revision.
// inside the document
const { text } = await idop.storage.read('model.json');
await idop.storage.write('model.json', next);_idop/Reserved by the specificationNames the specification keeps for itself. IDOP 1.1 defines an optional thumbnail here; publisher signatures and encryption metadata are reserved for future versions. A 1.0 reader ignores this root.
_idop/
├── thumbnail.png 1.1 draft
├── signatures/ reserved
└── encryption/ reservedextensions/Extension dataData for named extensions, each under its own reverse-domain namespace, so extensions cannot collide with each other or with the format.
extensions/
└── com.example.review/
└── comments.jsonThe complete rules — paths, limits, the manifest’s members — are in sections 4 to 8 of the specification. A walkthrough for developers is on the file format page.
§ 05How people use it
An IDOP document behaves like a file because it is one. This is the whole life of a document, as a person experiences it.
Receive
A colleague sends budget.idop, or you download it, or you start from a template.
Open
A reader validates the entire file. A broken or non-conforming file is refused, not half-run.
Consent
If the document declares network access, you see where it wants to go and why — and decide.
Use
The document runs in its sandbox. You work in it; it keeps your changes in a working copy.
Save
Saving writes a new revision into the same file. Nothing changes until you save.
Share
Send the file on, or share a link from IDOP Cloud. Your data travels in it; your keys do not.
§ 06Format, readers and IDOP Cloud
§ 07Architecture
Validation first, then a sandbox with a single, narrow channel to the reader. Every request the document makes passes through rules it cannot change.
Input
.idop file
Untrusted until proven otherwise.
Step 1 · Reader
Validation before execution
Any failure refuses the whole file, with a stable error code. Nothing runs before all checks pass.
Step 2 · Running
Sandbox
The document’s code. Opaque origin, no network, no access to the reader or other documents.
code/**Reader
Answers each request — or refuses it.
storage/Step 3 · Save
A new revision
Only storage/ and the revision in idop.json change. The result is validated again before it replaces the file.
§ 08Use cases
Documents whose value is in being used: explored, filled in, recalculated, kept.
A report where every figure can be opened to the numbers behind it, and every scenario can be tried.
A scoring or dosing formula that carries its own references and versioned logic, so the calculation a reviewer approved is the one that runs. Illustration only — not medical software.
Lessons, exercises and quizzes in one file a student keeps: progress is saved inside it, and it works offline.
A dataset with its own filters and views, so the reader explores the data rather than a screenshot of it.
§ 09Questions
The code is ordinary web code, which is deliberate: it is what most people who build interfaces already know. What IDOP adds is the contract around it — a fixed structure a reader can validate, a sandbox with no network by default, a small Runtime API for saving state, declared capabilities with user consent, and revisions saved into the file.
No. Any reader that implements the specification can open IDOP documents. IDOP Cloud is the reader we build and operate; it also adds storage, sharing and templates.
Only if its manifest declares the exact origins, methods and purpose, and you allow it. Without that, a document has no network access at all. API keys are added by the reader and are never visible to the document.
A document saves its state inside the file, under storage/, when you choose to save. Each save creates a new revision. You can keep, copy, send or delete the file like any other.
IDOP 1.0 is a Candidate Recommendation: the container and manifest are frozen, with editorial changes only. Minor versions are additive — a 1.0 document stays valid. IDOP 1.1 is a working draft.
IDOP Cloud runs in the browser. Start from a template, open a file you were sent, or keep your own — no installation, and no account needed just to open a document.