Eight properties to challenge a “complete” build

A practical starting rubric for finding work hidden behind a polished interface, and why each property needs a check that can fail.

Ask where the claim could break

“The product is complete” is not a test. Our original depth signature used eight observable properties to make that sentence discussable. It is a starting rubric, not a universal certification: a brochure site and a payment ledger need different depths. For a consequential product, try following one real action through each property.

1. Guards on change. Can a write bypass authentication, role, input schema, tenant scope, legal state transition or domain rule? Remove one guard in a test branch and ask whether the suite objects.
2. An audit of the refusal. Does the system record not only a success, but a blocked action that a buyer or operator may later need to explain?
3. Concurrency. Submit the same transaction twice, simultaneously or after a timeout. Does one durable effect remain, or can a race create two?
4. Independent domain mathematics. Seed known raw inputs, let the product calculate, read back the result and compare it with a separately derived answer. A test that asks the same code to grade itself is a mirror, not an oracle.
5. Verification substance. Do tests cover failure and state, and can deliberate faults kill them? A large test folder is not proof if the important assertion never goes red.
6. The edge-of-domain rule. Can a statutory clock, suppression threshold or jurisdiction choice be traced to an explicit versioned rule, including where the rule is advisory rather than blocking?
7. Self-serve understanding. Can users learn each feature from accurate help, and does someone verify the help against the real product rather than leaving stale screenshots in place?
8. Real provider seams. For money or external authority, has the system exercised a representative provider exchange, signature and failure path? A mocked green box does not settle a payment.

The current Depth Signature paper expands the method beyond those eight into privacy, resilience, performance, accessibility, operability, economics and changeability. The chosen depth should be proportional to the obligation. The important invariant is that every selected claim has a challenge, evidence and an explicit limit.

If a supplier says “all eight,” ask to see one reproducible failure-capable check per property. If access or evidence is missing, the honest answer is “not established,” not green. That is the distinction an independent depth audit is meant to preserve.