A publishing platform for a family memoir¶
A memoir written for great-grandchildren has to outlive every platform it is published on. This is the pipeline that takes it from source documents to four languages and three formats, and the licence model that keeps the code open while the story stays the family's.
Why it exists¶
A relative wrote a memoir addressed to descendants who mostly do not read the language it was written in, and who live in different countries. The requirement was awkward in a specific way: it had to be readable by relatives across three generations, and still readable in thirty years.
That rules out most of the obvious answers. A word-processor file is not multilingual. A social platform is not durable — the family's copy would be a tenant of somebody's product decisions. A single printed book is durable and reaches nobody who was not handed one.
So the requirement became an engineering one: one source of truth, several outputs, no dependency on a vendor for the content to survive, and access controlled by the family rather than by a platform's privacy settings.
The thesis it argues: the discipline that makes an enterprise knowledge platform trustworthy — a single source, declared structure, quality gates, explicit provenance, portable formats — is not an enterprise idea. It works just as well on a subject with no budget and no stakeholders, and it matters more there, because nobody will rebuild it later.
What it does¶
- One source, four languages. Chapters are held per language with shared metadata and a translation guide, rather than as four drifting copies.
- One source, three outputs. The same content builds a navigable website, an e-book, and slide decks.
- Completeness is measured, not assumed. A data-quality check classifies every chapter in every language as OK, STUB, or MISSING and reports coverage across the set.
- Access is controlled at the edge. The site is deployed to AWS behind Google OAuth2 via Cognito, with JWT sessions enforced in Lambda@Edge in front of CloudFront.
The system¶
Source documents → normalisation → per-language chapters → generated navigation → three build targets → deploy. Infrastructure is Terraform; 15 GitHub Actions workflows cover CI, the e-book build, a publish smoke test, and separate deployment paths for the book site, the promotional sites, staging and production.
The decisions worth explaining:
Quality gates over trust. The build reports content completeness per language rather than rendering whatever exists. A chapter that is a placeholder is named as a placeholder, and drift between the chapter taxonomy and the site navigation fails a check rather than producing a quietly wrong menu. Accepted trade-off: the pipeline is noisier and stops more often than a simple site build, and that is the intended behaviour.
Generated navigation instead of a hand-maintained menu. With four languages and a growing chapter set, a hand-written navigation file drifts within weeks. Navigation is generated from the chapter taxonomy, with parity checks between them. Accepted trade-off: a build step to debug when it goes wrong, in exchange for a class of error that can no longer happen silently.
Authentication at the edge, not in the application. The site is static; there is no application to authenticate against. Putting JWT verification in Lambda@Edge keeps the content static and cacheable while still gating it. Accepted trade-off: edge functions are harder to test locally than middleware, and a deployment mistake there fails closed for everyone.
One cloud in production, two scaffolded. AWS is real; Azure and GCP exist as Terraform scaffolds and are marked planned. Accepted trade-off: scaffolds that are not exercised will rot. They are kept because the portability question is the point of the project, not because anyone needs three clouds.
Two licences in one repository. Code is MIT. The narrative and biographical content is CC BY-NC-ND 4.0. Accepted trade-off: two licence files and a boundary to explain — in exchange for tooling anyone can reuse, and a family's story that stays theirs. This is the decision I would most encourage someone else to copy.
The pattern this shares with my enterprise work¶
The completeness checker is the fail-loud pattern in a content pipeline.
In a knowledge platform, contract validation with quarantine exists because a corpus that is silently 80% complete answers every question confidently, including the ones it should not. In a four-language book, a chapter that is missing in French does not announce itself either — the site simply renders without it, and the reader who needs French never learns there was more.
Same failure mode, same fix: measure completeness explicitly, name what is absent, and refuse to let the gap disappear into a successful build. The subject changed; the argument did not.
What AI did, and what I decided¶
AI-assisted: build scripts and the CI workflow scaffolding, draft translation passes for review rather than for publication, illustration prompts and iteration, and documentation drafts.
Human-owned: the requirement that the content outlive the platform, and everything that follows from it — portable Markdown as the source of truth, the licence split, the decision to gate access at the edge, the choice to measure completeness rather than trust the build, and the editorial judgement over a family member's words.
The translation point is worth being precise about. Machine translation moved a four-language book from impossible to feasible for one person. It did not make the result publishable on its own: a memoir carries idiom, period vocabulary and personal voice, and a fluent mistranslation is worse than an obvious one because nobody catches it. Assisted drafting, human review, and a translation guide to keep terminology consistent across languages.
Evidence¶
- Public repository, 200 commits, 15 CI workflows, tests covering the taxonomy and navigation checks.
- Content completeness is reported per language on every build — the coverage number is a build output, not an estimate.
- No secrets tracked in the repository; environment files and secret directories are gitignored, and this was verified rather than assumed.
Not evaluated: whether relatives actually read it, in which languages, or whether the authentication step deters more readers than it protects. There is no analytics and no feedback loop. That is the most useful thing I do not know about this project.
Limits¶
- Azure and GCP are scaffolds. They have not been deployed. Treat them as an argument about portability, not as working alternatives.
- Translation quality is uneven across the four languages and depends on how much review each has had. The completeness check measures presence, not quality — a chapter can be OK and still read poorly.
- Edge authentication is a single point of failure. A bad deployment there locks out every reader at once.
- No support offered. This is a family project published because the tooling may be useful to someone with the same problem. It is not a product, and I do not intend to maintain it for anyone else's use case.
- The site's uptime is not claimed here. Deployment architecture is documented; current availability is not something this page asserts.
Reuse¶
Three parts generalise beyond a memoir, and they are the reason the repository is public:
- The completeness checker — a per-language, per-chapter OK/STUB/MISSING report for any multilingual content set.
- The multi-output build — one Markdown source producing a site, an e-book and slides, without the content ever being trapped in a generator's format.
- The dual-licence model — MIT for the code, CC BY-NC-ND for the narrative content, in one repository. For anyone publishing personal, family or archival material alongside the tooling that renders it, this is the decision that keeps both possible.