MANTICORE — the calendar layer nobody builds before the content plan
Every content calendar starts by asking 'what do we post?' — but that skips a step. What dates actually matter to *this* business, and can that question be answered systematically instead of by whoever happens to remember Black Friday?
The value isn't in finding dates — anyone can search 'national days'. It's in the filter that throws most of them out. A date only earns a place if a real customer would recognise it, and the layer that makes a calendar feel like *this brand* is always the third one: the business's own anniversaries, launches and platform sale cycles. That layer can't be researched. You have to ask.
It isn't stopped — it's a component I now run before any content work. What's deliberately out of scope is the content itself: MANTICORE hands over the map, and something else decides what to post.
The problem it solves
Content strategy usually begins at the wrong end. Someone opens a calendar and starts inventing posts. The step that gets skipped is more basic: which dates does this specific business have any business talking about?
Get that wrong and you end up with the most common failure in brand social — a feed of generic "national day of X" posts that no customer asked for and no competitor envies.
Three layers
MANTICORE builds the date map in three passes, and they are not equal.
Layer 1 — Universal. Holidays, shopping seasons, widely recognised cultural moments. These apply to almost any consumer business, so they live in a reusable library rather than being researched from scratch each time. The one rule that keeps it from rotting: dates that move are stored as a calculation rule, not a hardcoded day. "Fourth Thursday of November", not "November 27, 2026". A file full of last year's dates is worse than no file.
Layer 2 — Niche. What this particular industry recognises. Researched fresh every time, with sources, and never recycled between businesses — "historical wargaming" and "fantasy miniatures" are not the same audience, any more than general dentistry and orthodontics are.
Layer 3 — The business's own. Founding anniversaries, product launches, past campaign milestones, and the sale cycles of whatever platform they actually sell on. This layer cannot be researched or inferred. You ask the owner, or you leave it blank.
The filter is the actual product
Any of this is worthless without a way to say no. The test I use before a date gets in:
Would a real customer of this business recognise this date and find it relevant — or does it only exist in aggregator lists of "international days of everything"?
A date needs two of three to qualify: genuine recognition inside the community, a content hook that doesn't feel forced, and repeatability year over year. One out of three can still go in, but flagged as optional — never as a pillar of the calendar.
The goal was never to maximise the number of dates. It's to maximise the ones worth making something for.
Honesty about sources
Every niche date carries its source. When the only thing backing a date is one of those "national day" aggregator sites with no traceable origin, it gets marked "weak source — verify before use" rather than presented as fact. That flag has saved me from putting invented holidays in front of a client more than once.
What the deliverable looks like
A month-by-month map — date, layer, region, priority, one line on why it matters, and the source. It ships as a document, a spreadsheet the owner can edit, and a printable visual calendar.
Two things I got wrong and fixed along the way:
- The calendar survives a phone; the index tables don't. A five-column source table at
390px pushes the notes column off-screen. Each row now collapses into a stacked card below
640px. Worth knowing: when you switch a table to
display:block, the<caption>strangles itself and has to be forced to block too. - Bilingual means one file with a switch, not two files. The first version shipped as separate Spanish and English documents. Two URLs to keep in sync is a worse problem than the one it solved. Now it's a single page with an ES/EN toggle that re-renders everything — months, weekday names, date formats, notes.
Where it fits
MANTICORE deliberately does one thing. It produces the input — the map of dates — and stops. Deciding what to actually make for those dates is a different job, done by a different part of the workspace. Keeping the two separate is what stops the date research from quietly turning into an unreviewed content plan.