npm install @dotit/core      # the format: parse, render, merge, query, trust
npm install @dotit/pdf       # optional: server-side PDFs (issue → seal → PDF)
npm install -g @dotit/mcp    # the MCP server for AI agents

1.0 is a statement, not just a version bump: the line grammar, the 38 canonical keywords, and the trust model are stable. And this release ships the feature we've wanted since the beginning — documents that aren't just readable in any language, but written in any language.

Arabic keywords, as written​

The keyword grammar is now Unicode (\p{L} words), so domain keywords in Arabic — or any script — parse as typed, queryable blocks exactly like ASCII ones:

مصروف: كراسي مكتب | المورد: ايكيا | فئة: أثاث | date: 2026-06-12

That's a typed block with keyword مصروف, queryable by Arabic property (فئة = أثاث) and by ISO date range.

But custom keywords were never the hard part. The hard part was semantics — and that's what the 33 registered Arabic aliases deliver. عنوان is title. قسم is section. مهمة is task. صف is row, أعمدة is columns, مؤشر is metric, توقيع is sign, اعتماد is approve, تجميد is freeze. An Arabic document gets full canonical behavior — totals rows, contact cards, signatures, deadline logic — and one query (type:task) finds tasks across languages.

The detail that makes this real: aliases now round-trip as written. documentToSource re-emits the keyword the author used (block.keywordAlias) instead of normalizing to canonical English. An Arabic document stays Arabic through every parse → serialize cycle. abstract: stays abstract:. Table keywords (أعمدة/صف, headers) are preserved too.

This matters most for trust. A sealed document's hash covers the exact bytes — if serialization rewrote توقيع as sign, the seal would break on the first round-trip. Now it doesn't. Sealed Arabic documents keep their hash.

Dates are ISO 8601​

One language did get standardized: dates. Date-bearing properties (date, due, at, expires, issued) are canonically YYYY-MM-DD (or full ISO timestamps), and the semantic validator now flags locale formats with a DATE_NOT_ISO warning.

09/03/2026 is ambiguous — March 9th or September 3rd, depending on who's reading — and it breaks the query engine's date-range comparisons, which work out of the box with ISO values. Write the content in any language; write the dates in ISO.

Escaping that survives round-trips​

| is the reserved property delimiter, and \| has always parsed correctly into a literal pipe. But the serializer emitted it back unescaped — so re-parsing split it as a property delimiter. Data corruption, two round-trips in.

Fixed. The serializer now re-escapes \ and | in content and property values, so escape round-trips are a fixpoint: parse → serialize → parse gives you the same document, every time.

A fuzz-tested parser​

1.0 also marks the start of the hardening track. The new fuzz/property suite throws 500 random structured documents, 200 random byte-soup inputs, and a gallery of pathological cases (10K newlines, 5K pipes, 100KB hash values, BOM, CRLF, deep nesting) at the full pipeline — parse → render → print → serialize → re-parse → hash → verify → merge — with one rule: never throw. Deterministic seeds, so every failure reproduces.

It already paid for itself: the suite found a stack-overflow DoS where a single ~10KB line of repeated list markers crashed the parser — a real risk for any server parsing untrusted .it. Fixed in 4.3.1, carried into 1.0. 897 tests passing.

What you need to do​

• New projects: install @dotit/core (and @dotit/pdf / @dotit/mcp as needed).
• Existing projects: swap @intenttext/* for @dotit/* in package.json and imports. The API is unchanged — it's the same code.
• Your .it files: nothing. The format is the format.

One format, every language, version 1.0.

Core API → · MCP Server →

The amendment story​

Frozen documents have a problem. After you seal a contract, reality changes. Payment terms get renegotiated. Scopes expand. Parties are replaced. Until v2.11, your only option was to create a new document.

The amendment: keyword gives frozen documents a formal amendment path:

amendment: Payment terms revised
  | ref: Amendment #1
  | section: Payment Terms
  | was: Net 30
  | now: Net 15
  | by: Ahmed Al-Rashid
  | at: 2026-03-07T09:00:00Z

Amendments are recorded in the trust history. They reference the section they modify, capture what changed, and track who authorized the change. The original document remains sealed — the amendment sits alongside it as an auditable record.

intenttext amend contract.it --section "Payment Terms" --was "Net 30" --now "Net 15" --ref "Amendment #1"

This is how legal teams actually work. Contracts get amended, not rewritten.

The metric story​

Organizations measure things. Revenue, expenses, conversion rates, uptime. Until now, these numbers lived in spreadsheets or dashboards — separate from the documents that give them context.

metric: Revenue | value: $4.2M | target: $4.0M | status: above | trend: up
metric: Customer Churn | value: 2.8% | target: 3.0% | status: below | trend: stable
metric: NPS Score | value: 72 | target: 65 | status: above | trend: up

Now you can query metrics across all your reports:

intenttext query ./reports --type metric --format table

Your quarterly reports become a queryable dashboard. No BI tool required.

The contact story​

Every organization has contacts scattered across documents — in contracts, proposals, invoices, HR files. Finding "everyone at Acme Corp" means opening dozens of files.

contact: Ahmed Al-Rashid | role: CEO | email: ahmed@acme.com | org: Acme Corp | phone: +1-555-0100

One query:

intenttext query ./company --type contact --format csv > contacts.csv

Your documents become a contact directory.

The deadline story​

Contracts have deadlines. Projects have milestones. Policies have renewal dates. These dates are critical — missed deadlines have consequences.

deadline: Phase 1 delivery | date: 2026-04-30 | consequence: Penalty clause applies
deadline: Contract renewal | date: 2026-12-31 | authority: COO

Query them:

intenttext query ./company --type deadline --sort date:asc --format table

Your document folder becomes a deadline tracker. Sort by date, filter by authority, export to CSV. No project management tool required for the basics.

Four more keywords​

• def: — Term definitions with meaning. Build glossaries, define jargon, create reference sections.
• figure: — Images with captions and numbering. figure: Architecture diagram | src: arch.png | number: 1
• signline: — Signature lines for print. signline: | role: CEO | date: true | line: true
• cite: — Formal citations with source, author, and date.

The vision​

We think AI agents will produce .it files alongside .md files. When an agent generates a contract, a report, or an invoice, the output should be structured — not just readable. IntentText gives agents a format where every block has a keyword, every property is named, and every document is queryable.

Eight new keywords. 718 tests passing. The format keeps growing because documents keep needing more.

See the full v2.11 reference →

Themes without npm​

Every theme is a JSON file with four sections: fonts, colors, spacing, and optional block overrides. No CSS to write. No build step. No npm package.

{
  "name": "corporate",
  "fonts": {
    "body": "Inter",
    "heading": "Inter",
    "mono": "JetBrains Mono",
    "size": "10pt",
    "leading": "1.5"
  },
  "colors": { "text": "#1a1a1a", "heading": "#111", "accent": "#2563eb" },
  "spacing": { "page-margin": "1in", "section-gap": "2rem" }
}

Apply it:

intenttext document.it --html --theme corporate

Eight themes ship built-in: corporate, minimal, warm, technical, print, legal, editorial, dark. Each is designed for a specific use case — legal themes use serif fonts, technical themes use monospace headers, editorial themes have generous whitespace.

The Hub​

The IntentText Hub at intenttext-hub.vercel.app is a two-tier platform:

1. Templates — Complete .it files with {{variable}} placeholders. Pull them, merge your data, render.
2. Themes — JSON theme files. Pull them, apply to any document.

We've seeded the Hub with 76 templates across 8 domains: business, legal, finance, HR, technical, education, healthcare, and government. Every template works with every theme.

Publishing​

Anyone with a GitHub account can publish:

intenttext hub login
intenttext hub publish invoice-premium.it --domain finance --description "Premium invoice with line items"

Templates are validated before publishing. They must parse cleanly, include at least one variable, and match their declared domain.

Shallow indexes​

v2.10 introduces .it-index files — shallow indexes that summarize a folder of .it documents:

intenttext index ./contracts

This produces a JSON file with metadata and block summaries for every .it file in the folder. Queries then run against the index instead of re-parsing every file:

intenttext query ./contracts --type deadline --format table

The architecture is deliberately shallow — each index covers one folder, no recursion. Compose indexes across folders for cross-cutting queries.

76 templates​

The seeded templates cover real document types:

Every template is a real, complete document — not a skeleton. Pull one and you have a working starting point.

Browse templates on the Hub →

The philosophy: you own the format. The CLI gives it trust.

The problem with document trust​

Organizations sign PDFs. They email Word docs back and forth. They track changes with version history buried in a proprietary app. None of this is portable, verifiable, or queryable.

What if trust was part of the document itself?

Five new keywords​

track:​

Enables the trust system for a document:

track: | version: 1.0 | by: Ahmed

This tells the parser to maintain a trust history — a registry of every block and a log of every change.

approve:​

Records an approval with the approver's identity:

approve: Reviewed by legal | by: Sarah Chen | role: Legal Counsel

sign:​

Records a cryptographic signature:

sign: Ahmed Al-Rashid | role: CEO | at: 2026-03-06T14:32:00Z

freeze:​

Seals the document. After this, any content change invalidates the hash:

freeze: | status: locked

revision:​

Records a version change in the trust history:

revision: Updated payment terms | by: Ahmed | at: 2026-03-07

How it works​

When you seal a document with the CLI (intenttext seal contract.it --signer "Ahmed"), the system:

1. Computes a SHA-256 hash of the document content
2. Adds a sign: block with the hash
3. Adds a freeze: block that locks the document

Later, intenttext verify contract.it recomputes the hash and checks it against the seal. If anyone changed a single character, the verification fails.

The trust data lives in the same .it file — below a history: boundary. It's human-readable. It's version-controlled. It travels with the document.

The organizational use case​

An HR department with 200 employment contracts:

intenttext query ./contracts --type approve --format table
intenttext query ./contracts --type sign --format table
intenttext verify ./contracts --recursive

Three commands. You know who approved what, who signed what, and whether any document has been tampered with. No PDF viewer required. No proprietary tool.

Read the trust documentation →

The print problem​

Every organization eventually needs to print something. A contract for signing. An invoice for records. A report for the board. Until v2.9, IntentText rendered clean HTML but had no concept of page layout.

Word processors solve this with WYSIWYG editors. LaTeX solves it with a typesetting language. Both are overkill for structured documents. You shouldn't need a page layout tool to put a logo in the header.

Six new keywords​

page:​

Set paper size and margins:

page: | size: A4 | margin: 1in

font:​

Control typography:

font: | body: Georgia | heading: Helvetica | size: 11pt

header:​

Three-zone page header (left, center, right):

header: | left: Acme Corp | center: CONFIDENTIAL | right: {{date}}

footer:​

Three-zone page footer:

footer: | left: Page {{page}} of {{pages}} | right: Ref: CONTRACT-042

watermark:​

Diagonal text overlay:

watermark: DRAFT | opacity: 0.08

break:​

Force a page break:

break: page

The three-zone layout​

Headers and footers use a three-zone model: left, center, right. This covers 95% of real document headers without requiring a layout engine:

header: | left: Company Name | center: Document Title | right: Page {{page}}
footer: | left: Confidential | right: Printed: {{date}}

The renderer maps these to CSS @page rules with running headers and footers. The result works in print-to-PDF workflows and dedicated PDF exporters.

Real examples​

A legal contract with full layout:

title: Master Service Agreement
page: | size: letter | margin: 1.25in 1in
font: | body: Times New Roman | heading: Arial | size: 11pt
header: | left: Acme Corp | right: MSA-2026-042
footer: | left: Confidential | center: Page {{page}} of {{pages}} | right: v1.0
watermark: DRAFT

section: Terms
text: ...

Render with intenttext contract.it --print --theme legal and you get a document that looks like it came from outside counsel.

See the print cookbook →

IntentText is a new open format that refuses the tradeoff.

The problem​

Organizations run on documents — contracts, invoices, reports, policies. These documents carry structured intent: deadlines, approvals, signatures, metrics, contact information. But in every existing format, that intent is buried in prose. You can read it. Your code cannot.

Markdown gets close. It's readable. It's plaintext. But try querying all deadlines across your contracts folder. Try sealing a document so no one can tamper with it. Try merging a template with your CRM data. Markdown has no answer.

The dual-purpose insight​

A document should be written once and serve two audiences:

1. Humans read it as a professional document — themed, printable, clear.
2. Machines parse it as structured data — queryable, composable, trustworthy.

This is what IntentText does. A .it file is a plain text document where every line starts with a keyword that declares its intent.

title: Service Agreement
summary: Consulting services Q2 2026
meta: | client: Acme Corp | ref: CONTRACT-2026-042

section: Scope
text: Strategic consulting for platform migration.
deadline: Phase 1 complete | date: 2026-04-30

section: Parties
contact: Ahmed Al-Rashid | role: CEO | email: ahmed@acme.com | org: Acme Corp

approve: Reviewed by legal | by: Sarah Chen | role: Legal Counsel
sign: Ahmed Al-Rashid | role: CEO | at: 2026-03-06T14:32:00Z
freeze: | status: locked

That's a complete contract. A human reads it clearly. But your code can also:

• Parse it into a typed AST
• Query all deadlines across 500 contracts
• Verify the document hasn't been tampered with
• Merge it from a template with CRM data
• Render it as a themed PDF

One file. Both audiences. No conversion step.

What's in the box​

IntentText ships as a core npm package (@dotit/core) with:

• A stable canonical keyword core with aliases and extensions for document identity, content, structure, data, agent workflows, trust, and print layout
• 8 built-in themes for professional rendering
• A query engine that works across files and folders
• A trust system — approvals, signatures, sealing, and tamper detection
• Template merging with {{variable}} syntax and {{each:}} loops

Plus an ecosystem: CLI, VS Code extension, MCP server for AI agents, Python SDK, web editor, and the Hub for community templates.

What's coming​

This is v2.11 — the result of rapid iteration on what documents actually need. We're working on:

• More themes from the community
• Richer query operators
• IDE integrations beyond VS Code
• A desktop app for visual editing

The format is open. The spec is public. If your documents carry intent, they should be .it files.

Get started →