It passed the tests. Is it ready to operate?

A service can produce the correct response without having demonstrated that it can handle the duration, volume and conditions of its intended operation. This brief proposes an evidence contract to address that gap.

Summary: before expanding a release, associate the software version with a usage profile, acceptance criteria, observed results and recovery capability. The aim is not to certify that the system “never fails”. It is to make the decision to operate within known limits verifiable.

The following procedures are this article's technical proposal. They do not describe controls already deployed in Forge, a certification or tests performed by our team.

Starting evidence and limits of the conclusion

The Santos et al. preprint evaluated 12 application/environment combinations in 48-hour runs, using Mann–Kendall and Sen to analyze trends. Memory was measured at server level, not only in the process. The sample, coupled environments and lack of independent repetition limit generalization. Memory growth does not establish a causal memory leak. Source.

The experiment's duration must not become a universal requirement. Test duration needs justification based on the usage, accumulation and recovery cycles of the system under examination.

1. Specify what “operate” means

Start with a user journey, not a load tool. For a document-processing service, for example, the journey might receive an allowed file, process it, deliver the result, and remove temporary files according to retention policy. This is a hypothetical example, not a client case.

The contract must record valid inputs, sizes, concurrency, dependencies, persistence and rejection conditions. Include what counts as correct completion; a successful HTTP response does not replace validation of the business outcome.

Choose limits before running the test. Latency, tolerable errors, consumption, and recovery depend on the service. If the team cannot yet justify them, the first assessment result is that gap — not a green light.

2. Distinguish the types of tests

I suggest separating four questions:

These questions are not interchangeable. A short spike does not represent accumulated state. A long run with identical inputs may miss growth driven by cardinality. Frequently restarting an application may hide an important trend.

The Google SRE testing chapter provides practical guidance for exploring limits and observing progressive releases. This matrix, however, is our editorial proposal, not a protocol prescribed by that source. Reference.

3. Make execution comparable and safe

Record the version identifier, configuration, dependencies, load profile and dataset. Use an authorized environment, separate from production when possible, with synthetic or appropriately de-identified data and spending limits. Do not send load to third-party services without authorization.

If the application calls AI models, separate local latency from provider latency; record observed retries, failures and costs. Pin the model identifier when available and note what cannot be pinned. Do not treat a different textual response as a failure without an outcome criterion.

Instrument the process and environment: memory, queues, connections, temporary files, storage and restarts, as appropriate to the architecture. For each signal, specify units, collection frequency and gaps. A missing metric cannot be replaced with “no issues found”.

Repeat critical scenarios when feasible. Record warm-up, load changes and interventions so an apparent improvement is not merely a restart or the removal of accumulated work.

4. Investigate before attributing a cause

A trend is the start of an investigation. I recommend formulating a specific hypothesis, such as temporary-file accumulation, and seeking measurements capable of confirming or refuting it.

Change one condition at a time whenever possible. Compare the original version and the fix under the same profile. Examine practical relevance, not just statistical significance. If the process is stable while the server grows, investigate the rest of the environment before attributing the effect to code.

Static analysis can guide the search, but does not prove that a suspicious path was activated during the test. Observation and controlled intervention must be recorded together, including when they contradict the original hypothesis.

5. Report a result with explicit scope

I propose three review outcomes: approved for the described scenario, rejected against an identified criterion, or inconclusive due to insufficient evidence. Each outcome needs an accountable person and a date.

The minimum package can include:

• system version and configuration;
• definition of the tested journey and profile;
• acceptance criteria established in advance;
• time series and logs without sensitive data;
• interventions, failures, repetitions and known differences;
• human conclusion, residual risks and revalidation conditions.

Approval in a controlled environment is not observed production operation. Subsequent release requires monitoring, limited exposure, and a recovery path. Changing a dependency or expanding the usage profile may require another assessment.

Where Forge fits in this discussion

Forge's editorial contribution is to connect intent, criteria, and evidence. This brief offers a design for that conversation; it does not claim that the methodology or platform eliminates failures, already executes all the controls presented, or has been validated by the researchers.

The responsible next step is to select an authorized service, adapt the contract and test the evaluation procedure itself. A good report is not one that always approves. It lets readers understand why an approval holds — and where it stops holding.

Additional engineering guidance

Small, reviewable changes help limit assessment scope; workspace isolation is not a security boundary. This earlier guidance is independent of the new study and does not validate its results. [R1-C2]

Sources and editorial context

1. Santos et al. — Investigating Software Aging…. arXiv, preprint v1 dated August 26, 2026. Accessed: August 28, 2026. Authors' artifacts. Availability checked; experiments not reproduced. No vendor response located; this does not imply agreement.
2. Google — Testing for Reliability. SRE book, engineering guidance. Accessed: August 28, 2026. Neither a replication of the preprint nor validation of this protocol.

Editorial and responsibility note

This text combines findings attributed to sources with the author's analysis and recommendations. Personal and professional views are not proven facts; verifiable data require sources and context. The content is informational, does not replace case-specific technical, legal, or financial assessment, and promises no results. Tech Human and Trustyu have commercial activities in related fields. Research and writing were AI-assisted; Fernando Parreiras reviewed and approved the Portuguese original on August 28, 2026, without independent human review. This translation was AI-assisted.

Research cutoff: August 28, 2026. Human editorial review: Fernando Parreiras, August 28, 2026. Correction history: initial version, no material corrections recorded.