TL;DR: MarTech Ledger is a public, dated and source-linked record of what 15 marketing platforms release, announce and retire, starting on 1 January 2026. A pipeline built around Claude reads vendor release notes on a declared cadence, writes each change into a fixed format and publishes it only after a set of deterministic checks have passed. It is meant for architects, implementation partners, analysts and product-marketing teams who need to know what a platform actually shipped and when, and it leaves every opinion to this site.
The question I kept answering by hand
Every Thursday evening, when the MarTech Watch run closes, I end up answering some version of the same question for at least one platform: is this feature generally available, and since when? It sounds like trivia until you notice how much depends on it. A platform selection turns on it, because a capability that is still in limited preview is a roadmap item and should be priced as one. A migration plan turns on it, because the target platform has to support on the day of cutover what the source platform does today. A client’s roadmap slide turns on it more often than anyone would like to admit.
The vendors do publish the answer, but they publish it in pieces. A feature appears as an announcement on a stage, then as a beta in a release note, then as an early-access item with a different label, then as a GA line in a changelog that may or may not mention the region or the data centre it applies to. Coming back to a feature a few months later means rebuilding its story from those pieces: was it only announced, was it in beta, did general availability cover every region, and was the date on the page the day it shipped or the day some page happened to confirm it existed? The Watch catches each piece in the week it appears, and my movement notes on CEP put the pieces together for a quarter, but both are prose, and prose cannot be queried across fifteen platforms and ten months.
MarTech Ledger is my attempt to turn that recurring question into a record, where every change is dated, classified and linked to the vendor’s own words, so that the answer can be looked up instead of reconstructed.
What MarTech Ledger records across CEP, CDP and B2B marketing automation
The record covers 15 platforms from 11 vendors, grouped in three categories that match the way I already write about the market:
- CEP: Adobe Journey Optimizer, Bloomreach Engagement, Braze, Iterable, Klaviyo, MoEngage, Salesforce Marketing Cloud Engagement and Salesforce Marketing Cloud Next.
- CDP: Adobe Experience Platform, Hightouch, Tealium and Treasure AI.
- MAP B2B: HubSpot Marketing Hub, Adobe Marketo Engage and Salesforce Account Engagement.
At the end of October the Ledger holds nearly 2,200 feature records read from 19 monitored vendor sources and 9 historical archives, together with 65 market signals such as acquisitions, partnerships, packaging changes and rebrands, which sit on the timeline without ever counting as features. History starts on the same day for every platform, 1 January 2026, so that two timelines placed side by side begin from the same line.
Each feature record carries the same fields, whoever the vendor is. It has a lifecycle state taken from a closed list of seven (announced, preview, beta, GA, regional GA, deprecation announced and retired), the date the vendor states for that state with its real precision, so that a date known only to the month is shown as a month and never completed with an invented day, the regions it applies to, a significance level of major, notable or minor, and a capability from a published taxonomy of 81 capabilities in 16 areas, now at version 1.6, whose version history is public too.
Keeping those steps apart is the point of the record. An announcement does not prove that a feature can be used, a beta is still some distance from general availability, and an end-of-support date that has already passed does not on its own confirm that a feature was retired, so the Ledger records a retirement only when a source says so. When a source shows that a feature was available by a certain date without saying when it became available, the record says exactly that, with a “Confirmed by” date, which is never read as a release date and never scored as late.
With those fields in place the record can answer four questions that a release note on its own never answers. Parity asks which platforms have a capability in general availability, and since when. Sequence asks who shipped first on a theme and who followed. Cadence asks where each vendor is putting its effort, area by area, over time. Lifecycle asks what is being deprecated or retired, which is the signal almost nobody tracks and the one that matters most to the teams who built on the feature being removed.
A dated record of releases, with no scores
Review sites and vendor comparison pages show a product at one moment, usually the moment someone chose to describe it in the most favourable light. The Ledger is built around the opposite axis, which is time. Where a snapshot tells you where a product stands, a trajectory also shows you how it got there and how reliably it keeps its promises, and the record tracks those promises explicitly: when a vendor announces a feature with an expected date, the feature card shows the promise, and later shows whether the vendor delivered on time or how many days late, measured only against the state the vendor actually named.
What the Ledger refuses to do matters as much as what it records. It publishes no scores, rankings, “best for” labels or recommendations, because the number of records per platform measures how finely a vendor documents its work much more than how much it ships, and a vendor that writes one changelog line per connector would win any leaderboard built on counts. For the same reason the Release Matrix shows only the most advanced state recorded for each capability, keeps counts out of the cells, excludes minor updates by default and states in its header corner that it shows recorded releases and is not a capability inventory.
There are three ways into the record: the latest changes on the home page, a single platform followed through its own timeline, or a capability traced across products. The Release Matrix lays the recorded changes out by platform and capability, and the side-by-side views open two platforms at record level, down to the source of each state.
Absence follows the same discipline. An empty cell in the Ledger means that no release has been recorded there, which is a different statement from saying that the platform cannot do it. Plenty of capabilities predate January 2026, and plenty of vendors document some areas better than others, so the site never claims that a product lacks something and explains in its methodology why it cannot. General availability is the default view everywhere, and announcements and betas stay visible but visually distinct, because announcing more should never look like shipping more. Judgement about which platform fits which organisation stays where it has always been, in pieces like my Field Notes on CEP.
How the MarTech Ledger pipeline works
The design principle behind the pipeline fits in one line of the project specification: deterministic where possible, a language model where necessary. Fetching, cleaning, merging and validation are scripts that behave the same way every time, and the model is used only for the one step that needs reading comprehension, which is turning a vendor’s paragraph into a structured record.
The day starts at 04:17 UTC, when the fetch job reads every active source on its declared cadence (most of them daily), keeps only the blocks that changed since the last visit and stores the raw text privately. Thirty minutes later the extraction job takes each platform that has new material, prepares a cleaned version of the changed text with markers for pre-release language, and hands it to Claude, running inside GitHub Actions, which proposes entries in a fixed JSON format. The model chooses capabilities only from the existing taxonomy; when something does not fit, it can propose a new capability into a separate queue that I review, which is how the taxonomy grew from 70 to 81 capabilities in its first weeks without the model ever inventing one on the fly.
A resolve script then links every proposed state to the source items it came from, records when the pipeline first saw it next to the date the vendor states, and merges the result with the existing record. Validation follows, in two layers: a JSON Schema check on every file, and a set of rules a schema cannot express, such as states that never go backwards, dates that never go backwards, no two states of a feature on the same day, every capability present in the current taxonomy and every source URL on an allowed domain. Each run lands on its own branch as a pull request, which merges only when validation passes and otherwise waits for me. A compile step finally writes the public projection, and the static site is rebuilt from it.
Figure 1. The model handles one step out of four; everything around it is a script that behaves the same way every day.
Not every source cooperates with a schedule. HubSpot Community sits behind a challenge that blocks cloud runners, so it is read twice a week by a scheduled task that uses the browser built into the Claude desktop app on my own computer. Salesforce Help began serving an error page to the headless browser the fetcher used, and the fix was to launch full Chromium instead.
The tools behind MarTech Ledger
The stack is small on purpose, and every piece of it was chosen so that one person can run the whole operation alongside a full-time job:
- Claude (Anthropic) does the extraction, through the official GitHub Action on my personal subscription, and Claude Cowork is where I designed the pipeline, review its output in batches and run the scheduled tasks that need my computer.
- GitHub holds a private data repository and a private raw-text repository. Nothing is written to the data except through a pull request, which makes every change to the record a reviewable diff with a history.
- Python scripts handle fetch, preparation, resolve, validation and compile, with Playwright for pages that only render in a browser, and JSON Schema defines every entity and the contract the model has to respect.
- Astro builds the site as static pages, one per feature, per platform, per capability and per month of the timeline, served from Cloudflare Workers static assets on the martechledger.com domain.
- Codex, Gemini and ChatGPT act as independent reviewers of the site before changes go live, working read-only and returning numbered findings that I accept or reject one by one.
The Ledger shares its fonts and colours with this site, so the two read as a family while keeping their own names and roles. One idea in the data model is borrowed: storing, next to the date a vendor states, the moment the pipeline first saw the change comes from Releasebot, which separates “date parsed from source” from “first seen”. On the Ledger that second timestamp makes the recording delay measurable, and therefore publishable.
The rules that keep the record honest
Every fact on the Ledger has at least one source, and every source sits on a vendor domain the pipeline is allowed to cite. Each state also shows where it was read, whether release notes, a changelog, documentation, a community post or an announcement relayed by my own MarTech Watch, which is labelled as such and can only ever produce an “announced” state. That label describes the kind of source and never grades it; the model’s confidence scores stay private, because a published number would suggest a precision the process does not have.
When a doubt comes up, whether during extraction, from a validation rule or in one of my reviews (two sources disagreeing about the date of the same state is the typical case), the record is marked “under review”, stays visible with its doubt stated, and drops out of the Release Matrix and the side-by-side views until the doubt is resolved. Every change I make to a published fact goes into a public corrections register, field by field, with the value before and after, the reason and the evidence; it held 101 entries at the end of October. A reader can report an error on any record through a form prefilled with its identifier, and the report triggers a check against public sources without ever becoming the basis for an edit on its own.
The pipeline also measures itself in public. The status page shows the recording lag per platform, the days between a vendor’s stated date and the moment the pipeline first saw it, and gives a median only when there are at least five observations. Before launch I measured recall against my own Watch over twenty weeks of history: 78% of the relevant Watch items were matched by a Ledger record, 88% including partial matches, and the misses (mostly press-only announcements and skipped minor items) became two fixes to the extraction rules and a dedicated lane for announcements. This is the practical answer to the problem I described in how agentic systems fail silently: the record cannot promise to be right, but it can show where it might be wrong.
Figure 2. The safeguards are visible on the record itself, so a reader can judge each entry without trusting the process blindly.
Two disclosures complete the picture. The entries are written by AI and are not reviewed by a person one by one, so every page that shows them carries the European Commission’s “AI generated” icon under Article 50 of the EU AI Act, with a link to a page that explains how AI is used and what it does not do. The About page states that I am a consultant certified on several of the tracked platforms who implements them for clients, which is a potential conflict of interest and is declared as one, that the same pipeline and rules apply to every vendor, and that no vendor pays for, reviews or influences what is recorded.
Who MarTech Ledger is for, and where the opinion lives
The record is written for people who need facts with dates more than they need a verdict: MarTech architects checking whether a capability is generally available in the right region before they design around it, implementation partners preparing a migration, analysts following where the market is moving, and product-marketing and competitive-intelligence teams who track what their competitors actually ship. In practice that means preparing a meeting with a vendor, finding the source of a release someone mentioned in a workshop, following a deprecation through to its end date, or watching one capability evolve across several platforms. It is deliberately not a buyer’s guide for CMOs, and it will not grow features such as summary scores or “best for” badges, which belong to a different kind of product.
The interpretation lives here. The Ledger links to andrea.veggiani.com sparingly, at most once per page and only where an article really covers the subject, under a label that says “The author’s view” with its publication date, so a reader always knows when they are leaving the record for an opinion. The Watch keeps running in parallel, and the monthly Patterns That Matter to Me already read the market through the Ledger’s taxonomy. When Salesforce agreed on 20 October to acquire Braze, the Ledger recorded one signal with both vendors attached and its source; what the deal means for a stack is a question I answered on this site, in an architect’s read of the acquisition.
Figure 3. Keeping facts and opinion on separate sites makes each easier to trust, and makes the link between them an explicit choice.
What Beta means, and what comes next
The header of the Ledger carries a Beta badge, and it means something specific: coverage is still growing, methods can still change, doubtful entries stay visible, and links remain stable. While the badge is there, RSS feeds are switched off, and the dataset download stays unlinked until its licence is decided. Three platforms (Insider One, Zeotap and GrowthLoop) are deferred because their public sources are not yet dated well enough to meet the record’s rules, and the data model is built so that a new category or vendor is a matter of configuration, which is how B2B marketing automation joined the original CEP and CDP scope in early October. The record makes its scope, its monitored sources and the limits of its method explicit, and makes no claim to capture every change in the market.
The best test is a platform you already know: open one of its records, follow the link to the vendor’s source, and if the two disagree, use “Report an issue” on the record, because that kind of feedback is how the Ledger becomes more useful.
On the next Thursday evening, when the same question comes up again for a feature I half remember, I will not search three release notes and a press release to answer it. The answer to “is it generally available, and since when?” should be a link anyone can check, and for fifteen platforms it now is.
Sources
MarTech Ledger
- About MarTech Ledger. Scope, audience, the meaning of Beta and the author’s disclosure.
- Methodology. Sources, lifecycle states, validation rules and the meaning of absence.
- How AI is used. What the model does, what it does not do, and the AI-generated label.
- Corrections. The public register of changes to published facts.
- Taxonomy. The 81 capabilities in 16 areas and their version history.
Tools and platforms
- Claude Code GitHub Actions. The GitHub Action that runs the extraction step.
- Cloudflare Workers static assets. The hosting model for the static site.
- Astro. The static site framework.
- JSON Schema. The validation standard for every entity and for the model’s output contract.
- Releasebot methodology. The source of the idea of storing “first seen” next to the date parsed from the source.
Regulation
- The EU AI Act’s transparency rules: a practical guide to Article 50. The labelling obligations behind the AI-generated icon.
