Understand My Workflow Complex workflows are why we’re here.
See the product output

Sample Reports

The sample below shows the kind of staged reports a prospect can expect. The goal is understanding first, not an automatic fix promise.

Complex workflows are why we’re here. We work in bounded stages so the workflow becomes understandable before anyone jumps to a fix.

Sample problem

A background job syncs customer records from Service A to Service B. The job runs every 15 minutes. Service A returns records through a cursor-based paginated API. The job loops through pages, then loops through records on each page, and writes each record to Service B.

Sometimes the job times out halfway through a run. When it retries, some records are duplicated and other records are missed. The team is not sure whether the bug is in pagination, retry handling, checkpointing, or Service B side effects.

Report set

  • Workflow Orientation Report
  • Cycle Map Report
  • Handoff / State Report
  • Retry / Side-Effect Risk Report
  • Missing Evidence Report
  • QC / Acceptance Criteria Report

Sample Report 1: Workflow Orientation Report

Active workflow

Scheduled customer sync from Service A to Service B using paginated reads and per-record writes.

Apparent workflow shape

  1. Scheduled job starts.
  2. Job requests first page from Service A.
  3. Service A returns records plus cursor / continuation token.
  4. Job loops through records on the page.
  5. Job writes each record to Service B.
  6. Job requests the next page.
  7. Job repeats until no more pages remain.
  8. Job records completion, checkpoint, or last cursor.
  9. If timeout or failure occurs, retry logic decides where to resume.
The deeper concern is that the system may not have a reliable rule for what has already been safely processed when a timeout or retry occurs.

Initial classification

Nested multi-cycle workflow with side effects and retry risk.

Sample Report 2: Cycle Map Report

Outer cycle: scheduled job cycle

The job runs every 15 minutes. Key questions: Can runs overlap? Is there a lock? What happens if the previous run has not completed?

Pagination cycle

The job repeatedly requests pages from Service A. Risk: the cursor may advance before all records on the current page are safely processed.

Record processing cycle

Inside each page, the job loops through individual records. If the job fails halfway through a page, the system may not know which records were successfully written.

Retry cycle

Retry logic decides whether to resume, restart, or stop. Its correctness depends on checkpoint state and idempotency.

Sample Report 3: Handoff / State Report

Key handoff objects

  • Service A cursor
  • Customer record ID
  • Service B write result
  • Checkpoint state
  • Retry trigger

State that must be tracked clearly

A safe implementation likely needs to distinguish page requested, page received, record write attempted, record write confirmed, page fully processed, cursor safely advanced, and job safely completed.

A cursor should not be treated as safely completed unless all records associated with that cursor have been processed or safely accounted for.

Sample Report 4: Retry / Side-Effect Risk Report

Duplicate record risk

Duplicates may occur if retry sends the same customer record to Service B more than once and Service B does not treat the write as idempotent.

Missed record risk

Records may be missed if the cursor advances before all records on the current page are processed.

Partial failure risk

A timeout may occur after Service B accepted writes but before local checkpoint state recorded those writes.

Compensation risk

If writes to Service B create externally visible effects, the team needs reconciliation or compensation logic.

Sample Report 5: Missing Evidence Report

To continue analysis, the assistant would request targeted evidence rather than a full code dump.

  1. Pagination loop code.
  2. Retry logic.
  3. Checkpoint storage logic.
  4. Service B write logic.
  5. Sample timeout log.
  6. Sample duplicate record.
  7. Sample missed record.
  8. Stored sync-state schema.
  9. Whether scheduled jobs can overlap.
  10. Whether Service B writes are idempotent.
Do not submit credentials, API keys, private customer data, unredacted production logs, or full repositories at this stage.

Sample Report 6: QC / Acceptance Criteria Report

Workflow understanding criteria

  • All cycles identified?
  • Nested cycles identified?
  • Handoff objects identified?
  • Accumulated state defined?
  • Continuation and stop rules explicit?

Retry safety criteria

  • Can the job safely retry after timeout?
  • Does retry resume from a safe checkpoint?
  • Are duplicate writes prevented or harmless?
  • Are missed records detectable?
  • Are partial failures reconciled?

Final-state verification criteria

A successful run should mean every expected record was considered, every required write was confirmed or accounted for, duplicate risk was handled, missed-record risk was handled, and checkpoint state matches actual processed state.

Want to try your own workflow?

Use the browser-based demo for a first-stage sample orientation report, or create a pilot brief for a bounded real problem.

Try a DemoCreate Pilot Brief