Quick answer: Not necessarily. A software system may restart successfully while leaving transactions duplicated, omitted or inconsistent across connected applications. Recovery testing should therefore examine whether the correct business state has been restored, rather than simply confirming that services are running again. Where the behaviour of a novel system cannot be determined from existing knowledge, systematic experimentation may be needed to investigate its recovery characteristics.
A Successful Restart Can Conceal an Incorrect Result
A construction materials supplier is developing a platform that connects warehouse inventory, delivery scheduling and customer ordering.
The platform receives dispatch information from warehouse devices, updates available stock and communicates those changes to the ordering system.
During initial testing, the integration performs as expected.
Orders are processed, inventory records are updated and delivery information reaches the relevant systems.
The engineering team then tests what happens when network connectivity is interrupted.
The system reconnects automatically, and its monitoring dashboard shows that the connection has been restored.
However, a subsequent inventory reconciliation reveals that some dispatch events were processed more than once.
The warehouse physically dispatched the correct quantity of materials, but the ordering system now shows less stock than is actually available.
The platform has recovered operationally without recovering a consistent view of the transactions.
This distinction matters because software recovery is not necessarily a single event.
A connected application may need to restore its own processing state, reconnect to other components and resolve transactions that were incomplete when the interruption occurred.
A message may have been transmitted but not acknowledged.
An application may retry an operation without knowing that the receiving system already completed it.
Different components may resume processing from different states.
These are well-recognised issues in distributed software systems.
Microsoft's architecture guidance notes that message-processing failures and retries can cause the same message to be delivered more than once. It recommends idempotent processing where repeated handling of the same logical operation could otherwise create duplicate records or other unintended effects.
The important point for an experimental recovery test is therefore not simply whether the connection returns.
It is whether the system reaches the correct business state afterwards.
Test the State of the System, Not Just Its Availability
A useful recovery test should begin by defining what must remain true after an interruption.
The engineering team needs to identify the transactions involved, the systems responsible for them and the state expected when recovery is complete.
Define the expected system state
For the construction materials platform, the team might establish that every valid dispatch event must be reflected exactly once in the relevant inventory records.
A dispatch should not cause the same stock movement to be applied twice.
A completed dispatch should not disappear from the ordering system.
If the system cannot reconcile an event automatically, the inconsistency should at least become identifiable rather than silently producing an incorrect stock balance.
These statements define the expected behaviour.
They do not establish which technical mechanism will achieve it.
That distinction is useful in research because the desired outcome should be separated from the particular architecture being investigated.
Interrupt the workflow at meaningful stages
A test that disconnects the system while no transactions are being processed may demonstrate basic reconnection capability.
It may reveal little about what happens when failure occurs during an active transaction.
A more informative experiment might introduce interruption:
• before a message is transmitted;
• after transmission but before acknowledgement;
• while the receiving application is processing the event; or
• after processing occurs but before the sender receives confirmation.
These conditions can produce different recovery problems.
The team may also need to examine what happens when connectivity returns after transactions have accumulated, messages arrive out of order or an operation is retried.
Microsoft's current Service Bus guidance illustrates why these distinctions matter. A send or processing operation may succeed even though confirmation is lost, causing a retry to repeat an operation that has already taken effect. Duplicate detection and idempotent consumer logic are therefore separate controls.
The purpose of the experiment is not to create arbitrary failures.
It is to identify the conditions under which the proposed recovery mechanism may produce a different system state from the one intended.
Compare the recovered state with an independent reference
After recovery, the researchers should compare the resulting records with a reliable reference showing which business events should have occurred.
A dashboard showing that every service is online is not sufficient evidence of transaction integrity.
The evaluation should establish whether:
• every intended update occurred;
• any event was processed more than once;
• any transaction was lost;
• ordering affected the final state; and
• manual intervention was required.
The distinction between automatic and manual recovery should also remain clear.
A system that requires an operator to reconcile several records may still be commercially useful.
But the experiment should not describe it as fully automatic recovery if manual correction was required.
Keep Backup Restoration and Transaction Recovery Separate
The Australian Signals Directorate's September 2026 Information Security Manual recommends coordinated testing of the restoration of data, applications and settings from backups to a common point in time as part of disaster recovery exercises.
That guidance supports a broader operational principle: restoring individual parts of a system independently does not necessarily establish that the overall restored environment is coherent.
However, backup restoration and distributed transaction recovery are not the same technical problem.
The ISM guidance does not determine whether a particular message was duplicated, whether an event was processed exactly once or whether a distributed workflow remained internally consistent.
Those issues require evidence from the architecture and recovery behaviour of the system being investigated.
The two forms of testing can complement one another, but they should not be treated as interchangeable.
When Does Recovery Testing Become a Research Question?
Software recovery and resilience testing are established engineering practices.
Implementing a conventional retry mechanism, configuring an existing message broker, applying a documented idempotency pattern or correcting a known transaction-processing defect does not automatically constitute core R&D under Australia's R&D Tax Incentive.
Current Australian Government software guidance makes this distinction relatively clear.
It states that software work may involve core R&D where a specific technical hurdle cannot be resolved using existing knowledge, methods or solutions, including by experienced professionals. The proposed solution must then be investigated through a hypothesis-led experiment.
The same guidance explains that software work can be technically difficult while still being routine where it applies known tools, techniques or established practices with predictable outcomes.
For example, following documented integration methods or applying established configuration options would ordinarily point towards implementation rather than an unresolved research question.
A different situation may arise where a business is investigating a transaction-coordination problem that established approaches cannot resolve under the relevant constraints.
For example, a proposed architecture might need to maintain consistent inventory records across intermittently connected devices while processing concurrent or conflicting updates.
The technical question should then be narrower than:
Can the software recover after a network failure?
It might instead be:
Can the proposed coordination mechanism restore a consistent inventory state after interruptions occurring at defined transaction stages without duplicate or lost stock movements?
If existing knowledge already allows a competent professional to determine how that outcome will behave, the work remains implementation.
If the outcome cannot be known or determined in advance and must be established experimentally, the activity may need to be assessed against the core R&D criteria.
Under current R&DTI guidance, core R&D activities must be conducted for the purpose of generating new knowledge and involve an outcome that cannot be known or determined in advance.
The outcome must be determined through a systematic progression of work based on principles of established science, proceeding through hypothesis, experiment, observation, evaluation and logical conclusions.
Testing alone does not satisfy that requirement. Current software guidance specifically states that testing which does not require a hypothesis to resolve a technical hurdle does not meet the systematic-progression requirement.
Preserve Evidence of What Happened During Recovery
For an investigation into transaction recovery, a practical experimental record may include:
• the technical hypothesis being tested;
• relevant software and configuration versions;
• transaction or message identifiers;
• the transaction sequence before interruption;
• the exact point at which interruption occurred;
• system state before and after recovery;
• duplicate, missing or out-of-order events;
• automatic and manual corrective actions; and
• the reasoning behind subsequent architecture changes.
These are practical records for this type of investigation rather than a prescribed R&DTI checklist.
Current Australian Government software guidance gives examples of records that may support software R&D, including design notes, architecture decision records, test plans and outputs, logs, dashboard screenshots, system-behaviour records and performance graphs.
The general R&DTI record-keeping guidance also states that records should be created at the time the activity is conducted and should show what was done, how it was performed, when it occurred and who carried out the work.
Unsuccessful recovery runs should therefore remain visible.
A test that produces duplicated transactions may provide important evidence about a limitation in the proposed architecture.
If the team then modifies the recovery mechanism, the record should preserve the relationship between the observed failure, the revised technical explanation and the next experiment.
Decide What the Evidence Actually Supports
For founders and CTOs, the immediate question is whether the system maintains the required transaction integrity under the operating conditions relevant to its intended use.
For CFOs, the same evidence helps determine whether further investment should go into routine implementation, another technical investigation or a different architecture.
A successful restart may establish that an application can return to operation.
It does not necessarily establish that every transaction has been recovered correctly.
Likewise, successfully recovering one interruption scenario does not automatically establish reliable behaviour across every possible failure point.
The conclusion should match the conditions actually tested.
A defensible finding might be:
The system restored connectivity automatically and maintained correct inventory state for interruptions occurring before transmission and after acknowledgement, but recovery from interruptions during message processing remains unresolved.
That is more useful than describing the entire platform simply as "recovery tested".
Conclusion
Software recovery should not be judged solely by whether services come back online.
In a connected system, the more important question may be whether the correct business state survives the interruption.
Retries can duplicate operations.
Lost acknowledgements can make completed work appear incomplete.
Different components can restart with inconsistent information.
A useful recovery experiment therefore examines the state of the transactions, not just the availability of the applications.
The key question is:
After the system recovered, did the business information recover correctly as well?
Sources & Further Reading
Australian Signals Directorate — Information Security Manual: Guidelines for System Management, September 2026
Microsoft Azure Architecture Center — Asynchronous Messaging Options
Microsoft — Prevent Message Loss and Duplicate Processing in Azure Service Bus
Australian Government — Software Development Sector Guide for the R&D Tax Incentive
Australian Government — Conducting Core R&D Activities
Australian Government — Record Keeping for the R&D Tax Incentive
Talk to Ignition Research if your software or systems-integration project involves uncertainty about transaction integrity after interruptions and you need to define what recovery behaviour the experiment must establish. As a Registered Research Service Provider, Ignition Research assists businesses with research question definition, experimental design, technical investigations and contemporaneous supporting records within its registered research fields.
RSP registration confirms that the provider has met the relevant registration requirements for its registered research fields. It does not constitute government endorsement of a project or guarantee R&DTI eligibility.
We do not determine R&DTI eligibility or provide tax advice. The R&D Tax Incentive is a self-assessment program, and companies remain responsible for assessing their activities, expenditure and circumstances and obtaining appropriate tax advice.
This article provides general information only and is not tax, legal or financial advice.
Working on a project like this?
Tell us what you're building and the part you're not sure will work. A researcher from our Adelaide team (registered Research Service Provider RSP000047) reads every enquiry and replies within two business days. No documents needed.
