Keep a Course Updated When Sources Change

Keeping a course updated when sources change is the difference between a curriculum and a blog you forgot to unpublish. APIs gain required fields. Runbooks swap staging URLs. Pricing pages quietly drop a plan. If your email series still cites last quarter's PDF, you are teaching archaeology.

Source-grounded courses make this visible. Every claim points at a chunk. When the chunk's content hash changes, the issue is a candidate for review — not an automatic rewrite. Automatic rewrite is how you destroy human-in-the-loop AI written courses that someone already approved.

Cadensend is built for this loop: ingest with content-hash keyed steps, scoped retrieval, structural citations, and locks in Plan Studio. It is MIT open source, self-hosted, with no hosted signup. It is not ConvertKit and not a bulk sender. Clone it from GitHub.

Key Takeaways:

• Version sources by content hash. Filenames and URLs are not identity.
• Mark issues stale when a cited chunk changes; do not silently regenerate approved teaching.
• Re-ingest on a schedule, then open a review queue ordered by learner impact (upcoming sends first).
• Patch the smallest unit: one section, one diagram spec, one citation — then re-approve.
• Retire issues whose objective vanished from the product instead of stretching old prose over a new system.
• Measure whether updates actually landed with the same quizzes you use to measure whether the course taught.

Table of Contents:

• Why email courses rot faster than wikis
• Identity: hashes, not titles
• Detecting staleness without false alarms
• What to regenerate, lock, or kill
• A weekly maintenance ritual
• Citations that survive moves
• Cadensend ingestion and locks
• When the source is a person
• Frequently Asked Questions

Why email courses rot faster than wikis

Wikis have editors, timestamps, and a URL that always means “latest.” Email issues are immutable snapshots once sent. You cannot patch issue 4 in 40 inboxes. You can only send issue 4b as errata, or fix issue 4 for the next cohort.

That split is easy to ignore when you are the only learner. It is painful in internal onboarding when new hires still receive the IAM diagram from February. It is reputationally expensive when founders teach customers using a changelog that is two versions behind.

Rot also hides because open rates stay healthy. People open mail. They do not always notice the flag was renamed. Reviewing AI-generated lesson content at authoring time does not protect you at week six.

The engineering analogy is schema migrations: you version the artifact, you detect drift, you migrate with a plan. HinterBuild's about work on production systems is the same habit. If you need the queue and webhook side, that is backend API engineering.

Identity: hashes, not titles

A source named auth-guide.md can be rewritten in place. The URL /docs/auth can be a new CMS page with the same path. Identity for teaching ops is bytes (plus a stable logical ID you assign).

Practical scheme:

• source_id: your durable ID (src_auth_guide)
• content_hash: SHA-256 of normalized bytes
• chunk_id: hash of source_id + heading path + chunk bytes
• issue_version cites chunk_ids, not “the auth guide”

When ingestion is idempotent and content-hash keyed, retries are safe. Cadensend's ingest path is fetch → parse → chunk → embed → verify, resumable after failure. That is RAG hygiene; see also why RAG pipelines return garbage when you skip it.

Normalization matters. HTML from a docs site includes nav chrome that changes every theme deploy. Parse to structure — headings, code, tables — before hash. Cadensend preserves heading hierarchy and section anchors so a citation lands on a location, not a vibe.

If you embed without structure, a one-word typo fix can reshuffle chunks and mark every issue stale. That is a false alarm factory. Chunk on headings, not on every 500 characters of boilerplate.

Reducing LLM costs also starts here: do not re-embed the world because the footer year changed. Hash first.

Detecting staleness without false alarms

Not every hash change is a teaching emergency.

Cited-span comparison beats whole-document hash. Store the exact span the issue used. If that span is unchanged, the issue can stay locked even if another chapter moved.

Upcoming-send priority. If issue 9 sends tomorrow and its chunk moved, that is today's review. If issue 2 sent last month, log errata for the next cohort; do not panic-rewrite history unless the error is dangerous (security, billing, privacy).

Dangerous stale should page a human the way HITL approval gates page on high-risk tool calls. An onboarding issue that still says “disable MFA on staging” after the runbook removed that line is an incident.

Hallucinated citations never go stale because they never pointed at a real chunk. That is why grounding is a prerequisite. Read LLM hallucination causes and fixes before you automate maintenance.

What to regenerate, lock, or kill

Regenerate (section). The objective is still valid; one procedure changed. Feed the writer the new span and the old section. Diff. Re-approve. Update diagrams from the spec if arrows changed.

Keep locked. Hash changed outside cited spans, or the change is cosmetic. Record “reviewed, no-op” so you do not re-litigate next week.

Kill. The product no longer has the feature the issue taught. Do not “update” a lesson on a dead wizard into a vague principles essay. Drop it from the plan. Add a new objective if needed.

Errata issue. For already-sent cohorts, send a short correction: what changed, what to ignore in the previous mail, link to the source. Do not pretend the old email mutated.

Cadensend locks approved issues so a full plan regeneration cannot clobber them. Stale is a flag you apply to a lock, not an excuse to delete the lock without a person.

Personal vs team learning series differ only in who has permission to break a lock. Teams should not let a nightly job break locks.

A weekly maintenance ritual

A ritual beats a “living course” slogan.

1. Re-fetch registered URLs and re-hash uploads. Cadensend-style idempotent ingest.
2. Diff hashes against last week's map.
3. Intersect changed chunks with citations on unsent issues and on a “next cohort” snapshot.
4. Open a review queue with the 12-minute pass from review AI lesson content.
5. Ship or skip each item. Skipping is allowed if you log why.
6. Spot-check one sent issue for dangerous stale (security, payments, data residency).

Timebox the whole ritual to 45 minutes for a five-to-twelve issue series. If it takes half a day, your corpus is too wide for one series. Split series rather than one mega-course that cites the entire handbook.

Teach yourself system design by email can use a monthly ritual; the sources (papers, classic posts) change slowly. Internal product courses need weekly. Customer curricula need a pass on every tagged release.

Use coding assistants to inspect diffs in git, not to approve. OpenClaw vs Claude Code is relevant for reading the docs repo. Neither should own send. The ChatGPT cheat sheet can help you draft a changelog summary for the errata issue — then you verify against the diff.

Citations that survive moves

URLs rot. Heading text drifts. Line numbers in PDFs are a trap.

Better citation targets:

• Section anchors you control (#idempotent-retries)
• Stable doc IDs in your CMS
• Repo paths + commit for code (docs/auth.md@abc1234, then a moving main pointer separately)
• RFC numbers and section IDs for external standards

Cadensend's renderer turns model-returned source and chunk references into links deterministically. The model does not get to emit a raw href that “looks right.” When a source moves, you update the renderer map and mark citing issues stale if the span cannot be remapped.

For public standards, cite the canonical document: RFC 2046 for MIME types if you teach email internals, WCAG if you teach accessible diagrams, CAN-SPAM if you teach why Cadensend is not a bulk sender. Those move slowly. Your product docs move fast. Treat them differently.

Retrieval should be scoped to workspace and series so a hash change in another team's handbook does not stale your course. Multi-tenant isolation is not optional; see multi-tenant RAG if you share infra.

Cadensend ingestion and locks

Cadensend's Ground pillar is the maintenance substrate:

• Upload files or point at URLs
• Structure-aware ingestion
• Idempotent, content-hash keyed steps
• Scoped retrieval with diversification by source
• Structural citations

Write pillar: bounded agent, AST, section regenerate, version history.

Plan pillar: locks so approved issues survive regeneration of everything around them.

Deliver pillar: exactly-once, so a maintenance resend of an unsent issue cannot duplicate, and a mistaken retry of a sent issue will not create a second copy. Delivery is keyed on workspace, issue, recipient, and issue version.

There is no hosted Cadensend to “just log into.” You run it. That is intentional. Teaching data stays in your boundary. Product: Cadensend.

If you are wiring ingest workers, SSRF limits, and signature-checked provider webhooks, contact HinterBuild. That is production backend, not a Zapier diagram.

Figure 1. Maintenance starts in the source library: hashes, scope, and citations you can remap.

When the source is a person

Some courses are grounded in a founder's head, not a URL. That still needs a source object: a dated memo, a recorded decision, a seed document you upload. If the person changes their mind, they update the memo. The series then stales against the memo, not against Slack folklore.

This is how founders teach customers without pretending the model interviewed them live. Autonomous “research agents” that browse competitors nightly are out of scope. Cadensend is not an autonomous research agent. If a human pastes a new source, the loop restarts.

For team series, assign a source owner per document, distinct from the series owner. When ownership is “everyone,” hashes change and nobody triages the queue.

Prompt injection via a newly fetched page is a maintenance risk. Cadensend treats retrieved text as data, never instruction. Your fetch job should still sanitize. OWASP's LLM top 10 is the checklist. Pair with prompt injection defenses.

Frequently Asked Questions

How do I keep an email course updated when documentation changes?

Re-hash sources on a schedule, compare cited spans, mark affected unsent issues stale, review with a timeboxed pass, and send errata for dangerous mistakes already delivered. Do not silently rewrite approved issues.

Should I regenerate the whole series on every docs release?

No. Whole-series regeneration fights locks and creates noisy diffs. Remap or patch the citing issues. Kill objectives that no longer exist.

What if a URL stays the same but the content is new?

That is why identity is a content hash. Path stability is not content stability. Parse, then hash.

Does Cadensend auto-update courses?

It gives you hash-keyed ingest, citations, locks, and review states so you can update safely. It does not unsupervised-email a new syllabus to the internet. Self-hosted, MIT, not a bulk sender.

How often should I re-ingest?

Weekly for product/onboarding series, per release for customer curricula, monthly for slow external sources like system-design classics. Dangerous documents (auth, billing) can ingest on webhook when the docs repo merges.

Can I use RAG without citations and still maintain the course?

You can, but you will not know which issues to reopen. Ungrounded courses force full human rereads. That does not scale and reintroduces hallucination risk.

Who should own the weekly ritual?

The series owner. Source owners supply diffs. A nightly job should never hold the approve-and-send rights.

Conclusion

• Hash content, cite spans, and stale issues on intersection — not on vibes.
• Lock by default; patch the smallest unit; kill dead objectives.
• Errata for sent mail, edits for unsent. Inboxes do not rebase.
• Timebox a weekly ritual or the course will rot while open rates look fine.
• Cadensend is the self-hosted engine for ingest, citations, locks, and exactly-once send — not ConvertKit.

If you want this control plane on your docs corpus, contact HinterBuild. Team context: about and LinkedIn.