Decentralised News · Agentic Finance · Decision research
By Heath Muchena · Source review 2026-11-11 · Instrument version 1.0.0
What Matters
A successful-run dashboard starts with executions that exist. It can miss obligations that never triggered, completed late or produced the wrong outcome. DN’s Expected-Work Ledger begins with the work that should have happened, then reconciles unique obligations to verified results. Duplicate attempts remain separate from completed work.
A team expects a report every weekday. Its automation dashboard shows successful executions, so the workflow appears healthy. The unresolved question is whether every report that was due reached the right destination with the right period and content.
This is a denominator problem. An execution log describes attempts observed by the automation system. A business obligation describes work owed to someone, including work for which no execution exists. Keeping those records separate allows the operator to find omissions that a success-rate chart cannot reveal.
DN Evidence Block
Sources reviewed: 2026-11-11 · Evidence type: Official scheduling, queue-processing and HTTP documentation, combined with an original DN reconciliation method.
Scope: Expected work in a defined period, identified independently of execution logs. Product examples illustrate semantics rather than compare vendor reliability.
- n8n’s Schedule Trigger documentation describes publication and timezone settings that affect scheduled workflows. The current documentation should be consulted for the installed version’s scheduling behaviour.
- AWS documents at-least-once processing for Lambda with SQS. A repeated processing attempt is therefore a condition to handle, not evidence of a second business obligation.
- HTTP 202 means accepted for processing rather than completed processing. The distinction belongs in the completion record.
Not established by this work: DN has not audited a live scheduler or measured missing-work rates. The ledger example is synthetic.
Original DN instrument · version 1.0.0
DN Expected-Work Ledger
Reconcile unique obligations due in one defined period. Obtain the due list independently of execution logs and count each obligation only once.
Enter your assumptions or load a labelled example. Required blank numbers stay missing; unknown evidence remains unknown. Use nonpersonal labels only. This instrument makes no network requests and uses no persistent browser storage.
Use your own inputs
No current result. Complete inputs or load an illustrative example.
The tool cannot verify the expected list, final-state evidence or timing. Inputs must be mutually exclusive unique-obligation counts within one defined period. Cancelled obligations and changed deadlines need a separate authorised history.
1. The schedule is not active in the intended environment
A workflow can exist as a saved design while the business assumes it is operating. Publication, enablement and environment selection should be explicit entries in the handover record. Test the actual deployed configuration rather than inferring it from an editor screen.
2. The due time is interpreted differently
A business deadline may be expressed in a customer’s timezone while the scheduler uses another timezone. Daylight-saving transitions, local working days and month-end rules can make a simple-looking schedule ambiguous. Record the business deadline, its timezone and the rule that produces each expected occurrence.
These are proposed failure categories, not claims that every scheduler behaves the same way. Some systems provide durable scheduling or missed-run handling; others require different configuration. Inspect the documented semantics of the deployed version before deciding how a missed occurrence should be recovered.
The expected list must originate outside the run log. For a recurring report, a controlled calendar can generate due IDs. For an order workflow, an authoritative order record can establish the obligation. If the expected list is created only when the same broken trigger fires, both records can omit the same work.
3. Enqueueing or acknowledgement is counted as completion
A request can be accepted while processing is pending, blocked or eventually unsuccessful. Choose the state that proves the customer outcome, not the earliest available success signal.
For a report, completion might require the correct artifact to exist in the approved destination with the correct reporting period. For a record update, it might require an authoritative read showing the intended state. The definition should identify what is being checked and how stale or contradictory evidence is handled.
Keep intermediate events. They help diagnose whether the trigger, queue, processor or destination caused the delay. They should not replace the final-state evidence. A row can say “accepted at 09:00; completion unresolved at 09:15” without pretending that either success or failure has been established.
Define a review cutoff. A job still pending before its deadline is different from the same job unresolved after the deadline. Preserve due time, observation time and completion time where available. Otherwise a late success can be silently presented as on-time performance when the dashboard refreshes.
4. Repeated attempts inflate the apparent volume
Retries and repeated deliveries can generate several logs for one obligation. Link every attempt to the same stable obligation ID and reconcile their effects. Do not subtract duplicates from failure counts without checking what each attempt actually did.
5. The workflow completes the wrong instance of the task
A report for yesterday can be generated flawlessly when today’s report was due. Match period, customer, source version and destination to the expected record. A valid artifact is not automatically the artifact owed.
6. A successful step leaves the final recipient without the result
Saving a file, sending a request or producing a draft may be necessary but insufficient. Define whether delivery requires an accepted destination record, a confirmed publication or another agreed observable state. Do not invent a read receipt where the service provides none.
These distinctions protect the denominator. One hundred successful events can correspond to fewer than one hundred completed obligations, while some obligations may have no events at all. The ledger should make both patterns visible before the operator diagnoses their causes.
Methodology, limitations and corrections
DN designed the ledger to add an independent business denominator to execution records. Official documentation supplies examples of scheduling, repeated processing and acknowledgement semantics; no provider reliability ranking is implied. The 100-obligation example is synthetic. A real audit should preserve the origin of expected work, timezone rules, scope, observation cutoff, cancellation history and final-state evidence. Test omission detection and duplicate handling with authorised records, and keep uncertainty visible until the destination state is reconciled.
Use the DN Expected-Work Ledger
Give each expected obligation one row. Its identity should remain stable through retries, route changes and recovery. A useful minimal record contains the following fields.
| Field | Decision it supports |
|---|---|
| Obligation ID and authoritative origin | What work was owed, independent of attempts |
| Scope and required destination | Whether the correct task was completed |
| Due time, timezone and schedule rule | Whether completion was timely |
| Attempt IDs and acceptance events | How execution progressed or repeated |
| Final-state evidence and completion time | Whether the business outcome is verified |
| Unresolved reason and owner | What needs investigation next |
In a synthetic period with 100 due obligations, 88 have verified on-time completion and four have verified late completion. Three are explicitly unresolved. Five remain unaccounted for in the entered categories. Verified completion is 92%; on-time completion is 88%. Extra execution attempts do not change either numerator.
The calculator reconciles those counts. “Unaccounted” means the entered record does not yet explain the obligation. It is not proof that no action occurred. An operator should investigate the authoritative state before retrying a potentially consequential action.
Count unique obligations in the completion inputs. Enter additional duplicate attempts separately for visibility. That field is not a second source of completed work and cannot be used to cancel missing obligations. The tool does not fetch records or construct the independent expected list for you.
Make omissions actionable without creating duplicate work
Assign an owner and a response rule to each unresolved state. The first action should often be reconciliation: check whether the destination already contains the correct result. An absent local log can mean an observation failure rather than an execution failure.
Where retrying is appropriate, use the system’s documented idempotency or deduplication mechanism and preserve the original obligation ID. Where such protection is unavailable, require an explicit decision about the risk of repeating the action. A generic retry button cannot make every business operation safe to repeat.
Test the monitoring path in a controlled environment. Disable a permitted test schedule, delay a synthetic result and generate a duplicate attempt, then check whether the ledger exposes each state. Record what was actually tested and which production conditions remain outside the trial.
Review cancellations and changed commitments as well. If a customer no longer needs a report, the obligation should be cancelled through an authorised record, not deleted to improve the completion percentage. A changed deadline should retain the previous deadline and the reason for the change.
The ledger becomes useful when it closes a decision: investigate, wait, retry, escalate or cancel with authority. Its purpose is not to create another dashboard. It is to make owed work and uncertain outcomes visible enough for the operator to act.
For corrections, identify the claim, source and date when contacting Decentralised News. A new record-creation timestamp does not refresh its underlying evidence.
Change log: version1.0.0, 2026-11-11. Initial documentation review, original instrument and labelled examples.
Frequently asked questions
Why not calculate success from completed runs?
That denominator omits obligations that never created a run and can include repeated attempts. Start with the unique work due, then attach execution evidence.
Does an unaccounted obligation mean it should be retried?
No. First check whether the intended action already occurred. The monitoring record may be incomplete even when the destination changed.
What happens when no work was due?
The tool reports completion rates as unavailable. An empty period does not demonstrate successful execution or establish a failure rate.
Primary sources
- n8n: Schedule Trigger node. Published workflow and timezone configuration for scheduled work. Reviewed 2026-11-11.
- AWS Lambda: Using Lambda with Amazon SQS. At-least-once processing and duplicate-handling considerations. Reviewed 2026-11-11.
- RFC 9110: HTTP Semantics, 202 Accepted. Distinction between accepted and completed processing. Reviewed 2026-11-11.
Turn the finding into a decision
Research Desk: Commission an expected-work reconciliation for one recurring workflow and one reporting period. Supply a permitted obligation source and execution evidence. The deliverable should identify unaccounted work, unresolved outcomes and a controlled omission test. DN sells research services; the scope and access requirements should be agreed before any live-system inspection.
Related DN research
Disclosure: Analysis and instrument results are editorial. Where labelled affiliate links appear, DN may receive compensation when you sign up or buy through them. Commercial relationships do not determine findings. No tested integration or guaranteed outcome is implied.
