ZYEL LAB / TERRITORY EXPLORER / RECORDING PLAN

Show the question.
Then prove the answer.

By Chason Arthur · Draft script and speaker notes for a future computer tutorial

This plan connects the working demo to the eight coding steps. Each chapter names a screen action, an observable result and the boundary of the claim. It is a prepared recording plan; no video or transcript of an operated session has been produced.

Open the working demo Read the coding tutorial Read the draft script

Recording publication state

A future reviewed video and its published transcript can be attached here. Neither exists yet. The readable draft below is a script, not a transcript of a recording. This page loads no media, uploads, analytics, external players or account connections.

Read available draft script and notes

Attachment point: recording-media. Keep the current unavailable state until an authorized, reviewed media asset and text transcript actually exist; do not substitute a placeholder player or invented URL.

Prepare a clean, honest take

Use this isolated checkout and the bounded static preview. Keep private apps, notifications, credentials and customer records outside the captured desktop. This page does not request or start screen capture.
Use the demo's recording preparation controls: choose a known synthetic scene, prepare and confirm it. This preserves the first route/table/selection checkpoint in memory, uses a temporary table and leaves saved settings untouched. Restore returns the original route/table state; reload discards the checkpoint and resumes saved normal preferences. The ordinary reset controls operate only on the temporary scene while it is active.
Open the provenance panel. State that the 72 locations and all business values are synthetic. Approximate city centers are not customer addresses.
Decide whether this take can demonstrate the real ArcGIS SDK. Network access and supported WebGL are prerequisites. If it cannot render, keep the accessible record walkthrough and say the map is unavailable; do not narrate a successful live map.
Use the draft narration as a guide. Confirm the visible evidence before making each claim. Retake a chapter rather than hiding a failed result.

Opening walkthrough. In the first screen, establish the synthetic-data label and all-data counts. Ask which northern locations share the service load, apply North, and show the linked counts and records. Then introduce the code that makes those views agree. The optional map and the deterministic service fixture are two separate proof steps.

Frame the result before explaining the code

Prerequisites. Use the working demo in a local preview and confirm a known synthetic scene. Open its recording tools and choose Enter presentation mode. The optional layout uses the same live panels and values; it never resets data, loads ArcGIS or changes saved preferences. A loaded public map may redraw raster tiles when its visible viewport changes.

Opening cut — SAY: “Here are 72 fictional service locations, 1,782 synthetic tickets and six regions. We can ask a question and check its records.” SHOW: prepare Entire network, choose the Overview presentation view and Frame view. EXPECTED: the synthetic label, all three aggregate counts and readable geographic comparison appear together. At 1920 × 1080, the page leaves a native right-hand gutter for later annotations.
Focused cut — SAY: “North gives us 12 locations and 335 tickets. This is a subset, not a claim of operational improvement.” SHOW: apply North in the visible geographic controls, then Frame view. EXPECTED: 12 / 335 / one region, with the North comparison and all-region context agreeing. Capture the opening and focused frames separately.
Choose Map, Records or Service fixture when that view is the subject. Each view preserves the current query and selection. Panel deep links choose the corresponding presentation view; the original tutorial step links remain unchanged. Select Frame view after a take scrolls away from its context.
Use the visible Exit presentation mode button or Escape. Both return through the same toggle and retain the app session. Restoring the pre-recording session is a separate, explicit action; it is not the same as exiting the layout.

Alternative and tradeoff. Ordinary browser scrolling works without presentation mode, and the responsive page remains the better reading layout on a phone. The optional view makes desktop counts and context fit one recording frame, with no duplicate screenshot-only data. Pitfalls: do not narrate planned counts over an unverified filter, mistake view switching for a reset, hide a fallback as map success, or edit pixels to create annotation space. Verification before proceeding: read the actual counts, confirm Exit is visible and ensure no secret or private app enters the capture.

Draft narration and storyboard

These are planned words and screen actions for a future take. Read the coding step for its implementation, alternatives, pitfalls and test. A chapter is ready to move on only when its stated result is visible. No preset duration or production outcome is implied.

CHAPTER 01 / SETUP

Start with the contract

Link to this chapter Coding step 1 Preview commands Screen: provenance

Objective and prerequisites: Show a bounded local environment and the synthetic source contract. Use an isolated repository checkout, the existing Node.js runtime and a local browser. Reuse an already running preview instead of starting the same port twice.
Screen action: Begin in the reviewed committed Lab checkout/reference. Run the tutorial's file preflight for the demo and bounded preview before creating an isolated worktree from that reference; the draft may precede default-branch merge. From that isolated repository root, start node lab/tools/serve.mjs . with an unused LAB_PORT, then open the demo. Show the synthetic label, the provenance panel and the data-contract example. Do not show a private environment file or production admin tab.
Observable result before proceeding: The public demo loads over loopback HTTP. An all-data view has 72 fictional locations, 1,782 generated tickets and six regions. Source and evidence links are readable; backend/private/test paths are not exposed by this preview.
Draft narration: We are using a synthetic service network. The locations and business values let us verify the UI without exposing customer data. Each view will use the same stable ID and WGS84 coordinate contract.
Speaker notes: Describe numeric ArcGIS object IDs separately from business IDs. “Synthetic” applies to dealers and metrics; the optional public Esri basemap is real geographic context. Credit its native attribution.
Alternative, tradeoff and choice: A hosted FeatureLayer can separate data updates from UI releases, but adds access, provenance and operating duties. The bundled fixture makes this take reproducible without provisioning services. Show the fixture boundary instead of implying a live database.
Retake or recovery cue: If counts differ, do not read the planned numbers as observed. Inspect the active region/status/spatial and table filters, or reopen in a temporary profile. If the preview port is occupied, reuse it or select another unused port.

CHAPTER 02 / PREFERENCES

Explain what the browser keeps

Link to this chapter Coding step 2 Store example Screen: coverage controls

Objective and prerequisites: Distinguish device-local configuration from data storage or account synchronization. Use synthetic filters and the versioned store example.
Screen action: Show the browser-local preference notice. In an isolated temporary profile, first show normal preference persistence. Then prepare a confirmed synthetic recording scene and show its temporary-state notice. Edit a filter, prepare another scene, and restore the original checkpoint. Point out that the table has its own preference scope and that a reload intentionally discards the in-memory checkpoint.
Observable result before proceeding: Normal saved route filters restore on the same browser, while the data remains bundled. Temporary recording filters never become saved preferences; Restore returns the original checkpoint, and reload resumes the saved normal state. If storage is unavailable, the notice says the settings last for this page only; do not narrate persistence in that case.
Draft narration: The browser remembers configuration, not private service records. We validate the shape, version the namespace and keep a usable memory fallback. This is local to this browser, not an account-sync feature.
Speaker notes: Show the allowlisted fields in the store snippet. Mention the intentional 30-day preference lifetime. Avoid opening all browser storage during capture; unrelated values are outside this demo's proof.
Alternative, tradeoff and choice: Session storage is shorter-lived; a server preference service could synchronize users but requires identity and retention design. Device-local preferences fit this static demonstration. The memory-only scene protects saved configuration even if a reload interrupts a take. A checkpoint persisted as a recording backup would create unnecessary storage and cleanup obligations, so this one is deliberately lost on reload.
Retake or recovery cue: If reload restores an unexpected filter, inspect the named route and table controls rather than clearing every origin's storage. Keep a failed-storage take honest and show the in-memory fallback.

CHAPTER 03 / GEOGRAPHIC QUESTION

Ask a smaller question and keep the context

Link to this chapter Coding step 3 Spatial predicate Screen: controls Screen: comparison

Objective and prerequisites: Demonstrate a meaningful synthetic before/after. Start with all regions, all statuses and the entire dataset, with no table presentation search hiding records.
Screen action: Record the all-data counts, then choose North and Apply coverage query. Show the comparison row, its numeric equivalent and the linked records. Return to all regions, choose the 150 km radius at latitude 33.749 / longitude -84.388, and explain straight-line distance.
Observable result before proceeding: The North query shows 12 locations, 335 synthetic tickets and one region. The all-data context remains 72 locations / 1,782 tickets / six regions. The local Atlanta-radius predicate returns 33 locations and 828 tickets across four regions; if ArcGIS is loaded, report its actual displayed result because its geometry engine may differ at the boundary.
Draft narration: We narrowed the question from the whole network to the North region. These counts describe the selected subset; they do not claim that tickets were resolved or operations became faster. The comparison keeps the rest of the network visible as context.
Speaker notes: Read the actual visible count. Keep a clear distinction between an attribute filter, a spherical radius and a driving-time area. A radius of 150 kilometers is not a travel-time promise.
Alternative, tradeoff and choice: A routing service answers a different coverage question and requires approved access and costs. Pure WGS84 predicates are testable offline; SDK queries are a separate implementation gate. Show both boundaries, with the engine label that actually ran.
Retake or recovery cue: An empty result is a valid state. Widen the radius or reset only the synthetic scene, then repeat the question. Do not call an empty service/network failure “zero business activity.”

Planned synthetic comparison, verified against fixture synthetic-se-1
Question	Locations	Tickets	Regions
Before: entire dataset	72	1,782	6
After: North region only	12	335	1

The difference is a query subset, not a measured business improvement or performance gain.

CHAPTER 04 / ACTUAL MAP

Prove the ArcGIS view instead of implying it

Link to this chapter Coding step 4 SDK component example Screen: actual map

Objective and prerequisites: Show actual SDK rendering and a linked selection. Use supported WebGL, the pinned ArcGIS SDK 5.1.27 and network access to its public CDN and the public Esri raster tiles. No key, paid routing or hosted feature service is introduced.
Screen action: Before this chapter, explicitly prepare the Entire network recording scene after the radius chapter. Choose Load ArcGIS map (or Show retained ArcGIS map). Wait for the map, tiles and dealer points to render; do not cut from a placeholder to a claim of success. Select a visible point, inspect its stable record ID, toggle one layer and restore it. Show the native basemap attribution.
Observable result before proceeding: Actual point symbols appear on the map and selecting one updates the same record details/table. If the SDK or WebGL is unavailable, the error notice and accessible record workflow are the result to show; omit a successful-map claim.
Draft narration: This view uses the real ArcGIS component, with our synthetic features in a client-side FeatureLayer. The public basemap supplies geographic context. The table and comparisons still work if the optional SDK cannot load.
Speaker notes: The pinned CDN is a network dependency, not a local fixture render. View initialization alone does not prove that features were drawn. Preserve attribution and record whether a real map was demonstrated in this take.
Alternative, tradeoff and choice: Bundling SDK packages gives build-time dependency control but adds a build pipeline. A reviewed WebMap centralizes style and item lifecycle. The explicit, pinned CDN load keeps this static route light until the viewer requests a map.
Retake or recovery cue: If the map is unavailable, keep the error disclosure and continue with records. Retry only when the network/browser issue is resolved. Do not narrate the deterministic pagination fixture as evidence that a hosted ArcGIS feature service worked.

CHAPTER 05 / ONE ID

Link selection, not contradictory copies

Link to this chapter Coding step 5 Table integration example Screen: records Screen: comparison

Objective and prerequisites: Show the same business ID across records and optional map, with an accessible numeric comparison. Begin with all data and a visible record.
Screen action: Select D001 from the record control and read its details. With a map available, select another point and check the matching ID/page. Apply a table-only City filter for Atlanta, then select D060 on the map; explain the hidden-record notice and use Reveal selected record only when you intend to clear that presentation search.
Observable result before proceeding: The selected ID remains consistent. An off-page record is revealed on its page; a search-hidden selection is disclosed without silently clearing the search. Explicit Reveal clears the actual individual/global presentation filters and shows the selected row. Geographic totals keep their separate meaning.
Draft narration: The query owns the geographic result. The table can search within that result without changing the regional totals. A map selection does not silently discard the viewer's search; we explain why a row is hidden and make revealing it an explicit action.
Speaker notes: Keyboard record buttons and the comparison data table provide a non-map alternative. Point out that DataTables owns its row DOM; another framework must not independently render those same rows. Explain the DataTables 3 group-versus-individual-column search distinction when showing the reveal code.
Alternative, tradeoff and choice: A shared application store helps a larger SPA but adds framework coordination. Separate per-view filters may be flexible while making counts inconsistent. Stable IDs and one geographic matching set keep this route's claims inspectable.
Retake or recovery cue: If an ID is hidden, keep the notice in frame. Use the explicit Reveal action or clear the relevant named control; do not pretend a row is absent from the data. Return to a known query before recording the next chapter. A scene reset pauses the map; use its explicit Show action again rather than implying it was automatically reloaded.

CHAPTER 06 / DETERMINISTIC SERVICE FIXTURE

Make truncation visible, then recover it

Link to this chapter Coding step 6 Bounded adapter example Screen: service fixture

Objective and prerequisites: Show the completeness boundary using the local service fixture. No hosted feature endpoint, token or external API is required for this chapter.
Screen action: Read the fixture label, then choose Run pagination fixture. Show the completed count and batch count. In a separate take, run and cancel to show that incomplete work is not accepted.
Observable result before proceeding: The completed fixture returns 72 of 72 features across ten batch responses while enforcing a 17-feature response limit. Timing is measured locally and includes simulated latency. Cancellation explicitly reports no incomplete result was accepted.
Draft narration: A successful response can still be truncated. This deterministic fixture gives us a repeatable failure path: enumerate IDs, retrieve bounded batches, split a truncated batch and verify completeness. It does not prove access to a live hosted feature service.
Speaker notes: Wait for the completion text before reading its counts. Do not recite a fixed millisecond value: record the value actually displayed and its simulated-latency label. Keep cancellation as a distinct outcome.
Alternative, tradeoff and choice: Stable offset pagination can be simpler but must handle edits between pages. ID enumeration makes the requested set explicit; large services may need server aggregation or snapshots instead. The fixture demonstrates the boundary without operating a new service.
Retake or recovery cue: For a clean result, wait until Run is enabled again. A cancellation is not a passed completion. For a future live adapter, verify approved origin, credentials, rate limits, timeouts and update semantics separately.

CHAPTER 07 / EVIDENCE

Read the method before reading the number

Link to this chapter Coding step 7 Verification commands Screen: readable comparison

Objective and prerequisites: Distinguish domain correctness, rendered behavior and a narrow local benchmark. Have the test commands and raw evidence links available in the coding step.
Screen action: Run the eight domain/service tests in the isolated checkout. Read the benchmark's method, timestamp, runtime and row counts before its p50/p95 values. Show the readable numeric comparison and one loading/error/empty case.
Observable result before proceeding: Tests report actual results. The benchmark is identified as a pure radius predicate with synthetic repeated coordinates, 30 warmups and 200 samples. It excludes rendering, SDK/network, hosted service, concurrency and production capacity.
Draft narration: A local timing is evidence for the operation we measured. It is not evidence of production throughput, high traffic or a hosted GIS service. We keep the harness, raw output and limitations together so another developer can repeat the check.
Speaker notes: The existing October 25 measurement is historical evidence, not the latency of this recording. The live metric identifies local/scene WGS84 filtering or ArcGIS flow. The latter includes initial local filtering/rendering and the awaited SDK client-layer query; do not narrate it as isolated SDK latency or a provider benchmark. A rounded local 0.00 ms is an actual finite measurement at this precision. If you rerun it, retain the new method and runtime with the new results. Do not choose only the fastest sample.
Alternative, tradeoff and choice: A browser trace includes rendering; real-user monitoring needs actual traffic, consent and data minimization. The pure benchmark isolates a small algorithm, while rendered checks verify a different claim. Avoid mixing these measures.
Retake or recovery cue: On a failed test, retain the result, fix the cause and rerun the affected check. Do not edit terminal output to create a pass or label a fixture as production-scale proof.

CHAPTER 08 / RELEASE BOUNDARY

End with what is proven and what is still a decision

Link to this chapter Coding step 8 Versioned data example Screen: limits and provenance

Objective and prerequisites: Close the tutorial with a bounded operating model and an honest release status. Know the reviewed source revision for the take; do not assume this local preview has been deployed.
Screen action: Show provenance/limits, explain the repository fixture update path and rollback plan, then return to this recording publication state. Identify which map and fixture checks actually ran in this take.
Observable result before proceeding: The viewer can distinguish prepared source, tests, independent review and authorized live deployment. No video or published transcript is claimed to exist. No hosted GIS service, production credentials or procurement compliance is implied.
Draft narration: The next release is a reviewed asset set on the existing host, with a known rollback. A future live data service needs an owner, an update contract, access and cost decisions. This prototype demonstrates implementation choices; it does not establish years of operating history or fulfillment of a broader solicitation.
Speaker notes: Use the exact release state that is true for the source in frame. No bids, job applications or production changes happen through this guide. Domain/table restoration and camera restoration are separate: the first leaves the optional map paused; the explicit Restore pre-recording map view action can request public tiles. Do not narrate full camera restoration before that action. A future recorded video needs its own reviewed transcript and authorization before attachment.
Alternative, tradeoff and choice: A live service can update data independently but adds availability/access/cost duties. A reviewed static snapshot is easier to reproduce and roll back, with releases required for updates. This Lab deliberately demonstrates the latter boundary.
Retake or recovery cue: If the operating model or publication state changed, update the script before recording a claim. Verify a deployed URL only after an authorized release; a local screenshot is not a live readback.

Checklist after the take

Read the actual screen counts against the spoken claims, including empty/error/cancel states.
Keep the SDK render proof and deterministic service fixture proof labeled separately.
Review the recording for private desktop content before any publication. This page does not upload or share media.
Prepare a transcript from the actual final recording, then independently review its code, links, captions and limits before attaching it.

Continue with release and rollback guidance · Return to recording publication state

Show the question.Then prove the answer.