This page documents how RoamView’s software specifications will be verified through measurable, repeatable tests, preferably before final deployment.

For each specification, the test procedure defines:

• Setup and tools: The environment and equipment needed.

• Steps: Instructions for executing the test.

• Measurements: The quantities, units and precision used.

• Pass/fail criteria: The results required to satisfy the specification.

• Risks and intermediate tests: Missing information, testing limitations and methods for testing before full integration.

Each test references its corresponding specification in the Software Requirement Specification. Any changes to a specification or its verification method must be reflected in the Requirement–Specification Tracing table.

Specification ID	Test ID	Verification
SP-4.0.1	VT-4.0.1	Account Uniqueness
SP-4.0.2	VT-4.0.2	Email Verification
SP-4.0.3	VT-4.0.3	Authentication Data Capacity and Retention
SP-4.0.4	VT-4.0.4	Mesh First-Load Time
SP-4.0.5	VT-4.0.5	Mesh Reload Time
SP-4.0.6	VT-4.0.6	Mesh History Retrieval
SP-4.1.1	VT-4.1.1	Live Walkthrough Latency
SP-4.1.2	VT-4.1.2	Live Walkthrough Robot Access Authorization
SP-4.1.3	VT-4.1.3	Live Walkthrough Control Lease
SP-4.1.4	VT-4.1.4	Live Walkthrough Requests Limitation
SP-4.1.5	VT-4.1.5	Live Walkthrough Minimum Stream Resolution
SP-4.1.6	VT-4.1.6	IoT Gateway Video Relay Capacity
SP-4.1.7	VT-4.1.7	Streaming Service Transcoding Capacity
SP-4.1.8	VT-4.1.8	API Gateway Relay Capacity
SP-4.1.9	VT-4.1.9	RoamView App Playback Capacity
SP-4.1.10	VT-4.1.10	App Backend Load Capacity
SP-4.3.1	VT-4.3.1	Guest Account Public Browsing
SP-4.3.2	VT-4.3.2	Guest Request Limitation
SP-4.5.1	VT-4.5.1	Autonomous Inspection Video Recording
SP-4.5.2	VT-4.5.2	Video Recording Save Time
SP-4.5.3	VT-4.5.3	Reconstruction Frame Sampling Rate
SP-4.5.4	VT-4.5.4	Reconstruction Data Capacity
SP-4.5.5	VT-4.5.5	Reconstruction Compute Capacity

Test ID: VT-4.1.1
Date last modified: Sept 27, 2026

Section	Field	Description
Test definition	Objective	Measure the time between sending a control command from the App and registration of that command at the robot-side receiver.
	Setup and tools	Running App, API Gateway, IoT Gateway and robot-side receiver or mock. Use an automated command sender, unique command IDs and timestamped logs. Configure the network conditions specified in SP-4.1.1.
Procedure	Steps	1. Establish an authorized session and start a mock tour. 2. Record the network configuration and confirm the receiver is ready. 3. Send 30 commands at a permitted rate, each with a unique ID. 4. Record each command’s send time and matching receiver-registration time. 5. Calculate the delay for each command and report the mean, maximum and any missing commands. 6. Repeat under each specified network condition.
Confirmation	Quantity / units / precision	Command-registration latency: ms. Network bandwidth: Mbps. Record timestamp resolution and clock-synchronization uncertainty; both must support comparison against the specified latency limit.
	Pass/fail criteria	All commands are registered within the latency limit defined in SP-4.1.1. Missing commands count as failures. The numerical limit remains TBD in the specification.
Feasibility	Risks / required clarification	Finalize the latency formula and its input values. A gateway response alone does not prove robot registration. Timestamps from different devices require synchronized clocks with measured uncertainty.
	Intermediate / integrated test	Use an instrumented mock receiver before robot integration. Repeat with the real robot receiver and representative network conditions.

Test ID: VT-4.1.2
Date last modified: Sept 27, 2026

Section	Field	Description
Test definition	Objective	Verify that commands containing invalid session tokens are rejected and never forwarded to the robot.
	Setup and tools	API Gateway, IoT Gateway and mock robot with received-command logs; API request script or tool; valid, expired and revoked test tokens. Assign a unique ID to each command.
Procedure	Steps	1. Acquire control and send 10 valid commands; confirm acceptance and delivery. 2. Send 10 commands without a token. 3. Send 10 commands with malformed tokens. 4. Send 10 commands with expired tokens. 5. Release a session’s control and send 10 commands using its revoked token. 6. Send 10 commands with a valid token altered by one byte without re-signing. 7. Check responses and gateway/receiver logs using command IDs; confirm no invalid command reached the robot.
Confirmation	Quantity / units / precision	Exact counts of rejected and delivered commands. Rejection rate = rejected invalid commands ÷ 50 × 100%. With 50 requests, results change in increments of 2 percentage points.
	Pass/fail criteria	All 50 invalid commands rejected; zero invalid commands forwarded; all 10 valid commands accepted and delivered. Otherwise, fail.
Feasibility	Risks / required clarification	Correct the specification’s ±1% precision wording. These cases verify the listed token categories; a separate test using a valid session that does not hold control is needed to confirm the single-controller requirement.
	Intermediate / integrated test	Execute against a mock robot before hardware integration. Repeat with the real receiver using safely observable commands.

Test ID: VT-4.1.3
Date last modified: Sept 27, 2026

Section	Field	Description
Test definition	Objective	Verify that control is released after 180 s of inactivity or after 360 s total, regardless of activity.
	Setup and tools	Lease-management service, two test sessions, mock robot, automated command sender and timestamped server logs.
Procedure	Steps	1. Acquire control and record the acquisition time. 2. Send one valid command, record its acceptance time, then send nothing further. Record the actual release time. 3. Confirm the previous holder cannot send commands after release and another session can acquire control. 4. Acquire a new lease and send valid commands every 30 s. Record when control is released relative to acquisition. 5. Repeat both cases three times. 6. In a separate idle test, send an invalid command and confirm it does not reset the inactivity timer.
Confirmation	Quantity / units / precision	Idle duration = release time − last valid-command time, in s. Total lease duration = release time − acquisition time, in s. Record server timer resolution.
	Pass/fail criteria	Control is released at the 180 s idle and 360 s total boundaries within the agreed timing tolerance. Commands from the former holder are rejected afterward. Timing tolerance remains TBD.
Feasibility	Risks / required clarification	Clarify whether the card’s ±30 s refers to measurement precision or acceptable timing variation. Checking only after 300 s does not verify release at the 180 s boundary.
	Intermediate / integrated test	Verify timer logic using a controlled clock, then execute the real-duration tests with the service. Repeat expiry and command rejection checks with the integrated robot.

Test ID: VT-4.1.4
Date last modified: Sept 27, 2026

Section	Field	Description
Test definition	Objective	Verify per-session request limiting and system responsiveness during excess traffic.
	Setup and tools	Isolated test deployment, authorized controller session, request-generation script, gateway/IoT logs and mock robot. Use another session to send permitted non-control requests during the test.
Procedure	Steps	1. Record N_max, T_window and the limiting algorithm. 2. Reset limiter state and send legitimate traffic for one window; record responses. 3. Reset state and send 5 × N_max requests during T_window. 4. Identify requests exceeding the permitted allowance and check their responses and downstream logs. 5. Repeat across a window boundary according to the chosen algorithm. 6. Measure other-session response times before and during the flood.
Confirmation	Quantity / units / precision	Requests: exact counts. Request rate: requests/s. Window duration: s. Response time: ms. Record actual request timestamps and timing resolution.
	Pass/fail criteria	Zero legitimate requests rejected; every over-limit request returns 429 and is not forwarded. Other-session response times meet the agreed latency criterion. N_max, T_window and the applicable latency threshold remain TBD.
Feasibility	Risks / required clarification	Define fixed-window, sliding-window or token-bucket behavior. Use consistent time units in N_max = c × T_window ÷ Z. Confirm the legitimate command rate generated by the actual UI, including held-button behavior.
	Intermediate / integrated test	Test limiter boundaries with a controlled clock and mock receiver. Then run sustained traffic against a representative deployment.

Test ID: VT-4.1.5
Date last modified: Sept 28, 2026

Section	Field	Description
Test definition	Objective	Verify that the encoded and rendered stream meets the minimum resolution and allows viewers to distinguish two boxes at 12 m.
	Setup and tools	Intended camera on a stationary mount, encoder, streaming pipeline, target viewing device, two 0.3 m boxes, measuring tape, stream metadata tools and five independent observers. Record lighting, box gap and display settings.
Procedure	Steps	1. Measure the boxes and position them 12 m from the camera with an agreed, recorded gap. 2. Configure the candidate resolution and agreed frame rate. 3. Check actual encoded and rendered dimensions. 4. Show the stream separately to five observers and ask whether they can distinguish two separate boxes. Record answers without coaching. 5. Repeat one supported resolution tier below the candidate. 6. Repeat with recorded smaller and larger box dimensions to check the feature-size assumption.
Confirmation	Quantity / units / precision	Resolution: integer pixels. Distance: m, within ±0.5 m. Box dimension: m, within ±0.05 m. Recognition success: exact observer count and %. Frame rate: fps, with the card requesting ±1 fps.
	Pass/fail criteria	Encoded and rendered width ≥398 px and height ≥302 px, plus ≥90% observer success. With five observers, this requires 5/5. A 640 × 480 stream is a candidate configuration to test.
Feasibility	Risks / required clarification	Confirm box gap, lighting, viewing distance, aspect ratio and frame rate. Five observers give 20-percentage-point increments. If a lower resolution also passes, report this and revisit the derivation.
	Intermediate / integrated test	Use a stationary camera before mounting it on the robot. Repeat under representative robot movement and site conditions.

Test ID: VT-4.1.6
Date last modified: Sept 28, 2026

Section	Field	Description
Test definition	Objective	Verify video relay throughput, buffer usage, frame preservation and gateway-added delay.
	Setup and tools	IoT Gateway connected to a repeatable encoded video source and Streaming Service. Use frame IDs/timestamps, network byte counters, buffer instrumentation and resource monitoring. Configure the agreed codec, resolution, frame rate and bitrate.
Procedure	Steps	1. Record source and gateway settings. 2. Stream a representative motion sequence for 360 s, corresponding to the maximum control-lease duration. 3. Measure ingress and egress separately in 1 s intervals. 4. Record maximum queued frames and buffer bytes. 5. Match incoming and outgoing frames after allowing the pipeline to drain. 6. Calculate gateway-added delay and verify that the gateway is configured for pass-through operation.
Confirmation	Quantity / units / precision	Throughput = 8 × byte-count change ÷ elapsed seconds ÷ 1,000,000, in Mbps. Buffer memory: MB, where 1 MB = 1,000,000 bytes. Buffered/dropped frames: integer counts. Delay: ms. Record counter and timer resolution.
	Pass/fail criteria	Zero dropped frames; buffer depth ≤2 frames; buffer memory ≤M_gw; available ingress and egress capacity each meets BW_gw; added delay stays within its allocated budget. M_gw, BW_gw and the delay budget remain TBD.
Feasibility	Risks / required clarification	Clarify whether BW_gw is specified per direction or as combined traffic. Total process RAM does not measure video-buffer RAM. Variable bitrate and keyframes may produce peaks hidden by average measurements.
	Intermediate / integrated test	Replay encoded footage without the robot. Repeat with the onboard encoder, intended gateway hardware and representative network.

Test ID: VT-4.1.7
Date last modified: Sept 28, 2026

Section	Field	Description
Test definition	Objective	Verify that the Streaming Service maintains the required video output within its compute and memory budgets.
	Setup and tools	Streaming Service on identified hardware or fixed container resources; representative video source; CPU/RAM metrics; frame counters; stream metadata and network monitoring.
Procedure	Steps	1. Configure the agreed input/output codecs, resolution and frame rate. 2. Start a 360 s representative stream and record startup separately. 3. Sample CPU, RAM and outbound traffic every second, retaining available peak measurements. 4. Check output dimensions, frame rate and frame counts at the API Gateway boundary. 5. Allow the pipeline to drain, then compare expected and received frames and report resource peaks.
Confirmation	Quantity / units / precision	Compute: CPU-seconds per elapsed second, expressed as cores used on named hardware. RAM: MB. Throughput: Mbps. Resolution: px. Frame rate: fps. Dropped frames: exact count. Record monitor resolution and sampling interval.
	Pass/fail criteria	Zero dropped frames or reductions below the required resolution/frame rate; compute and RAM stay within P_ss/M_ss; outbound capacity supports BW_ss. Numerical budgets and measurement tolerances remain TBD.
Feasibility	Risks / required clarification	Define CPU measurement consistently across core counts. Confirm whether transcoding occurs, the hardware used and how startup peaks are assessed. If resource limits apply continuously, 1 s samples alone may miss brief violations.
	Intermediate / integrated test	Replay recorded streams to verify processing and instrumentation. Repeat on the intended compute resources before accepting capacity results.

Test ID: VT-4.1.8
Date last modified: Sept 28, 2026

Section	Field	Description
Test definition	Objective	Verify that the API Gateway supports authenticated control and video relay simultaneously without added data loss.
	Setup and tools	API Gateway, Streaming Service, App, authorized session, mock robot, request generator and CPU/RAM/network/connection monitoring.
Procedure	Steps	1. Establish one stream connection and one control connection. 2. Run the agreed video stream for 360 s. 3. Send valid commands at the agreed legitimate rate throughout the run. 4. Record connection continuity, CPU/RAM, outbound traffic and command delivery. 5. Compare video frames entering and leaving the gateway and measure added delay.
Confirmation	Quantity / units / precision	Connections and dropped frames: integer counts. Compute: cores used on named hardware. RAM: MB. Outbound traffic: Mbps. Delay: ms. Record monitoring resolution and sampling interval.
	Pass/fail criteria	Both required connections remain supported; zero gateway-added frame drops; valid commands are delivered; resource use remains within P_api/M_api; outbound capacity supports BW_api. Resource budgets and permitted added delay remain TBD.
Feasibility	Risks / required clarification	Confirm the actual video-routing path and resource limits. Compare video payload/frame delivery separately from total network traffic, which also includes protocol and control overhead.
	Intermediate / integrated test	Use recorded video and a mock robot. Repeat on the intended gateway deployment with the complete stream and control path.

Test ID: VT-4.1.9
Date last modified: Sept 28, 2026

Section	Field	Description
Test definition	Objective	Verify smooth playback on the minimum supported client device.
	Setup and tools	Minimum supported device and browser, representative stream, browser performance/media statistics, device resource monitoring and playback instrumentation.
Procedure	Steps	1. Record the device, OS, browser, codec and hardware-decoding state. 2. Connect using the agreed network conditions. 3. Play the target stream for 360 s. 4. Record CPU/RAM, inbound traffic, rendered/dropped frames, playback stalls and buffer depth. 5. Measure receipt-to-render delay for identifiable frames. 6. Repeat for each minimum supported device/browser configuration.
Confirmation	Quantity / units / precision	RAM: MB. CPU: normalized utilization on named hardware. Traffic: Mbps. Frame rate: fps. Dropped/buffered frames: integer counts. Stalls: count and duration. Receipt-to-render delay: ms. Record supported measurement resolution.
	Pass/fail criteria	Zero dropped/stuttered frames during the defined measurement interval; buffering ≤N_client_buffer; resource use within the agreed budgets; rendering delay within its allocation. Device class, numerical budgets and the measurable definition of a stall remain TBD.
Feasibility	Risks / required clarification	Confirm hardware decoding on the minimum device. Browser metrics may report average buffering time rather than maximum queued frames; use suitable instrumentation to verify the actual specified limit.
	Intermediate / integrated test	Use a controlled video server before robot integration. Repeat with the complete system on the minimum supported device and representative network.

Test ID: VT-4.1.10
Date last modified: Sept 29, 2026

Section	Field	Description
Test definition	Objective	Verify that the account/scheduling backend supports 20 concurrent users generating approximately 60 requests/s, with 95th-percentile response time ≤200 ms, within 2 vCPU and 2 GB RAM.
	Setup and tools	Backend test deployment limited to 2 vCPU and 2 GB RAM; representative test database; 20 authenticated test accounts; a load-testing tool such as k6 or Locust; request logs and CPU/RAM monitoring. Run the load generator separately from the backend. Prepare available booking slots and existing bookings for valid booking/cancellation operations.
Procedure	Steps	1. Record backend version, resource limits, database configuration and network conditions. Measure idle CPU/RAM usage. 2. Configure 20 virtual users to generate a combined 60 requests/s—an average of 3 requests/s per user—across schedule viewing, booking/cancellation and viewing own bookings. Record the endpoint mix. 3. Warm up the system, then maintain the target load for 5 minutes, aiming for 18,000 requests during the measured interval. 4. Record each request’s response time, status and expected result; count timeouts, errors and requests the generator could not issue. 5. Monitor CPU/RAM throughout the run and check that successful booking/cancellation responses correspond to the expected database changes. 6. Calculate overall and per-endpoint 95th-percentile response times, achieved throughput, failure counts and resource usage.
Confirmation	Quantity / units / precision	Concurrent users: exact count, target 20. Throughput: requests/s, reported in 1 s intervals and over the full run. Response time: ms, using timer resolution of 1 ms or finer. Failures: exact count. CPU cost = backend CPU time consumed ÷ requests processed, in ms/request. RAM: MB/GB with byte conversion stated. Estimate incremental session memory as (RAM with 20 authenticated idle sessions − baseline RAM) ÷ 20, in MB/session; report peak memory separately during load.
	Pass/fail criteria	Sustain 20 concurrent users at the approximately 60 requests/s target for 300 s; overall 95th-percentile response time ≤200 ms; zero failed, timed-out or dropped requests; correct responses and scheduling updates; no resource-limit breach, out-of-memory termination or restart. Report whether average CPU cost is ≤33.3 ms/request and incremental session memory is ≤approximately 75 MB/session, as derived in the specification.
Feasibility	Risks / required clarification	The original verification wording could generate only 20 requests/s if each user sends one request/s total; configure 3 requests/s per user to exercise the 60 requests/s target. Define how booking and cancellation share the workload and avoid unintended booking conflicts. Clarify whether ±10 requests/s is an acceptance tolerance or measurement precision; a run near 50 requests/s does not demonstrate capacity at 60. Confirm whether the 2 GB budget includes OS/runtime overhead and use consistent GB/GiB units. The 33.3 ms/request calculation consumes the full two-core budget without headroom; background work also uses CPU. Confirm the cited SP-4.1.2/SP-4.1.3 references match the current account/scheduling requirements.
	Intermediate / integrated test	Before the backend is ready, validate the load script against a mock API and confirm it generates 20 sessions and the intended traffic. This verifies the test setup only. Measure actual capacity once the scheduling backend and representative database are available, then repeat on the intended deployment configuration.

Test ID: VT-4.0.1
Date last modified: Sept 29, 2026

Section	Field	Description
Test definition	Objective	Verify that each active account has exactly one email address and that the same email cannot create separate accounts through password signup and Google OAuth.
	Setup and tools	Authentication backend, password-signup and Google OAuth flows, controlled test email addresses, test Google accounts, API request tool, authentication logs and read access to account/identity records. Record account IDs before and after each operation.
Procedure	Steps	1. Create and verify a password account. Attempt another password signup with the same email; confirm rejection and no additional account. 2. Sign in through Google OAuth using that same email; confirm the Google identity links to the original account ID. 3. Create a different account through Google OAuth, then attempt password signup with its email; confirm rejection or a secure link-existing-account flow without a new account. 4. Attempt to change one account’s email to another account’s email; confirm rejection and unchanged account records. 5. Repeat duplicate signup and valid login using different capitalization of an existing email; confirm no duplicate and login to the original account. 6. Send two simultaneous password-signup requests for one unused email; confirm only one account is created. 7. Inspect account and identity records after each case for duplicate emails, missing emails or multiple emails on one account.
Confirmation	Quantity / units / precision	Accounts per registered email: exact integer count. Emails per active account: exact integer count. New accounts created during duplicate/linking attempts: exact count. Account ID equality: exact comparison. Email comparisons use the specification’s case-insensitive rule.
	Pass/fail criteria	Exactly one account per registered email and exactly one email per active account. Duplicate signup and email-collision attempts create no additional account or conflicting association. Successful OAuth linking preserves the existing account ID. Simultaneous signup creates only one account.
Feasibility	Risks / required clarification	Confirm the password-email verification policy and its interaction with SP-4.0.2: OAuth linking to an unverified password account must remain blocked until verification. Check enforcement at the database level as well as the application level to avoid concurrent-signup races. Gmail dot/plus variants remain distinct under the current specification.
	Intermediate / integrated test	Test uniqueness constraints and linking logic with controlled identity data before Google integration. Repeat through the actual password and Google OAuth flows in a test deployment; simulated identity data alone does not verify the provider integration.

Test ID: VT-4.0.2
Date last modified: Sept 29, 2026

Section	Field	Description
Test definition	Objective	Verify that password accounts cannot log in before email verification, verification tokens expire after 24 h and are single-use, and issuing a replacement immediately invalidates the previous token.
	Setup and tools	Authentication backend, controlled email inbox or test mail server, password and Google OAuth test accounts, API request tool, timestamped authentication/email logs and a controllable test clock. Access to token-generation code/configuration is needed to check the randomness source and configured entropy.
Procedure	Steps	1. Sign up with a password and controlled email address. Confirm the account is unverified and a verification email is sent to that address. 2. Attempt password login and direct access to authenticated endpoints before verification; confirm no authenticated access is granted. While the token remains valid, confirm login attempts do not issue replacement tokens. 3. Follow a valid link within 24 h; confirm verification and successful subsequent login. Reuse the link and confirm rejection. 4. On a separate unverified account, click resend before expiry. Confirm a new email/token is issued, the old token immediately stops working and the replacement expires 24 h after issuance. 5. Using separate test tokens, test immediately before, at and after the 24 h expiry boundary. 6. After expiry, attempt login with valid credentials. Confirm login remains blocked, a new token is sent automatically and only that replacement token can verify the account. 7. Submit altered, unknown and another account’s token against the wrong account; confirm they cannot verify that account. 8. Complete Google OAuth signup and confirm the email-verification gate does not block the resulting account. Attempt OAuth linking to an unverified password account and confirm it remains blocked until verification. 9. Trigger two resend requests concurrently; confirm at most one live token remains. Once the resend limit is defined, test requests below, at and above that limit.
Confirmation	Quantity / units / precision	Token lifetime: 24 h = 86,400 s. Record issue/expiry timestamps and clock resolution. Live tokens per account: integer count, maximum 1. Successful uses per token: integer count, maximum 1. Emails sent: exact count. Resend rate: attempts per defined window. Token entropy: bits, assessed from the generator’s design rather than token appearance.
	Pass/fail criteria	No authenticated access before password-email verification. An unused, valid token verifies only its associated account; used, expired, replaced or invalid tokens cannot verify it. Both replacement paths reset expiry to 24 h and leave at most one live token. Google signup receives the stated exemption, while linking to an unverified password account remains blocked. Resend-limit acceptance remains TBD until its value and window are defined.
Feasibility	Risks / required clarification	Define exact expiry-boundary behavior; a proposed rule is rejection when current time ≥ expiry time. Finalize the token entropy requirement and resend limit, including whether automatic reissues share that limit. Successful sample tests do not establish cryptographic randomness; inspect the generation method. Delivery to a test mail server does not demonstrate real inbox delivery.
	Intermediate / integrated test	Use a controlled clock and test mail server to exercise expiry and resend behavior without waiting 24 h. Then verify real email delivery, links and Google integration in the intended test environment, and perform a real-time expiry check.

Test ID: VT-4.0.3
Date last modified: Sept 29, 2026

Section	Field	Description
Test definition	Objective	Verify that unverified accounts and their associated data are hard-deleted after 7 days from signup, verified accounts are retained, and authentication data fits within the existing managed PostgreSQL instance.
	Setup and tools	Authentication backend, isolated test database matching the intended PostgreSQL configuration, account-generation script, controllable test clock, cleanup-job logs and database size queries. Prepare unverified accounts, verified accounts and associated verification tokens.
Procedure	Steps	1. Record account creation times, verification states and associated records. 2. Run cleanup immediately before the 7-day boundary; confirm unverified accounts remain. 3. Advance to and beyond the boundary, execute cleanup and confirm eligible accounts and associated data are hard-deleted. 4. Verify an account shortly before the boundary; confirm it survives subsequent cleanup runs. 5. Resend a verification token for another unverified account; confirm this does not reset the account’s 7-day lifetime from signup. 6. Simulate 20 signups/day with 20% remaining unverified over several weeks; execute scheduled cleanup and record pending-account counts. 7. Seed approximately 5,840 verified and 28 pending accounts. Measure authentication storage, including indexes and associated tables, and total database storage alongside session/mesh metadata. 8. Confirm the same managed PostgreSQL instance stores both authentication and session metadata.
Confirmation	Quantity / units / precision	Account age and deletion delay: s or days, with 7 days = 604,800 s. Account and orphaned-record counts: exact integers. Storage: bytes and MB, where 1 MB = 1,000,000 bytes. Average storage per account: authentication storage growth ÷ inserted account count, including indexes and associated data. Record clock resolution and cleanup frequency.
	Pass/fail criteria	No unverified account is deleted before 7 days; eligible accounts and associated data are hard-deleted within the agreed cleanup delay after that boundary. Verified accounts remain untouched by this cleanup. Zero orphaned verification records remain. Authentication uses the existing PostgreSQL instance, and combined storage remains within its provisioned capacity. Compare pending count and storage against the estimates of approximately 28 accounts and 3.5 MB, with the stated ±20% range, to identify sizing assumptions needing revision.
Feasibility	Risks / required clarification	Define the permitted cleanup delay: a periodic job cannot guarantee deletion at the exact expiry instant. Specify which associated data must be deleted. Test simultaneous verification and cleanup to prevent deletion of an account that has become verified. Estimated counts depend on actual signup behavior and are not unconditional limits. PostgreSQL may retain allocated disk space after deletion; distinguish removal of records and reusable space from reduction in database file size. Define the required storage headroom for “well within” capacity.
	Intermediate / integrated test	Use a controlled clock and seeded data to verify retention and capacity before deployment. Then confirm scheduled cleanup in the intended environment with a real 7-day test. After several weeks of operation, compare observed signup rates, pending counts and storage with the estimates and update the tracing table if the specification changes.

Test ID: VT-4.0.4
Date last modified: Sept 29, 2026

Section	Field	Description
Test definition	Objective	Verify that the root/coarsest mesh tile becomes visible and navigable within the specified first-render time at 20 Mbps, while finer tiles continue loading without blocking interaction.
	Setup and tools	Mesh viewer, representative published tileset with a root tile near 9.4 MB, API Gateway, CDN/storage, target client device, browser performance tools, network throttling and render-event instrumentation. Record actual root-tile transfer size, device/browser, network latency and cache conditions.
Procedure	Steps	1. Record root-tile size and confirm which render event indicates that it is visible and navigable. 2. Warm the CDN edge using a separate client, then clear the test browser’s mesh caches and establish fresh connections for the measured load. 3. Throttle the test client to 20 Mbps and verify the configured rate. 4. Open the mesh and measure from the user’s click until the root tile is visible and navigation works. Record handshake, metadata, transfer and rendering timings where available. 5. While finer tiles load, repeatedly rotate, pan and zoom; record whether the viewer responds and whether loading errors occur. 6. Repeat 10 times, restoring the same browser-cold/CDN-warm conditions. Report individual times, mean and maximum. 7. Repeat at 50 Mbps and 100 Mbps to characterize bandwidth scaling. 8. Run a separate cold-CDN test using a confirmed uncached asset or controlled cache purge and record the additional delay.
Confirmation	Quantity / units / precision	First usable root render: s, reported to 0.01 s with raw browser timestamps retained. Component timings: ms. Bandwidth: Mbps, targeting 20 Mbps with the specification’s stated ±2 Mbps range recorded. Root transfer size: bytes/MB, compared with 9.4 MB ±20%. Interaction response: ms and recorded UI behavior; numerical threshold remains TBD.
	Pass/fail criteria	Under the specified cache and network conditions, the root tile is visible and navigable within 4.4 s if this is confirmed as the hard maximum. Finer tiles continue loading successfully while navigation remains available. Clarify whether ±15% describes estimation uncertainty or an acceptance tolerance before assigning results near the boundary; it must not automatically extend the limit to 5.06 s. Cold-CDN results are assessed separately until their acceptance threshold is defined.
Feasibility	Risks / required clarification	The assumptions specify a warm CDN, but the original verification requests no CDN warm-up; these are different conditions and must be reconciled. Browser cache clearing does not clear CDN caches. Define the target device, network latency and a measurable interaction-response threshold. The estimated pyramid ratio does not guarantee an actual 9.4 MB root tile. The 4.4 s derivation requires measurement before it can support a worst-case guarantee.
	Intermediate / integrated test	Use a fixed, pregenerated tileset to verify timing instrumentation, progressive loading and navigation before robot-generated meshes are available. Repeat with actual pipeline-generated tilesets on the intended API/CDN deployment and minimum supported client device.

Test ID: VT-4.0.5
Date last modified: Sept 29, 2026

Section	Field	Description
Test definition	Objective	Verify that reopening the same mesh version uses cached tile data and renders the root tile near the specified 500 ms target.
	Setup and tools	Mesh viewer, fixed published mesh version, browser performance and network tools, render-event instrumentation and controlled network conditions matching SP-4.0.4. Enable browser caching and record cache headers, signed-URL expiry and device/browser configuration.
Procedure	Steps	1. Clear the browser’s mesh cache, open the mesh and record its initial load time. Wait until the root tile has been downloaded and cached. 2. Close the mesh view and reopen the same version within the cache-validity window, without clearing the cache. 3. Measure from the reopening action until the root tile is visible and navigable. 4. Check the network inspector to confirm the root tile was served from browser memory/disk cache without downloading its body again. 5. Repeat 10 times and report individual times, mean and maximum. 6. Repeat after the signed URL expires and is refreshed, while the cached tile remains fresh; check whether the refreshed URL preserves cache reuse. 7. Separately clear only the browser cache while keeping the CDN warm. Measure this case independently. 8. Open a different mesh version and confirm the viewer displays the new version rather than stale cached content.
Confirmation	Quantity / units / precision	Reload latency: ms, using browser timestamps with resolution of 1 ms or finer and recording actual timer resolution. Root-tile body bytes transferred: exact byte count. Cache source: browser memory, browser disk or network/CDN. Compare reload time with the initial load measured under the same device/network conditions.
	Pass/fail criteria	The correct root tile is visible and navigable, and the browser-cached case transfers no root-tile body again. Compare each reload time against the approximately 500 ms target. Confirm whether 500 ms is a hard maximum and define any tolerance before assigning timing pass/fail. A CDN-only cache hit must be assessed separately because it still requires transfer over the client connection.
Feasibility	Risks / required clarification	A warm CDN does not remove the D_root/BW_client transfer term; only locally cached tile bytes avoid that download. The derivation includes T_handshake, but the 500 ms total includes only metadata and rendering—clarify connection reuse. Confirm caching headers and whether refreshed signed URLs change the browser cache key. Define whether retained in-memory mesh objects are included in the test or whether the viewer must rebuild them from cached tile data.
	Intermediate / integrated test	Use a fixed tileset and local server with the intended cache headers to verify cache reuse and rendering measurements. Repeat against the actual API/CDN deployment, including signed-URL refresh, on the target client device. Update SP-4.0.5 and its tracing entry when the browser-cache and CDN-cache conditions are clarified.

Test ID: VT-4.0.6
Date last modified: Sept 29, 2026

Section	Field	Description
Test definition	Objective	Verify that the mesh-history API returns the correct metadata list for a room with a 95th-percentile response time ≤200 ms, without including full mesh data.
	Setup and tools	API Gateway, backend and representative PostgreSQL database; authenticated test accounts; rooms seeded with 20 and 50 historical scans; API load-testing tool; request/database logs; payload inspection and query-plan tools. Use the backend resource configuration from SP-4.1.10 and run the load generator separately.
Procedure	Steps	1. Seed rooms with 20 and 50 known mesh versions and record the expected IDs, dates and preview URLs. 2. Confirm that the database schema contains the intended room/session lookup index and inspect the query plan. 3. Request each room’s history once and check returned records against the seeded data, following pagination if applicable. 4. For each dataset, send 100 timed history requests from an authenticated client. Prevent browser response caching from bypassing the backend query. 5. Repeat while the backend operates under the agreed SP-4.1.10 load conditions, recording history-request latency separately from other endpoints. 6. Calculate the 95th percentile for each dataset and load condition; record errors and timeouts separately. 7. Inspect response bodies to confirm they contain metadata and preview URLs, not embedded preview images or mesh/tile data.
Confirmation	Quantity / units / precision	API response time: ms, measured from client request start until the complete response is received, using timer resolution of 1 ms or finer. Report the 95th percentile separately for each scenario. Returned records and failed requests: exact counts. Payload size: bytes/KB. Record network conditions, request rate and concurrent-user count.
	Pass/fail criteria	The 95th-percentile response time is ≤200 ms for each agreed dataset/load condition. Returned history matches the seeded records and contains metadata plus preview URLs only. Errors, timeouts, missing records and incorrect responses cannot count as successful results.
Feasibility	Risks / required clarification	Define the history endpoint’s share of the SP-4.1.10 workload so the total load remains consistent. Clarify pagination and whether the threshold applies to one page or the complete history list. API response timing excludes thumbnail downloads and UI rendering; measure these separately if user-visible list completion is also required. A small fixture may hide missing-index problems, so use representative total database size when checking scale.
	Intermediate / integrated test	Use seeded scan metadata before robot-generated history exists. Verify response correctness and query behavior locally, then repeat on the intended backend/database deployment with representative network and concurrent load.

Test ID: VT-4.3.1
Date last modified: Sept 29, 2026

Section	Field	Description
Test definition	Objective	Verify that guests can view and navigate public meshes and their scan histories, while all restricted actions and private content remain inaccessible through server-side enforcement.
	Setup and tools	App, API Gateway/backend, mesh storage/CDN, one public mesh and one private mesh with known scan histories, an authorized admin account, a clean browser session without authentication, API request tool and server logs. Seed identifiable test account fields to check for information leakage.
Procedure	Steps	1. Use an authorized admin to configure one mesh as public and another as private. Record their IDs and expected histories. 2. In an unauthenticated browser session, open the public mesh, navigate it and retrieve its history. Confirm no signup or email verification is required. 3. Apply the relevant viewing tests from VT-4.0.4, VT-4.0.5 and VT-4.0.6 to the guest path. 4. Directly request the private mesh, its history, tileset and protected tile/download URLs. Confirm denial without relying on hidden UI controls. 5. As a guest, directly attempt future-session booking, immediate session joining/control acquisition and robot commands. 6. Attempt annotation creation, editing and deletion, account-data access, account modification and changing mesh visibility. 7. Inspect public metadata, history and error responses for account IDs, emails and other personal information. 8. Check server logs and stored records to confirm rejected actions produced no changes, reservations or robot commands.
Confirmation	Quantity / units / precision	Permitted action categories: exactly 2—public mesh viewing/navigation and public history viewing. Unexpectedly permitted restricted actions, unauthorized state changes and exposed account-data fields: exact counts. Viewing latency uses the units and measurement methods of the referenced tests.
	Pass/fail criteria	Both permitted action categories work without authentication. Every tested restricted action is denied server-side, with zero private-content disclosures and zero unauthorized state changes. Public responses contain no account identifiers, emails or other PII. Guest viewing satisfies the applicable criteria from SP-4.0.4–SP-4.0.6 once their outstanding thresholds are resolved.
Feasibility	Risks / required clarification	Confirm the visibility flag exists and applies consistently to the mesh and its history. Define whether all historical versions inherit that visibility. Agree an allowlist of fields suitable for public responses. Confirm storage/CDN access cannot bypass backend authorization. Define what happens to cached content and previously issued URLs when a mesh changes from public to private. Clarify that account-management denial concerns protected account actions and does not unintentionally prohibit visitors from signing up or signing in.
	Intermediate / integrated test	Test the permission rules using seeded meshes, metadata and a mock robot before hardware integration. Repeat through the deployed App, API and actual storage/CDN path to verify that direct asset access and caching do not bypass the restrictions.

Test ID: VT-4.3.2
Date last modified: Sept 29, 2026

Section	Field	Description
Test definition	Objective	Verify that guest requests are limited to the agreed allowance, approximately 10 requests per 10 s, that excess requests are rejected before reaching the mesh-serving path, and that changing anonymous tokens cannot bypass the IP-based restriction.
	Setup and tools	API Gateway with guest rate limiting enabled, public mesh/history endpoints, request-generation tool, anonymous session tokens, gateway/downstream logs and a controllable clock for boundary tests. Use separate load sources with verified distinct IP addresses, plus two guest sessions sharing one IP.
Procedure	Steps	1. Record the exact request allowance, window algorithm, counted endpoints and how the IP/token combination is enforced. Confirm the gateway identifies each test source correctly. 2. Browse a public mesh and its history normally for 60 s, approximately one navigation request every 3 s. Record background asset requests separately and check for rejection. 3. Reset limiter state. From one IP/token, send 50 counted requests within one controlled 10 s window. Record response codes and correlate rejected request IDs with downstream logs. 4. Test the final allowed request and the first over-limit request. Verify allowance recovery according to the configured window algorithm. 5. After exhausting the allowance, discard or replace the anonymous token from the same IP and send more requests; check that the IP restriction remains effective. 6. Run two tokens behind the same IP at normal browsing pace for 60 s and record any shared-IP throttling. 7. During the flood, run normal browsing from distinct IPs. Compare their rejection counts and response times with the baseline. 8. Confirm authenticated requests are governed by their own policies rather than the guest allowance.
Confirmation	Quantity / units / precision	Allowed, rejected and forwarded requests: exact counts. Request rate: requests/s. Window duration: s, with the card stating ±1 s; use finer timestamp resolution for boundary checks. Rejection rate = rejected requests ÷ requests sent × 100%. Other-source response times: ms, including the 95th percentile. Record IP/token combinations and token issuance events without exposing token secrets.
	Pass/fail criteria	Zero legitimate counted requests rejected in the single-guest normal-browsing test. Every request exceeding the configured allowance returns 429 and does not reach the mesh-serving path. For a fixed window configured to allow exactly 10 requests, the controlled 50-request test permits 10 and rejects 40. Token replacement does not reset the IP-based allowance. Different-IP guests receive no flood-induced rate-limit rejections and meet the applicable response-time criteria. Document shared-IP throttling against the stated limitation.
Feasibility	Risks / required clarification	Finalize the exact integer allowance; “approximately 10 ±2 requests” is insufficient for a boundary test. Specify fixed-window, sliding-window or token-bucket behavior, since expected flood counts differ. Clarify whether an aggregate IP limit exists alongside token-level tracking: a counter keyed only by IP+token can be bypassed by obtaining new tokens. Define whether tile fetches, prefetching and polling count toward the limit. Confirm trusted proxy handling for client IPs and define the numerical criterion for other sessions being “unaffected.”
	Intermediate / integrated test	Use a controlled clock and mock downstream service to verify counting, reset boundaries, token rotation and zero forwarding of rejected requests. Repeat behind the intended proxy/CDN using actual distinct-IP and shared-IP clients to confirm source identification and realistic browsing behavior. Update the specification and tracing entry when the enforcement key, counted requests or limits are finalized.

Test ID: VT-4.5.1
Date last modified: Sept 29, 2026

Section	Field	Description
Test definition	Objective	Verify that a complete 30-minute autonomous inspection recording is saved using the OAK-D’s onboard H.264 encoder, meets the storage target and follows the 90-day retention policy.
	Setup and tools	OAK-D Pro W, robot computer, recording software and intended storage. Configure H.264 at 1280 × 720 pixels, 30 fps and approximately 2.5 Mbps. Use a video inspection tool such as ffprobe, a video player, encoder configuration logs, CPU monitoring and a controllable clock for retention tests.
Procedure	Steps	1. Record the camera configuration and confirm that the recording pipeline uses the onboard hardware encoder. 2. Run a 30-minute mock inspection containing movement and stationary periods. Log recording start and stop times. 3. Save the recording and measure its size in bytes. 4. Inspect codec, resolution, frame rate, duration and frame timestamps. Decode the entire file and check for errors or missing intervals. 5. Play and seek through the beginning, middle and end of the recording. 6. Record robot-computer CPU utilization during recording as supporting evidence. 7. Using test records and a controlled clock, check availability immediately before the 90-day expiry and run the retention process at and after expiry.
Confirmation	Quantity / units / precision	Duration: 1,800 seconds; inspect timestamps at frame-level resolution, approximately 33.3 ms at 30 fps. Video size: bytes, converted using 1 MB = 1,000,000 bytes. Target size: 563 MB ±10%, equivalent to 506.7–619.3 MB. Decode errors and missing intervals: integer counts. CPU utilization: percentage, sampled once per second. Retention: 90 days; record expiry and deletion timestamps.
	Pass/fail criteria	The file uses H.264 at 720p30, covers the full inspection and decodes with zero errors and zero missing recording intervals. Its size is within 506.7–619.3 MB. Pipeline configuration and runtime evidence confirm onboard encoding. The recording remains available for the required retention period and expires according to the defined 90-day policy.
Feasibility	Risks / required clarification	Low CPU utilization alone does not prove hardware encoding; inspect the actual encoder pipeline. Variable bitrate and container overhead can affect file size. Define the retention start event and permitted cleanup delay: “90 days, exact” does not specify how a scheduled deletion process must behave at the boundary. No numerical CPU limit is specified.
	Intermediate / integrated test	Before robot integration, record a moving scene using the actual OAK-D and test file integrity and size. Test retention with a controlled clock. Repeat with the complete inspection pipeline and intended storage to verify operation under concurrent workloads.

Test ID: VT-4.5.2
Date last modified: Sept 29, 2026

Section	Field	Description
Test definition	Objective	Verify the elapsed time between inspection completion and the saved video becoming playable in the app at an effective uplink of 20 Mbps.
	Setup and tools	Recording and upload software, intended object storage, app playback and a representative 30-minute recording from VT-4.5.1. Use a network shaper, transfer monitoring and timestamped logs. Use a common clock or measure all elapsed times from one test controller.
Procedure	Steps	1. Configure and measure an effective upload rate of 20 Mbps. Record competing traffic and the video file size. 2. Complete a 30-minute mock inspection and record the session-end timestamp. 3. Record when finalization finishes, upload begins and upload completes. 4. Open the recording in the app and record when playback first succeeds. Check that the complete recording is accessible, including its end. 5. Calculate finalization time, upload time and total time from session end to playback availability. 6. Repeat for three recordings and report every result. 7. Run a separate slower-uplink test to check local buffering and whether another inspection can start while upload is pending.
Confirmation	Quantity / units / precision	Effective uplink: Mbps, reported to 0.1 Mbps. File size: MB using decimal units. Finalization, upload and total availability time: seconds, reported to 0.1 s. Derived upload time for 563 MB at 20 Mbps: approximately 225 seconds. With 10–30 seconds of finalization: approximately 235–255 seconds, before additional app-availability delays. Stated overall target: approximately 4–5 minutes, with ±20% listed in the specification.
	Pass/fail criteria	Every measured run must make the complete recording playable within the agreed maximum time at 20 Mbps. The exact maximum needs clarification: the specification gives an approximate range and ±20%, rather than one unambiguous upper limit. If 5 minutes is selected as the maximum, every run must complete within 300 seconds. Faster completion is acceptable.
Feasibility	Risks / required clarification	Clarify whether ±20% changes the permitted maximum or only describes estimation uncertainty. Also reconcile “job complete” with “playable in the app,” since app processing may add delay after upload. A 20 Mbps link limit does not necessarily provide 20 Mbps of effective file transfer. Concurrent reconstruction uploads may reduce available bandwidth.
	Intermediate / integrated test	Initially upload a representative file through a shaped connection to measure transfer and app-availability time. This does not verify finalization. Repeat using the actual recording pipeline, storage and app to measure the complete session-end-to-playback interval.

Test ID: VT-4.5.3
Date last modified: Sept 29, 2026

Section	Field	Description
Test definition	Objective	Verify that reconstruction frames are selected by distance travelled and provide at least 70% overlap under the stated working conditions.
	Setup and tools	OAK-D, capture software, odometry logs and reconstruction software. Use a measured test area with a textured wall approximately 2 m from the camera, distance markers and an independent position reference. Log timestamps, positions and identifiers for every saved depth, RGB and pose frame set.
Procedure	Steps	1. Configure the stated 95° horizontal field of view and nominal distance threshold of approximately 1.31 m. Record the actual settings. 2. Move parallel to the measured wall at 0.5 m/s while maintaining approximately 2 m working distance. 3. Measure travel between saved frames and check that each saved set contains matching depth, RGB and pose data. 4. Measure consecutive-frame overlap using corresponding wall features or registered depth data. Record the overlap method. 5. Repeat at a lower speed and with pauses. Confirm that selection follows travelled distance rather than a fixed timer. 6. Reconstruct the observed surfaces and record uncovered regions and alignment errors against the reference geometry. 7. Repeat with the threshold doubled to approximately 2.62 m and compare overlap and reconstruction quality. 8. Repeat closer to the wall and during turns to identify conditions where the fixed-distance rule fails to preserve overlap.
Confirmation	Quantity / units / precision	Travel and working distance: metres; use a reference capable of approximately 0.01 m resolution and report its uncertainty. Speed: m/s. Frame interval: seconds, reported to 0.01 s. Nominal interval at 0.5 m/s: approximately 2.62 s, or 0.38 frames/s. Overlap: percentage, reported to one percentage point. Reconstruction coverage: percentage of the reference surface. Alignment error: mm.
	Pass/fail criteria	Frame selection follows the configured distance threshold, each saved set is complete and consecutive frames maintain at least 70% measured overlap under the stated conditions. No observed reconstruction gaps or misalignment should occur in the baseline test; numerical limits for coverage and alignment error must be defined for an objective quality decision. The doubled-distance run is a comparison: visible defects are not guaranteed, so their absence is not itself a failure.
Feasibility	Risks / required clarification	The source needs correction: with a fixed distance threshold, slower motion produces fewer frames per second, while spatial spacing stays the same. The footprint calculation assumes suitable translation and scene geometry; turns, occlusions and closer surfaces can invalidate it. Define overlap measurement and trigger tolerance. The stated ±20% distance and ±0.05 overlap precision must not automatically permit overlap below 70%.
	Intermediate / integrated test	Replay synthetic odometry containing constant speed, slow movement and pauses to check trigger behaviour. Then test the camera on a measured route. Final verification requires actual robot motion, synchronized frame sets and reconstruction against known geometry.

Test ID: VT-4.5.4
Date last modified: Sept 29, 2026

Section	Field	Description
Test definition	Objective	Measure reconstruction-frame count and storage for a 30-minute inspection, verify complete frame sets and check the 7-day intermediate-data retention policy.
	Setup and tools	Capture software using SP-4.5.3’s distance-triggered policy, OAK-D, odometry logs and intended reconstruction storage. Use a frame manifest, file-size measurement script, data-integrity checks and a controlled clock for retention testing. Keep continuous-video storage separate from reconstruction-data measurements.
Procedure	Steps	1. Record the configured sampling distance, frame formats and compression settings. 2. Run a 30-minute inspection with sustained 0.5 m/s motion where practical. Record total path length and saved frame identifiers. 3. Count complete RGB, depth and pose sets. Check for missing, duplicate or unreadable components. 4. Measure RGB, depth and pose bytes separately, then calculate total reconstruction storage and average bytes per frame set. 5. Compare frame count with travelled distance divided by the configured sampling distance, accounting for the initial-frame rule. 6. Repeat for a 30-minute route containing slower motion and pauses. Compare frame count and storage with the first run. 7. Generate the final mesh, advance the test clock around the 7-day boundary and exercise the intermediate-data cleanup process. Verify that cleanup preserves the finished mesh and tileset.
Confirmation	Quantity / units / precision	Duration: seconds. Path length: metres. Frame sets: exact integer count. Storage: bytes, converted using decimal MB and GB. Estimated frame-set size: 2.8 MB, plus pose and other overhead. Source estimate: 684 sets × 2.8 MB = 1,915.2 MB. For comparison only, ±15% around that estimate is 1,627.9–2,202.5 MB. Retention: 7 days; record expiry and deletion timestamps.
	Pass/fail criteria	Every selected frame has a complete, readable RGB+depth+pose set, and the saved count agrees with the distance-triggered policy within the defined trigger tolerance. Retention follows the clarified 7-day policy without deleting final outputs. The stated minimum of 684 frames and minimum of 1.9 GB cannot be used as valid acceptance criteria until corrected: slower or paused inspections can legitimately produce fewer frames and consume less storage. The ±15% size comparison applies only to a run with the corresponding frame count and encoding assumptions.
Feasibility	Risks / required clarification	Under a fixed 1.31 m threshold, frame count follows path length, not inspection duration alone. Continuous top-speed motion gives approximately 687 distance intervals over 30 minutes; the source’s 684 comes from rounding the sampling rate. Clarify initial-frame handling and replace the “worst-case floor” with an appropriate reference estimate or capacity limit. Real compression, pose files and metadata affect storage. Define when retention begins, permitted deletion delay and handling of unfinished reconstruction jobs at expiry.
	Intermediate / integrated test	Use odometry replay and representative frame files to verify counting and storage calculations. Exercise cleanup using dated test objects. Repeat with the actual camera and reconstruction workflow to measure real frame sizes, storage overhead and safe retention behaviour.

Test ID: VT-4.5.5
Date last modified: Sept 29, 2026

Section	Field	Description
Test definition	Objective	Measure the processing time and compute resources required for TSDF fusion and mesh extraction, and determine the smallest tested hardware configuration that meets the agreed performance and output-quality requirements.
	Setup and tools	Implemented reconstruction pipeline, a representative inspection dataset containing synchronized RGB, depth and pose data from SP-4.5.4, and candidate CPU-only and GPU-enabled machines supported by the implementation. Use timestamped processing logs, CPU/RAM monitoring, GPU/VRAM monitoring where applicable, and a mesh viewer. Record hardware, software versions, frame count, image dimensions, voxel size and reconstruction settings.
Procedure	Steps	1. Select a representative inspection dataset and verify that all required frame sets are readable and complete. Record its actual frame count rather than assuming 684 is a guaranteed minimum. 2. Define the measurement interval as the start of TSDF fusion through completion of mesh extraction. Measure input loading and output saving separately. 3. Fix voxel size, reconstruction bounds and other settings so hardware comparisons use the same workload and output quality. 4. Run the pipeline on the first candidate machine. Record fusion time, mesh-extraction time, total processing time and peak CPU/RAM/VRAM usage. 5. Open the resulting mesh and check that it contains the expected surfaces, with no processing errors or missing output. 6. Repeat three times per hardware configuration, recording every result and whether input data was cached. 7. Repeat on another supported configuration, including CPU-only processing where available. Compare processing time and required resources. 8. Test a larger representative dataset and a finer voxel size separately to identify resource growth and out-of-memory failures. Use the measurements to propose numerical provisioning limits and update the specification and tracing table.
Confirmation	Quantity / units / precision	Processing time: seconds, reported to 0.1 s, separately for fusion, mesh extraction and their combined interval. CPU consumption: CPU-seconds and average cores used; record provisioned vCPU count and processor model. Peak RAM and VRAM: MB, using 1 MB = 1,000,000 bytes. GPU utilization: percentage, with GPU model recorded. Dataset size: exact frame count. Voxel size: mm. Sample resource metrics at least once per second and retain available peak-memory counters; report sampling limitations.
	Pass/fail criteria	Every run completes without crashes, out-of-memory errors or unreadable output, and its mesh meets the agreed reconstruction-quality criteria. Every run must finish within T_process and remain within the agreed CPU, RAM and GPU/VRAM budgets. Numerical limits are currently TBD, so these tests initially establish measured requirements; they cannot yet demonstrate compliance with a defined capacity target. “Substantially below” the old budget is not a measurable acceptance threshold.
Feasibility	Risks / required clarification	Define the maximum processing time, resource budgets and measurable mesh-quality criteria. Confirm whether texturing, input loading and output saving belong inside the processing deadline. Voxel size, scene extent and implementation affect resource use, so frame count alone is insufficient for sizing. The old 8 vCPU / 32 GB RAM / 8 GB VRAM figures describe provisioning, not measured consumption; comparison against them does not establish an actual speedup or cost saving. CPU-only support also depends on the selected implementation.
	Intermediate / integrated test	Start with a small recorded dataset to verify fusion, mesh extraction and monitoring. Then benchmark a complete inspection dataset on candidate hardware before deployment. Repeat on the intended processing node with the actual job runner and representative concurrent workloads to confirm the selected capacity.