The Test.

Testing is not the ritual performed after the real work. It is part of the real work. A useful test asks a question the system must answer, then gives the institution evidence about whether the design deserves trust.

The best tests are not ornamental. They are tied to the invariant, the user obligation, the operational risk, or the failure mode that would matter in the field.

A test designed only to pass is a document of confidence, not evidence. The institution values tests that can embarrass the design while the cost of correction is still low.

Failure in testing is not reputational loss. It is transferred risk. The system was going to meet the condition somewhere; better that it meets the condition before a customer, partner, operator, or regulator has to bear it.

A unit test guards a local rule. An integration test guards a crossing between parts. An operational test guards the conditions under which the system will actually be used. The three are not substitutes for each other.

Financial infrastructure especially requires operational tests. Permissions, settlement timing, reconciliation, currency movement, incident response, and human approval cannot be fully understood by inspecting isolated functions.

A test result is more useful when it can be read by someone who did not write the code. Evidence should travel from engineering to operations, from operations to governance, and from governance back into engineering when the design needs correction.

The institution therefore treats logs, traces, receipts, review notes, and decision records as part of the test surface. A passing build is not the whole proof. It is one signal within a wider record.