Generated, sent and recorded are different facts

A scheduled report can have a saved definition, a valid PDF and no actual delivery. My Atlas reporting contributions connected those pieces: migrating the email scheduler, assembling shared report data, adding delivery targets and making the resulting state inspectable.

The operator needs to know which step finished.

A shared document beneath several outputs

The authored change introduced Similarweb reporting and reusable report contracts. It superseded closed authored changes; those two records are one implementation trail, not two delivered features. The authored change joined facts, compatible sections, pivots and presentation into a document that the PDF and PPTX renderers could consume.

My assembler contribution composes existing helpers instead of duplicating their compatibility and pivot rules. The inspected module has no persistence, renderer or clock dependency. An injected generation time supports comparable outputs for the same input. A section whose data shape cannot support its presentation raises an assembly error instead of quietly plotting a plausible wrong number.

I kept assembly separate from scheduling and source refresh.

The next the authored change used saved PPC audit data as a canary source. Its rationale separates reading an existing audit from refreshing it. A scheduled report can otherwise keep restating old findings; later audit-refresh scheduling and watchdog contributions address that separate lifecycle.

A schedule can repeat stale source data. It needs its own freshness evidence.

Cost and coverage before delivery

The inspected Similarweb engine clamps the report period to available provider data, preflights estimated cost before domain-metric fetching, checks completeness after retries and renders a review PDF. Failed domain data blocks that PDF rather than being emailed as a complete report.

Inspect the system diagram

Open full-size SVG →Horizontal version →

Carl source models and exports. This view describes the Similarweb module; the shared generator has its own target-summary policy.

I keep three limits explicit.

Availability is read before the domain budget check, so “no domain metrics fetched” does not mean no provider call occurred. Credits are estimated, not a newly verified invoice. Non-production sending is skipped by default, but this engine exposes forceSend; its runtime condition is not an unconditional prohibition on sending.

Generation and delivery retain separate outcomes.

A successful report result can have emailSent: false when recipients are absent or sending is skipped. The engine awaits the mail call when sending. If that call rejects, it does not reach its subsequent success-record write. These stages are not one transaction.

The delivery registry had a missing implementation

The authored change records a concrete mismatch: Slack was accepted in saved definitions, while the engine special-cased email and no delivery target was registered. A Slack-only definition could be skipped with a message about missing email recipients.

My change registered email and Slack through the existing target contract. In the inspected shared engine, it builds the delivery plan, invokes each target, collects its result and summarizes failed, skipped or successful delivery. The plan can retain partial target results. A generated attachment alone does not make every destination successful.

The authored change persists normalized delivery results, prevents a patch from creating a missing definition and stamps source cost units. Those selected later diffs strengthen the contribution story; they do not prove a production send happened during this case-study work.

A retained destination result makes the delivery claim inspectable.

Scheduling adds another recovery boundary

The email scheduler migration and the authored change address recurring source-to-email work. The anchor diff constructs the requested calendar time with an Eastern-zone offset rather than relying on the server's local timezone. The implementation deserves explicit daylight-saving boundary tests before making a universal scheduling-correctness claim.

The schedule still needs to advance after delivery.

In the inspected due-job loop, mail is sent before its run record and next-send update. A later local-write failure can therefore leave an external delivery with stale scheduling state. My interview explanation would include that window and the absence of an inspected exactly-once transport guarantee.

Invented report sequence

1. Define an internal review report for two example domains and a supported trailing period.
2. Clamp the cover period to available provider data. An estimated budget failure stops domain metrics; incomplete metrics after retries also stop the report.
3. With complete metrics, render the PDF. In a default non-production run, retain emailSent: false and the successful generation result.
4. In a permitted send, wait for the mail operation. If it rejects, the engine does not write its success record afterward.
5. For a shared-generator report, choose email and Slack. Inspect each target result and the summary rather than infer delivery from the artifact's existence.
6. If delivery succeeds but recording fails, inspect provider evidence and local state before a resend. This is a hypothetical recovery review, not an implemented replay guarantee.

Source map and application assets

My record supports shared report assembly, scheduled execution, delivery integration and evidence repair. Operator volume, deliverability rate, measured preparation savings and current deployed configuration remain unverified. Merged UX design documents remain proposals where they explicitly say nothing was built.