{"id":"device-completion-reset-epochs","name":"Completion, reset and execution epochs","shortName":"One job across canceled attempts","role":"Separate physical work, accepted completion and useful output while a device is stopped and reinitialized.","description":"An asynchronous device job can have written some output without establishing an accepted completion. Reset makes that distinction consequential: the host must not assume that every in-flight request finished, or that none of its side effects occurred. The teaching recovery path first establishes quiescence, retires the old queue and mappings, and cancels the uncommitted attempt. It then optionally runs the same pure matrix job under a new epoch with intact host inputs. The stable job identity connects both attempts, while the epoch prevents an older host-side notification from authorizing the new result. Every executed multiply-accumulate remains counted, including work whose partial output is discarded. The accepted consumer result appears once after all current-attempt writes, matching completion identity and output visibility. This finite replay is safe only under the stated pure-operation contract; repeating external side effects would require a stronger application recovery design.","mechanism":["A descriptor carries the stable job ID and the current execution epoch.","Every output cell is written before the normal completion record is posted.","Reset-needed stops the host from treating the old attempt as successful; the device is then assumed quiescent only at reset acknowledgement.","The old attempt’s arithmetic becomes discarded work, and its queue/mappings are retired before reuse.","An optional retry reestablishes readiness and performs the same operation under a new epoch.","A previously queued host notification for the old epoch is rejected; only one matching current completion can authorize publication."],"prerequisites":["dma-visibility-ownership","firmware-device-contract"],"related":["retained-work-restart-boundary","checkpoint-retained-work","cluster-commissioning-gates"],"specs":[{"label":"Job identity","value":"matrix-job-1","context":"Retained across attempts; completion also needs the active epoch."},{"label":"Default reset position","value":"After two output cells","context":"Four MACs have executed and eight output bytes have been written."},{"label":"Retry assumption","value":"Intact inputs and acknowledged quiescence","context":"No fault rate, repair latency or external side-effect recovery is inferred."}],"interfaces":[{"name":"Declared runtime inputs","direction":"in","signal":"Stable matrix job, buffer identities and the stated device/visibility contract"},{"name":"Inspectable accepted or rejected result","direction":"out","signal":"Event trace, actual buffer values and bounded completion/work ledger"}],"science":[{"title":"Account every executed MAC","equation":"Executed MACs equal active, discarded and committed MACs at every event.","explanation":"Reset moves the uncommitted attempt’s active count to discarded. Publication moves the accepted attempt’s active count to committed. Committed arithmetic is still separately checked for semantic correctness.","assumptions":"Exact finite ledger of this one pure 2×2 job, at most one reset and one retry. Reads and writes are accounted separately in bytes."},{"title":"Completion must belong to the live attempt","equation":"Completion acceptance requires matching job and epoch, a live queue, all output cells written and no prior acceptance.","explanation":"The implementation additionally requires a published live descriptor. A repeated notification cannot cause a second accepted result.","assumptions":"A bounded local protocol. Epochs are identifiers here, not cryptographic tokens or a distributed exactly-once guarantee."}],"engineeringExample":"Reset the default job after its second output cell. The old memory contains [19,22,−777,−777], but no C is published. A retry performs eight more MACs, producing 12 executed = 4 discarded + 8 committed, with 64 input read bytes and 24 output write bytes across both attempts. It publishes [[19,22],[43,50]] once. Stop instead publishes nothing. Reset after all four writes still cancels eight uncommitted MACs when the completion boundary has not been crossed.","learningObjective":"Reconcile partial output, discarded arithmetic and one accepted result across a device reset, and reject an old or duplicate completion.","misconception":"Physical writes and notifications do not independently establish that an entire intended job is safe to publish.","check":{"question":"A reset cancels four MACs, then a full retry executes eight. How much arithmetic was executed and committed?","options":["Eight executed, eight committed","Twelve executed, twelve committed","Twelve executed, eight committed"],"answer":2,"explanation":"The canceled four MACs remain physical work but do not belong to the accepted attempt."},"checks":[],"whyAI":"Long-running accelerator services need to separate retried execution from completed useful requests. Recovery correctness is part of delivered compute capacity, not merely an availability percentage.","tradeoff":"Keeping inputs and tracking generations enables this pure-job retry. The model does not restore corrupted input memory, repair firmware or make side-effecting requests safely replayable.","evidenceNotes":"Primary sources establish the cited runtime mechanisms. Numerical values, address ranges, ABI strings, event schedule and reset/retry epochs are authored teaching contracts. No real device, firmware image, operating-system driver, page table, cache protocol or security verification is executed.","sourceIds":["runtime-virtio-13"],"sources":[{"title":"OASIS — Virtual I/O Device (VIRTIO) Version 1.3","url":"https://docs.oasis-open.org/virtio/virtio/v1.3/virtio-v1.3.html"}],"workedTrace":{"modelVersion":"commissioning-execution-1","scenario":"device-reset","expected":{"executedMacs":12,"discardedMacs":4,"committedMacs":8,"readBytes":64,"writeBytes":24,"publishedResults":1}},"level":"software","branch":"Executable software","subbranch":"Commissioning and runtime boundaries","scale":"One process and device job; logical states and byte addresses, no timing or physical geometry","kind":"system","workstream":"N12","visualFamily":"software-flow","labId":"library","investigationId":"execution","labScope":"The commissioning-execution-1 studio executes this bounded 2×2 matrix, buffer and completion contract. The surrounding atlas scene is conceptual; it is not a firmware emulator or system simulator.","history":[]}