Acceptance rounds, retests, and training material — one content framework.

Acceptance testing without spreadsheets

The proven half first. Test rounds run on the engagement hub as typed, in-code test plans — served like any other page, with evidence captured as testers work and every submission carrying a stable, citable id.

The discipline is in what happens next: every submission is classified — a genuine miss, a spec gap, or a conflict with a decision someone already made — each judged against a named authority instead of absorbed into a vague punch list. Conflicts are quarantined and ruled on explicitly.

Feedback becomes a partition, not a pile.

Where it goes next: tests that train

Here is the part we are building toward, stated plainly as a design rather than a deployment. Every test section in the framework already carries a deliberate seam: a mandatory feature-guide field — the explanation of what the feature is for, written by the people who built it, attached to the test that exercises it.

That seam is the hinge of the combined framework. Test plans mint the regression pool: when a round finds and fixes real issues, those fixes become the standing tests the next release must pass. And the feature guides seed the training content: the material that teaches your staff a feature is the same material that tests it, so documentation and verification cannot drift apart.

The sidecar: retests that respect your testers’ time

The second designed piece — the sidecar — adds retest mechanics: when a round is re-run after fixes, testers see the delta. What changed since your last pass, what needs a second look, what can be trusted from before. Nobody re-tests a whole system to check three fixes.

The first full pilot is scheduled on a production engagement’s next retest round. The plans already carry the seams; live rounds upgrade instead of migrating. That is deliberate: we build the socket before the appliance, so adopting the framework costs a version bump, not a rewrite.