BackcountryOS
Corrected review build — not for public release
This build implements the MVP Correction Specification (P0-1 through P1-3). It is a preliminary planning and screening tool — not an engineering certification, property survey, or substitute for professional due diligence.
- What changed: parcel-ID lookup is disabled; a nearby road no longer produces an access verdict; unsupported engineering values are removed; utilities report verification status, not availability; structures are provisional comparisons, never “Recommended”; the bear rule is a road-independent safety precaution.
- Round 2 (second review): coordinate parsing is now strict — exactly two plain decimal numbers, extra or malformed values rejected; road distances use line-segment geometry, not mapped vertices; climate averages are shown only after date/value/coverage validation (≥90% of 1,095 days); structure claims are qualified as site- and model-dependent; the test suite is expanded to 23 tests including full report-generation and workflow tests; live-service results are documented in the test panel. Passing tests verify the checked rules only — they do not prove the absence of defects.
- Final Round-2 refinements (third review) — MVP feature set frozen after these: (1) climate validation now also checks that every date is unique and the daily sequence is continuous, with no duplicates or gaps — endpoint dates and counts alone no longer pass; (2) every report explicitly displays the OpenStreetMap radius that actually succeeded (18, 9, 4, or 2 km), in the banner, the access facts, and a gap notice when a fallback radius was used; (3) the three browser-side live checks now run independently — each starts on its own, uses fixed coordinates where it previously depended on geocoding, and reports its own PASS / BLOCKED result even if another service fails. No new capabilities were added, and the test count stays at 23 — existing tests were strengthened instead.
- Round 4 (owner field review of the Tract E assessment — feature freeze lifted for this round only): (A) legal access research states plainly that legal access remains UNVERIFIED, fetches parcel attributes from the Mat-Su Borough cadastral service where it resolves (labeled “Observed from source”), links the official record sources as “Not searched by this tool,” and names title search as a title-company step this tool does not perform; (B) design criteria presents the nearest covered jurisdiction's published ground snow load (IBC Table 1608.2) and ASHRAE 99.6% heating design temperature where a published value exists in the curated dataset — never calculated from climate averages, never estimated, omitted when unsourced — under the exact label “Reference only — nearest jurisdiction's published criteria. Verify with the authority having jurisdiction before design use,” plus a clearly-labeled professional-guidance line (not a code value) for remote Interior / Yentna-corridor sites; (C) permitting lists the typical authorities with official links as starting points, not a determination; (E) verification tasks are reworked into app actions — items the app can confirm are done and labeled with their source, and Section C names the nearest utility providers with contact information under “Service availability unverified” (nearest provider is never presented as serving the parcel). The test suite grows to 28 tests. The freeze re-applies after this round.
- Round 5 (presentation restructure — owner review: “That info should be made available in its corresponding areas”): No new features and no change to data, datasets, fetch logic, or honesty rules. The Round 4 content now appears where it belongs: legal access research at the “Legal access & easements” item in Section A; published design values at the “Structural snow load” and “Heating design temperature” items in Section B (guidance line with the heating item); permitting authorities as next-step entries in Section E. There are no standalone extra sections beyond A–E. The test suite grows to 29 tests, including a check that a rendered report contains no standalone-section pointer text for the removed sections.
- Round 6A — Stage 1 corrections (independent audit, Oct 29, 2026; Stage 1 only — the map, export, and customer-experience restructure come in the next round): (1) ambiguous address matches are unselected radio choices with the run button disabled until a deliberate selection, the chosen location stated prominently before the run, and the demo shortcut opening the same unselected state; (2) parcel confirmation copy states the actual coverage for the resolved jurisdiction (Mat-Su lookup available and attempted, GIS polygon not a survey and establishing no boundary, ownership, title, or legal access — or, where uncovered, that no parcel service is integrated); (3) road distance uses motorable mapped classes only, with trails/paths reported separately as non-motorized context and never labeled roads; (4) the summary pill and detail share one status value — a failed map source reads “Unknown — source unavailable” in both; (5) research timestamps render the viewer's time zone; (6) a third-party data-provider disclosure sits next to the location form before submission, alongside the standing “Nothing is saved” language; (7) “Re-run research” is renamed “Run a new assessment” and the visit history is labeled as separate runs with their own timestamps. Suite: 33 tests.
- Round 6B — Stage 2 + consumer experience (owner product direction, Oct 29, 2026 — “sophisticated technology underneath, extraordinary simplicity on the surface”): the default view is now the customer app only — brand, a short plain limitation note, and the location form — with everything reviewer-facing (this correction history, the change log, the automated test panel, the mocked samples, live-check documentation, and the feedback/copy tools) behind a separate “Reviewer tools” toggle a customer never needs to open. Screen 1 follows the owner's spec (“Your land. Your vision. Your plan.” / “Assess My Property” / “Free preliminary assessment. No technical experience required.”). After a run, the customer first sees a plain-language Property Overview — four cards (Property, Access, Climate, Utilities) with honest everyday statuses (Data found / Needs verification / We couldn't check — never “verified” from data-return alone), a “What should you know?” synthesis, a property map, and a prominent “Start Planning Your Project” button; the full technical report (Sections A–E) sits behind “See details” and source attributions behind “View sources.” Findings are translated into everyday language with miles alongside kilometers (a 6.17 km trail reads “about 3.8 miles away”; a county area reads “approximately 20 acres — not a surveyed measurement”). The map is a schematic drawn from the fetched data itself (assessed point, county parcel outline where the parcel service returned one, motorable roads solid and trails dashed drawn distinctly, water and airstrips where returned), permanently labeled “Not a survey. Does not verify access.”, and says plainly when it cannot be drawn. A “Download assessment” produces the full document — overview, all technical sections, sources, retrieval dates with time zones, evidence labels, limitations, the map, and the user's optional property note — and reminds the user nothing is stored. Every assessment is structured internally as a property profile (original location, retrieved evidence, source dates, the one user-confirmed condition, unknowns, user-supplied note) that the download contains and the planning step consumes; no accounts or cloud storage are implied anywhere. “Start Planning Your Project” opens structure selection (the existing four types) with the assessment context restated in plain language and every unknown carried as a “Still to confirm” item — no budgeting, scheduling, pricing, or payment in this round. Suite: 40 tests.
- Round 6C — repair note (Oct 29, 2026): Panel before: 38 / 40. Panel after: 40 / 40. No test was changed. Root cause, found by re-running the suite in a browser and checking each failing assertion against the DOM rows (in plain-text extraction each row's PASS/FAIL badge appears before its test name, which misattributes the failures): the property map itself was NOT failing — test 37's assertions (assessed point, parcel outline, solid road vs. dashed trail, the permanent “Not a survey. Does not verify access.” label, and both honest degradations) were verified passing sub-check by sub-check, and the map code is unchanged. The two real failures were: (1) test 38 — the downloadable document phrased its retrieval line “Source data retrieved …” and never carried the “Sources retrieved <date>” line (the report banner's own phrasing); the download now uses “Sources retrieved” in both places it states the retrieval date. (2) Test 39 — the planning step's plain-language utilities sentence (“We couldn't confirm electricity, water, or sewer service…”) was entity-escaped by the shared HTML escaper (' for the apostrophe), so the sentence as written was absent from the HTML even though it displayed correctly; the escaper no longer escapes apostrophes (every attribute this app builds is double-quoted, so a literal ' is safe, and & < > " are still escaped).
- Round 7 — Consumer Experience Refinement (Oct 29, 2026): planning handoff fixed (Step 1 label, Back + Download on the planning screen, Property summary restored, What-happens-next line); findings restructured into three labeled levels (Understand / Explore / Technical evidence, full detail retained); schematic map gained point/parcel distinction, north arrow, scale bar, “Schematic” label, and a fixed legend; the trail name/class conflict is disclosed with vehicle use UNCONFIRMED and the Section A heading is conditional; agency containing polygons render as large mapped areas, never as the customer's parcel or in the account slot; internal review terminology removed from customer screens and the download; borough terminology for Alaska boroughs; coordinate errors carry a format example; a blank note no longer confirms success; new assessments reset expansion state and tab switches clear stale input; card statuses separate finding from confirming and “What should you know?” is now a decision summary. Suite: 49 tests. The build freezes after this round.
- Demo — fixed-coordinate sample property, owner-approved: the start screen's demo entry is now labeled “Explore a Sample Remote Property — Alaska” and shows the exact coordinates it will assess, 61.938502, -151.834736 (the Mat-Su Borough-verified Tract E centroid, Friday Creek area), beside a plain disclaimer line (a demonstration using live public data — not a verified ownership or legal-access assessment). Activating it runs the assessment directly on those fixed coordinates with the normal live fetches — no geocoder lookup, no match selection, no confirmation gate for the demo. The old Yentna demo path (button, geocoder call, customer-facing references) is removed; the ordinary address workflow keeps its deliberate selection gate unchanged. Suite: 56 tests (new tests 53–56; test 30 adjusted only in its description of the old demo mechanism). The build re-freezes after this change.
- Round 8 — Owner phone-run findings (Oct 29, 2026): (1) the app header is restyled as a website-style header bar — same lockup (30px mark, Cormorant Garamond 600, #162A1E), presented as a proper header bar like the site's, with the cream tile given a border so it reads as the same tile on the app background; the download's cover uses the same lockup, larger. (2) The downloaded assessment is rebuilt as a professional paginated document: a cover page (large lockup, “Property Assessment”, assessed location/coordinates, date with time zone, company block — “BackcountryOS · backcountryos.com · Founder-led remote project services, Alaska-focused · Contact: chad@backcountryos.com” — and the preliminary/not-a-survey limitation), a running header on content sections, a running footer with “Page X of Y” via @page counters, page-break rules, and the three levels (Understand / Explore / Technical Evidence) as document sections with the static map, sources, and limitations. (3) Jurisdiction generalization: customer text no longer hard-names one borough — the jurisdiction shown comes from the run's own data (the demo legitimately shows Mat-Su because its data returns it), and service wording is generic (“local borough or census area”, “the local parcel/records service (where available)”, “the recording district”). (4) Interactive map: Leaflet + OpenStreetMap tiles replace the in-app schematic — marker, parcel polygon where returned, roads solid / trails dashed, zoom/pan, scale control, OSM attribution, and the honesty caption; on library/tile failure the schematic renders as fallback with a plain note; the download keeps the schematic, labeled as a static map image. (5) Elevation is fetched from the Open-Meteo elevation API alongside the climate call and shown in Property details (“~X m (Y ft) above sea level”, source “Open-Meteo elevation data”, dataset-derived limitation); on failure it reads “Unknown — source unavailable”. (6) Access alternatives: when no motorable road is found, an “Alternative access to evaluate” block (overview card, Explore, Section A, download) presents boat/river, floatplane, fixed-wing via the nearest mapped airstrip, winter snowmachine/sled, and helicopter options keyed to the returned evidence — every mode POTENTIAL AND UNVERIFIED with what confirming it requires. (7) Utilities alternatives: whenever utilities are unverified, “Plan as if off-grid until a provider confirms service” plus the standard set (solar with generator backup, wind, well or treated surface water, septic with the ADEC starting point, propane/wood heat, satellite internet) appears in the Utilities card, Explore, Section C, and the download — labeled planning guidance, not findings. (8) Reviewer tools render ONLY with ?reviewer=1; otherwise the containers and toggle are removed from the customer DOM entirely. Tests: suite grows to 62 (new tests 57–62); the only earlier assertions adjusted are test 34 (reviewer visibility) and test 37 (interactive map), both deliberate behavior changes of this round. The build freezes after this round.
- Round 9 — Paginated assessment document (Oct 29, 2026): the downloaded assessment is rebuilt as a designed, paginated document — a consulting deliverable that reads one page at a time. The file now presents as discrete US Letter sheets stacked vertically on a neutral gray backdrop, each sheet a page with visible separation and shadow. Page plan: page 1 is a cover (large logo lockup, “Property Assessment”, the assessed property, date with time zone, the company block — “BackcountryOS · backcountryos.com · Founder-led remote project services, Alaska-focused · Contact: chad@backcountryos.com” — and the standing preliminary/not-a-survey limitation); then Understand (the plain-language overview); then The Property (the static map, labeled as a static map image, plus property facts including elevation, parcel identification, and acreage); then Explore; then Technical Evidence Sections A–E, each starting on a fresh sheet; and final Sources & Limitations and Verification & Next Steps sheets (the still-to-confirm list, the user's note, and any structure selection travel there). Every sheet carries the same furniture — top: small logo lockup + “BackcountryOS” at the left, “Property Assessment” at the right; bottom: “BackcountryOS · backcountryos.com”, “Preliminary assessment — not a survey”, and a computed “Page X of Y”. Pagination is deterministic and builder-controlled: sections are assigned to sheets and split only at block boundaries, with “(continued)” in the section header of continuation sheets — it does not rely on browser print flow. Printing reproduces the same sheets (@page Letter, zero page margin; the sheet furniture is the only header/footer — the Round 8 @page margin-box counters are removed so nothing duplicates). The document is BackcountryOS branded throughout — the outside package the owner cited set the presentation standard only; none of its branding appears. Every element of the Round 8 download survives, reorganized; the in-app report is unchanged. Tests: suite grows to 65 (new tests 63–65: discrete sheets with sequential “Page X of Y” numbering matching the sheet count; cover company block + contact email, full Round 8 content coverage, and zero third-party branding in the download; long-report continuation pagination). Test 62 is rewritten for the new single pagination mechanism — its @page-counter assertions described the Round 8 mechanism this round deliberately replaces; no other earlier assertion was changed. The build freezes after this round.
- Round 10 — Briefing + appendix document redesign (Oct 29, 2026; owner-authorized via his editorial review of the Round 9 PDF — the engine does not change; the assessment remains free): the single download is replaced by two documents. (A) A 7-page customer BRIEFING (primary download, “Download assessment briefing”): page 1 cover with the platform lockup, property, date with time zone, status line, limitation, and a REAL map as centerpiece — OpenStreetMap tiles composited client-side on a canvas at download time with the parcel polygon and point marker drawn over them, carrying “© OpenStreetMap contributors” attribution and the “Not a survey; mapped proximity does not establish legal or physical access” caption (tile failure falls back to the schematic, captioned as a schematic — never a blank space); page 2 property snapshot with a dominant feasibility-gates panel (LEGAL ACCESS and PHYSICAL ACCESS unresolved, first) and key findings carrying visual confidence indicators rendered from the existing evidence labels (Verified / Observed · Calculated estimate · Unverified · Source unavailable); page 3 access & logistics with the alternative-access block HERE ONLY and plain-language freight implications; page 4 climate, utilities & site development with the “Plan as if off-grid” guidance and alternative set HERE ONLY plus permitting starting points; page 5 development feasibility (provisional reading, major unknowns ranked) with the structure selection carried through from the property profile — the selected direction with its stated assumptions, or the four types as the pending decision with one line each; page 6 a prioritized verification checklist, gates first, each item with what it resolves and the recommended action/owner; page 7 “Continue Your Project” — the Assess → Design the Project → Build the Budget → Plan the Execution → Connect and Build journey with platform stages honestly labeled In Development and project services available for consultation now, an invitation, the contact address, and the website's Start Your Project path. No pricing anywhere in the briefing; the words “Founder-led” do not appear in it; each fact lives on one briefing page only. Briefing sheets carry the Round 9 furniture (lockup header; footer “Page X of 7” + “Preliminary assessment — not a survey”). (B) The TECHNICAL APPENDIX (secondary download, “Download full technical appendix”): the complete Round 9 paginated document unchanged in content and defensibility (Sections A–E, sources, limitations), retitled with the cover line “Technical Appendix — [property]” and its own Page X of Y numbering; buildDownload remains as the appendix alias so all Round 9 assertions run against it. Both documents use the dedicated BackcountryOS contact address chad@backcountryos.com (owner update, Round 10) — the briefing cover's “Project inquiries” line and the appendix cover/company block; the old Green Industry address appears in neither document. The in-app interactive Leaflet map and all engine behavior are unchanged. Tests: suite grows to 72 (new tests 66–72: briefing exactly 7 sheets; alternatives block exactly once on page 3 and off-grid guidance exactly once on page 4; gates before other findings on the snapshot; selected vs. pending structure on page 5; cover map image + attribution + fallback schematic + no “Founder-led” in the briefing; appendix full Round 9 content set + retitle + new address; both download controls on the report view and the planning screen). The build freezes after this round.
- Round 11 — Final refinement: property map, confidence labels, document checks (Oct 29, 2026; owner-authorized via his second editorial review — briefing 84/100, up from 65; the final refinement before the pilot decision, frozen after this round): (1) PROPERTY MAP rebuilt: the downloads' static map builder (shared by the briefing cover and the appendix Property sheet) now composites a TERRAIN base — OpenTopoMap relief/contour tiles first, standard OpenStreetMap tiles if the topo layer fails, the captioned schematic if all tiles fail (never blank) — at a wider context extent (zoom 13, stepping to 12 for very large parcels), with vector overlays drawn from the run's own fetched data: parcel polygon (bold forest-green outline, translucent fill), the assessment-point marker, mapped motorable roads (solid, light-cased), mapped trails/paths (dashed), and mapped waterways (blue). Furniture: a LEGEND naming each overlay with the standing honesty note that mapped features are map data, not verified access; a SCALE BAR computed for the map's actual zoom and latitude (drawn on the image and in the legend block); a NORTH ARROW (on the image and in the legend block); the caption “Not a survey. Mapped proximity does not establish legal or physical access.” plus attribution for whichever base was used. (2) CONFIDENCE LABELS tightened — names only, meanings unchanged, applied in the in-app UI, the briefing, and the appendix: “Verified / Observed” and “Observed from source” → “Source Observed”; “Calculated estimate” → “Calculated”; “Unverified”, “Source unavailable”, and “Owner-reported” unchanged. “Verified” no longer appears as an evidence label anywhere customer-facing (it remains inside disclaimer sentences, verbatim). (3) CHECKS: LINKS — every hyperlink in the downloaded documents was followed and verified; three dead targets were fixed (Alaska State Recorder's Office: dnr.alaska.gov/ssd/recoff/about returned 404 → now https://dnr.alaska.gov/ssd/recoff/ ; Mat-Su Mandatory Land Use Permit PDF returned 404 → now the borough Permit Center https://matsugov.us/permits ; Chugach Electric node/87243 returned 404 → now https://www.chugachelectric.com/) and MEA upgraded to https://www.mea.coop/. Full verified link list for the documents: https://matsugov.us/shapefiles (Mat-Su Borough GIS & parcel data) · https://maps.matsugov.us/map/rest/services/ParcelViewer/Cadastral_Parcels_OptOut/FeatureServer (the parcel service queried) · https://dnr.alaska.gov/ssd/recoff/ (Alaska State Recorder's Office) · https://matsugov.us/permits (Mat-Su Permit Center) · https://matsu.gov/services/encroachment-permit (Mat-Su driveway/encroachment permits) · https://dec.alaska.gov/water/wastewater/domestic/ (Alaska DEC — Division of Water) · https://www.adfg.alaska.gov/index.cfm?adfg=uselicense.fish_habitat_permits_apply (ADF&G Fish Habitat Permit) · https://dnr.alaska.gov/mlw/lands/permitting/how-to-apply/ (ADNR land-use permits) · https://www.mea.coop/ (Matanuska Electric Association) · https://www.chugachelectric.com/ (Chugach Electric Association) · https://www.gvea.com/member-resources/my-bill-explained/payment-options/ (Golden Valley Electric Association). The briefing itself carries no hyperlinks (contact and website are plain text); all document hyperlinks live in the appendix's record-source, permitting, and provider entries. PAGINATION re-verified: briefing exactly 7 sheets, “Page X of 7” sequential, with either map variant; appendix sequential “Page X of Y” with either map variant. MOBILE READABILITY: both downloads now carry a viewport meta and a screen-only max-width scaling rule — sheets fit phone width with no horizontal scrolling on screen, while @page Letter keeps print true US Letter. Both documents remain valid self-contained HTML that opens standalone. Out of scope and untouched, per the round's authorization: the appendix's structure and its Round 9 “Founder-led” company line, the assessment engine's data and cautionary language, and persistent projects (the “nothing is stored” limitation stays, stated plainly). Tests: suite grows to 76 (new tests 73–76: the exact new label set with no label reading “Verified”; map furniture + overlay drawing + scale computation + clean tile-failure fallback; the document link/mobile/standalone checks; pagination re-verified with the new map). Earlier assertions updated only where this round deliberately renamed labels: tests 27, 38, 65 (fixture), and 68. The build freezes after this round.
- Core rule: an unavailable data source never becomes a negative property finding. Missing data is reported as Unknown / Source unavailable.
- Nothing is saved. Lookups run in your browser; entries disappear when you close the page.
Your land. Your vision. Your legacy.
Find out what you should know before building on remote property.
Address results are a geocoded match — the map service's best interpretation of what you typed — not a verified parcel. You'll confirm the coordinates before the assessment runs.
Before you submit — where your entry goes: the address or coordinates you enter are sent to third-party data providers for lookup — Nominatim / OpenStreetMap (geocoding and map data), Open-Meteo (climate archive), and, where available, the local parcel/records service (where available). BackcountryOS itself does not store the assessment — nothing is saved when you close this page.
Free preliminary assessment. No technical experience required.
61.938502, -151.834736
This is a demonstration using live public data — it is not a verified ownership or legal-access assessment.
… Collecting map features (OpenStreetMap)…
… Pulling descriptive climate history (Open-Meteo, 2021–2023)…
… Classifying evidence & withholding conclusions the data can't support…
… Checking the local parcel/records service (where available)…
Real lookups against live public data — this can take 20–40 seconds. A failed lookup is reported as Source unavailable, never converted into a finding.
Level 3 — Technical evidence: sources, calculations, engineering references, evidence classifications, and limitations, retained in full.
For reviewers only — you never need to open these to use the assessment.
Assessment runs in this visit
Each entry below is a separate assessment run with its own timestamp. “Run a new assessment” adds a new entry — it does not refresh, replace, or overwrite an earlier run.
Nothing run yet this visit. Assessments are kept here only while this page stays open — this review build doesn't save them.
Sample assessments — access conditions + in-place research content
Built from mocked map data run through the same corrected logic as live reports, so reviewers can check the reasoning without a network. Mocked inputs are labeled as such in each sample. Sample D additionally exercises the in-place placements (legal access detail at the Section A legal-access item, design values at the Section B snow-load and heating items, permitting entries in Section E, nearest utility providers in Section C) with a mocked Mat-Su parcel-service response.
Automated tests (P1-3, expanded rounds 2, 4, 5, 6A, 6B, 7, Round 7 final corrections & the fixed-coordinate demo, Round 8, Round 9, Round 10, Round 11) — deterministic, mocked data
76 tests run in your browser on load against mocked source responses — no network involved. Tests 1–12 cover the correction specification's acceptance criteria; 13–17 cover the round-2 fixes (strict coordinate parsing, line-segment road geometry, climate completeness — test 17 now also proves a full-length sequence with a duplicated date or a gap is rejected, not just short or low-coverage data); 18–23 are end-to-end tests that generate and render full reports from mocked inputs and exercise the confirmation, missing-data, navigation, and repeat-assessment workflows — test 18 now also proves a 2 km fallback map search is reported as 2 km, not as a full 18 km search. Tests 24–28 cover the Round 4 content in its Round 5 in-place locations: nearest-jurisdiction selection picks the geographically nearest covered town; out-of-coverage coordinates produce the coverage-unavailable note in place at the Section B items with no values shown; an invariant test fails if any in-place design value lacks a source or the reference label; link-only records elements at the Section A legal-access item are labeled “Not searched by this tool”; and the utilities content never renders a service-availability claim. Test 29 proves a rendered report contains no standalone-section panel or pointer text for the removed sections. Tests 30–33 cover the Round 6A Stage 1 corrections: ambiguous-match radio gating with no preselection and a disabled run button until a deliberate choice; motorable-road vs. trail/path classification — a mocked path-class trail closer than any motorable road must appear as the trail result, never the road result; summary-equals-detail consistency under a mocked map failure; and jurisdiction-accurate parcel-confirmation copy for covered and uncovered jurisdictions. Tests 34–40 cover Round 6B: customer/reviewer separation (no reviewer material in the customer DOM path), plain-language overview translation using the owner's audited examples, the all-sources-failed overview, property-map rendering and honest degradation, download completeness (sources, dates with time zones, labels, limitations, the user's note), the planning transition carrying the property profile forward, and the rule that no status renders as verified from data-return alone. Tests 41–49 cover Round 7: the trail-name/class-conflict guard, agency-parcel rendering, the planning handoff (Step 1 label, Back + Download on the planning screen, structure choice carried into the download), the three labeled levels with Level 3 retaining sources and limitations, internal-terminology absence from customer screens and the download, borough wording for Mat-Su, the coordinate-error example, blank-note behavior, and new-assessment state resets. Tests 50–52 cover the Round 7 final corrections: the Section A (technical-evidence) account/ID field for an agency-polygon result, the downloaded assessment for the same result, and the absence of the title-search certainty assertion from every customer surface and the download. Round 7 deliberately changed rendered text in two places, and only those assertions were adjusted: test 35 (Property status wording — 'Data found' is now 'Information found — key items still to confirm' where open items exist — and 'Borough mapping' replacing 'County mapping' in the audited example) and test 40 (the allowed-status set gains that same new wording). No other prior assertion was changed. Tests 53–56 cover the owner-approved fixed-coordinate demo (change log: “Demo — fixed-coordinate sample property, owner-approved”): the exact demo label and the exact coordinates on the start screen, a direct run at 61.938502, -151.834736 with no match-selection step, the demo disclaimer line, and no Yentna in customer-facing text. In that pass, test 30's name and detail were adjusted only to remove their description of the old demo mechanism (the demo shortcut opening the same confirmation path as an address search); test 30's address-gating assertions themselves are unchanged. Tests 57–62 cover Round 8: elevation rendering on success and on failure, the access-alternatives block for a no-road/no-trail report naming the mocked waterway and airstrip, utilities alternatives labeled as planning guidance (not findings), a non-Mat-Su jurisdiction report free of any hard-coded borough name, and the paginated download (cover, @page page counters, page-break rules). Round 8 adjusted exactly two earlier assertions, each because the round deliberately changed the behavior: test 34 (reviewer tools: hidden-behind-a-toggle → rendered only with ?reviewer=1 and removed from the customer DOM otherwise) and test 37 (schematic map in-app → interactive Leaflet/OpenStreetMap map with the schematic retained as fallback and as the download's static map). Tests 63–65 cover Round 9: the download's discrete page sheets with sequential “Page X of Y” numbering matching the actual sheet count; the cover sheet's company block and contact email with every Round 8 content section present in the paginated document and no third-party branding anywhere in it; and pagination holding for a long mocked report (continuation sheets with “(continued)” headers, numbering still sequential). Round 9 rewrote test 62 for the new single pagination mechanism — its @page margin-box counter assertions described the Round 8 mechanism this round deliberately replaces; no other earlier assertion was changed. Tests 66–72 cover Round 10 — Briefing + appendix document redesign: the Round 9 download assertions (tests 62–65) now run against the technical appendix via the buildDownload alias and must still pass there (tests 62 and 64 had only their contact-email assertion updated to the dedicated BackcountryOS address, chad@backcountryos.com, per the owner's Round 10 update); the new tests prove the briefing is exactly 7 sheets for the Tract E fixture with Page X of 7 footers, the alternative-access block appears exactly once in the briefing (page 3) and the off-grid utilities guidance exactly once (page 4), the snapshot presents the access gates before the other findings, a fixture with a structure selected shows that selection on briefing page 5 while a fixture without shows the four options as a pending decision, the cover contains a map image element with OSM attribution (and a captioned schematic fallback) with no “Founder-led” string anywhere in the briefing, the appendix contains the full Round 9 content set under its own retitle and numbering, and both download controls appear on the report view and the planning screen. The no-LIMBO assertion applies to both documents (tests 64, 70, 71). Tests 73–76 cover Round 11 — Final refinement: the tightened confidence-label set (Source Observed / Calculated / Unverified / Source unavailable / Owner-reported) with an assertion that no evidence label reads “Verified” and that the briefing snapshot chips use exactly the new names (tests 27, 38, 68 and the test-65 fixture were updated only for these deliberate renames); the rebuilt property map (terrain-base builder with OpenTopoMap → OpenStreetMap → schematic fallback, legend + computed scale bar + north arrow furniture, and overlay drawing — parcel bold, road solid, trail dashed, waterway blue — verified against a recording canvas stub); and the document checks (every hyperlink in both downloads a well-formed absolute https URL with the three dead targets fixed, both documents standalone with a viewport meta and phone-width screen scaling while print stays true US Letter, and pagination re-verified — briefing exactly 7 sheets and appendix sequential — with the new map embedded).
Live integration checks — documented results (round 2)
Build-environment check, 2026-10-29 (direct HTTPS requests to the same endpoints and parameters the page uses, from the build environment — not from a reviewer's browser):
- Nominatim geocoding — responded. The demo query returned the Yentna River match (61.9941, −151.1105, Matanuska-Susitna Borough).
- Open-Meteo archive — responded. Daily temperature / precipitation / snowfall returned for the requested period with values present.
- OpenStreetMap map API — responded. Valid OSM XML returned for a sample bounding box.
- Mat-Su Borough cadastral parcel service (Round 4) — responded. A point query at the Tract E coordinates (61.9385, −151.8347) returned the parcel containing that point (account 5725000T00E; legal description “FRIDAY CRK RRCS (ASLS 2003-11) TRACT E”; GIS polygon area 870,043 sq ft), and the service returns a CORS header allowing browser fetches. A point outside the borough returned an empty feature set, as expected.
What this does not prove: browser-side behavior (CORS, rate limits, sandbox restrictions) can differ from a direct request. The in-browser check below is the browser-side test: run it from a normal browser connection and read its result as the browser result. In sandboxed preview environments outbound fetches may be blocked entirely — that outcome is reported as BLOCKED, not as a service failure or a pass.
Run the browser-side live checks
Live services behave differently from mocks (rate limits, coverage, CORS). The checks below now run independently: each starts on its own, the map, climate, and parcel checks use fixed coordinates instead of depending on the geocoding result, and each reports its own result in its own row. If geocoding fails, the other checks still run and report — one failed service no longer stops the others. A blocked check is reported as blocked, not passed or failed. Round 4 adds a fourth independent check: the Mat-Su Borough cadastral parcel service at the fixed Tract E coordinates.
Note: some sandboxed preview environments block outbound fetches entirely. If all three checks show blocked here, re-run from a normal browser connection before treating it as a service failure.
Change log — tied to the correction specification
- P0-1 Property identification: Parcel-ID tab disabled with an on-screen explanation; it can no longer produce an assessment. Address results are labeled “Geocoded match — not a verified parcel.” Coordinates and resolved location are shown for explicit user confirmation before any assessment runs. Invalid coordinates are rejected; multiple address matches are flagged as ambiguous and selectable.
- P0-2 Access: The “road within 1 km = road access” rule is deleted. Reports now show only the nearest mapped road and straight-line distance, with legal access, physical connection, surface, weight limits, and seasonal usability each listed as Unverified. Year-round truck claims and definitive off-road classifications are removed. A failed map lookup yields “Unknown,” and no mapped road yields “No qualifying road identified in the search area.”
- P0-3 Climate: The heating design temperature (coldest day − 10°F) and snowfall-derived snow-load classes are deleted and no longer feed any warning or comparison. Historical temperature, snowfall, and precipitation remain as descriptive data labeled with source (Open-Meteo Archive) and period (2021–2023). Snow load, heating design temperature, and foundation criteria read “Requires jurisdiction-specific design verification.”
- P0-4 Utilities: Municipal water, sewer, and electric verdicts derived from community/road proximity are deleted. All three read “Service availability unverified.” Wells, septic, solar, generators, and micro-hydro are presented as possible alternatives requiring site-specific evaluation — never as feasible because a map feature is nearby.
- P0-5 Structures: Numeric scoring and ranking are deleted (the log cabin no longer starts at 70 points). Each option shows potential advantages, potential limitations, key unknowns, and verification conditions, with a status of Potential option / Requires further evaluation / Not assessed. Because soils, foundation feasibility, verified access, design loads, and owner requirements are unknown, no option can be labeled “Recommended.”
- P1-1 Wildlife: The bear precaution no longer depends on road proximity — identical wildlife evidence now produces the identical precaution whether or not a road is nearby. It is labeled a construction and wildlife-safety precaution based on owner experience, not a site-specific ecological assessment.
- P1-2 Evidence: Every material finding carries source, retrieval context, one of the five standard evidence labels, limitations, and required verification. “Confirmed by data” is removed everywhere.
- P1-3 Testing: The 12 specified scenarios are implemented as deterministic in-page tests with mocked responses (panel above), kept separate from live integration checks. Passing tests are not claimed as proof that no defects remain — see the round-2 expansion below.
Round 2 — corrections from the second independent review
- R2-1 Strict coordinate parsing (High): The parser no longer uses
parseFloaton the first two tokens. Input must contain exactly two plain decimal numbers (comma- or space-separated); extra values (61.9, -151.6, 999), trailing characters (61.9abc), repeated decimal points, empty values, and stray symbols are all rejected with a specific error before any lookup. - R2-2 Road geometry (High): Distances to mapped ways are now computed to the nearest point along each line segment (local-projection point-to-segment distance), not to mapped vertices. A long segment passing beside a property is no longer reported at its endpoints' distance. The finding is labeled a Calculated estimate with the geometry method and map-accuracy limits stated.
- R2-3 Climate completeness (High): Returned climate data is validated before any average is shown: date range must span 2021-01-01 to 2023-12-31, and temperature, precipitation, and snowfall must each have at least 90% non-missing daily coverage (1,095 expected days). Incomplete datasets withhold their averages, are labeled with their coverage, and are disclosed in the report's gap notices.
- R2-4 Structure claims qualified (Medium): Structure advantages and limitations were rewritten to remove unqualified claims about insulation and thermal performance, cost, speed, and foundation requirements. Each claim is now conditioned on the variables that actually determine it (sealing and detailing, verified freight, model- and site-specific anchoring, jurisdiction loads), with cost and foundation needs explicitly site-dependent.
- R2-5 End-to-end tests (Medium): The suite grows from 12 to 23 tests. New coverage: strict-parser rejections, segment geometry vs. vertex distance, climate completeness thresholds, full report generation from mocked inputs, incomplete-climate and total-failure reports, rendered-HTML checks (no “Road-accessible” / “Recommended” verdicts), section navigation rendering, repeat-assessment independence, and the confirmation-gate workflow.
- R2-6 Live integration (Medium): Direct requests to all three live endpoints were run and documented on 2026-10-29 (results in the test panel above — all three services responded from the build environment). Browser-side verification remains a separate, explicitly labeled check, because a direct request does not prove browser CORS/rate-limit behavior; blocked browser checks are reported as BLOCKED.
- Tests ≠ no defects: The test summary no longer claims “0 unresolved defects.” Passing tests verify the checked rules only; untested behavior and live-data accuracy remain open review items.
Final refinements — third review (MVP feature set frozen)
- F-1 Climate date uniqueness & continuity:
validateClimateDailynow walks the returned dates one by one with a seen-set and a day-by-day step check: any duplicate date is rejected (“Duplicate climate date found…”), and any step other than exactly one day is rejected (“Gap or discontinuity in the climate date sequence…”). This closes the case the endpoint-plus-count check missed — a 1,095-row series with correct first/last dates and full counts that duplicates one day while omitting another. Test 17 was strengthened in place to build exactly that series and prove it now fails, while a clean 1,095-day sequence passes. - F-2 Successful map radius displayed: The radius that actually succeeded in
osmMap(18, then fallback 9, 4, 2 km) is now carried into every report asmapRadiusKmand displayed three ways: a banner pill (“Map searched: X km radius”, flagged as a fallback when below 18 km), a dedicated access fact (“Map search radius actually searched”) stating only that radius was searched, and — for any fallback below 18 km — a gap notice at the top of the report warning that “not identified” in this run must not be read as an 18 km search result. Sample cards show the radius too. Test 18 was strengthened in place to prove a mocked 2 km fallback is reported as 2 km with the fallback notice. - F-3 Independent live checks: The live-check button no longer runs one sequential chain (geocode → map → climate) where a geocoding failure stopped the rest. Each of the three checks now starts independently in its own promise chain with its own result row; the map and climate checks use fixed demo coordinates (61.9, −151.6) instead of the geocoding result, each row starts as CHECKING and settles to its own PASS or BLOCKED, and the button re-enables only after all three have individually reported.
- No new capabilities, no test-count inflation: Nothing else was added. The suite remains at 23 tests; the refinements above are covered by strengthening tests 17, 18, and 21 in place.
Round 4 — Tract E field-review feedback (owner lifted the freeze for this round only)
- R4-A Legal access research: Legal access is stated plainly as UNVERIFIED. Where the Mat-Su Borough cadastral/parcel service resolves for the point, the attributes it actually returns (account/parcel ID, legal description as recorded in the service, GIS polygon area) are fetched live and shown labeled “Observed from source” with the source named; when no service resolves or it does not respond, the content says “Source unavailable” and shows nothing in its place. Direct links to the official record sources (borough GIS/plats, Alaska Recorder's Office) carry one line each on what to pull there and are labeled “Not searched by this tool.” TITLE SEARCH is named explicitly as a professional step performed by a title company — this tool does not perform one, and links are never presented as a search of the recordings. (Placement restructured in Round 5 — see below.)
- R4-B Design criteria (reference): Backed by a small curated dataset of Alaska jurisdictions with published values only: ground snow load from IBC Table 1608.2 (Ground Snow Loads for Alaskan Locations) and, where a published value was sourced, the ASHRAE 99.6% heating design temperature (ASHRAE Handbook—Fundamentals climatic design conditions; Fairbanks −43.5°F per ASHRAE 2013 as published in the CCHRC/NREL cold-climate study; Anchorage −14.8°F from the published −26.0°C for the Anchorage/Elmendorf station). The nearest covered jurisdiction is selected, named with its approximate distance, and the values are labeled exactly: “Reference only — nearest jurisdiction's published criteria. Verify with the authority having jurisdiction before design use.” A value that could not be sourced is omitted, never estimated. A separate professional-guidance line (labeled guidance, NOT a code value) suggests planning for −40°F-class conditions at remote Interior / Yentna-corridor sites. Outside the dataset's 200 km coverage limit, coverage is stated as unavailable and no values are shown. No design temperature or snow load is calculated from climate averages — that prohibition stands. (Placement restructured in Round 5 — see below.)
- R4-C Permitting research: “Permitting — where to check,” listing the typical authorities for a remote Alaska build (borough land-use/development permits and driveway/encroachment permits where applicable, ADEC wastewater/drinking water, ADF&G Fish Habitat Permits for water crossings, ADNR Division of Mining, Land & Water land-use permits where state land is involved), each with a link to the authority's official page, labeled “Starting points — not a determination of what this project requires.” (Placement restructured in Round 5 — see below.)
- R4-D Utilities: Approved as-is except as changed by R4-E4 below.
- R4-E Verification tasks reworked into app actions: (1) Items the app can confirm itself (user-confirmed resolved location; parcel attributes fetched from the public parcel service) are performed by the app and shown as done with their source. (2) Search items became in-report research content with honest searched / not-searched labels. (3) Cross-checks the app can perform (coordinates falling inside the named borough's parcel fabric, reverse-geocoded county matching the parcel service's borough) are verified and labeled with the legal-access content. (4) Section C presents the nearest utility providers by name with phone and website from a curated Alaska dataset keyed by region, under the standing label “Service availability unverified” — the nearest provider is never presented as serving the parcel, and a location far from every provider reference point is described plainly as a plan-as-off-grid location. (5) Closest-jurisdiction design data is provided directly in the report instead of left as an owner verification task, keeping its reference / verify-before-design-use label. (6)(7) Remaining checklist items are unchanged.
- R4 tests & sample: Tests 24–28 added (suite then 28). One mocked sample assessment (Sample D) exercises the new content end to end. Passing tests verify the checked rules only — they do not prove the absence of defects. The MVP feature freeze re-applies after this round.
Round 5 — presentation restructure (owner review: content in its corresponding areas)
- R5-1 Legal access into Section A: The legal access research content now renders in place at the “Legal access & easements” item in Section A (Access): fetched parcel attributes where a public parcel service resolves (labeled “Observed from source” with the source named), the official record-source links labeled “Not searched by this tool” with what to pull at each, the borough cross-check, and the title-search-as-professional-step note. The item states its limitation directly and no longer points to a separate location.
- R5-2 Design criteria into Section B: The “Structural snow load” item in Section B (Climate & Engineering) now shows the nearest covered jurisdiction's published ground snow load in place (jurisdiction named, approximate distance, value, published source, and the “Reference only — verify with the authority having jurisdiction before design use” label). The “Heating design temperature” item shows the published ASHRAE 99.6% value in place where the curated dataset carries one (same labeling), states plainly in place where it does not, and carries the −40°F-class professional-guidance line (labeled guidance, not a code value) where that guidance applies. Beyond the dataset's coverage range, both items render the coverage-unavailable note in place with no values. No design value is calculated from climate data, and no value renders without its published source and reference label — those prohibitions stand.
- R5-3 Permitting into Section E: The permitting authorities with their official links now appear as next-step entries in the verification / next-steps area (Section E), keeping the “starting points — not a determination of what this project requires” framing.
- R5-4 Standalone sections removed: The three standalone sections added in Round 4 are removed entirely, every pointer to them is removed (limitations in Sections A and B now state the limitation directly), and section letters A–E are unchanged. The utilities provider content in Section C is untouched.
- R5 tests & sample: Tests 24–28 now check the values and labels in their new in-place locations, and test 29 asserts a rendered report contains no standalone-section panel or pointer text for the removed sections. The suite is now 29 tests. The mocked Sample D now exercises the in-place placements instead of the former standalone sections. Passing tests verify the checked rules only — they do not prove the absence of defects.
Round 6A — Stage 1 corrections (independent audit, October 29, 2026)
- 6A-1 Ambiguous address selection (High): Multiple geocoding matches are now presented as mutually exclusive radio choices with NONE selected by default. The “Confirm & run assessment” button stays disabled until the user deliberately selects one, and the chosen location (name + coordinates) is stated prominently in the confirmation panel before the run. The demo shortcut opens the same unselected state — there is no preselection anywhere. Single-match and direct-coordinate flows keep their existing explicit confirmation.
- 6A-2 Confirmation parcel copy (High): The confirmation step now states the actual parcel coverage for the resolved jurisdiction. Where a parcel service is integrated (currently Mat-Su Borough), it says a parcel-attribute lookup by point is available and will be attempted, and that the GIS polygon is not a survey and does not establish boundary, ownership, title, or legal access. Where no parcel service covers the jurisdiction, it says plainly that no parcel service is integrated for that jurisdiction. The confirmation copy and the report's behavior no longer contradict each other.
- 6A-3 Road vs. trail classification (Medium): Road distance is computed over motorable mapped classes only (motorway / trunk / primary / secondary / tertiary / unclassified / residential / service / track / road / living_street and their links). Paths and trails (path / footway / cycleway / bridleway / pedestrian / steps and similar non-motorized classes) are measured and reported separately as “nearest trail / path,” with the mapped feature's class displayed alongside its name for both the nearest road and the nearest trail. A trail is never labeled a road anywhere in the report; the access summary reflects the motorable-road result, with any trail noted as non-motorized context.
- 6A-4 Failed-source summary consistency (Medium): The summary pill and the access detail are driven by the same status value. When the map source fails, the summary reads “Unknown — source unavailable” — never “Not established.” A self-test renders a full report under a mocked map failure and asserts the summary shows the Unknown state.
- 6A-5 Timestamp time zone (Low): Report timestamps now render the viewer's local time zone explicitly (the locale time-zone name/abbreviation) everywhere a research timestamp appears — the report banner and the run-history entries.
- 6A-6 Entry-point disclosure (Medium): Next to the location form, before submission, a concise disclosure states that the address or coordinates entered are sent to third-party data providers for lookup — Nominatim / OpenStreetMap (geocoding and map data), Open-Meteo (climate archive), and, where covered, the Mat-Su Borough parcel service — and that BackcountryOS itself does not store the assessment. It sits with the existing “Nothing is saved” language, which remains accurate alongside it.
- 6A-7 Re-run semantics (Medium): “Re-run research” is renamed “Run a new assessment,” and the visit history is labeled to make plain that each entry is a separate assessment run with its own timestamp — a new run adds an entry; it does not refresh or overwrite an earlier one.
- Tests: The suite grows to 33 tests. Tests 30–32 cover items 1, 3, and 4 as specified — no-selection-no-run gating including the demo path; a mocked path-class “Historic Trail” closer than any motorable road appears as the trail result, never the road result, with the road result computed from motorable classes only; and summary-equals-detail under map failure. Test 33 covers the item 2 confirmation copy for both covered and uncovered jurisdictions. Existing tests and samples were updated only where these fixes change rendered text. Stage 2 (map, export, customer-experience restructure) is not in this round.
Round 6B — Stage 2 + consumer experience (owner product direction, October 29, 2026)
- 6B-1 Customer / reviewer separation: The default view is the customer app: brand, a short plain limitation note, and the location form, reachable without scrolling past engineering material. Everything reviewer-facing — correction history, this change log, the automated test panel, the mocked samples, live-check documentation, and the feedback/copy tools — moved behind a clearly separate “Reviewer tools” toggle. No test results, changelog entries, or correction banners appear in the customer flow. Test 34 asserts the test panel and samples are not descendants of the customer view and that every reviewer container starts hidden.
- 6B-2 Screen 1 (owner's spec): “BackcountryOS” / “Your land. Your vision. Your plan.” / “Find out what you should know before building on remote property.” — one location entry (address or coordinates), the primary button labeled “Assess My Property”, the line “Free preliminary assessment. No technical experience required.”, and the Round 6A third-party lookup disclosure beside the form in short plain language.
- 6B-3 Screen 2 — Property Overview: After a run, the customer first sees the plain-language overview, not the technical report: four cards — Property (parcel information), Access (“Getting to your land”), Climate (“Weather conditions”), Utilities (“Power, water, sewer”) — each carrying an honest everyday status (Data found / Needs verification / We couldn't check). Below the cards, a “What should you know?” synthesis in plain sentences names what was found and what must be confirmed before planning construction, followed by a prominent “Start Planning Your Project” button. The full technical report (Sections A–E with evidence labels, limitations, sources, design references) remains behind “See details” expanders; source attributions sit behind “View sources”. Green / verified is never used for data a source merely returned — the only verified condition in the profile is the location the user confirmed themselves. Test 40 enforces this.
- 6B-4 Plain-language translation: Overview findings are stated in everyday words with the technical values one tap away in the details, following the owner's audited examples (test 35): a trail 6.17 km away becomes “A mapped trail is about 3.8 miles away. We haven't confirmed whether vehicles can reach your property.”; a county area becomes “County mapping suggests approximately 20 acres. This is not a surveyed measurement.”; unverified utilities become “We couldn't confirm electricity, water, or sewer service.” Miles are shown alongside kilometers for overview distances, and jargon (parcel fabric, geocoded, polygon, pg) is kept out of the overview layer.
- 6B-5 Property map: A schematic map rendered from the fetched data itself — no API-key services, no tile dependency: the assessed point; the county parcel outline where the parcel service returned geometry (the live fetch now requests the outline for exactly this purpose); motorable roads drawn solid and trails/paths dashed, distinctly; water features and airstrips where the map data returned them. Permanently labeled “Not a survey. Does not verify access.” Where the map source failed, the map area says so plainly; where no line geometry came back, it draws only the point and says so — never a blank or misleading graphic. Test 37 covers rendering and both degradations.
- 6B-6 Downloadable report: “Download assessment” produces a printable/saveable document containing the overview, all technical sections (A–E) with evidence labels and limitations, source names, retrieval dates with time zones, the still-to-confirm list, the user's note, and the map (or the explicit couldn't-draw note). The download flow reminds the user that nothing is stored — save the file before closing. Test 38 verifies the contents.
- 6B-7 Property profile: Every assessment is structured internally as a property profile: original location, retrieved evidence, data-source dates, verified conditions, unknowns, and user-supplied information (an optional “Add a note about this property” field joins the profile and the download). The profile is what the download contains and what the planning step consumes. Copy states the profile lives in the downloaded copy and this visit — accounts and cloud storage are never implied.
- 6B-8 Start Planning transition: “Start Planning Your Project” opens the first project-definition step: structure-type selection (log cabin, stick-framed, steel kit, yurt — the existing set, statuses unchanged) with the property profile carried forward visibly — access, climate, and utilities context restated in plain language, and unknowns listed as “Still to confirm” items that travel with the project. No information already collected is re-asked. This step is structure selection and project definition only — no budgeting, scheduling, pricing, or payment functionality. Test 39 verifies the carry-forward.
- 6B-9 Mobile + failure states: The overview, cards, map, and planning step are single-column at phone width with full-width tappable controls and no horizontal scrolling components. Blocked/failed sources render the same overview structure with “We couldn't check” statuses and plain gap language (test 36, from a mocked all-sources-failed run) — never a broken or empty overview.
- Tests: The suite grows to 40 tests (34–40 above). Data, datasets, fetch logic, and honesty rules are unchanged except as this round's presentation requires (the parcel fetch now also returns the outline geometry the map needs). Passing tests verify the checked rules only — they do not prove the absence of defects.
Round 7 — Consumer Experience Refinement (owner-authorized after the Consumer Experience & Simplicity Audit, baseline 74/100, target ≥90/100; build FREEZES after this round)
Friction-removal round: fewer banners, fewer repeated disclaimers, less text. No budgeting, scheduling, contractor, payment, or account functionality was added. Every material finding, uncertainty, and limitation is retained — reorganized and reworded, never deleted or softened. Each correction below names its evidence.
- 7-1 Planning handoff (Critical) — fixed. The structure-selection step is now labeled “Step 1 of planning: choose a structure type,” with one line that more planning capabilities (budgeting, scheduling) are forthcoming, presented as a preview. The screen carries its own “Back to your overview” and “Download assessment” actions; the Property summary travels alongside Access / Climate / Utilities; after a selection, a “What happens next” line appears instead of silence; and the download generated from that screen includes the structure choice. Evidence: test 43 renders the planning screen (Step 1 label, planBack + planDownload present, Property card present, forthcoming line, What-happens-next line) and a download naming the selected structure.
- 7-2 Three-level information hierarchy. Each finding area is now presented as Level 1 — Understand (the plain-language overview cards, labeled on screen), Level 2 — Explore (a new layer gathering the practical considerations and verification/next-step actions from the technical sections into short action-language paragraphs, one tap away), and Level 3 — Technical evidence (the full existing A–E detail — sources, calculations, engineering references, evidence classifications, limitations — retained in full behind a labeled “Technical evidence” toggle). Evidence: test 44 finds all three level labels in the rendered output and confirms Level 3 still carries per-item Source and Limitation lines.
- 7-3 Schematic map orientation. The existing schematic map only (per owner scope discipline, no tile-based context map was built): the assessment point now carries a halo so it is unmistakable against the parcel outline; a north arrow is drawn on the map; a distance scale bar is drawn from the drawing's own extent where its scale supports one; the label reads “Schematic map. Not a survey. Does not verify access.”; and the legend is fixed — the same entries every run, on the map box. Evidence: test 37 (unchanged assertions) still passes against the improved map, including the permanent not-a-survey label and both honest degradations.
- 7-4a Contradictory access presentation (High) — owner road/trail rule applied. Features are not classified as road or trail by name, and a motorable map class is never treated as establishing vehicle access. Where a feature's name and its map classification conflict (e.g., a track-class feature named “…Trail”), customer text states what was mapped (name + class), discloses the conflict plainly, and states that actual vehicle access remains UNVERIFIED — vehicle usability is never asserted for such a feature. The Section A heading/subtitle are conditional on the actual result (trail/water/air context when no confirmed vehicle road exists). Evidence: test 41 — a mocked track-class “Iditarod National Historic Trail” renders with the conflict disclosed and UNCONFIRMED wording, never as a road vehicles can use, and the Section A heading switches to trail/water/air.
- 7-4b Agency parcel rendering. A generalized ownership class is never rendered in the account slot (guarded in both the overview and the in-place legal facts). A containing polygon is presented as the customer's parcel only when the service identified it (account/legal description); a class polygon and/or a polygon vastly larger than a single lot renders plainly: the point falls inside a large area shown in borough mapping as [class] land — about [X] acres — “This is not an individual parcel result,” not identified as the customer's parcel, with ownership, boundaries, and legal status unverified. Acreage is formatted with thousands separators everywhere. Evidence: test 42 — a mocked AGENCY polygon of 25,766 acres renders exactly that statement, formatted “25,766 acres,” with no “account AGENCY” anywhere.
- 7-4c Internal language removed. “CORRECTED ENGINE,” “corrected review build,” and round references are removed from all customer-facing screens, the downloaded report, and sources text (the page title and report banner included). This changelog (reviewer tools) is the only place round history remains. Evidence: test 45 scans the rendered overview, explore, planning, technical report, the generated download, and the live customer-view DOM for those strings.
- 7-4d Borough terminology. Alaska borough jurisdictions use “borough” in customer text (Borough records / borough mapping / borough parcel service); neutral “county/borough” wording is kept where the jurisdiction type is unknown. Evidence: test 46 — the Mat-Su overview reads “Borough mapping suggests approximately 20 acres” with no “County mapping” in the overview.
- 7-4e Coordinate errors. Every coordinate validation error now includes “Example: 61.9385, -151.8347.” Evidence: test 47 checks the example in both the empty-input and letters-only errors.
- 7-4f Empty note. A blank note can no longer produce a success confirmation: the note action responds plainly “Nothing was added — the note is blank.” A non-blank note confirms exactly what was saved, quoting the note, and where it lives (the downloaded assessment). Evidence: test 48 exercises the same note-result function the button uses, for blank and non-blank input.
- 7-4g State resets. Starting/rendering a new assessment collapses the details, sources, and explore layers; switching entry tabs clears stale input text. Evidence: test 49 drives the real tab switch and report render in the DOM and verifies both resets, then restores the start screen.
- 7-5 Status wording + decision synthesis. The bare “Data found” status is replaced, where open items exist, with “Information found — key items still to confirm”; unqualified positive wording is reserved for cards with nothing material open, and nothing reads as verified unless verified. “What should you know?” is rewritten as a decision summary: the biggest concern, what it means for the customer's plans, and the single most important next action (a title-company search) — not a repetition of the card text. The overview answers only: what we learned, the biggest concern, and what to investigate first. Evidence: tests 35/40 as adjusted (see below) plus the decision-synthesis wording rendered in every overview.
- 7-6 Design standard / friction removal. The preliminary not-a-survey disclosure is consolidated to the start screen and the download, stated once each; redundant defensive text was trimmed (the planning screen's closing note, the map's varying legends). The journey reads: Enter your property → Understand your land → Explore your options → Start planning. Evidence: the customer flow carries one start-screen disclosure; the fixed map legend replaces per-run varying captions (7-3).
- Cleanup (post-Round 7, Oct 29, 2026): the two remaining “Round 4” references in the customer-facing footer sources line are removed and rewritten in plain customer language — the Mat-Su Borough cadastral parcel service is now described as applying “(where it resolves)” and the IBC Table 1608.2 / ASHRAE design references as “(published reference values only)”. No other customer text changed, and no other Round 7 behavior changed. Test 45 is extended to scan the actual rendered customer surfaces — the live start-screen DOM, the footer disclosure, a rendered confirmation step (single-match and ambiguous), the sources view, overview, explore, planning, technical report, and the generated downloads — for /Round \d/, instead of generated strings alone. Round history remains only in these reviewer tools (changelog/tests). Suite remains 49 tests.
- Adjusted prior assertions (only these, both forced by deliberate Round 7 text changes): test 35 — the Property card's status wording (see 7-5) and “Borough mapping” replacing “County mapping” in the owner's audited example (see 7-4d); test 40 — the allowed-status set gains “Information found — key items still to confirm.” No other prior assertion was changed; the suite is now 49 tests. Owner verification matrix for this round: Tract E coordinates, the Yentna demo flow, ambiguous locations, repeated runs, invalid inputs, mobile layouts, downloaded-file inspection, and source-failure conditions.
Round 7 Final Corrections — independent audit findings closed (Oct 29, 2026; build re-freezes after this pass)
The independent acceptance audit scored the Round 7 build 81/100 (improved from 74/100), with the deployed browser test suite showing 49/49 passing and the primary customer journey working — but it found two High-severity defects that the Round 7 completion report stated were fixed. Both are closed in this pass, in every surface. No features were added, nothing was redesigned, and no other edits were made.
- Finding 1 (High), as the audit stated it: “AGENCY still appears in the Parcel account / ID field in the Yentna assessment's technical evidence” — Section A displays
AGENCYunderParcel account / ID, even though the overview correctly describes the large containing polygon. Exact fix: one guard (realParcelAccount) now decides what may render in any account/ID field anywhere — a returned value is treated as a generalized mapping classification, never an account, when it is a known class name (e.g. AGENCY), when it matches the service's generalized ownership value after normalization, or when it contains no digit at all. Every account rendering goes through that guard: the overview card, the Section A technical-evidence field list, the Section E parcel task, the Explore layer, the planning screen, the sources-adjacent sample card and live-check row, and the download builder (which renders the same Section A fields). Where the parcel service returns a classification instead of an account identifier, the “Parcel account / ID” field now reads “No parcel account was identified for this point” (in Section A and in the downloaded assessment), and the classification appears only in a clearly labeled classification field: “Mapping classification: AGENCY — generalized, not a parcel account.” Evidence: new test 50 (Section A field rendering specifically, not only the overview) and new test 51 (the downloaded assessment for the same agency-polygon result). - Finding 2 (High), as the audit stated it: customer text states that a title-company search of recorded easements and the plat “settles whether you have a legal right to reach the land.” Exact fix: that certainty assertion is replaced everywhere it appeared — the overview synthesis (“Investigate first”), the still-to-confirm list, the Section A legal-access limitation and verification text, and the Section A title-search guidance, and through those same sources the Explore layer, the planning screen, and the downloaded assessment — with language in this substance: a title-company review can help identify recorded access rights (easements, plats, recorded documents), while legal interpretation of those records, whether a route actually connects, and whether it is physically usable may require additional verification. The recommendation to do the title search is kept; only the certainty claim changed. The full customer text and the download template were searched for “settles” and equivalent certainty phrasing about legal access; the two “settles” instances above were the only ones in customer text. Evidence: new test 52 — no customer surface or download contains the “settles whether you have a legal right” assertion or the word “settles” in a legal-access context, and the replacement language is present.
- Suite: 52 tests — the prior 49 kept green without weakening any assertion (no prior assertion was changed in this pass), plus tests 50–52. The build re-freezes immediately after this pass.
Demo — fixed-coordinate sample property, owner-approved
- What changed (the only change in this pass): the start screen's demo entry no longer geocodes an address. The old entry — “Use the demo property — Yentna River,” which ran a live geocoder lookup and landed the customer on a two-match choice between nearly identical results — is removed: its button, its geocoder call, and every customer-facing Yentna reference are gone. Yentna mentions remain only inside reviewer tools and changelog history (including the historical entries above, which describe earlier rounds as they were).
- The new demo entry: labeled exactly “Explore a Sample Remote Property — Alaska”, showing the exact coordinates it will assess: 61.938502, -151.834736 — the Matanuska-Susitna Borough-verified centroid of the owner's own parcel, Tract E, Friday Creek area (ground truth already validated by the owner). It is NOT presented as the Yentna geocoder location or as the same parcel as any geocoder result.
- Disclaimer line, beside the label and coordinates: “This is a demonstration using live public data — it is not a verified ownership or legal-access assessment.”
- Behavior: activating the entry runs the assessment DIRECTLY on those fixed coordinates with the normal live data fetches (parcel, map, climate) — no geocoder lookup, no match-selection step, and no confirmation gate for the demo (there is nothing ambiguous to confirm). The resulting report is a normal assessment of that point, with all standard labels, limitations, and evidence classifications.
- Unchanged: the ordinary address-search workflow — ambiguous address results still require the deliberate radio selection before a run, exactly as Round 6A built it; coordinate and parcel-ID entry are unchanged.
- Supporting adjustments forced by removing the demo path (nothing else changed): the start-screen address placeholder no longer uses the Yentna example (now “e.g. Talkeetna, Matanuska-Susitna Borough, AK”); the empty-input hint now names the new demo entry; the professional-guidance region label rendered in customer reports for the demo's area now reads “western Matanuska-Susitna Borough” instead of naming the river corridor (the guidance substance, region bounds, and its not-a-code-value labeling are unchanged) so that no customer report text mentions Yentna; and the reviewer live-integration check for geocoding now resolves a Talkeetna test address instead of the removed demo query (it is a reviewer tool, not part of the customer demo path).
- Adjusted assertions (only these, each describing the old demo mechanism): (1) test 30 — its name dropped “(demo path included)” and its detail dropped the sentence claiming the demo shortcut opens the same unselected, gated confirmation state as an address search; its address-gating assertions (no preselection, run disabled until a deliberate selection, chosen location restated) are unchanged and stay green. (2) The test-panel introduction's description of test 30 was updated to match. No other prior assertion was changed.
- New tests 53–56: the start screen shows the exact demo label and the exact coordinates; activating the demo starts a run at 61.938502, -151.834736 without presenting a match-selection step (geocoder and confirmation renderer spied, neither called); the demo disclaimer line is present; the address ambiguity gate still blocks runs until a selection (test 30, unchanged assertions); and no customer-facing text mentions Yentna (start screen, and a mocked assessment at the demo coordinates rendered through overview, Explore, planning, technical evidence, sources, and the download). Suite: 56 tests. The build re-freezes after this change.
Headline & logo — owner-directed
- Headline — 'Your land. Your vision. Your legacy.', owner-directed
- Logo — the app's brand lockup now matches the website (backcountryos.com), owner-directed: the website's mark (cream rounded tile, forest-green line icon) at about 30px beside the 'BackcountryOS' wordmark in 'Cormorant Garamond', Georgia, serif, weight 600, color #162A1E, letter-spacing .02em, about 1.2rem — on the start screen header and in the downloaded assessment's header. The previous in-app logo graphic and its 'Build Beyond the Grid' tagline treatment are removed from customer surfaces.
Round 10 — Briefing + appendix document redesign
- What changed (documents only — the assessment engine, evidence, and cautionary language are unchanged; the assessment remains free): the single paginated download is replaced by two downloads. The primary download is a 7-page customer briefing (“Download assessment briefing”): cover with a real OpenStreetMap-tile map image composited in the browser at download time (parcel polygon + point marker over the tiles, OSM attribution, not-a-survey caption; captioned schematic fallback), a property snapshot led by a dominant feasibility-gates panel (legal access and physical access unresolved) with confidence indicators rendered from the evidence labels, access & logistics (alternative-access block on this page only), climate / utilities / site development (off-grid guidance on this page only), development feasibility with the planning flow's structure selection carried through the property profile (or the four types as the pending decision), a prioritized verification checklist (gates first, each with what it resolves and the recommended action/owner), and a “Continue Your Project” closing page (Assess → Design the Project → Build the Budget → Plan the Execution → Connect and Build; platform stages labeled In Development, project services available for consultation now; no pricing anywhere; no “Founder-led” in the briefing). The secondary download (“Download full technical appendix”) is the complete Round 9 document retitled as the appendix, with its own cover line (“Technical Appendix — [property]”) and Page X of Y numbering; nothing from its evidence content is lost, and the Round 9 test assertions run against it via the buildDownload alias.
- Contact address (owner update): both documents use the dedicated BackcountryOS address chad@backcountryos.com — the briefing cover's “Project inquiries” line and the appendix cover/company block. The Green Industry address appears in neither downloaded document. In-app UI and the website are unchanged by this item.
- Tests: suite grows to 72 — tests 66–72 cover the briefing's exact 7-sheet count, the once-only placement of the alternatives block (page 3) and off-grid guidance (page 4), gates-first snapshot ordering, selected vs. pending structure on page 5, the cover map image + attribution + fallback + absence of “Founder-led” in the briefing, the appendix's full Round 9 content set under its retitle, and both download controls on the report view and planning screen; tests 62 and 64 updated only for the contact-email assertion. The build freezes after this round.
Capabilities still requiring authoritative data integrations
- Parcel boundaries & ownership — Mat-Su Borough cadastral attributes are now fetched where that service resolves (Round 4), but GIS polygons are inventoried boundaries, not a survey, and no other borough's service is integrated; parcel-ID lookup remains disabled.
- Legal access & easements — recorded plats and easement documents are linked, not searched (Round 4); title search remains a title-company product.
- Physical road connection, surface, weight limits & seasonal status — road authority / field verification.
- Utility service areas & connection terms — serving water, sewer, and electric providers.
- Engineering design values — jurisdiction-adopted codes, ASHRAE design conditions, local snow-load tables.
- Soils, percolation & foundation feasibility — on-site geotechnical and perc testing.
- Site-specific wildlife guidance — ADF&G / local guidance and on-site evidence.
Reviewer feedback
Direction matters more than polish at this stage. The questions that help most:
- Where does the corrected report still state more than its evidence supports?
- Are the withheld conclusions withheld in the right places — and is anything needlessly withheld?
- What's missing before this could support a real go / no-go decision on a parcel?
- Who else should see this?