OLAMIP Delta Updates

*olamip-delta.json provides incremental updates that keep AI systems synchronized with your website as it changes. Instead of reprocessing the full OLAMIP snapshot, AI agents ingest only new, updated, or removed entries. This ensures fresher data, faster processing, and scalable alignment for dynamic sites such as stores, blogs, and documentation portals.

Keeping AI Systems Synchronized as Your Website Changes

Modern websites change continuously. New products are published, articles are revised, documentation pages are added or retired, and seasonal or campaign-driven content comes and goes. If an AI system only ingests a static snapshot of a website, it will quickly drift out of sync with the site’s current state.

olamip-delta.json solves that problem by providing an incremental update mechanism for OLAMIP. Instead of reprocessing the entire OLAMIP file every time the site changes, AI systems can ingest only the changes that occurred since the last refresh.

What is olamip-delta.json?

*olamip-delta.json is an optional companion file to olamip.json that lists only the changes since the last update. It records added, updated, and removed entries so AI systems can process incremental modifications instead of re‑ingesting the entire site snapshot.

olamip-delta.json is the delta file used by the OLAMIP-DELTA protocol. It is an optional companion to olamip.json, which remains the authoritative, complete snapshot of the site.

The delta file contains only changes since the last update, including:

  • Newly added entries, sections, or subsections.
  • Updated entries, sections, or subsections.
  • Removed entries, sections, or subsections.

Together, olamip.json and olamip-delta.json let a website behave like a stream of structured changes rather than a static metadata dump.

Why Delta Updates Matter for AI

*Delta updates help AI systems stay current by processing only meaningful changes. This improves efficiency, keeps content fresh, scales to large sites, and ensures AI agents remain aligned with live website updates across e‑commerce, news, documentation, and other frequently changing platforms.

Delta updates give AI systems several practical advantages:

  • Efficiency: Only changed content must be processed.
  • Freshness: New and revised content becomes available quickly.
  • Scalability: Large sites remain manageable because updates are incremental.
  • Precision: AI systems can apply only meaningful changes.

For e-commerce stores, news publishers, documentation portals, and content-heavy blogs, this makes it much easier to keep AI systems aligned with the live website.

Protocol Relationship

*OLAMIP-DELTA works alongside the main OLAMIP file by describing how the site has changed over time. While olamip.json provides the full current snapshot, olamip-delta.json supplies the incremental change log that AI systems apply between refreshes.

OLAMIP-DELTA is a separate protocol from the main OLAMIP file format. The main file describes the current state of the site. The delta file describes how that state changed over time.

In practical terms:

  • olamip.json = authoritative full snapshot.
  • olamip-delta.json = incremental change log.

Validation Rules and Requirements

*OLAMIP delta files must follow strict validation rules to ensure each change record is consistent, canonical, and safe for AI ingestion. Implementations must validate file‑level metadata, enforce URL requirements, and ensure added, updated, and removed entries follow the protocol’s structural constraints.

This section defines the validation constraints that govern OLAMIP delta files. These rules ensure that each change record is structurally consistent, machine-readable, and safe to ingest.

Implementations should enforce these rules to preserve protocol integrity, maintain canonical URL references, and prevent ambiguous or conflicting updates.

File-level Rules

  • protocol must be "OLAMIP-DELTA".
  • version must match the documented version scheme.
  • window_days, if present, must be a positive integer, typically between 7 and 30.
  • deltas must be non-empty.
  • Each delta object must contain a date in ISO 8601 format (YYYY-MM-DD).
  • deltas must be sorted by date in ascending order.

Operation Rules

For each delta object:

  • added entries must include url.
  • updated entries must include url.
  • removed entries must include url.
  • url in all three operations must be an absolute, canonical URL.
  • No url should appear more than once in the same delta object.
  • For consistency, all three operation fields should be present in every delta object, even when some are empty arrays.

Entry Rules

  • added items should be full OLAMIP objects for the affected type.
  • updated items must include url and may be either:
    • a partial object containing only changed fields, or
    • a full object containing all fields.
  • Missing fields in updated are treated as unchanged.
  • removed items must include only url and no other fields.

Basic OLAMIP-Delta File Structure

*A basic OLAMIP‑Delta file defines the protocol version, the rolling window of retained changes, and a list of dated delta objects. Each delta includes added, updated, and removed items, even when empty, ensuring a consistent structure that AI systems can ingest predictably and without ambiguity.

A minimal rolling delta file looks like this:

{
  "protocol": "OLAMIP-DELTA",
  "version": "1.0.0",
  "window_days": 7,
  "last_updated": "2026-03-02",
  "deltas": [
    {
      "date": "2026-03-02",
      "added": [],
      "updated": [],
      "removed": []
    }
  ]
}

For machine-interpretable clarity and consistency, webmasters should include all three operation fields—added, updated, and removed—in every delta object, even when some are empty. If a date includes only additions, the other two arrays must still appear as empty arrays. If a date includes only updates, the other two arrays must still appear as empty arrays. If a date includes only removals, the other two arrays must still appear as empty arrays.

This uniform shape makes ingestion logic predictable and simplifies logs, debugging, and pipeline testing.

How olamip-delta.json Works

*olamip-delta.json records incremental changes to your site so AI systems can update their index without reprocessing the full OLAMIP snapshot. Each delta date lists items to add, update, or remove, and AI agents apply only deltas newer than their last known sync point.

The basic workflow is straightforward:

  1. Publish olamip.json as the full canonical snapshot.
  2. Generate olamip-delta.json whenever content changes.
  3. AI systems ingest the delta and apply the changes.
  4. Repeat this process as the site evolves.

In operational terms:

  • added → append to the index.
  • updated → overwrite the existing indexed record for that URL.
  • removed → delete the indexed record for that URL.

AI systems should only apply deltas with a date later than the last sync point they know about.

Rolling Delta Window

*A rolling delta window preserves all changes from the last 7–30 days, preventing data loss when crawlers miss daily updates. By retaining recent additions, updates, and removals, the delta file ensures AI systems stay synchronized even when ingestion is delayed or infrequent.

A common failure mode in incremental ingestion is the missed-update problem: if crawlers do not fetch the delta file every day, older updates may be lost.

To reduce that risk, OLAMIP recommends a Rolling Delta Window. Instead of storing only the most recent changes, the delta file should retain all changes from the last 7–30 days, depending on the update cadence of the site.

This ensures that:

  • AI systems can crawl weekly or monthly without data loss.
  • Webmasters do not need to coordinate publishing schedules with crawler timing.
  • Sites remain synchronized even when crawlers are delayed.

Rolling Delta Example for Entries

*A rolling delta file contains multiple dated change sets, each listing added, updated, or removed entries. AI systems process these deltas in chronological order, applying removals, overwrites, and new additions to maintain an accurate, up‑to‑date representation of the site’s content.

The following example shows daily deltas within a 7-day window.

{
  "protocol": "OLAMIP-DELTA",
  "version": "1.0.0",
  "window_days": 7,
  "last_updated": "2026-03-05",
  "deltas": [
    {
      "date": "2026-03-03",
      "added": [],
      "updated": [],
      "removed": [
        {
          "url": "https://example.com/product/c"
        }
      ]
    },
    {
      "date": "2026-03-04",
      "added": [],
      "updated": [
        {
          "url": "https://example.com/product/b",
          "summary": "Updated description reflecting new features."
        }
      ],
      "removed": []
    },
    {
      "date": "2026-03-05",
      "added": [
        {
          "title": "New Product A",
          "url": "https://example.com/product/a",
          "summary": "A new addition to our catalog.",
          "tags": ["product", "new"]
        }
      ],
      "updated": [],
      "removed": []
    }
  ]
}

The summary text in this example is illustrative only. Webmasters should generate actual summaries that accurately describe the item being added or updated, rather than using the example wording literally.

Section and Subsection Deltas

*The delta protocol applies to sections and subsections as well as individual entries. Structural changes—such as new categories, renamed groups, or retired collections—must be represented using added, updated, and removed operations so AI systems can track both content and hierarchy changes accurately.

The delta protocol applies not only to lowest-level entries, but also to the site’s structural hierarchy: sections and subsections.

This is important because AI systems do not only need to know which pages exist. They also need to understand how those pages are organized. A section may represent a blog category, documentation category, product collection, project group, or other structural grouping. A subsection may represent a nested grouping within that hierarchy.

When a section or subsection changes, it should be represented using the same delta operations:

  • added for new sections or subsections.
  • updated for renamed or revised sections or subsections.
  • removed for retired sections or subsections.

Adding a Section or Subsection

When adding a new section or subsection, include a full section object in added. The object should use the same fields defined in the main OLAMIP file specification.

Example:

{
  "date": "2026-05-01",
  "added": [
    {
      "title": "Tutorials",
      "summary": "Step-by-step guides for beginners and advanced users.",
      "url": "https://example.com/tutorials/",
      "section_type": "blog_category",
      "policy": "allow",
      "tags": ["tutorials", "beginner", "advanced"],
      "priority": "medium"
    }
  ],
  "updated": [],
  "removed": []
}

Instruction:

When adding a section or subsection, use a canonical absolute URL and a section type that reflects the semantic role of the content, such as blog_category, doc_category, or product_collection.

Updating a Section or Subsection

When updating a section or subsection, include the url plus any fields that changed. Missing fields are treated as unchanged.

Example:

{
  "date": "2026-05-02",
  "updated": [
    {
      "url": "https://example.com/blog/tutorials/",
      "title": "Step-by-Step Tutorials",
      "summary": "Guides for beginners and advanced users, with code examples and best practices.",
      "tags": ["tutorials", "beginner", "advanced", "code-examples"]
    }
  ],
  "added": [],
  "removed": []
}

Instruction:

updated may be either a partial object or a full replacement object. Any field not present should be treated as unchanged.

Removing a Section or Subsection

When a section or subsection is removed, include only the url in removed.

Example:

{
  "date": "2026-05-03",
  "removed": [
    {
      "url": "https://example.com/blog/retired/"
    }
  ],
  "added": [],
  "updated": []
}

Instruction:

The url must be the canonical URL of the section or subsection being removed. It must not be partial, ambiguous, or inferred from a path fragment.

Validation Rules for Section-Level Deltas

The same validation rules apply to sections, subsections, and entries:

  • added sections must include title, summary, url, and section_type.
  • updated sections must include url.
  • removed sections must include url and no other fields.
  • url in all operations must be an absolute, canonical URL.
  • No url should appear more than once in the same date object.

This keeps structural updates aligned with entry-level updates and ensures that AI systems can track hierarchy changes as well as page-level changes.

Versioned Delta Files

*Versioned delta files store each day’s changes in a separate document rather than a rolling window. AI systems discover all delta files, sort them by date, and apply them sequentially. This model suits high‑volume sites such as news publishers, large catalogs, and frequently updated documentation platforms.

Some webmasters may prefer separate delta files instead of one rolling file. In that model, each file contains the changes for one date.

Example directory:

yoursite.com/olamip.json
yoursite.com/olamip-delta-2026-03-01.json
yoursite.com/olamip-delta-2026-03-02.json
yoursite.com/olamip-delta-2026-03-03.json

A versioned delta file uses the same logical structure, but it represents only one change date.

Example:

{
  "protocol": "OLAMIP-DELTA",
  "version": "1.0.0",
  "date": "2026-03-02",
  "added": [
    {
      "title": "New Blog Post",
      "url": "https://example.com/blog/new-post",
      "summary": "A short overview of the latest update.",
      "tags": ["blog", "update"]
    }
  ],
  "updated": [],
  "removed": []
}

AI systems should discover all delta files in the directory, sort them by date, and apply them in order. Files older than the supported window can be ignored.

This approach is especially useful for:

  • News sites.
  • High-volume e-commerce catalogs.
  • Documentation platforms with frequent releases.

How Long Should Deltas Be Kept?

*Delta retention depends on how frequently a site updates. The goal is to keep enough recent history to cover normal crawler delays without letting the delta file grow unnecessarily. Faster‑changing sites use shorter windows, while slower‑changing sites benefit from longer retention.

The recommended retention period depends on the update cadence of the site:

  • Daily updates: 7 days.
  • Weekly updates: 14–30 days.
  • Monthly updates: 30–60 days.
  • High-volume sites: at least 30 days.

The goal is to keep enough history to bridge normal crawler delays while avoiding unnecessary file growth.

How AI Systems Discover the Delta File

*AI systems discover olamip-delta.json automatically by locating olamip.json through standard link and meta tags, then checking the same directory for the delta file. This avoids extra HTML markup and lets agents apply rolling or versioned deltas without additional webmaster configuration.

Webmasters do not need to add a <link> tag for olamip-delta.json.

AI systems should:

  • Discover olamip.json using the <link> and <meta> tags in the site <head>.
  • Look for olamip-delta.json in the same directory.
  • Apply either rolling or versioned deltas automatically.

This keeps the protocol simple and avoids cluttering the HTML with extra discovery metadata.

Why LLMs.txt Falls Short

*llms.txt does not support structured change tracking. It lacks added, updated, and removed fields, provides no canonical URL mapping, and offers no incremental ingestion model. OLAMIP‑DELTA fills this gap by defining a machine‑readable stream of changes that AI systems can apply reliably.

The proposed llms.txt approach does not define structured delta updates. It does not provide:

  • A way to express what changed.
  • Added / updated / removed structure.
  • Summaries tied to canonical URLs.
  • An incremental ingestion model.

OLAMIP-DELTA addresses these gaps by providing a structured change stream that AI systems can process reliably.

Why Delta Support is Essential for the AI-Readable Web

*Delta updates keep AI systems synchronized with a site as it evolves. By supplying incremental changes instead of full snapshots, olamip-delta.json makes websites AI‑readable, AI‑maintainable, and AI‑synchronized, giving agents an efficient way to track ongoing content updates.

As AI systems become more deeply integrated with the web, the central question is no longer whether they can read a site, but whether they can stay synchronized with it efficiently.

Delta updates are the answer.

By adopting olamip-delta.json, you make your site:

  • AI-readable.
  • AI-maintainable.
  • AI-synchronized.

You give AI systems a clean, incremental way to track website evolution over time.

Best Practices

*Reliable delta generation requires integrating updates into your CMS or deployment pipeline. Webmasters should refresh olamip-delta.json whenever content changes, maintain accurate timestamps, use stable canonical URLs, and preserve a complete olamip.json so new AI systems can bootstrap before applying deltas.

For reliable operation, webmasters should:

  • Tie delta generation to the CMS or deployment pipeline.
  • Update olamip-delta.json whenever content is published, revised, or removed.
  • Keep last_updated accurate.
  • Use stable canonical URLs as identifiers.
  • Preserve a current olamip.json so new AI systems can bootstrap from the full snapshot before applying deltas.

Summary of Roles

*OLAMIP provides the full site snapshot, while OLAMIP‑DELTA supplies the incremental change log. Rolling deltas protect against missed updates, versioned deltas suit high‑volume publishing, and llms.txt does not support structured changes. Together, they create a continuously updated, AI‑readable representation of the site.

  • olamip.json — full, structured snapshot.
  • olamip-delta.json — incremental change log.
  • Rolling deltas — protect against missed updates.
  • Versioned deltas — useful for high-volume publishing workflows.
  • llms.txt — does not provide structured delta support.

If you care about how AI understands your site and how that understanding stays current, OLAMIP-DELTA is the missing piece that turns static metadata into an evolving, machine-readable signal.