Accept your builder website with witnessed tests

Accept a builder website by witnessing account control, representative buyer paths, synthetic inquiry behavior, analytics access and recovery records. AgAI Labs proposes the acceptance matrix below to record evidence, failures and unresolved dependencies. Keep asset custody, working functionality and release permission separate. A completed worksheet does not certify security or accessibility.

What must the builder witness before accepting the website?

Start with the website revision under review. Record its identifier, preview location, review date, approved page inventory and responsible builder role. Evidence from another revision cannot close a test on this one. If a repair changes the revision, identify which tests need repeating.

Select buyer tasks that represent your approved website. Examples include finding a plan, reading its specifications, checking a project and locating the inquiry route. Write the expected destination before testing. A page that opens can still contain the wrong plan revision or an unavailable document.

Use separate decisions for custody, function and release. Custody means the builder controls the asset and can retain it. Function means the witnessed result matched the expected result within the stated test boundary. Release permission records who authorized a particular production action. Passing a preview test grants no permission to publish.

The Handoff stage describes the broader transfer. This proposed worksheet narrows that transfer to observable website acceptance. Agree on blocking conditions before the session, including which missing ownership records or broken buyer paths prevent acceptance.

Copy this worksheet header and matrix

Website revision: [identifier]
Review environment: [isolated preview reference]
Approved page inventory: [document reference]
Review date and timezone: [value]
Builder acceptance role: [role]
Technical witness role: [role]
Permitted tests and excluded actions: [scope]
Evidence folder: [private reference]
Blocking conditions: [agreed list]
Custody decision: [pending]
Function decision: [pending]
Release permission: [separate decision reference or none]

Copy the table into your private working document. Replace each bracketed value during the review. Add rows for website features outside this starter set. Keep one expected result per row so a partial success cannot hide a failed step.

Which account evidence proves control?

A public website or a vendor invoice alone does not demonstrate builder control. Ask the authorized account owner to attest to the builder's role, asset identity and recovery responsibility. Record what was witnessed and what remains unverified. Obtain approval before viewing real accounts or private records.

Keep separate evidence for the domain, hosting, source archive and analytics. A builder-controlled domain does not establish hosting custody. An analytics report does not establish account administration. Use the domain ownership reference when defining the domain row.

For analytics, record the approved role and which website the account concerns. Distinguish access evidence from event collection evidence. Viewing the right account does not prove that an inquiry event arrived. Mark collection unresolved unless a separately authorized test supplies that evidence.

Use private document references in the working matrix. Keep passwords, tokens, recovery codes, real addresses and private account screenshots out of the public checklist. Do not copy credentials into evidence notes. If evidence cannot be shared safely, record an authorized witness's attestation and its limits.

How do buyer-path tests work without live messages?

Ask the technical owner to prepare an isolated preview with outbound inquiry actions disabled and replaced by stubs. A stub returns a chosen test response without delivering an inquiry. If isolation is unverified, stop before activating any inquiry control. Leave its row unresolved.

1. Agree on the revision, permitted environment, witnesses and expected results before testing.
2. Confirm that inquiry, email, call and analytics actions cannot reach production services.
3. Follow the approved plan-to-specification path using a phone view and keyboard navigation.
4. Compare each destination and document revision with the approved page inventory.
5. Use synthetic fixtures to inspect invalid-input, simulated-success and simulated-service-failure states.
6. Record the visible message, test boundary and evidence reference for each result.
7. Assign exceptions and review custody, function and release decisions separately.

Label fixtures with invented identifiers such as INQUIRY-A and PROJECT-B. Use no real buyer details. Inspect telephone and email link destinations without placing calls or opening a send action. A message shown by a stub proves only the interface response tested.

The W3C form notification tutorial recommends clear success feedback and errors that explain corrections. Apply that guidance when writing expected interface results. For example, an invalid required field should receive a useful correction message rather than an unexplained color change.

Do not record simulated success as delivered mail or a stored inquiry. Production routing, storage and analytics collection remain unresolved in this worksheet until separately authorized and witnessed. This guide does not define the behavior of any particular website form.

How are failed and unresolved items recorded?

Use three result states. Pass means the witnessed result matched the expected result within scope. Fail means a witnessed result contradicted it. Unresolved means the evidence or permission needed to decide was absent. A pending provider response belongs in unresolved, with an owner and next action.

Record the observed behavior before proposing a fix. Keep the original failed observation when a retest passes. Add the repair revision and new evidence. Disposition describes the next decision: hold acceptance, retest, or accept a documented exception within the agreed scope.

Fictional worked example

The following example is invented. Revision DEMO-C contains a plan page, an inquiry stub and an analytics access dependency. The references are fictional labels, not real files or account evidence.

The successful document path does not offset the failed inquiry check. The absent analytics witness does not establish a defect or control. Both open rows retain their own evidence requirements. No production release is authorized by these fictional observations.

Who accepts the remaining work?

The designated builder acceptance role reviews each exception with its responsible owner. Record the affected asset, dependency, next action, agreed review point and decision authority. Avoid an unassigned label such as “vendor issue.” Identify which role must obtain the missing answer.

Recovery review should identify the source revision, archive location, publishing instructions and rollback decision authority. A document review does not prove restoration works. Record recovery execution unresolved unless an approved isolated rehearsal supplies evidence. Do not perform a production rollback as an acceptance exercise.

Close the session with separate custody and function decisions. Record excluded tests and accepted exceptions explicitly. Keep production release permission in its own decision record. Transfer ongoing checks to the website maintenance plan with the same test IDs and evidence references.