EVIDENCE BEFORE CONFIDENCE

Proof earns the claim.

APDD asks to be judged by what can be observed, examined, tested and challenged - not by how confidently something is described.

A demonstration can be promising without proving universal reliability. A test can succeed without proving every condition has been covered. A correction can improve one failure without establishing that no other failure remains.

WHAT COUNTS AS PROOF?

Evidence should be proportional to the statement.

The stronger the claim, the stronger the evidence should be. If APDD says a page loads, that can be checked directly. If an application performs a defined job, the job and success conditions can be tested. If a capability is called reliable, evidence must extend beyond a single successful run.

Useful proof may include observable behavior, reproducible tests, source verification, comparisons, failure cases, documented boundaries, independent checks and evidence that a correction addressed the observed problem.

INSPECT WHAT EXISTS NOW

Start with reality before changing it.

Testing begins by inspecting what actually exists. Identify the current page, application, behavior, code, evidence or output before deciding what is wrong or what should change.

This protects against fixing a problem that has not been demonstrated and protects working behavior from accidental damage. APDD prefers a bounded change tied to observed evidence over an unnecessary rewrite driven by assumption.

For public work, inspection includes whether links work, pages load, navigation makes sense, content is readable, mobile layouts survive, claims match readiness, and private material remains outside the public surface.

TEST US

Try to make the claim fail.

A useful test is not designed merely to produce a green checkmark. It challenges conditions under which the claim might break: different inputs, screen sizes, sequences, failure states, conflicting evidence, missing dependencies or another vantage point.

THE METHODOLOGY

APDD tests APDD itself.

The Methodology is not exempt from its own standard. APDD can observe what happened, stress an explanation, change a suspected factor, probe another angle, observe again, and update only when evidence earns the update.

A methodology can become dogma if treated as automatically correct. APDD intends the opposite: the method remains examinable and procedures can be revised when repeated evidence demonstrates a better way.

VANTAGE POINT

One result can look different from another position.

EXAMINE VANTAGE POINT

A test may miss weakness because it examines only the expected path. Another user, device, question, source, sequence, environment or interpretation may reveal something the original test did not.

This does not mean every interpretation is equally supported. It means looking for relevant conditions that could change what the evidence justifies.

CAPABILITY DEMONSTRATION

A demonstration shows something. It should not claim everything.

Public demonstrations let visitors inspect behavior rather than relying only on description. But a demonstration has a boundary. It can establish that a capability performed an observed task under observed conditions; broader reliability requires broader evidence.

Experimental, pre-release, demonstrated and production-ready are not synonyms. Status should follow evidence.

INVESTIGATION AND SOURCES

ATLAS should expose uncertainty, not bury it.

Evidence can conflict. Sources can differ in quality, recency, scope and interpretation. A useful investigative system should make those distinctions easier to examine rather than turning disagreement into artificial certainty.

For ATLAS, the strength of an answer should depend on the strength and relevance of supporting material. Unknowns, limitations and unanswered questions belong in the result when they materially affect the conclusion.

FAILURE AND CORRECTION

A correction needs proof too.

Finding failure is only the beginning. A correction must be tested against the failure it was meant to address, and surrounding behavior should be checked for regressions or unintended changes.

Changing code, copy, configuration or design is activity. Demonstrating that the change improved the targeted condition without unacceptable collateral damage is evidence of correction. When correction does not survive the test, APDD should not declare completion.

REPRODUCIBILITY

Can the result survive another run?

A single success can depend on a temporary condition. When practical, APDD should repeat important tests, preserve relevant inputs and conditions, and compare later results with the earlier observation.

When repetition produces a different outcome, that difference becomes part of the investigation. Discover which conditions explain it and whether the original claim needs narrowing.

BASELINES AND COMPARISONS

Improvement requires something meaningful to compare.

Calling a change better is incomplete unless the comparison and measurement are visible. A baseline can be the previous version, a defined expected result, a manual process or a known failure state.

Faster is not automatically more accurate. More comprehensive is not automatically more useful. Different qualities can improve or deteriorate independently.

NEGATIVE RESULTS

A test that disproves the expectation still produced evidence.

If an approach fails, a source does not support a hypothesis, an interface confuses users, or a correction creates regression, the result narrows what can responsibly be claimed.

Recording negative outcomes prevents unsupported assumptions from quietly returning and reduces selection bias. Preserving only successful demonstrations makes apparent evidence stronger than the complete record justifies.

NO FALSE COMPLETION

Done should describe an earned state.

A task can be coded without being tested. A file can be uploaded without being live. A page can return HTTP 200 while containing broken navigation. A correction can solve a symptom while leaving its cause untouched.

A deployment gate can include protected rollback, candidate verification, live HTTP checks, privacy checks, link checks and representative rendering. Completion follows verification rather than preceding it.

SOURCE QUALITY

More sources do not automatically mean stronger evidence.

Repeated versions of the same unsupported assertion do not necessarily provide independent reasons for confidence. Source quality depends on relevance, proximity to underlying evidence, transparency, recency when time matters, and whether another person can inspect the basis of the claim.

Primary material can establish what an organization published, what a specification requires or what data contains. Secondary analysis can add context and comparison. Each should be suited to what it is being asked to establish.

TRACEABILITY

Can we get from the conclusion back to the evidence?

A useful proof trail connects a public statement to the observation, test, source or result that justified it. Without a path back to supporting material, a visitor may have confidence but no practical way to inspect why it was earned.

For web work, traceability can mean identifying the tested candidate, preserving the previous version, recording checks and verifying the live result after deployment. For investigation, it can mean connecting factual statements to supporting material while separating facts from inference.

ABLATION AND COUNTERFACTUAL TESTING

What happens when the suspected cause is removed?

When several factors could explain a result, changing or removing one can reveal whether it mattered. If removing a component does not change the result, the explanation may need revision.

Ask also what should be observed if the explanation is wrong. Designing a test around that alternative can expose confirmation bias and make the surviving explanation earn greater confidence.

REGRESSION TESTING

Did the correction damage something that already worked?

A local fix can create a distant failure. Navigation changes can affect mobile layout. Content rewrites can remove necessary links. Configuration changes can solve one path while breaking another.

Regression testing asks whether previously verified behavior survives after the change. Scope should be proportional to potential impact.

HUMAN VERIFICATION

Automation can test quickly. Humans still have things to inspect.

Automated checks are valuable for repeatable conditions: status codes, file sizes, structural rules, links, expected outputs and regression suites. But a passing automated check does not prove an experience is understandable, visually coherent or appropriate to its purpose.

Human inspection can complement automation. A page can technically render while still being confusing. Text can satisfy a word count while saying little. Proof is stronger when the chosen test corresponds to the quality being claimed.

PRIVACY AND BOUNDARIES

Testing does not justify exposing what should remain private.

Evidence gathering should respect the boundary between what needs demonstration publicly and what belongs inside the system. APDD can show outcomes, limitations and relevant testing without publishing private architecture, credentials or internal controls.

Proof does not require publishing everything known about a system. It requires enough appropriate evidence to justify the statement being made.

UPDATE ONLY IF EARNED

The evidence gets the last word.

Testing has little value if the conclusion is fixed in advance. When a result contradicts expectation, APDD should change the conclusion, narrow the claim, change implementation or design another test according to what evidence supports.

Question what deserves questioning, preserve what survives meaningful tests, and update when reality supplies a reason. The objective is confidence proportional to what has survived examination.

EDGE CASES

The ordinary path is only one path.

Systems often look reliable when tested only with expected inputs. Long text, missing information, unusual navigation, smaller screens, slower connections, conflicting sources and invalid inputs can expose behavior the ordinary demonstration never reaches.

Not every imaginable edge case deserves equal effort. Testing should follow risk and relevance. When failure could materially change a visitor result, understanding or ability to recover, less convenient paths deserve attention.

FROM TEST TO PUBLIC CLAIM

Translate evidence without enlarging it.

A bounded test should produce a bounded statement. If a candidate passed defined desktop and mobile checks, say that. If a capability succeeded in a controlled demonstration, say that. If reliability has not been established at production scale, promotional language should not imply it has.

Visitors should not have to reverse-engineer the difference between demonstrated behavior and aspiration. APDD should make that difference visible in the claim itself.

SHOW THE EVIDENCE. SHOW THE LIMITS.

What should the visitor get?

A visitor should understand what was tested, what happened, what the evidence supports, what it does not establish, and what remains open. That is more useful than unsupported declarations that everything passed.

As APDD develops, public proof should become more concrete: demonstrations, defined tests, visible outcomes, documented limitations and corrections that can be compared with the failures that produced them.

APDD remains in development. Evidence for one capability should not be interpreted as proof of unrelated capabilities or conditions that were not tested.