Coder Legion - Recent posts tagged publishing

Design Publishing Queues That Survive Image Provider Outages

Sun, 18 Oct 2026 11:52:14 +0000

A publishing queue should not forget an article because a photo API had a bad afternoon.

Quick solution:

if (providerError.isTransient) {
  return queue.defer({ state: "MEDIA_PENDING", retryAfter: "1h" });
}

The retry design must respect Cloudflare Workflow limits and the provider's Pexels API documentation; provider failure does not decide whether the article itself is valid.

Yet that is exactly what happens when a pipeline treats every missing hero image as "invalid content."

The article may be complete. The metadata may be valid. The internal links may pass. The only failure is an external media provider returning no usable result, a rate-limit response, or a temporary server error.

That is not the same class of failure as a malformed article.

The queue should preserve the article and defer the media stage.

Separate source validity from media availability

A clean pipeline asks two different questions:

Is the article publishable?
Is a valid hero asset available right now?

The first question is editorial.

The second depends partly on external systems.

If you merge them into one boolean, this happens:

article valid
photo provider unavailable
=> source rejected
=> next topic generated

Now a temporary outage has changed editorial history.

A better state model is:

VALIDATED
MEDIA_PENDING
MEDIA_SELECTED
READY_TO_PUBLISH
PUBLISHED

The article identity stays the same while the media stage retries.

Classify media failures

Not every visual failure deserves a retry.

Retryable

provider 429 rate limit;
temporary 5xx response;
network timeout;
provider returns zero acceptable results for one query;
asset download temporarily fails;
deployment check is still pending.

Deterministic repair

selected asset already used when uniqueness is required;
wrong dimensions;
missing attribution;
stale manifest hash;
unsupported media type.

Terminal for that candidate

license does not allow the intended use;
source URL cannot be established;
raster is corrupt;
asset content is clearly irrelevant;
provider explicitly rejects the request.

A terminal candidate is not necessarily a terminal article. Select another asset.

Bound provider retries

External APIs need retry budgets.

Pexels’ API documentation currently documents default API limits of 200 requests per hour and 20,000 per month. A publisher that retries without bounds can turn temporary scarcity into a quota problem. Cloudflare’s Workflow limits are a separate runtime ceiling, so keep provider quotas and orchestration limits distinct.

Use a fixed strategy such as:

query 1 -> retry transient failure up to 2 times
query 2 -> try one alternate search phrase
reviewed catalog -> use only if a genuinely relevant asset exists
otherwise -> MEDIA_PENDING

Do not keep changing the query forever inside one Workflow instance.

The purpose of retries is to absorb transient noise, not to search the entire internet before the run can finish.

Keep the source queued

When media is unavailable, persist the article in a state that makes the next run resume it.

Do not delete the source, mark it duplicate, move to a new topic, create another draft with the same intent, or reset the article ID.

A durable record needs enough identity to resume:

article_id: art_example
slug: example-article
state: MEDIA_PENDING
revision: 2
visual_attempts: 3

Whether this lives in Git, Workflow state, or another durable store depends on the architecture. The invariant is the important part: the article survives.

Reuse reviewed assets carefully

A local catalog can reduce provider dependence.

If the catalog already contains an unused or reusable raster that is genuinely relevant and its license permits reuse, it may be a better fallback than another external request.

But "available" is not enough.

Check topic relevance, provider/source URL, license, attribution, byte hash, dimensions, reuse rules, and whether the same visual is already overused.

Never reuse an unrelated image simply to make the pipeline green.

Bind provenance when selection succeeds

Once an asset is selected, record the evidence immediately.

Useful fields include:

provider: Pexels
source_url: https://www.pexels.com/photo/...
license_url: https://www.pexels.com/license/
attribution: Photo by ...
article_id: art_example

After downloading the final raster, add the MIME type, width, height, byte count, and SHA-256 of the transformed file.

The first block explains where the image came from. The second explains exactly which bytes the publication uses.

Do not invent file metadata before the file exists.

Avoid duplicate work after uncertain responses

Media providers and storage APIs can fail after doing the work.

Example:

download completes
network layer times out before caller records success
retry starts
same image downloaded again under another asset ID

Use stable stage identity.

If an asset selection has already been recorded for article A revision 3, the retry should inspect that record before searching again.

Likewise, if the final raster already exists and its hash matches the intended manifest, verify it instead of creating another copy.

This is the same idempotency principle used throughout Building a Reliable Batch Publishing Workflow.

Verify the actual raster, not provider metadata

A provider response can describe the original photograph, while your pipeline may crop or resize it.

The publication should bind to the final transformed bytes, not merely the provider metadata.

After transformation:

decode the file;
read actual dimensions;
compute byte length;
compute SHA-256;
update the asset manifest;
verify the article points to that asset.

The provider page remains provenance. The transformed file becomes publication evidence.

Keep provider outages out of editorial scoring

A photo API outage says nothing about whether an article has information gain.

Do not lower article quality, factual confidence, duplicate status, or rank-potential merely because an image API is unavailable.

Instead report the failure in the stage that owns it:

editorial: PASS
research: PASS
visual: DEFERRED_PROVIDER
publication: PENDING

This makes the blocker understandable to both humans and automation.

Verify after deployment

A queue is not finished when the image reaches Git.

After deployment, fetch the public hero URL and verify a successful response, correct content type, decodable bytes, expected dimensions, and that the expected article actually references it.

If the article is live but the asset is stale, keep the same publication pending until the intended raster is visible.

That exact-version discipline is part of Designing a Reliable Serverless AI Publishing Workflow.

Design for a provider-independent future

Do not let one provider's response schema leak across the whole publishing system.

Normalize a candidate:

type ImageCandidate = {
  provider: string;
  sourceUrl: string;
  downloadUrl: string;
  attribution: string;
  licenseUrl: string;
  width?: number;
  height?: number;
};

Then the rest of the pipeline can perform relevance checks, dedupe, transforms, manifest binding, and deployment verification without caring where the candidate came from.

That makes adding a second provider a local adapter change instead of a workflow rewrite.

A practical recovery algorithm

When an article reaches the visual stage:

1. inspect existing bound asset
2. if healthy -> continue
3. inspect reviewed catalog for relevant candidate
4. if found -> bind, transform, verify
5. otherwise query provider within request budget
6. reject duplicates or invalid provenance
7. transform final raster
8. validate bytes and dimensions
9. if provider unavailable -> MEDIA_PENDING
10. retry same article later

The crucial line is number 10.

When maintaining these pipelines, teams should also review policies for preventing search intent duplicates in automated systems to ensure safe retries.

Verification and execution checklist

Inspect the active article state to confirm MEDIA_PENDING is recorded instead of deleting the draft.
Verify that external API calls respect rate-limit thresholds and orchestration timeouts.
Confirm that transformed asset hashes match the recorded manifest before deployment.
Check public staging endpoints to ensure the final raster is accessible and correctly linked.

Preserve Captions in Markdown Publishing

Sat, 17 Oct 2026 15:04:18 +0000

Markdown looks simple because it is easy to type. That simplicity can be deceptive when you build an automated publisher.

Quick solution:

def extract_hero_and_caption(ast_nodes):
    hero_index = find_hero_image_node(ast_nodes)
    if hero_index is not None and is_valid_caption_block(ast_nodes[hero_index + 1]):
        return ast_nodes[hero_index + 2:]
    return ast_nodes[hero_index + 1:]

CommonMark 0.31.2 defines link and image syntax; caption handling is an application-level convention that the transform must preserve explicitly.

A regular expression removes a hero image. Another inserts an internal link. A third strips a caption. The pipeline passes unit tests, but the rendered article suddenly contains an orphan caption or an unnatural sentence where one word has been replaced by an entire destination title.

The problem is not Markdown itself. The problem is treating structured editorial text as an unstructured string.

Two transformations deserve particular care:

extracting an image and its visible caption;
inserting contextual links without rewriting the author's voice.

Standard Markdown does not give you a universal caption node

CommonMark defines links and images, but there is no universal native image-plus-visible-caption construct.

Publishers therefore use conventions such as:

![Architecture overview](hero.jpg)

*The pipeline keeps content and deployment state separate.*

or raw HTML:

`<figure>`
  `<img src="hero.jpg" alt="Architecture overview">`
  `<figcaption>`The pipeline keeps content and deployment state separate.`</figcaption>`
`</figure>`

The first form is just an image block followed by a paragraph. Your pipeline may decide that the paragraph is a caption, but that interpretation is application-specific.

That means caption extraction needs an explicit rule.

The greedy whitespace bug

Consider this input:

![A deployment workflow](hero.jpg)

*The publication path has three independent gates.*

The article begins here with a normal paragraph.

A regex designed to remove the image may accidentally consume too much or too little whitespace.

If it removes only the image token, the caption remains at the top of the article as ordinary prose.

If it greedily absorbs multiple following paragraphs, the first real paragraph disappears too.

The dangerous pattern is matching the image, then matching arbitrary whitespace and text.

The safer rule is structural:

locate the image block;
identify exactly the next block;
classify that block as a caption only if it matches your caption convention;
remove those exact blocks;
preserve all other whitespace and prose.

Prefer an AST when transforms become important

For one tightly controlled format, a carefully tested parser can be enough.

As soon as your pipeline performs several Markdown transformations, an abstract syntax tree becomes easier to reason about than stacked regular expressions.

The conceptual flow becomes:

Markdown
  -> parse blocks/nodes
  -> identify hero image node
  -> inspect immediate next paragraph
  -> classify caption
  -> transform nodes
  -> render Markdown or HTML

Now the next paragraph is an actual node, not a substring discovered by a greedy expression.

An AST also helps distinguish links inside paragraphs, headings, code fences, image alt text, and existing link nodes.

That matters for internal-link insertion.

Contextual links should preserve an existing phrase

Imagine the article contains:

A reliable serverless publishing workflow needs explicit retry boundaries.

You want to link serverless publishing workflow to a relevant internal article.

The good result is:

A reliable [serverless publishing workflow](https://raylabs.app/articles/designing-a-reliable-serverless-ai-publishing-workflow/) needs explicit retry boundaries.

A bad automation finds only the word workflow and replaces it with the destination page title:

A reliable serverless publishing [Designing a Reliable Serverless AI Publishing Workflow](https://raylabs.app/articles/designing-a-reliable-serverless-ai-publishing-workflow/) needs explicit retry boundaries.

The URL may be correct, but the sentence no longer sounds authored.

The rule should be simple: link an existing natural phrase, and do not rewrite prose to manufacture an anchor.

Score candidate phrases instead of replacing tokens

A practical link inserter can work from phrase candidates.

For each destination:

collect phrases already present in the article;
reject phrases inside headings, code, existing links, and captions;
prefer multiword phrases with clear semantic overlap;
choose the first contextually useful occurrence;
wrap exactly that phrase;
do not alter surrounding words.

A basic score can favor three-to-six-word phrases, exact topic terms, and body paragraphs over navigation-like text.

The scoring system does not need artificial intelligence. It needs predictable editorial constraints.

Never link inside code, image syntax, or an existing link

String replacement is especially risky because the same phrase may appear in code, image alt text, headings, or a link that already exists.

A syntax-aware transform can exclude those node types.

A regex stack tends to solve this by adding exceptions until maintenance becomes harder than parsing Markdown correctly.

Link insertion should be idempotent

Run your publishing transform twice.

The second run should not:

add a second copy of the same link;
nest Markdown links;
change the anchor phrase;
reinsert a removed caption;
move the hero;
change unrelated whitespace.

Idempotency is one of the strongest tests for editorial automation because production jobs are retried.

If the same draft can be transformed twice with a different output, recovery becomes dangerous.

This is part of the same design problem discussed in Automating Medium Draft Workflows: retries should continue the same artifact rather than mutate it unpredictably.

Separate editorial transformation from privacy validation

A Markdown transformer may also need to reject private repository URLs or internal hostnames.

Keep that as a separate validator.

Caption extraction answers which blocks belong to the hero presentation. Internal-link insertion answers which existing phrase can safely become an anchor. Privacy validation answers whether any forbidden URL or identifier remains in the final document.

RayLabs treats private-link detection as its own boundary in Preventing Private Repository Links in Public Articles.

Verify the rendered result, not only the source

A Markdown file can look correct and still render incorrectly under the target parser.

Your final test should render the transformed document through the same stack used in production and inspect the result.

For caption handling, confirm that exactly one hero exists, the caption appears in the intended location, and the caption does not appear again as the first article paragraph.

For contextual links, verify that anchor text matches the intended phrase, the destination is the expected existing URL, no nested anchors exist, and code and headings remain unchanged.

Execution Checklist

[ ] Confirm caption extraction isolates hero image and caption blocks without consuming subsequent paragraphs.
[ ] Verify contextual link insertion wraps exact natural phrases without altering surrounding text.
[ ] Execute the publishing transform twice to guarantee idempotency.
[ ] Render the final output through the production parser to validate HTML structure.

Bristol Replaced Its Voynich Press Release. Only the Withdrawn Page Tells You What Happened.

Fri, 04 Sep 2026 00:24:35 +0000

On 15 May 2019 the University of Bristol's news site published a story under the headline "Bristol academic cracks Voynich code, solving century-old mystery of medieval text." Open the same address today and you get a different page with a different headline: "Statement re: Voynich research paper," dated 16 May 2019. The story is not there. In its place the university explains that "concerns have been raised about the validity of this research from academics in the fields of linguistics and medieval studies," that it takes such concerns seriously, and that it has "removed the story regarding this research from our website to seek further validation and allow further discussions both internally and with the journal concerned."

That page is the subject of this piece. Not the manuscript, and not whether it was deciphered. It was not, and the people qualified to say so said it within a day. The subject is what a reader who arrives in 2026 can learn from each of the things the claim left behind, because it left behind at least three, they have three different owners, and seven years later they do not agree.

The three artifacts and who owns them

A public research claim deposits a paper, a press release, and, if things go wrong, a correction. Each is kept by a different institution under different rules, and nobody is obliged to reconcile them.

The paper is "The Language and Writing System of MS408 (Voynich) Explained," by Gerard Cheshire, in Romance Studies, volume 37, issue 1, pages 30 to 67, published online on 29 April 2019. Its abstract lists nine features of the manuscript and then says: "As a result, identifying the language and solving the writing system required some ingenuity and lateral thinking, but both were duly revealed" (accepted manuscript, p. 2). The body states that "the manuscript was compiled by a Dominican nun as a source of reference for the female royal court to which her monastery was affiliated" (p. 3), that it "originates from Castello Aragonese, an island castle and citadel off Ischia, and was compiled for Maria of Castile, Queen of Aragon" (p. 4), and that the language "is known as proto-Romance (prototype-Romance)" (p. 4). The page numbers are those of the accepted author manuscript, which the University of Bristol's own research portal hosts as a PDF, because the publisher's page refused to be read by the tools used for this piece. That detail matters later.

The press release was the paper with a clock attached. Bristol's copy is gone, but the wire copies are not, and they agree with each other. Its first sentence read: "A University of Bristol academic has succeeded where countless cryptographers, linguistics scholars and computer programs have failed - by cracking the code of the 'world's most mysterious text', the Voynich manuscript." Its fourth paragraph supplied the clock: "It took Research Associate Dr. Gerard Cheshire two weeks, using a combination of lateral thinking and ingenuity, to identify the language and writing system." Put the abstract beside that sentence and you can see the release being written: the paper's "ingenuity and lateral thinking" becomes the release's "lateral thinking and ingenuity," and two weeks is added.

The correction is the statement that now occupies the release's address. It does three things and it is worth reading them as three separate acts. It records that concerns were raised. It removes the story. And it disclaims the affiliation: the research "was entirely the author's own work and is not affiliated with the University of Bristol, the Faculty of Arts or the Centre for Medieval Studies." What it does not do is say the research is wrong. The university withdrew its endorsement and its name. It did not, and could not, withdraw the paper.

The day it happened

The sequence is short. The release went out on 15 May. By that evening the objections were public. Gizmodo's corrective of 17 May quoted the medievalist Lisa Fagin Davis, executive director of the Medieval Academy of America, on the method: "I tried several years ago to reproduce Cheshire's Voynich results, because initially I was intrigued. But when you apply his Roman-letter substitutions and then try to translate the result, you have no choice but to be subjective. It's gibberish. The methodology falls apart." The same article quoted Greg Kondrak of the University of Alberta, whose objection is about agreement rather than taste: "a number of people have come up with a mapping to Latin letters, but those mappings rarely agree with each other, or with this proposal." A Language Log commenter put the linguistic point in one sentence: a proto-language "is most emphatically not a random collection of words from its daughter languages."

Michael Stillman's account for Rare Book Hub gives the timing of the withdrawal in one line: "The following day, after the report hit the news wires, the University of Bristol withdrew its news release." So the correction arrived about a day after the release. Everything since has been the three artifacts drifting apart.

What did not happen: the paper is exactly where it was

The sentence this piece was most careful about is the one it cannot find a way to write. The paper was not retracted.

That is checkable without reading anything. Crossref, the registry behind the DOI, records post-publication notices as relations on the original record: a retraction, a correction, or an expression of concern appears as an "updated-by" entry. On 3 September 2026 the record for 10.1080/02639904.2019.1599566 carried none. The title, journal, volume, issue, pages and dates are all present; the update fields are empty. The query that shows this is a dozen lines of Python and is shipped beside this essay, so anyone can re-run it and see whether that is still true on the day they read this.

What the journal said at the time is a separate question, and it should not be blurred into that one. The coverage opened for this piece, and the DOI record, contain no statement from Romance Studies or its publisher, Taylor & Francis. That is the absence of my finding one. It is not evidence that nothing was said, and this piece does not build on the journal having stayed silent. It builds on something narrower and firmer: whatever anyone said in May 2019, the peer-reviewed record itself carries no marker, and it is the record a search engine, a citation manager, or a curious reader will reach first.

There is a fourth artifact, and it is the strangest. The University of Bristol's research portal still hosts the accepted manuscript of the paper as a downloadable PDF, with a cover sheet generated on 21 July 2026, and lists the author's affiliations as the School of Biological Sciences and the Bristol Doctoral College. The last page of that manuscript carries a symbol key signed "Gerard Edward Cheshire. University of Bristol" (p. 48). No note, no link to the statement, nothing. So one Bristol page says the research is not affiliated with the university, and another Bristol page serves the research under the university's name. Both are doing their jobs. The news office corrects its news. The repository preserves what its researchers deposit. Neither is wrong by its own rules, and a reader who finds just one of them will come away with a picture the other would spoil.

The coverage is not one artifact, it is a population

It is tempting to say the coverage is the third owner, alongside the university and the journal. It is not one thing. It is a population of pages, and on 3 September 2026 they were in every possible state at once.

Sci-News published its story on 15 May 2019 and it still opens the way it opened that morning: the manuscript "may be written in proto-Romance," compiled "by a Dominican nun as a source of reference for Maria of Castile, Queen of Aragon, according to research by University of Bristol's Dr. Gerard Cheshire." There is no update, no editor's note, no mention that the release was withdrawn. Popular Archaeology carries the release itself, headline and all, with the two-weeks sentence intact and no note either. A reader who lands on either page is standing in 15 May 2019 and has no way to know it.

New Atlas's story of 16 May, by James Holloway, now lives at a different domain, and it did what the others did not: an editor's note at the foot of the article quotes the university's statement in full. Language Log's post of the same day, by Victor Mair, reproduced the release's opening sentence and then, later, appended the Guardian's headline, "University backtracks on disputed Voynich manuscript theory." Gizmodo's piece two days later was the correction from the start.

So the coverage falls into three kinds by chance of editorial habit: pages frozen at the claim, pages that grew a note, and pages written after the collapse. Nothing on any of them tells a reader which kind they are holding. The only way to know is to already know, which is the one thing a reader arriving from a search does not.

The standard none of these three owners met, which is why this keeps happening

The reason the specialists could answer within a day is that the test has not changed in a century. A proposed reading of the manuscript is judged by whether it produces coherent text from the whole of it, not a plausible gloss on a few chosen words. Jillian Foley's 2020 survey for Undark traces the pattern back to 1921, when William Newbold, a philosopher at the University of Pennsylvania, claimed the manuscript was a thirteenth-century scientific treatise, and she states the running total plainly: "every claim of a Voynich solution, including both of last year's, has been either ignored or debunked by other experts." Davis's objection above is the same test applied to one method. Apply the substitutions, translate the result, and see whether you had to choose.

A stable, public test does not stop the claims arriving. It makes them cheap to answer. That asymmetry is the engine of this story: the claim took a paper, a release and a news cycle to make, and the answer took a day, and then the three artifacts of the claim went on existing at three different rates.

Which one to trust, if you can find just one

Here is the counter-intuitive result. The institution that got the announcement wrong left the clearest record of it. Bristol did not delete the URL. It replaced the story with a dated statement at the same address, so anyone who saved the link in 2019 and follows it in 2026 arrives at the correction. The URL that failed tells you that it failed, when, and why.

The paper's record is honest and says less. It tells you the paper was reviewed and published and where. It does not tell you what happened next, and the record that would carry that information is empty.

The coverage says whatever it said on the day, unless a particular editor came back, and you cannot tell from the page whether one did.

If you can find just one of the three, find the press release. Not because it was right. Because its owner fixed it in place, and the others were never under any obligation to. And if you find the paper first, run the Crossref query before you cite it, because the absence of a notice is a fact about a registry, not about a manuscript.

There are things this piece did not check. It did not evaluate the paper's linguistic argument; that is the specialists' work and they did it in 2019. It did not open two documents that would have added weight, Lisa Fagin Davis's own written response and a separately circulated critique of the journal's review, because both sit behind a login the tools used here cannot pass, so neither is quoted. It did not locate EurekAlert's copy of the release, which may carry a marker of its own. And it cannot know what was said between the university and the journal in the "further discussions" the statement promised. The record it can see is the one described above, and that record is the point.

Sourcing notes: every quotation carries a locator. Quotations from the paper are from the accepted author manuscript hosted by the University of Bristol's research portal, cited by PDF page, and the sentences were pulled from that PDF by extract_manuscript_quotes.py, shipped beside this file with the PDF; the journal's own pagination (30 to 67) was not used because the publisher's page could not be opened. The statement that the paper carries no retraction, correction or expression of concern is a reading of the Crossref record for its DOI on 3 September 2026, produced by check_crossref_status.py, also shipped beside this file. The press release's wording is quoted from surviving reproductions (Rare Book Hub, Language Log, Popular Archaeology), not from Bristol's site, which no longer carries it. Coverage pages were opened on 3 September 2026 and their update status is reported as found that day. No number in this piece was computed except those the two scripts print.*

Sources

University of Bristol, "Statement re: Voynich research paper," 16 May 2019 (the whole page; the statement replaced the release at the same address). https://www.bristol.ac.uk/news/2019/may/voynich-manuscript.html
Gerard Cheshire, "The Language and Writing System of MS408 (Voynich) Explained," Romance Studies 37:1 (2019), 30–67, published online 29 April 2019, DOI 10.1080/02639904.2019.1599566 (https://doi.org/10.1080/02639904.2019.1599566); accepted author manuscript, University of Bristol Research Portal (abstract p. 2; the nun p. 3; Castello Aragonese and proto-Romance p. 4; the signed symbol key p. 48). https://research-information.bris.ac.uk/en/publications/the-language-and-writing-system-of-ms408-voynich-explained/

Crossref REST API record for the same DOI (fields "updated-by" and "relation"; read 3 September 2026): https://api.crossref.org/works/10.1080/02639904.2019.1599566

Ryan F. Mandelbaum, "Sorry, It Looks Like a Researcher Didn't Just Crack the Voynich Manuscript After All," Gizmodo, 17 May 2019 (the Davis and Kondrak quotations; the Bristol statement quoted). https://gizmodo.com/sorry-it-looks-like-a-researcher-didn-t-just-crack-the-1834841706
Michael Stillman, "The Voynich Manuscript Code Has Finally Been Cracked...Or Not," Rare Book Hub, July 2019 (the release's first sentence; "The following day…"). https://www.rarebookhub.com/articles/2636
"Bristol academic cracks Voynich code, solving century-old mystery of medieval text," University of Bristol news release as reproduced by Popular Archaeology, May 2019 (the two-weeks sentence; no correction present). https://popular-archaeology.com/article/bristol-academic-cracks-voynich-code-solving-century-old-mystery-of-medieval-text/
Victor Mair, "Voynich code cracked?," Language Log, 16 May 2019 (paragraph 2, the release's opening sentence; paragraph 5, the journal and online date; the appended Guardian headline; comment 6 on proto-languages). https://languagelog.ldc.upenn.edu/nll/?p=42749
James Holloway, "Has the medieval 'Voynich code' finally been cracked by a Bristol academic?," New Atlas, 16 May 2019, now hosted at Refractor (the editor's note quoting the Bristol statement). https://refractor.io/science/has-the-medieval-voynich-code-finally-been-cracked-by-a-bristol-academic/
News Staff, "Has Voynich Manuscript Been Decoded? Mysterious Book May Be Written in Proto-Romance Language," Sci-News, 15 May 2019 (opening sentences; no update present as of 3 September 2026). https://www.sci.news/othersciences/linguistics/voynich-manuscript-07190.html
Jillian Foley, "The Strange Quest to Crack the Voynich Code," Undark, 12 February 2020 (Newbold, 1921; "every claim of a Voynich solution…"). https://undark.org/2020/02/12/decoding-bizarre-voynich-manuscript/
Wikipedia, "Voynich manuscript," section "Gerard Cheshire" (used only to locate the contemporaneous coverage listed above; not quoted). https://en.wikipedia.org/wiki/Voynich_manuscript

Why I'm Building an Engineering Publishing Platform

Sun, 30 Aug 2026 02:46:00 +0000

Over the past several months, I've made a commitment to write more.

Not because I want to become a content creator, but because I've come to appreciate how much engineering knowledge quietly disappears every day. Architecture discussions end when the meeting is over. Production incidents become stories that fade with time. Lessons learned on one project rarely make it to the next. As engineers, we spend years building experience, but very little of it ever becomes knowledge that others can benefit from.

Writing has become my way of changing that.

Like many engineers, I started publishing wherever I could. I have a blog on my own website, along with accounts on Medium, Hashnode, DEV.to, and Coder Legion. Each platform reaches a different audience, and I genuinely like the idea of meeting engineers where they already are. If someone prefers reading on Hashnode instead of my website, that's perfectly fine with me. My goal has never been to drive traffic to a particular platform. It's to share ideas.

Unfortunately, that turned out to be much harder than I expected.

Every article followed the same routine. Once the writing was finished, I still had to copy Markdown between editors, upload images multiple times, recreate tags, tweak formatting, update SEO metadata, generate excerpts, and create social posts. By the time I finished publishing everywhere, I had spent almost as much time managing content as I had writing it.

As an engineer, my first instinct was simple.

Automate it.

I envisioned a small service that would let me publish an article once and have it automatically appear everywhere else. My website would remain the source of truth while Medium, Hashnode, DEV.to, and every future platform would simply become destinations. It felt like a straightforward integration problem—build a few connectors, push the content out, and move on to the next article.

Then I started designing it.

Like many software projects, it didn't take long before I realized I was solving the wrong problem.

The more I thought about the architecture, the less it resembled a collection of publishing scripts. If every platform was going to behave differently, I needed a common deployment model instead of a collection of one-off integrations. Articles would become immutable releases. Releases could be deployed to one or more publishing targets. Each destination would have its own connector responsible for understanding that platform, while the orchestration layer would manage deployments, retries, status, and lifecycle. The result was an architecture that felt much more like a software delivery pipeline than a blogging tool.

That solved the technical problem.

It didn't solve the real one.

Somewhere in the middle of working through the design, I realized that publishing was never the difficult part.

Thinking is.

Every article I've written over the past few months has started long before a Markdown file ever existed. Sometimes it begins with a conversation. Sometimes it's a lesson I didn't fully appreciate until years later. Other times it's an architectural decision that seemed obvious in hindsight but required hours of discussion to reach. The words themselves are usually the final step in a much longer process of reflection.

That's the process I don't want to lose.

Most writing tools begin with a blank editor. They assume you already know exactly what you want to say. My experience has been almost the opposite. The most valuable part of writing is discovering the idea. It's connecting experiences that didn't seem related, questioning assumptions, and slowly uncovering the principle hidden underneath the story. By the time I begin writing, the real work has already happened.

That realization changed the project entirely.

I'm still building the cross-posting platform because I genuinely want to publish once and distribute everywhere with as little manual effort as possible. But that's no longer the vision.

The vision is to build a platform that supports the entire journey from idea to publication. Conversations become drafts. Drafts become articles. Articles become releases that can be published anywhere. The platform should help organize ideas, generate summaries and metadata, manage revisions, and eventually understand the relationships between everything I've written. I don't want another tool that stores Markdown files. I want a system that helps preserve engineering judgment.

Over the coming weeks, I'll be documenting the architecture, implementation, tradeoffs, and inevitable mistakes as I build this into the M²S² platform. Some articles will be technical deep dives into the connector architecture or deployment pipeline. Others will focus on the decisions that shaped the system and the lessons learned along the way. My hope is that readers don't just see the finished product—they understand the thinking behind it.

If there's one thing I've learned throughout my career, it's that good engineering rarely starts with the perfect solution. More often, it starts with solving one problem, discovering a better question, and allowing the architecture to evolve alongside your understanding.

That's exactly what happened here.

I thought I was building a way to publish blog posts.

Instead, I found myself designing a platform for capturing and sharing engineering experience.

And I think that's a much more interesting problem to solve.