# Scanned_20260730-1650 > [!privacy] Privacy-redacted working copy > Private-person names approved by the vault owner are replaced with `[PERSON REDACTED]`. The private source PDF and pre-redaction backup preserve the original wording. This notice governs over any general statement below describing transcription as exact or unchanged. ## Archival scope and method This note reconstructs **all 50 physical PDF pages** of `Scanned_20260730-1650.pdf`, including the front cover, blank and bleed-through leaves, pasted manufacturer labels, handwritten copies of regulatory identifiers, crossed-out telephone records, credential-bearing router and computer notes, drawings, narrative fragments, and duplicated close-up photographs of the same physical objects. The canonical notebook identity is the exact filename stem; **“Certs and Info” is retained only as a source alias derived from the cover**. Every page was inspected visually from its rendered scan rather than inferred from OCR. Except for explicit privacy redactions, quoted transcription preserves source spelling, capitalization, punctuation, line grouping, and meaningful crossings; uncertain readings are bracketed rather than silently normalized. Telephone numbers are replaced with `xxx-xxx-xxxx (see Scanned_20260730-1650.pdf, page N)`. Passwords, wireless keys, PINs, startup-security passwords, and password-equivalent account strings are replaced with `[REDACTED CREDENTIAL — see Scanned_20260730-1650.pdf, page N]`. Device serial numbers, IMEIs, ICCIDs, MAC addresses, model numbers, FCC identifiers, public domains, public business addresses, and non-secret technical identifiers remain because they are integral to the notebook’s function as a physical-device provenance ledger. Nothing recorded here was used, tested, authenticated, or submitted to any service. The research layer distinguishes **visible evidence**, **verified technical context**, **strong inference**, **plausible interpretation**, and **unresolved ambiguity**. The notebook contains consequential statements attributed to named or partially named people, including allegations of fraud, hacking, coercion, and violent speech. Those statements are preserved as historical notebook evidence; adjacency and quotation do not establish that the statements were true, that the named people made them, or that any threatened act occurred. ## Privacy-redacted source identity At the vault owner’s direction, a private person’s name and aliases have been replaced with `[PERSON REDACTED]` in transcription, analysis, navigation, and indexes. The original wording remains available only in the private source PDF and the pre-redaction backup. ## Knowledge-graph navigation [[Index - Master Chronology|Master Chronology]] · [[Index - People|People]] · [[Index - Company and Institution|Companies and Institutions]] · [[Index - Acronym Dictionary|Acronym Dictionary]] · [[Index - Technology and Product Lineage|Technology and Product Lineage]] · [[Index - Domain and URL Index|Domain and URL Index]] · [[Index - Device Inventory|Device Inventory]] · [[Index - Project and Concept|Projects and Concepts]] · [[Index - Pattern Ledger|Pattern Ledger]] · [[Index - Unresolved Names and Identifiers|Unresolved Names and Identifiers]] · [[Index - Notebook Sources|Notebook Sources]] ## Notebook-level orientation This notebook is best understood as a **certificate-and-identity field ledger for heterogeneous physical and virtual systems**. Its pages repeatedly move from a human-facing object name to the identifiers beneath it: a PlayStation Portable becomes a model, battery, FCC record, serial, and power-supply specification; a hotspot becomes an SSID, administrator endpoint, SIM, carrier band, IMEI, MAC address, and default gateway; a Linux live environment becomes `grub.cfg`, EFI graphics modules, `initrd`, GNOME services, a terminal profile UUID, and session permissions; a hotel room becomes a graph of telephones, wireless access points, occupancy controls, smart-lighting bridges, lamps, public-IP observations, and pasted compliance labels. The central question is not merely **what is this device?** but **which identity is authoritative, where does it sit in the control chain, and what physical or software evidence survives migration, reset, or dispute?** --- ## PDF page 1 — Front cover marked “Certs and Info!” **Source.** `Scanned_20260730-1650.pdf`, PDF page 1. **Visible page.** Black flexible cover with rounded upper corners and a slightly reflective, creased surface. White paint-marker lettering occupies the center. “ALL TERRAIN” is printed in small silver capitals near the lower edge. **Faithful transcription.** > "Certs > and > Info!" > "ALL TERRAIN" **Normalized linked entities.** [[Scanned_20260730-1650|Scanned_20260730-1650]]; [[Certificate and Device Identity Ledger|certificate and device identity ledger]]; [[All Terrain Notebook|ALL TERRAIN notebook]]. **Entity and technical context.** “Certs” most plausibly abbreviates **certifications** or **certificates**. The pages that follow support both meanings: physical compliance marks such as FCC, CE, UL, ETL, NOM, RoHS, Wi-Fi Certified, and product serial labels coexist with software-security and account material. **Whole-page reconstruction.** The cover accurately forecasts the notebook’s operating method. Instead of treating commercial names as sufficient identity, the author harvested the less visible attestations attached to objects: model numbers, radio approvals, electrical ratings, MAC addresses, software builds, boot paths, session profiles, and ownership or login records. “Info!” is broad, but the artifact is structurally a provenance notebook. **Evidentiary status.** The title and printed product wording are directly visible. The interpretation of “Certs” as a combined compliance/security category is a strong inference from the rest of the notebook. **Cross-notebook connections.** The cover gives an explicit name to the practice visible throughout [[Scanned_20260730-1802|Scanned_20260730-1802]], where bundle IDs, FCC markings, USB identities, and industrial devices were decomposed below their consumer names; [[Scanned_20260730-1659|Scanned_20260730-1659]] extends the same method into firmware, ASN, OID, and domain attribution. **Missed Signals and Open Leads.** Determine whether “Certs” originally meant regulatory certifications, digital certificates, professional certifications, or intentionally all three. The subsequent convergence suggests that the ambiguity may have been productive rather than accidental. ## PDF page 2 — Sony PSP, battery, and power-supply provenance board **Source.** `Scanned_20260730-1650.pdf`, PDF page 2. **Visible page.** Four pasted black manufacturer labels are outlined and annotated in white marker on the inside cover. The largest upper-left label is from a Sony PlayStation Portable; below it is a Sony battery label. A narrow damaged strip appears at upper right. A smaller lower-right block combines a date/inspection sticker with a Merryking switching-power-supply label. White captions identify owners or object roles. **Faithful transcription.** > "SONY® PSP-1001 > PSP™ (PlayStation®Portable) > DC 5V 1.2A > FCC ID AK8PSP1001B > IC 409B-PSP1001B > [additional certification and laser-compliance text] > SERIAL NO. FU6158659 6B > SONY COMPUTER ENTERTAINMENT INC. > MADE IN CHINA" > "SONY® > MODEL PSP-110 > BATTERY PACK 3.6V — 1800mAh > [multilingual caution and certification text] > 5914CWG > MADE IN CHINA" > "[PERSON REDACTED] > PSP" > "[uncertain: [PERSON REDACTED] USB]" > "PSP > Batt" > "CMG19 > C94465 > DOM 30/04/2020" > "Merryking > Switching power supply > MODEL: MKS-1301500 > INPUT: 100-240V~ 50/60Hz 0.8A > OUTPUT: 13V ⎓ 1500mA > [regulatory marks and polarity diagram] > MADE IN CHINA > MKX 1912" **Normalized linked entities.** [[Sony PlayStation Portable PSP-1000|Sony PSP-1001]]; [[Sony PSP-110 Battery|PSP-110 battery]]; [[Sony Computer Entertainment|Sony Computer Entertainment]]; [[Federal Communications Commission Identifier|FCC ID]]; [[Industry Canada Certification Number|IC number]]; [[Merryking Switching Power Supply|Merryking MKS-1301500]]; [[Device Label Harvesting|device-label harvesting]]; [PERSON REDACTED] [uncertain]. **Entity and technical context.** The PSP-1001 belongs to the original PSP-1000 family. Its pasted label preserves radio and laser-product certification, while the separate PSP-110 label preserves the removable battery’s chemistry, voltage, capacity, and safety status. The Merryking supply is not a PSP charger—the 13-volt output differs from the PSP label’s 5-volt input—so physical proximity should not be converted into electrical compatibility. **Whole-page reconstruction.** This is a miniature **physical asset registry** assembled directly from discarded or removed labels. Handwritten names attach social custody to technical identity: “[PERSON REDACTED] PSP” associates a person with the console, while “PSP Batt” distinguishes a separable component whose lifecycle can diverge from the host. The page’s deeper logic is component continuity: the consumer object, battery, adapter, serial, and owner are independent nodes that must be related rather than conflated. **Evidentiary status.** Model, serial, regulatory, and electrical data are visible on the pasted labels. “[PERSON REDACTED]” and “[uncertain: [PERSON REDACTED] USB]” are handwritten annotations whose relationship to the objects is not independently verified. The power supply is not asserted to belong to the PSP. **Cross-notebook connections.** The label-collage method recurs in [[Scanned_20260730-1230|Scanned_20260730-1230]] with Mac Pro chassis labels and in [[Scanned_20260730-1802|Scanned_20260730-1802]] with batteries, radio approvals, and industrial hardware. Across the corpus, removed labels function as durable identity tokens after devices are sold, lost, repaired, or disassembled. **Missed Signals and Open Leads.** Link the PSP serial and battery code to dated photographs, purchase records, or repair notes. Identify the object belonging to the Merryking adapter before associating it with any console or hotel device. ## PDF page 3 — Mesh Wi-Fi, loaned MiFi, Verizon router, and APN warning **Source.** `Scanned_20260730-1650.pdf`, PDF page 3. **Visible page.** Dotted page divided by horizontal strokes into three credential clusters. A long note runs vertically down the right margin. Usernames or passwords are written openly in the source and are redacted here. **Faithful transcription.** > "[uncertain: Roboril/Mesh] (wifi) > [REDACTED CREDENTIAL — see Scanned_20260730-1650.pdf, page 3] didnt connect" > "[PERSON REDACTED] Loaned > Hotspot (Mifi)" > "Verizon Router > pw: [REDACTED CREDENTIAL — see Scanned_20260730-1650.pdf, page 3]" > "Admin: (<<) > pw: [REDACTED CREDENTIAL — see Scanned_20260730-1650.pdf, page 3] > worst password > in history!!" > "It is advanced / advanced → Don’t Change APN settings. Located to cell tower." **Normalized linked entities.** [[Mobile Wi-Fi Hotspot|MiFi]]; [[Verizon Communications|Verizon]]; [[Access Point Name|APN]]; [[Mesh Wi-Fi|mesh Wi-Fi]]; [[Router Administrator Interface|router administrator interface]]; [PERSON REDACTED]. **Entity and technical context.** A MiFi or mobile hotspot joins a cellular wide-area network and republishes connectivity over Wi-Fi. An [[Access Point Name|APN]] identifies the carrier packet-data service and can determine routing, authentication, IP-family, and MMS behavior. The marginal warning therefore belongs to cellular provisioning, not ordinary Wi-Fi mesh configuration. **Whole-page reconstruction.** The page records three distinct access layers that were at risk of being collapsed into one: a mesh Wi-Fi network that failed to connect, a person-to-person loaned hotspot, and a Verizon-branded router with local administrator credentials. The emphatic criticism of the password indicates retrospective security awareness, while “Don’t Change APN settings” suggests fear that low-level carrier settings could strand or redirect the device. **Evidentiary status.** The access labels and warning are visible. The precise reading of the first network name is uncertain. “Located to cell tower” is notebook language and should not be treated as a technically precise geolocation claim. **Cross-notebook connections.** This page is a compact precursor to [[Scanned_20260730-1706#PDF page 5 — Mint-T-Mobile APN and MMS configuration|1706 page 5]], where APN parameters are preserved field by field, and to [[Scanned_20260730-1719#PDF page 6 — T-Mobile LTE cell identity and Wi-Fi Direct names|1719 page 6]], where radio-network identity is recorded after attachment. **Missed Signals and Open Leads.** Resolve the first mesh-network name from archived screenshots. Preserve carrier, SIM ICCID, hotspot model, firmware, APN profile, and date as separate evidence fields rather than relying on remembered ownership. ## PDF page 4 — Librem 5, Inseego hotspot, SIM provenance, and “Fyade” concern **Source.** `Scanned_20260730-1650.pdf`, PDF page 4. **Visible page.** Dense handwritten page with an underlined upper section about the Librem 5 and a lower narrative about a hotspot, its battery and SIM, carrier branding, and phones belonging to “the Girls.” **Faithful transcription.** > "Librem 5 phone > $700. > Suggested by [PERSON REDACTED] (secure phone)" > "Hotspot Info > Battery: ‘inseego’ > Sim: private ASN? and secure > because it runs on [uncertain: reuse]. > ‘Band 12’? T-mobile sim > but Verizon branded device, > looks older and exactly > like the one at [PERSON REDACTED]’s." > "So, that is two T-Mobile SIMS > from front / [PERSON REDACTED] and [PERSON REDACTED]. > Insisted on putting two T-mobile > Sims in the Girls phones with > Fyade installed practically by > force. Ask girls about it." **Normalized linked entities.** [[Purism Librem 5|Librem 5]]; [[Purism|Purism]]; [[PureOS|PureOS]]; [[Inseego|Inseego]]; [[T-Mobile US|T-Mobile]]; [[Verizon Communications|Verizon]]; [[LTE Band 12|Band 12]]; [[Autonomous System Number|ASN]]; [[Subscriber Identity Module|SIM]]; [[Fyade Software|Fyade]] [unresolved; possibly Fing]; [PERSON REDACTED]. **Entity and technical context.** Purism’s [[Purism Librem 5|Librem 5]] is a Linux-based smartphone running PureOS rather than Android or iOS; its defining privacy feature is a set of physical hardware switches controlling cellular, Wi-Fi/Bluetooth, and camera/microphone functions.[^purism-librem5][^purism-kill] [[Inseego|Inseego]] makes mobile-broadband hotspots and modems. An ASN belongs to an Internet routing organization, whereas a SIM carries subscription identity; “private ASN” is therefore either exploratory language or a conflation of network and subscriber layers. LTE Band 12 is a low-band cellular allocation used in the United States, but the page does not establish the hotspot’s exact radio profile. **Whole-page reconstruction.** The author was evaluating **security claims through provenance contradictions**. A product recommended as a “secure phone” sits beside a hotspot whose battery maker, SIM carrier, external branding, apparent age, and resemblance to another person’s device do not align cleanly. The lower paragraph moves from technical ambiguity into a personal allegation: the author believed SIMs and software had been pushed onto other people’s phones under pressure. That allegation is historically important to the notebook’s interpretive state but remains uncorroborated here. **Evidentiary status.** The Librem 5 recommendation, names, carrier labels, and concern are visible notebook evidence. Purism’s product architecture is independently verifiable. The claimed SIM chain, coercion, meaning of “Fyade,” and relation among the named people are unresolved notebook assertions. The vault owner recalls another note saying “maybe Fing,” but that separate wording has not yet been located in the integrated Markdown corpus. **Owner-supplied identity and relationship overlay.** The vault owner identifies “[PERSON REDACTED]” here as [PERSON REDACTED], also written elsewhere as [PERSON REDACTED] and associated with `[PERSON REDACTED]` / `[PERSON REDACTED]`. The owner describes him as former military and DoD-adjacent and states that he used [[SpiderOak|SpiderOak]] security on his phone. Those details are owner-supplied; this page itself documents neither SpiderOak nor the biographical claims. The corrected installed-software reading is **“Fyade.”** It may refer to Fing according to a separate owner-recalled note, but it should not be equated with [[FydeOS|FydeOS]] without stronger evidence. **Cross-notebook connections.** This page extends the corpus-wide question of **who claims a device before the user does**. Compare the reseller/enterprise-enrollment concern in [[Scanned_20260730-1802|Scanned_20260730-1802]], the carrier provisioning and SIM migration in [[Scanned_20260730-1706|Scanned_20260730-1706]], and the Android partition/update identity in [[Scanned_20260730-1719|Scanned_20260730-1719]]. **Missed Signals and Open Leads.** Locate the separate “maybe Fing” note and identify “Fyade” by package name, signing certificate, installer source, version, and permissions. Reconstruct each SIM-to-device assignment from carrier records and handset ICCIDs rather than memory. Do not infer coercion or malicious intent without corroborating testimony or device evidence. ## PDF page 5 — Samsung Odin flashing and CSC behavior **Source.** `Scanned_20260730-1650.pdf`, PDF page 5. **Visible page.** Dotted page headed “Odin Flash software / [PERSON REDACTED]: NOTES.” The lower portion records an Odin version and the Samsung firmware slots BL, AP, CSC, and HOME_CSC. **Faithful transcription.** > "Odin Flash software > [PERSON REDACTED]: NOTES" > "[PERSON REDACTED]’s Version is > special in that it > will force write over > any ROM no matter > what." > "Oden 3.14." > "use BL, AP, and > CSC at same time" > "CSC, wipe user data > Home CSC use same > user data [uncertain: without]" **Normalized linked entities.** [[Samsung Odin|Odin]]; [[Samsung Firmware Package|Samsung firmware package]]; [[Bootloader Firmware Slot|BL]]; [[Application Processor Firmware Slot|AP]]; [[Consumer Software Customization|CSC]]; [[HOME_CSC|HOME_CSC]]; [[Read-only Memory Image|ROM]]; [PERSON REDACTED]. **Entity and technical context.** Odin is a Windows utility used in Samsung service and enthusiast workflows to write signed firmware packages to Galaxy devices. The conventional package fields are BL for bootloader material, AP for the main system/application-processor package, and CSC for regional/carrier configuration; HOME_CSC is commonly selected when attempting to preserve user data, whereas the ordinary CSC package normally performs a wipe. Samsung has not published a comprehensive public technical specification for Odin, so community documentation must be treated as operational rather than authoritative.[^odin-fields] **Whole-page reconstruction.** The page preserves a **firmware overwrite recipe and a claim of exceptional write authority**. The ordinary BL/AP/CSC notes are consistent with established Samsung flashing practice. The assertion that “[PERSON REDACTED]’s Version” can force-write “any ROM no matter what” is not verified and may reflect a patched tool, an engineering build, a permissive device state, or an exaggerated explanation. The distinction matters because the real authority lies in bootloader state, signature enforcement, anti-rollback fuses, partition layout, and package compatibility—not merely in the front-end executable. **Evidentiary status.** The operational notes are visible. The generic CSC/HOME_CSC distinction is technically plausible. The existence, origin, and powers of a special version are unverified. **Cross-notebook connections.** This page pairs with the Galaxy Tab S7 firmware strings in [[Scanned_20260730-1659#PDF page 4 — Galaxy Tab S7 firmware UDisks2 and cellular identifiers|1659 page 4]] and with bootloader/firmware-sovereignty research in [[Scanned_20260730-1719|Scanned_20260730-1719]]. It reveals the recurring desire to separate a vendor’s installation interface from the cryptographic and hardware boundaries underneath it. **Missed Signals and Open Leads.** Recover a hash, file name, source archive, and version metadata for the alleged special Odin build without executing it. Record device model, binary revision, bootloader lock, Knox state, anti-rollback level, and exact firmware package before drawing conclusions about “force write” capability. ## PDF page 6 — New MiFi provisioning and administrator credentials **Source.** `Scanned_20260730-1650.pdf`, PDF page 6. **Visible page.** Dotted page dated “2/14.” A top block records a new hotspot and its primary SSID; a horizontal rule separates the administrator endpoint and password below. **Faithful transcription.** > "2/14 > New > MiFi Hotspot > primary ssid: > [PRIVATE NAME REDACTED] > [REDACTED CREDENTIAL — see Scanned_20260730-1650.pdf, page 6]" > "Admin Pw > my.jetpack > [REDACTED CREDENTIAL — see Scanned_20260730-1650.pdf, page 6]" **Normalized linked entities.** [[Mobile Wi-Fi Hotspot|MiFi hotspot]]; [[Service Set Identifier|SSID]]; [[Verizon Jetpack|Jetpack]]; [[Router Administrator Interface|administrator interface]]; [PERSON REDACTED]; [[Person - Bryant McGill|Bryant McGill]]. **Entity and technical context.** SSID names are human-facing Wi-Fi network identifiers; the administrator interface controls cellular, Wi-Fi, security, and device-management state. Verizon has used “Jetpack” as a brand for mobile hotspots, and local management hostnames such as `my.jetpack` are intended to resolve only while connected to the device. **Whole-page reconstruction.** This is a complete provisioning snapshot in miniature: date, object class, primary network name, wireless secret, management endpoint, and administrator secret. The page’s value is not the passwords themselves—which are suppressed—but the evidence that the hotspot had both a user-facing Wi-Fi identity and a deeper management identity. **Evidentiary status.** The date and labels are visible. The year is not written on this page, but adjacent pages explicitly dated February 2021 make February 14, 2021 the strongest contextual reading. **Cross-notebook connections.** The dual identity of SSID versus management account recurs in router pages 27–30 below and in the account/phone migration ledgers of [[Scanned_20260730-1659|Scanned_20260730-1659]]. **Missed Signals and Open Leads.** Add hotspot make/model, IMEI, ICCID, firmware, carrier account, APN, MAC addresses, and the direction of any SIM transfer. Secrets should live in a controlled vault while the notebook retains only stable identifiers and recovery context. ## PDF page 7 — ASUS ZenScreen MB16AMT and secondary hardware labels **Source.** `Scanned_20260730-1650.pdf`, PDF page 7. **Visible page.** A wide spread containing a large white ASUS product label at upper left, a long black regulatory strip below, a smaller vertical black label at lower left, and a damaged black adhesive or tamper label at lower right. The ASUS label is the only fully attributable object. **Faithful transcription.** > "Designed by ASUS > Assembled in China > LCD Monitor > Model MB16AMT > Rated 5-9V ⎓ 2.0A > ASUSTeK COMPUTER INC. > [manufacturer addresses and regulatory text] > Version No.: MB16AMT > Manufactured Date: Sep. 2020 > Serial No.: L9LMTF112813" > "Contains FCC ID: [uncertain: AKBM18DA01] > [additional regulatory identifiers and marks]" > "[Lower-left black label: partial SONY/model text, not safely complete.]" > "[Lower-right damaged adhesive label: no safely recoverable text.]" **Normalized linked entities.** [[ASUS ZenScreen Touch MB16AMT|ASUS ZenScreen Touch MB16AMT]]; [[ASUSTeK Computer|ASUSTeK Computer]]; [[Federal Communications Commission Identifier|FCC ID]]; [[Portable Monitor|portable monitor]]; [[Touchscreen|10-point touchscreen]]. **Entity and technical context.** ASUS describes the [[ASUS ZenScreen Touch MB16AMT|MB16AMT]] as a 15.6-inch Full HD portable IPS monitor with ten-point capacitive touch, a built-in 7800 mAh battery, USB-C, and micro-HDMI connectivity.[^asus-mb16amt] The date and serial on the physical label establish this individual unit’s manufacturing identity more directly than the product page. **Whole-page reconstruction.** The author retained the monitor’s rear label as an **object passport**. Portable displays occupy an ambiguous place between peripheral and autonomous device: touch capability, battery, USB data, video input, firmware, and radio-bearing subassemblies can each create distinct attack, compatibility, and ownership surfaces. The separate lower labels may have belonged to accessories or unrelated equipment; the layout records colocation, not proven assembly. **Evidentiary status.** The MB16AMT model, date, and serial are visible. The FCC code and secondary labels remain partially uncertain because of scale and damage. **Cross-notebook connections.** The page fits the collection’s inventory of displays, Macs, mobile devices, and edge peripherals. It also anticipates the hotel-room infrastructure later in this notebook, where every apparently simple furnishing is treated as a networked or electrically governed component. **Missed Signals and Open Leads.** Associate the serial with host USB descriptors, display EDID, firmware version, touch-controller identity, and purchase history. Identify the lower labels only from a higher-resolution original or surviving hardware. ## PDF page 8 — `grub.cfg`, ARKH narrative, YouTube audience, and alleged financial dispute **Source.** `Scanned_20260730-1650.pdf`, PDF page 8. **Visible page.** Dense dotted page. Upper left contains GRUB module notes; upper right says the “audience is Kids.” Most of the page is a narrative attributed to [PERSON REDACTED] and “[PERSON REDACTED],” with quoted words and a final emphatic marginal line. **Faithful transcription.** > "grub.cfg > insmod > - efi_gop > efi_uga" > "audience is Kids" > "According to [PERSON REDACTED] and > ‘[PERSON REDACTED].....’" > "The ‘Kid’ they want to ‘destroy’, > who ‘ripped them off’ for $100K > and who owes them $14m > equity, is a ‘youtube’ star > who live streams > He had alex design a board for > his ‘project’. But he embezzelled > money by using their brand > and [REDACTED] Brand > to ‘raise money.’ He is > a narcissistic fraud who > ‘cries’ at every REDACTED..." > "[uncertain: Misrepresentation ed post!!]" **Normalized linked entities.** [[GNU GRUB|GRUB]]; [[grub.cfg|grub.cfg]]; [[EFI Graphics Output Protocol|efi_gop]]; [[EFI Universal Graphics Adapter|efi_uga]]; [[YouTube|YouTube]]; [REDACTED]; [[ARKH Project|ARKH]] [provisional]; [PERSON REDACTED]; [[Unverified Financial Allegation|unverified financial allegation]]. **Entity and technical context.** GNU GRUB is a modular boot loader. Its `insmod` command loads modules, and the GRUB manual identifies EFI GOP and UGA graphics modules as firmware display mechanisms used in EFI environments.[^grub-manual] The narrative below is not technically connected to those lines by an explicit arrow, but the next pages link “ARCH,” `vmlinuz`, `initrd`, and a project called ARKH. **Whole-page reconstruction.** Two inquiries are superimposed. One is concrete boot engineering: how an EFI machine displays and loads a live Linux environment. The other is a volatile account of a business or project dispute involving a young online personality, alleged misuse of brands, equity, fundraising, and a designed board. The page may record what the author was told while inspecting a computer or project environment. Its emotional intensity makes source separation essential: the quotes are evidence of the notebook’s information state, not proof of the accusations. **Evidentiary status.** The GRUB strings and narrative are visible. The identity of “the Kid,” exact speakers, sums, project, board, and alleged conduct are not independently verified. No current public source located in research securely tied `arkh.com`, `arkh-funds.com`, the quoted product language, [REDACTED], and the named people into one attributable entity. **Cross-notebook connections.** The page echoes the corpus’s recurring collision of technical troubleshooting with interpersonal and institutional claims. In [[Scanned_20260730-1659|Scanned_20260730-1659]], process names and network identifiers were preserved precisely because narrative interpretations could otherwise outrun evidence. **Missed Signals and Open Leads.** Recover the original conversation, project pitch, corporate filings, source code, board design, fundraising pages, and dated domain captures. Maintain separate evidence graphs for the GRUB environment, ARKH project, named people, [REDACTED] references, and financial allegations until corroborated. ## PDF page 9 — Continuation of ARKH dispute and violent quoted language **Source.** `Scanned_20260730-1650.pdf`, PDF page 9. **Visible page.** Full dotted page continuing the previous narrative. Several clauses appear in quotation marks. “ARCH” is large and centered near the lower half; `vmlinuz` and an ARCH-like fragment are written beside it. **Faithful transcription.** > "He is ‘untraceable’ and > a gunner. ‘([PERSON REDACTED]) would like to > just bury him alive (Kill him) > or keep him happy. They are > afraid he will use his platform > to hurt their operation...." > "Not sure what to do with > him. He could have an > accident or fucking Kill > himself. what ever...." > "His project is called > ~ ARCH ~ > vmlinuz? / ARCH? > it is worthless like him. > He still has their money > in an account > ‘... just kill him - Just [uncertain: joking]’" **Normalized linked entities.** [[ARKH Project|ARKH/ARCH project]] [uncertain]; [[Linux Kernel Image|vmlinuz]]; [[Arch Linux|Arch Linux]]; [[Threat Language in Source Records|threat language]]; [PERSON REDACTED]; [[Unverified Financial Allegation|unverified financial allegation]]. **Entity and technical context.** `vmlinuz` conventionally names a compressed Linux kernel image. “ARCH” could denote [[Arch Linux|Arch Linux]], an independently named project, an architecture label, or a phonetic spelling of ARKH. The page does not justify collapsing those possibilities. **Whole-page reconstruction.** The notebook preserves disturbing language about killing or an “accident,” mixed with strategic concern about a person’s online platform and money allegedly remaining in an account. The final qualification may read “Just joking,” but it is uncertain and does not erase the archival significance of the preceding text. At the same time, the insertion of `vmlinuz` beside “ARCH” shows the author attempting to determine whether a project name corresponded to actual Linux boot artifacts found on a computer. **Evidentiary status.** The violent phrases are visible historical source text. Speaker attribution, intent, target identity, seriousness, and surrounding context are unresolved. The page is not evidence that violence occurred or that any named person made a threat. **Cross-notebook connections.** This is a case where the project’s evidentiary discipline is especially important. The notebook’s technical strings can be independently evaluated; the social narrative requires corroboration. Similar separation between telemetry and testimony becomes a major concern in later corpus writings and in the device-forensics pages of [[Scanned_20260730-1719|Scanned_20260730-1719]]. **Missed Signals and Open Leads.** Preserve the source safely and locate contemporaneous messages, recordings, witness accounts, and dates. Do not infer criminal intent from the notebook alone. Resolve whether “ARCH,” “ARKH,” and the Linux distribution were one object or three adjacent associations. ## PDF page 10 — `arkh.com`, spatial-data IoT, biometrics, and haptic interaction **Source.** `Scanned_20260730-1650.pdf`, PDF page 10. **Visible page.** Dotted page with two domains at top, “ArchLinux?” circled at left, and an underlined “IOT & ICE” heading. The lower two-thirds contain a quoted slogan and feature description. **Faithful transcription.** > "arkh.com [alex had me load] > arkh-funds.com" > "ArchLinux?" > "IOT & ICE" > "‘Revealing the world of > Secrets around you....’" > "ARKH Spatial Data / IOT" > "ecosystem running on > connected hub devices. Engineered > to seamlessly integrate users > with their technology. > ‘haptic feedback’ > biometrics; > user hand model > tracking > (3D touch)" **Normalized linked entities.** [[arkh.com|arkh.com]]; [[arkh-funds.com|arkh-funds.com]]; [[ARKH Project|ARKH]]; [[Arch Linux|Arch Linux]]; [[Internet of Things|IoT]]; [[Spatial Data Infrastructure|spatial data]]; [[Haptic Feedback|haptic feedback]]; [[Biometrics|biometrics]]; [[Hand Tracking|hand tracking]]; [[3D Touch|3D touch]]; [[Connected Hub|connected hub]]; [PERSON REDACTED]. **Entity and technical context.** The feature language describes an immersive or augmented interaction system that combines spatial data, connected hubs, body/hand modeling, biometrics, and tactile feedback. Those components are technologically coherent: modern spatial-computing systems fuse sensors, user models, geospatial or environmental data, and haptic output. However, web research did not establish an authoritative historical page connecting both handwritten domains to a specific company or product. `arkh-funds.com` should not be confused automatically with ARK Investment Management or its current fund sites. **Whole-page reconstruction.** This page converts the interpersonal dispute into a product ontology. The author was not merely noting a website; he was extracting a proposed architecture: **distributed hub devices reveal hidden spatial information and mediate the user through biometric hand tracking and haptic feedback**. The circled “ArchLinux?” indicates an effort to test whether the project’s name and its runtime substrate were related. The words “alex had me load” suggest direct installation or browsing activity but do not establish what was loaded or on which device. **Evidentiary status.** Domains and feature phrases are visible. Their historical ownership, product maturity, funding, and relationship to Arch Linux remain unresolved. The technology synthesis is a strong interpretation of the written feature set, not validation of the project’s claims. **Cross-notebook connections.** The page strongly anticipates the **universal object interaction** intuition reconstructed in [[Scanned_20260730-1802|Scanned_20260730-1802]]: objects expose hidden identity, state, and capabilities through an intermediary semantic layer. It also foreshadows later interest in spatial computing, digital twins, and machine-mediated environments. **Missed Signals and Open Leads.** Recover archived DNS, WHOIS, TLS certificates, website captures, package names, binaries, and investor materials for both domains as of early 2021. Search the larger corpus for the exact slogan and the pair “IOT & ICE.” Preserve the possibility that `ICE` was a product acronym rather than U.S. Immigration and Customs Enforcement. ## PDF page 11 — LiDAR/spatial-data note and suspected live Arch boot environment **Source.** `Scanned_20260730-1650.pdf`, PDF page 11. **Visible page.** Dotted page divided by a horizontal rule. The upper block continues the prior narrative and names “Lidar Spatial Data” and “Robots.” The lower block records a theory that hacked computers run virtual machines and copies a GRUB/initrd path. **Faithful transcription.** > "‘The kid is afraid > to have a REDACTED > with [PERSON REDACTED] at his > building.’" > "Lidar Spatial Data > ‘Robots’" > "Hacked Computers all run > some form of VM > - ARCH > ro.uder > [uncertain mark] > initrd ‘called’ from grub.cfg > is ‘Live!!’ and generated in > real-time. [crossed/uncertain text] > initrd /live/initrd[uncertain: {ARCH3}.img]" **Normalized linked entities.** [[LiDAR|LiDAR]]; [[Spatial Data|spatial data]]; [[Robot|robots]]; [[Virtual Machine|virtual machine]]; [[Arch Linux|Arch Linux]]; [[Initial RAM Filesystem|initrd/initramfs]]; [[GNU GRUB|GRUB]]; [[Live Linux System|live Linux system]]; [PERSON REDACTED]. **Entity and technical context.** [[LiDAR|LiDAR]] measures distance by timing reflected laser light and is widely used for spatial mapping and robotics. A Linux `initrd` or initramfs supplies early userspace during boot; on Arch systems, `mkinitcpio` is a standard tool for generating initramfs images, while `archiso` builds live ISO/USB environments.[^mkinitcpio][^archiso] A GRUB configuration can name a prebuilt initramfs image, but the existence of `/live/initrd...img` does not mean it was generated “in real-time” during every boot. **Whole-page reconstruction.** The author was trying to reconcile a product narrative about spatial data and robots with a concrete boot trace discovered on a computer. The phrase “Hacked Computers all run some form of VM” is a broad hypothesis; the copied `/live/` path more specifically suggests a bootable or forensic Linux environment. A live operating system can leave the installed disk untouched, provide consistent tools, and run inside a VM, but none of those properties by itself proves compromise. **Evidentiary status.** The copied strings and theory are visible. The interpretation of the underlying machine as hacked, virtualized, or dynamically generating an initrd remains unverified. `ro.uder` and the image name are not safely resolved. **Cross-notebook connections.** The page is an early form of the **substrate-versus-appearance** inquiry found across [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1719|Scanned_20260730-1719]]: the desktop appearance may be GNOME or Chromium, while the authoritative state lies in the bootloader, kernel, initramfs, mount graph, and hypervisor. **Missed Signals and Open Leads.** Recover the entire `grub.cfg`, boot-medium label, kernel command line, initramfs hash, filesystem layout, hypervisor process list, and UEFI boot entries. Separate evidence of a live system, evidence of virtualization, and evidence of unauthorized access. ## PDF page 12 — “Hacker Tool / Virus?” and `vmlinuz` hypothesis **Source.** `Scanned_20260730-1650.pdf`, PDF page 12. **Visible page.** Very sparse dotted page with four short centered lines. The final word or marks after “Future” are faint. **Faithful transcription.** > "Hacker Tool / Virus? > VMLINUX > or I.C.E - I.O.T > Future [uncertain marks]" **Normalized linked entities.** [[Linux Kernel Image|vmlinux/vmlinuz]]; [[Malware|virus]]; [[Hacker Tool|hacker tool]]; [[Internet of Things|IoT]]; [[I.C.E. Acronym|I.C.E.]] [unresolved]. **Entity and technical context.** `vmlinux` normally refers to an uncompressed Linux kernel image containing symbols; `vmlinuz` usually refers to a compressed bootable kernel. Neither is inherently a hacking tool or virus. The preceding pages make it possible that the handwritten “VMLINUX” is a normalization attempt after seeing `vmlinuz` in a boot configuration. **Whole-page reconstruction.** This is an epistemic checkpoint rather than a conclusion. The author had encountered unfamiliar boot artifacts in an environment associated—rightly or wrongly—with a disputed IoT/spatial project and was testing competing classifications: ordinary Linux kernel, dual-use “hacker tool,” malware, or product component. The question mark is significant and should be preserved. **Evidentiary status.** Visible evidence is limited to the four lines. No binary, hash, behavior, antivirus result, or process provenance is attached. **Cross-notebook connections.** The same classification problem appears repeatedly in [[Scanned_20260730-1659|Scanned_20260730-1659]], where normal Apple services, launch daemons, and package names were recorded beside suspected persistence mechanisms. The later notebook demonstrates why **unfamiliarity is not anomaly evidence** without provenance and behavior. **Missed Signals and Open Leads.** Determine whether the source string was `vmlinux`, `vmlinuz`, or a product name. Acquire the file hash, ELF metadata, signature, package owner, build ID, and boot reference before classifying it. ## PDF page 13 — [PERSON REDACTED], Canadian keyboard, and terminal profile metadata **Source.** `Scanned_20260730-1650.pdf`, PDF page 13. **Visible page.** Dotted page headed with a name and arrow. A long sequence of zeros follows. The page then records keyboard locale, a terminal/shell discovery, a profile ID that resembles a UUID, compatibility, delete-key behavior, encoding, and menu accelerator. **Faithful transcription.** > "→ [PERSON REDACTED] - > [long sequence of zeros]" > "Canadian Multilingual, > Keyboard" > "Terminal - Shell (Discovered on PC)" > "General" > "Profile ID: > [uncertain: b1dacc9dd-5262-4d8d- > a863-c897e6d979b9]" > "Compatibility: Ascii Del > delete key: Escape sequence. > encoding: UTF-8 Unicode" > "Menu accelerator key F10" **Normalized linked entities.** [PERSON REDACTED]; [[Canadian Multilingual Standard Keyboard|Canadian Multilingual keyboard]]; [[Terminal Emulator|terminal emulator]]; [[Command Shell|shell]]; [[Universally Unique Identifier|UUID]]; [[ASCII DEL|ASCII DEL]]; [[Escape Sequence|escape sequence]]; [[UTF-8|UTF-8]]; [[Unicode|Unicode]]; [[Menu Accelerator Key|F10]]. **Entity and technical context.** These fields closely resemble a graphical terminal emulator’s profile preferences. Terminal profiles commonly preserve locale and keyboard behavior, encoding, cursor/scroll settings, and a UUID-like profile identifier. `ASCII DEL` is byte 0x7F; terminal applications can map Backspace/Delete either to that byte or to multi-byte escape sequences, a compatibility distinction inherited from physical terminals. **Whole-page reconstruction.** The author was attempting to turn a discovered shell into a stable forensic object. A profile UUID, keyboard layout, encoding, and delete-key behavior are not user-visible branding; they are environmental fingerprints that can explain why copied commands, credentials, or control characters behave differently across machines. The name “[PERSON REDACTED]” may identify a person associated with the discovery, but the page does not state whether he was the user, owner, source, or merely a research target. **Evidentiary status.** The settings are visible; the UUID is partly uncertain because the first group appears to contain an extra character. No application name is written. Identity and ownership implications are unresolved. **Cross-notebook connections.** This page is a semantic companion to the Linux user/session pages 45–47 below and to [[Scanned_20260730-1706|Scanned_20260730-1706]], where hostnames, users, shells, and administrator groups are treated as identity layers rather than incidental strings. **Missed Signals and Open Leads.** Identify the terminal application by matching field names and profile-schema structure; recover its configuration file, creation/modification timestamps, shell command, working directory, and host account. Do not bind the profile to [PERSON REDACTED] without corroboration. ## PDF page 14 — GNOME accessibility, D-Bus, dconf, Chromium GPU process, and live-ISO GRUB path **Source.** `Scanned_20260730-1650.pdf`, PDF page 14. **Visible page.** Upper-left corner of a two-page spread contains a compact process/path list. The remainder, including the facing page, is blank dotted paper. **Faithful transcription.** > "at-spi2-registryd > dbus-daemon > dconf-service > ‘gnome’ > chromium --type=gpu-process" > "/isodevice/boot/grub/grub.cfg" **Normalized linked entities.** [[Assistive Technology Service Provider Interface|AT-SPI2]]; [[D-Bus|D-Bus]]; [[dconf|dconf]]; [[GNOME|GNOME]]; [[Chromium|Chromium]]; [[GPU Process|GPU process]]; [[GNU GRUB|GRUB]]; [[ISO Device Mount|/isodevice]]. **Entity and technical context.** `at-spi2-registryd` is part of GNOME’s accessibility infrastructure; `dbus-daemon` provides interprocess messaging; `dconf-service` supplies GNOME settings; and Chromium isolates graphics work in a process labeled `--type=gpu-process`. `/isodevice/boot/grub/grub.cfg` is characteristic of a system booted from or retaining access to an ISO-backed medium. **Whole-page reconstruction.** The list substantially clarifies pages 11–12. Rather than an unidentified “virus” process inventory, it resembles a normal GNOME/Chromium desktop running from a live or ISO-derived Linux environment. The author had located both the user-session services and the underlying boot configuration. This is precisely the kind of evidence that can correct an initial anomaly hypothesis: unfamiliar process names are mutually coherent components of one desktop stack. **Evidentiary status.** Process names and path are visible. The originating command, timestamps, executable paths, package ownership, and system distribution are not preserved. **Cross-notebook connections.** [[Scanned_20260730-1706|Scanned_20260730-1706]] later expands this method into Ubuntu, X11, system information, disk images, and network protocols. This page is an early **layered stack snapshot**: boot medium → GRUB → GNOME configuration buses → browser GPU subprocess. **Missed Signals and Open Leads.** Recover `ps`, `/proc`, package-manager, mount, and boot logs. Verify whether `/isodevice` came from Ubuntu’s live-media conventions, another derivative, or a custom image. ## PDF page 15 — Blank dotted leaf with top-edge bleed-through **Source.** `Scanned_20260730-1650.pdf`, PDF page 15. **Visible page.** Nearly blank dotted paper. Faint dark transfer or bleed-through is visible near the upper edge; no intentional marks can be read. **Faithful transcription.** > "[No intentional legible text. Faint reverse transfer at upper edge.]" **Normalized linked entities.** [[Blank Notebook Page|blank page]]; [[Bleed-through|bleed-through]]. **Whole-page reconstruction.** The page preserves the physical spacing between the live-Linux notes and the dated personal entry on page 17. It should not be silently omitted or treated as an OCR failure. **Evidentiary status.** Visible physical evidence only. **Cross-notebook connections.** Blank and transfer pages recur throughout the collection and help distinguish intentional duplication from recto-verso impressions, as documented explicitly in [[Scanned_20260730-1802|Scanned_20260730-1802]]. **Missed Signals and Open Leads.** None beyond checking whether a higher dynamic-range scan reveals an erased pencil note. ## PDF page 16 — Blank dotted leaf **Source.** `Scanned_20260730-1650.pdf`, PDF page 16. **Visible page.** Clean dotted page with a few tiny incidental specks and no deliberate writing or attached object. **Faithful transcription.** > "[No intentional legible text.]" **Normalized linked entities.** [[Blank Notebook Page|blank page]]. **Whole-page reconstruction.** This is a genuine blank physical leaf within the notebook sequence. **Evidentiary status.** Visible physical evidence only. **Cross-notebook connections.** Preserving it maintains exact PDF-to-notebook page correspondence for future citation. **Missed Signals and Open Leads.** None. ## PDF page 17 — Dated Facebook note, conspiracy videos, and perceived threat **Source.** `Scanned_20260730-1650.pdf`, PDF page 17. **Visible page.** Sparse dotted page with a dated handwritten paragraph in the upper quarter and a small pasted blue image below. The image appears to be a reduced version or companion to the larger blue graphic on page 18. **Faithful transcription.** > "2/14/21 FB 9.3m > 3 time for conspiracy > videos; but no time > for discussing a plot > against her or the > potential threat at our > [uncertain: papers];" > "[Small blue printed image; no legible text.]" **Normalized linked entities.** [[Facebook|Facebook]]; [[Conspiracy Video|conspiracy videos]]; [[Perceived Threat|perceived threat]]; [[Visual Insert|pasted blue image]]. **Entity and technical context.** “FB 9.3m” could record a Facebook time, metric, video length, audience count, or account statistic; the page does not define the unit. The phrase “a plot against her” is a personal concern rather than a technical indicator. **Whole-page reconstruction.** This page timestamps the notebook’s emotional and investigative context to February 14, 2021. The author contrasts attention given to conspiracy media with the absence of discussion about a personally perceived plot or threat. The small blue image may have served as a mnemonic or symbolic separator, but no secure identification is possible. **Evidentiary status.** The date and general wording are visible. The first word of the second line and the final noun are uncertain. No underlying plot, threat, or Facebook metric is established by the page. **Cross-notebook connections.** The page shows why later notebook practice increasingly sought objective identifiers—files, builds, MACs, labels, dates—alongside narrative concern. It is a bridge between the charged testimony on pages 8–12 and the highly material device evidence that follows. **Missed Signals and Open Leads.** Locate the referenced Facebook item, its exact timestamp/metric, and any contemporaneous messages discussing the threat. Keep media consumption, subjective concern, and independently documented events as separate evidence classes. ## PDF page 18 — Full-page blue printed or rubbed spatial-animal graphic **Source.** `Scanned_20260730-1650.pdf`, PDF page 18. **Visible page.** Beige rectangular insert filling nearly the entire scan. A cyan-blue graphic depicts a large vertically oriented animal-like or mask-like form, plausibly an elephant or mammoth profile with a long central trunk, surrounded by blocky architectural or glyph-like shapes. Edges and line density suggest a stamp, rubbing, photocopied linocut, or low-resolution print rather than handwriting. **Faithful transcription.** > "[No legible text. Cyan-blue figurative graphic on beige paper.]" **Normalized linked entities.** [[Unidentified Blue Graphic|unidentified blue graphic]]; [[Printed Insert|printed insert]]; [[Elephant Iconography|elephant-like iconography]] [possible]. **Whole-page reconstruction.** The insert is preserved as a visual artifact rather than forced into a logo identification. Its repetition at miniature scale on page 17 indicates intentional placement or copying. In the immediate notebook sequence it may mark a psychological, project, or interpersonal association, but no written caption establishes meaning. **Evidentiary status.** The graphic’s visible form and color are direct evidence. Subject identification, artist, organization, and symbolism are unresolved. **Cross-notebook connections.** This page belongs to the collection’s iconographic layer: stickers, QR codes, labels, diagrams, and drawings often retain associations that text alone cannot recover. **Missed Signals and Open Leads.** Perform reverse-image search only from a clean crop if provenance becomes important. Compare the miniature on page 17 and any surviving physical stamp, book, packaging, or correspondence. ## PDF page 19 — Blank leaf with ink transfer and mirrored bleed-through **Source.** `Scanned_20260730-1650.pdf`, PDF page 19. **Visible page.** Mostly blank dotted paper. A small vertical cluster of black transfer marks sits near the center; faint mirrored writing from the reverse is visible at right. **Faithful transcription.** > "[No intentional legible text. Ink transfer near center and reverse-page bleed-through at right.]" **Normalized linked entities.** [[Ink Transfer|ink transfer]]; [[Bleed-through|bleed-through]]; [[Blank Notebook Page|blank page]]. **Whole-page reconstruction.** The marks are physical consequences of notebook use rather than a separate textual entry. **Evidentiary status.** Visible physical evidence only. **Cross-notebook connections.** As with adhesive impressions in [[Scanned_20260730-1802|Scanned_20260730-1802]], this page demonstrates the importance of preserving recto-verso materiality. **Missed Signals and Open Leads.** Align the transfer with adjacent pages if reconstructing the notebook’s original closed-page pressure pattern. ## PDF page 20 — NETGEAR Nighthawk M1 identity label **Source.** `Scanned_20260730-1650.pdf`, PDF page 20. **Visible page.** Close-up of a single white manufacturer label attached to dotted paper. Barcodes, identifiers, and the product name are sharply visible. **Faithful transcription.** > "NETGEAR® MR1100 > SKU: MR1100-100NAS > UPC: 6 06449 13673 9 > TA: 100-22865-01R13 > IMEI: 015240000646450 > SN: 5K1513NN50A6E > Nighthawk M1 > MAC: 44A56EEDA96C > Made in Taiwan" **Normalized linked entities.** [[NETGEAR Nighthawk M1 MR1100|NETGEAR Nighthawk M1 MR1100]]; [[International Mobile Equipment Identity|IMEI]]; [[Media Access Control Address|MAC address]]; [[Stock Keeping Unit|SKU]]; [[Universal Product Code|UPC]]; [[Device Serial Number|serial number]]. **Entity and technical context.** NETGEAR’s MR1100 is a mobile LTE router/hotspot that shares cellular connectivity with Wi-Fi devices and includes Ethernet, USB, removable battery, and SIM-based operation.[^netgear-mr1100] The label simultaneously identifies commercial configuration (`SKU`), cellular hardware (`IMEI`), local network interface (`MAC`), manufacturing unit (`SN`), and retail packaging (`UPC`). **Whole-page reconstruction.** This is one of the notebook’s purest examples of **multi-namespace object identity**. The same hotspot appears differently to the carrier, Wi-Fi clients, manufacturer support, retailer, and owner. Retaining all identifiers allows those systems to be reconciled after a SIM move, firmware reset, account dispute, or loss. **Evidentiary status.** All quoted identifiers are visible on the label. The page does not identify the subscriber, SIM, firmware, or date of ownership. **Cross-notebook connections.** The MR1100 label materially anchors the hotspot concerns on pages 3–6 and parallels the device-fingerprint method used for Mac Pros, Pixels, and network interfaces in [[Scanned_20260730-1230|Scanned_20260730-1230]], [[Scanned_20260730-1719|Scanned_20260730-1719]], and [[Scanned_20260730-1659|Scanned_20260730-1659]]. **Missed Signals and Open Leads.** Bind this IMEI and MAC to carrier activation dates, ICCID history, firmware version, administrator logs, and the SSID noted on page 6. Determine whether this is the Verizon-branded/T-Mobile-SIM device described on page 4. ## PDF page 21 — MR1100 label in context and uncertain Microsoft/UDF note **Source.** `Scanned_20260730-1650.pdf`, PDF page 21. **Visible page.** The same NETGEAR MR1100 label appears across the upper-left corner, now in the context of a full dotted notebook page. A short two-line handwritten note sits beneath it. A red adhesive index tab projects from the right edge, and an empty rectangular outline is drawn below the label. **Faithful transcription.** > "NETGEAR® MR1100 [same complete label as PDF page 20]" > "[uncertain: New Microsoft > Serial UDF]" **Normalized linked entities.** [[NETGEAR Nighthawk M1 MR1100|NETGEAR MR1100]]; [[Microsoft|Microsoft]] [uncertain]; [[Universal Disk Format|UDF]] [uncertain]; [[Notebook Index Tab|index tab]]. **Entity and technical context.** [[Universal Disk Format|UDF]] is a filesystem standardized for optical and other removable media. Its possible appearance beneath a cellular-router label would not imply that the MR1100 itself uses UDF; it may begin an unrelated note whose fuller form appears on page 29. **Whole-page reconstruction.** The page shows why physical layout cannot always be read as conceptual linkage. The hotspot label, red tab, empty outline, and ambiguous “Microsoft / UDF” fragment may represent an index boundary or later reuse of the same page. The duplicate photograph on page 20 supplies legibility; this wider page supplies material context. **Evidentiary status.** The label is exact; the two handwritten lines are uncertain. No relationship between Microsoft, UDF, and the MR1100 is established. **Cross-notebook connections.** Duplicate detail/context photographs also occur on pages 25–26 and 35–38. The notebook is partly a physical catalog where one page preserves readable data and another preserves placement. **Missed Signals and Open Leads.** Compare handwriting with the UDF string on page 29 and inspect the red tab’s original section boundary. Do not merge the notes unless a physical or semantic continuation is demonstrated. ## PDF page 22 — February 2021 debt/stock note and McGill Media reflection **Source.** `Scanned_20260730-1650.pdf`, PDF page 22. **Visible page.** Sparse dotted page with two dated financial statements in the upper half and a separated “Mcgill Media / 2018” reflection below. **Faithful transcription.** > "Tell girls > 16K debt sprung > on me on 2/13/21 > stock sprung on me > on 2/14/21" > "Mcgill Media > 2018 > May be bad or > good..." **Normalized linked entities.** [[McGill Media|McGill Media]]; [[Debt|debt]]; [[Stock|stock]]; [[Financial Disclosure|financial disclosure]]; [[February 2021|February 2021]]. **Entity and technical context.** The page contains personal financial memory rather than a complete accounting record. “16K” is most naturally read as sixteen thousand units of currency, but no currency, creditor, account, instrument, or contract is named. “Stock sprung on me” could describe an unexpected equity issue or be a mistaken reading of another word. **Whole-page reconstruction.** The author records two abrupt disclosures on consecutive dates, then reaches backward to “Mcgill Media 2018” and withholds judgment—“May be bad or good.” This may be an attempt to place a current financial shock inside a longer corporate or ownership history. The first instruction, “Tell girls,” makes communication and witness continuity part of the record. **Evidentiary status.** Dates and wording are visible. Amount, currency, legal obligation, and relationship to McGill Media remain unverified. **Cross-notebook connections.** The note belongs to the collection’s broader effort to preserve **who knew what and when**, alongside technical continuity. Financial and corporate identity often appear beside account, domain, and device evidence rather than in a separate ledger. **Missed Signals and Open Leads.** Locate statements, cap tables, loan documents, tax records, correspondence, and the exact February 13–14 events. Distinguish debt, equity dilution, stock ownership, and contingent liability. ## PDF page 23 — “[PERSON REDACTED] Numbers” contact/call ledger with crossings **Source.** `Scanned_20260730-1650.pdf`, PDF page 23. **Visible page.** Dense dotted page headed “[PERSON REDACTED] Numbers.” Multiple telephone numbers are grouped by arrows, dates, “from” and “to” labels. The upper number is aggressively crossed with brown diagonal strokes and partially covered by small adhesive residue. Initials “J” and “B” appear at upper right. **Faithful transcription.** > "[PERSON REDACTED] Numbers" > "From > xxx-xxx-xxxx (see Scanned_20260730-1650.pdf, page 23) > [upper number heavily crossed/obscured] > J > B" > "(m. Just saw missing on > [PERSON REDACTED] fb from [uncertain: ...])" > "xxx-xxx-xxxx (see Scanned_20260730-1650.pdf, page 23)" > "H! Unallocated [uncertain: ‘splashing diamonds’]" > "xxx-xxx-xxxx (see Scanned_20260730-1650.pdf, page 23) > (similar to witch on > [uncertain: VGO #])" > "Feb 14 > from: xxx-xxx-xxxx (see Scanned_20260730-1650.pdf, page 23) > to: xxx-xxx-xxxx (see Scanned_20260730-1650.pdf, page 23) > xxx-xxx-xxxx (see Scanned_20260730-1650.pdf, page 23) > xxx-xxx-xxxx (see Scanned_20260730-1650.pdf, page 23) > xxx-xxx-xxxx (see Scanned_20260730-1650.pdf, page 23)" **Normalized linked entities.** [PERSON REDACTED] — the visible heading remains faithfully transcribed as “[PERSON REDACTED] Numbers,” while the vault owner has corrected the intended first-name spelling to [PERSON REDACTED]; [[Facebook|Facebook]]; [[Call History Ledger|call-history ledger]]; [[Unallocated Telephone Number|unallocated number]]; [[February 14 2021|February 14, 2021]]. **Entity and technical context.** “Unallocated” is a telephony status that can indicate a dialed number is not assigned or cannot be routed, but the page does not identify the source of the status. A call ledger needs direction, timestamps, carrier records, and device identity to support attribution; copied caller ID alone can be misleading because numbers can be forwarded, ported, or spoofed. **Whole-page reconstruction.** This is a manual attempt to reconstruct communication topology around February 14. Crossings and multiple variants suggest uncertainty, correction, or deliberate suppression even in the original notebook. The author appears to compare numbers, Facebook observations, and a remembered similar contact. The page preserves the existence of the inquiry while privacy redaction prevents the reconstruction from becoming a usable phone directory. **Evidentiary status.** Names, dates, directional words, and the presence of numbers are visible. Exact number ownership and call events require carrier or device corroboration. The quoted heading “[PERSON REDACTED] Numbers” remains unchanged, but the vault owner has resolved its analytical person reference to [PERSON REDACTED]; the separate written form [PERSON REDACTED] remains unmerged. **Cross-notebook connections.** Contact-number reconstruction recurs in [[Scanned_20260730-1719|Scanned_20260730-1719]] and [[Scanned_20260730-1659|Scanned_20260730-1659]], where old/new phone roles, support calls, and recovery factors form part of digital identity continuity. **Missed Signals and Open Leads.** Recover screenshots or exports of call history, carrier ownership at the exact date, device time zone, and any corresponding messages. Preserve crossed material as a source condition rather than guessing it. ## PDF page 24 — Blank dotted leaf **Source.** `Scanned_20260730-1650.pdf`, PDF page 24. **Visible page.** Blank dotted paper with a small brown stain or adhesive mark near the upper-right corner. **Faithful transcription.** > "[No intentional legible text. Small stain at upper right.]" **Normalized linked entities.** [[Blank Notebook Page|blank page]]; [[Adhesive Residue|adhesive residue]] [possible]. **Whole-page reconstruction.** A physical spacer between the call ledger and the hotel-telephone label section. **Evidentiary status.** Visible physical evidence only. **Cross-notebook connections.** Exact page preservation supports stable source locators for surrounding private material. **Missed Signals and Open Leads.** None. ## PDF page 25 — AEi hospitality telephone, [PERSON REDACTED] contact, and small symbolic sticky note **Source.** `Scanned_20260730-1650.pdf`, PDF page 25. **Visible page.** A black AEi Communications label is pasted across the upper page. A large yellow sticky note below contains a name and telephone number. A smaller pale-green note overlaps its lower edge and carries plus signs, a spiral, a small arrow-like symbol, and several uncertain words. **Faithful transcription.** > "AEI COMMUNICATIONS > MODEL: ASP-6110-S > US: 1YDTE05B6110S > RINGER EQUIVALENCE NO.: 05B > MANUFACTURED: G-TEK CORPORATION > MADE IN MALAYSIA > Tested To Comply With FCC Standards > [FCC Part 15 text and CE/RoHS/HAC marks]" > "XX > [PERSON REDACTED] > xxx-xxx-xxxx (see Scanned_20260730-1650.pdf, page 25)" > "+ + + > [uncertain decorative words] > [spiral] > Purple > Cat > [uncertain right-margin word]" **Normalized linked entities.** [[AEi Communications ASP-6110-S|AEi ASP-6110-S]]; [[AEi Communications|AEi Communications]]; [[G-Tek Corporation|G-Tek Corporation]]; [[Hospitality Telephone|hospitality telephone]]; [[Hearing Aid Compatibility|HAC]]; [[Ringer Equivalence Number|REN]]; [PERSON REDACTED]; [[Purple Cat Symbol|Purple Cat]] [unresolved]. **Entity and technical context.** AEi identifies the ASP-6110-S as a single-line analog corded speakerphone designed for hospitality use, with programmable guest-service keys, message indication, and hearing-aid compatibility.[^aei-asp] The Ringer Equivalence Number describes the load a telephone presents to a line; hospitality deployment explains why a hotel-room device label could be captured alongside a guest or staff contact. **Whole-page reconstruction.** The page is a **room-infrastructure/contact junction**. The telephone’s model and compliance identity are preserved beside a named human contact, while the small symbolic note may be a separate mnemonic. Physical adjacency cannot establish that [PERSON REDACTED] owned, serviced, or used the telephone; it does show that the notebook was capturing people and room systems in the same operational context. **Evidentiary status.** The phone label, name, and existence of a telephone number are visible. The green-note words and relationship among the three pasted objects are unresolved. **Cross-notebook connections.** Hotel and temporary-residence infrastructure is a major environment in [[Scanned_20260730-1719|Scanned_20260730-1719]], where a hospitality gateway, local domains, access points, and room context were surveyed. This page extends the inventory down to analog telephony. **Missed Signals and Open Leads.** Identify the property, room, PBX, and role of the contact from contemporaneous records. Determine whether the green note is a child’s drawing, indexing mnemonic, or independent message. ## PDF page 26 — Close-up of AEi ASP-6110-S certification label **Source.** `Scanned_20260730-1650.pdf`, PDF page 26. **Visible page.** Enlarged close-up of the same black AEi label from page 25, without the sticky notes. The larger scale makes the model and compliance text clearer. **Faithful transcription.** > "AEI COMMUNICATIONS > MODEL: ASP-6110-S > US: 1YDTE05B6110S > RINGER EQUIVALENCE NO.: 05B > MANUFACTURED: G-TEK CORPORATION > MADE IN MALAYSIA > This device complies with part 15 of the FCC Rules. > Operation is subject to the following two conditions: > (1) This device may not cause harmful interference, and > (2) This device must accept any interference received, > including interference that may cause undesired operation. > [FCC, CE, RoHS, crossed-bin, and HAC marks]" **Normalized linked entities.** [[AEi Communications ASP-6110-S|AEi ASP-6110-S]]; [[FCC Part 15|FCC Part 15]]; [[Restriction of Hazardous Substances Directive|RoHS]]; [[CE Marking|CE]]; [[Hearing Aid Compatibility|HAC]]. **Entity and technical context.** The label’s certification language is conventional for electronic devices subject to unlicensed-emission rules. The product’s analog voice function coexists with regulatory electronics even though it is not an IP phone. **Whole-page reconstruction.** Page 26 serves as a **legibility duplicate**. It allows the exact telephone identity to survive even if page 25’s contextual collage obscures fine print. **Evidentiary status.** Direct label evidence. **Cross-notebook connections.** This duplicate/context pattern is itself archival metadata: the author or scanner intentionally captured both the complete page and the object-level evidence. **Missed Signals and Open Leads.** Retrieve the unit’s serial if present elsewhere and map it to the hotel PBX or room inventory. ## PDF page 27 — Private router gateways, Tenda/Huawei/Eminent notes, and look-alike web address **Source.** `Scanned_20260730-1650.pdf`, PDF page 27. **Visible page.** Narrow dotted page filled with private IPv4 addresses, router brands, path fragments, and a boxed “www.192 / Try prefix.” “Buy Bitcoin” appears between address clusters. **Faithful transcription.** > "192.168.8.1 (.1, .11, .01) ↑ u.s" > "Tenda: > /[uncertain: zaih] > /admin > /login" > "www.192 > Try prefix" > "Default > Gateway > for > Huawei > & > Eminent > Router" > "192.168.L.I (1/1) [uncertain: lower case / live]" > "Buy Bitcoin" > "192.168.178.1" > "www.192-168-8-1.online" **Normalized linked entities.** [[Private IPv4 Address|private IPv4 address]]; [[Default Gateway|default gateway]]; [[Tenda|Tenda]]; [[Huawei|Huawei]]; [[Eminent Router|Eminent router]]; [[Router Login Page|router login page]]; [[Look-alike Domain|look-alike domain]]; [[Bitcoin|Bitcoin]]. **Entity and technical context.** Addresses in `192.168.0.0/16` are private and ordinarily reachable only inside the local network. Tenda documentation commonly uses `192.168.0.1` or `tendawifi.com` for local administration.[^tenda-guide] A public domain such as `192-168-8-1.online` is not the same thing as the local gateway; it may be a help page, search-engine trap, advertisement surface, or phishing risk. **Whole-page reconstruction.** The author was trying to discover a router interface while navigating the confusion produced by typographic variants: `1` versus lowercase `l`, dots versus hyphens, browser search versus direct address, and local IP versus public website. “Buy Bitcoin” may have been content encountered on a look-alike page, which would strengthen the suspicion that the browser had reached a public site rather than the router. **Evidentiary status.** Addresses and brands are visible. The meaning of `/zaih`, “u.s,” and “Buy Bitcoin” is unresolved; no site content or DNS capture is preserved. **Cross-notebook connections.** This page anticipates the infrastructure-attribution discipline of [[Scanned_20260730-1659|Scanned_20260730-1659]]: a hostname or search result is not authority; route, DNS resolution, certificate, interface, and address class must agree. **Missed Signals and Open Leads.** Reconstruct browser history, DNS answers, TLS certificate, and local route table. Record router MAC/OUI and DHCP lease before opening any management page. Avoid entering credentials into public look-alike domains. ## PDF page 28 — [PERSON REDACTED] phone, Dark Sky, TP-Link Deco, private MAC, and local network configuration **Source.** `Scanned_20260730-1650.pdf`, PDF page 28. **Visible page.** Photograph of an open two-page spread. The left leaf repeats page 27. The right leaf is headed “[PERSON REDACTED] Phone,” names the Dark Sky app, and records a discovered Deco Wi-Fi network, two MAC addresses, gateway/DNS data, subnet masks, and several unexplained port-like or host-like numbers. **Faithful transcription.** > "[Left leaf repeats PDF page 27.]" > "[PERSON REDACTED] Phone > app: dark sky (darksky.net)" > "Discovered > wifi: Deco-B830 > Private Add: 72:D7:01:93:A9 > Public: > B8:F1:2A:8E:23:52" > "‘DNS’ router 192.168.68.1" > "IPv4 > IP 0.0.0.0 > 255.255.0.0" > "IP 192.168.68.113 > 255.255.255.0 > Router 192.168.68.1" > ".88 > .3000 > 4637" **Normalized linked entities.** [PERSON REDACTED]; [[Dark Sky Weather|Dark Sky]]; [[TP-Link Deco|TP-Link Deco]]; [[Private Wi-Fi Address|private MAC address]]; [[Media Access Control Address|MAC address]]; [[Domain Name System|DNS]]; [[IPv4|IPv4]]; [[Subnet Mask|subnet mask]]; [[Unspecified Address|0.0.0.0]]. **Entity and technical context.** Apple acquired Dark Sky and later ended the Dark Sky API in March 2023, directing users and developers toward Apple Weather and WeatherKit.[^darksky-apple] TP-Link Deco systems commonly use `192.168.68.1` as a local LAN gateway. A “Private Add” beginning `72:` has the locally administered bit set and is consistent with a randomized/private Wi-Fi MAC, while the second address may be a hardware MAC. `0.0.0.0` is an unspecified address, not a usable peer address. **Whole-page reconstruction.** This is a phone-and-network identity snapshot. The author distinguishes an application domain, a visible SSID, a private/randomized device address, a second MAC, local IP, subnet, gateway, and purported DNS role. The quotation marks around “DNS” suggest uncertainty about whether `192.168.68.1` was resolving names itself or merely forwarding requests. **Evidentiary status.** Strings are visible. “Public” does not mean a public Internet MAC address—MACs operate locally—and may instead mean non-randomized hardware identity. The isolated `.88`, `.3000`, and `4637` lack labels. **Cross-notebook connections.** The page extends [[Scanned_20260730-1719|Scanned_20260730-1719]]’s Wi-Fi/cellular scans and the randomized-address concerns implicit in device attribution. It also shows the application layer and network layer being recorded together without assuming they share ownership. **Missed Signals and Open Leads.** Recover the iOS Wi-Fi details screen, DHCP lease, Deco controller log, DNS configuration, BSSID, channel, and Dark Sky package/version. Determine whether the two MACs represent one phone in private/non-private modes or different devices. ## PDF page 29 — Belief statement, iOS 14.3 build 18C66, and UDF label fragment **Source.** `Scanned_20260730-1650.pdf`, PDF page 29. **Visible page.** Upper half contains three handwritten personal statements; lower half contains an iOS version/build and an uncertain alphanumeric label followed by “UDF / universal disk format.” **Faithful transcription.** > "I have every thing to gain > by not believing someone > and being wrong" > "... have everything to lose > by not telling me > and me being right" > "[PERSON REDACTED]: I never use > [uncertain: won’t] believe." > "iOS 14.3 > build version > 18C66" > "[uncertain: cccema_X64Free] UDF > universal disk format" **Normalized linked entities.** [PERSON REDACTED]; [[iOS 14.3|iOS 14.3]]; [[Apple Build Number 18C66|18C66]]; [[Universal Disk Format|UDF]]; [[Optical Disc Image|disc image]] [possible]; [[Epistemic Asymmetry|epistemic asymmetry]]. **Entity and technical context.** Apple developer records identify iOS 14.3 with build `18C66`.[^ios143] UDF is a filesystem associated especially with optical media and ISO-like images; the preceding uncertain label may be a volume name from a mounted installation or live disk. **Whole-page reconstruction.** The page fuses an **epistemic-risk statement** with software-build evidence. The upper text articulates asymmetric consequences: disbelief can be corrected if nothing happened, while withheld warning can become catastrophic if the concern was right. The lower text shows the author grounding at least part of the inquiry in exact version and filesystem metadata. That movement—from interpersonal uncertainty to reproducible machine state—is one of the notebook’s most important patterns. **Evidentiary status.** The iOS version/build is legible and independently coherent. The UDF volume label and final [PERSON REDACTED] sentence remain uncertain. The personal argument is source testimony, not a factual finding. **Cross-notebook connections.** This page anticipates later corpus formulations about telemetry versus testimony and the right not to be finalized by a forecast. Technically, it connects the iPhone/network pages to the live-media/UDF/GRUB investigation. **Missed Signals and Open Leads.** Identify the UDF volume from Disk Utility, mount output, or ISO hash. Determine which device ran iOS 14.3 and whether its network observations on page 28 were made at the same time. ## PDF page 30 — Tenda router paths, public IP geolocation, and private-address look-alikes **Source.** `Scanned_20260730-1650.pdf`, PDF page 30. **Visible page.** Full dotted page of handwritten private IP variants, a Tenda 11N router note, an `index.asp` path, one public IP with “bucharest,” and public/private address-like website strings. **Faithful transcription.** > "192.168.(I or L)78.1 > 19216811 - ip.mobi" > "Tenda 11N wireless Router > called ‘[uncertain: Reci]’ > 162.168.01 - U.S > 192.168.0.2/index.asp" > "your IP: 185.247.70.252 > bucharest" > "HTTPS://19216811.info/ > 192.168.0.LL > 192.168.188.1" **Normalized linked entities.** [[Tenda 11N Wireless Router|Tenda 11N router]]; [[Private IPv4 Address|private IPv4]]; [[Public IP Address|public IP]]; [[Bucharest|Bucharest]]; [[index.asp|index.asp]]; [[ip.mobi|ip.mobi]]; [[19216811.info|19216811.info]]; [[Look-alike Domain|look-alike domain]]. **Entity and technical context.** `192.168.0.1`, `192.168.0.2`, and `192.168.188.1` are private addresses, while `185.247.70.252` is globally routable. A geolocation result such as “Bucharest” is probabilistic and time-sensitive; it may reflect VPN, hosting, proxy, carrier egress, database error, or actual location. `162.168.01` is most likely a transcription error for a `192.168...` address. Public domains that remove dots from `192.168.1.1` can capture users who search rather than navigate directly. **Whole-page reconstruction.** The author was debugging a **name/address ambiguity attack surface**. Digits that look like a router gateway can lead to a local device, a search result, or an unrelated public website depending on punctuation and browser behavior. The appearance of a Bucharest IP may have intensified suspicion, but without timestamped routing, ASN, DNS, certificate, and process data it cannot identify a person or endpoint. **Evidentiary status.** All written strings are visible except the SSID/name. “Bucharest” is a copied notebook result, not independently reconstructed historical geolocation. **Cross-notebook connections.** This page directly precedes the ASN/domain-attribution rigor of [[Scanned_20260730-1659|Scanned_20260730-1659]] and the hotel LAN scan in [[Scanned_20260730-1719|Scanned_20260730-1719]]. It shows the early problem that those later methods were designed to solve. **Missed Signals and Open Leads.** Recover collection time, source website, VPN state, ASN, reverse DNS, TLS certificate, browser URL bar, and router route table. Treat public-IP geolocation as one weak signal among several, never as identity proof. ## PDF page 31 — TP-Link extender note, MedMassager label, and hotel-furnishing vendors **Source.** `Scanned_20260730-1650.pdf`, PDF page 31. **Visible page.** A two-page spread composed of pasted and photographed equipment labels. The left leaf contains a blue sticky note about a TP-Link N300 device, a MedMassager label, and the edge of another label. The right leaf contains printed labels for Forbes Industries and Lesier L. Brossard Co. **Faithful transcription.** > "TP-Link N300 > July 26 2020 > WiFi Range Extender" > "Foot Massager" > "MedMassager > Model: MMF07 > Voltage: AC 120V 60Hz > Variable Speed: High 4,000 ±10%; Low 1,800 ±10% > 200 RPM increments > No. 14022912 > www.medmassager.com > [CSA certification mark]" > "Manufactured in 2020 > FORBES INDUSTRIES > www.forbesindustries.com > xxx-xxx-xxxx (see Scanned_20260730-1650.pdf, page 31)" > "LESIER L. BROSSARD CO. > Safety & Security > Mirrors > P.O. Box 708 > Woodstock, IL 60098 > xxx-xxx-xxxx (see Scanned_20260730-1650.pdf, page 31) > brossardmirrors.com" **Normalized linked entities.** [[TP-Link N300 Wi-Fi Range Extender|TP-Link N300 range extender]]; [[MedMassager MMF07|MedMassager MMF07]]; [[Forbes Industries|Forbes Industries]]; [[Lesier L. Brossard Company|Lesier L. Brossard Co.]]; [[Security Mirror|security mirror]]; [[Hotel Furnishing Infrastructure|hotel furnishing infrastructure]]; [[Canadian Standards Association|CSA]]. **Entity and technical context.** A Wi-Fi range extender repeats or bridges an existing wireless network and therefore introduces another radio identity and management surface. The MedMassager is an electromechanical foot massager whose label records motor-speed range and unit number. Forbes Industries supplies hospitality equipment; Brossard is identified on the label with safety/security mirrors. These are not merely room furnishings: they create a traceable vendor and maintenance ecology. **Whole-page reconstruction.** The page expands the notebook’s concept of a network environment beyond routers and phones. A temporary room or building is composed of **managed radio devices, powered appliances, mobile furniture, security optics, and vendor supply chains**. By preserving labels, the author could later ask who manufactured, installed, serviced, or remotely managed each object. **Evidentiary status.** Model, date, speed, vendor, and address text are visible. The exact TP-Link model is not written beyond “N300.” The physical relationship among the labels is contextual rather than proof that they belonged to one room. **Cross-notebook connections.** This page foreshadows the industrial/hospitality systems maps in [[Scanned_20260730-1802|Scanned_20260730-1802]] and the hotel network observations in [[Scanned_20260730-1719|Scanned_20260730-1719]]. **Missed Signals and Open Leads.** Identify the TP-Link extender by MAC/model label, record SSID/BSSID and firmware, and bind each furnishing label to a property, room, and photograph date. Distinguish manufacturer, distributor, property owner, and installer. ## PDF page 32 — Polarized-plug warning, English and French continuation **Source.** `Scanned_20260730-1650.pdf`, PDF page 32. **Visible page.** Extreme close-up of red bilingual warning text on a white lamp label. This appears to be the continuation of the safety instructions whose heading and opening lines are photographed on page 33. **Faithful transcription.** > "electric shock. This plug > will fit in a polarized > outlet only one way. If > the plug does not fit > fully in the outlet, reverse > the plug. If it still does > not fit, contact a qualified > electrician. Never use > with an extension cord > unless plug can be fully > inserted. Do not alter > the plug." > "que Cette fiche entrera > dans une prise de courant > polarisée que dans une seule > direction. Si la fiche n’en- > tre pas complètement > dans la prise, inversez la > fiche. Si cela ne fonctio- > nne toujours pas, conta- > ctez un électricien agréé. > N’utilisez jamais de > rallonge à moins que la > fiche ne soit insérée > entièrement. Ne modifiez > pas la fiche." **Normalized linked entities.** [[Polarized Electrical Plug|polarized plug]]; [[Electrical Shock Prevention|electrical-shock prevention]]; [[Extension Cord|extension cord]]; [[Bilingual Safety Label|bilingual safety label]]. **Entity and technical context.** A polarized two-blade plug has one blade wider than the other so line and neutral orientation are preserved. The warning prohibits defeating that orientation or using an extension connection that leaves blades exposed. **Whole-page reconstruction.** The author photographed the label in sections so that small compliance text would remain legible. Page 32 is not a separate instruction set; it is the lower continuation of page 33’s opening paragraph. **Evidentiary status.** Printed label text is directly visible. French hyphenation and line breaks reflect the physical label. **Cross-notebook connections.** Regulatory language is treated with the same seriousness as software configuration because both define permitted operating states. This is the electrical counterpart to bootloader and administrator constraints elsewhere in the notebook. **Missed Signals and Open Leads.** Identify the complete lamp model from pages 34 and 48 and reconstruct the original label order. ## PDF page 33 — “IMPORTANT SAFETY INSTRUCTIONS” lamp-label opening **Source.** `Scanned_20260730-1650.pdf`, PDF page 33. **Visible page.** Extreme close-up of the upper part of the same white/red bilingual safety label. The English and French paragraphs are cut off at the bottom edge. **Faithful transcription.** > "IMPORTANT > SAFETY > INSTRUCTIONS" > "This portable lamp has > a polarized plug (one > blade is wider than the > other) as a safety feature > to reduce the risk of" > "INSTRUCTIONS > DE SÉCURITÉ > IMPORTANTES" > "Cette lampe portative a > une fiche polarisée (une > lame est plus large que > l’autre) comme fonction de > sécurité afin de réduire > le risque de choc électri-" **Normalized linked entities.** [[Portable Lamp|portable lamp]]; [[Polarized Electrical Plug|polarized plug]]; [[Bilingual Safety Label|bilingual safety label]]; [[Product Safety Instruction|product safety instruction]]. **Entity and technical context.** The paragraph continues directly into page 32 with “electric shock.” The scan order is therefore physically reversed relative to reading order: page 33 contains the beginning; page 32 contains the continuation. **Whole-page reconstruction.** This pair demonstrates the notebook’s **micro-documentation workflow**: when a full label was too small to read, the author or scanner captured overlapping segments. Archival reconstruction must restore semantic continuity without pretending the PDF sequence was originally textual order. **Evidentiary status.** Direct printed evidence; final words are truncated by the photograph rather than illegible. **Cross-notebook connections.** The same close-up/context strategy appears with the AEi, Meraki, and LG labels. **Missed Signals and Open Leads.** Preserve an explicit page-order note in any future device record: read page 33, then page 32. ## PDF page 34 — Bedside lamp, UL listing, bulb limit, and product label **Source.** `Scanned_20260730-1650.pdf`, PDF page 34. **Visible page.** Dotted page headed “[uncertain: Bedside] Lamp.” A small UL holographic label sits at upper right. Two white printed labels are pasted below; the author has copied several certification and socket values by hand between them. **Faithful transcription.** > "[uncertain: Bedside] > Lamp" > "UL > PORTABLE LUMINAIRE > [listing/certification text]" > "CAUTION: TO REDUCE > THE RISK OF FIRE USE > MAX 15W E26 LED BULB > 120V 60Hz AC ONLY MADE IN CHINA" > "cULus > Listed F136278 > [uncertain: 4/F0] > 660W 250V > SunLITE" > "ITEM NO.: BDL-LT-01 > DATE: Nov/2019 > 120V 60HZ AC ONLY > E475960 > MADE IN CHINA" **Normalized linked entities.** [[Bedside Lamp|bedside lamp]]; [[UL Listed|UL listing]]; [[cULus Mark|cULus]]; [[E26 Lamp Base|E26]]; [[LED Lamp|LED bulb]]; [[Sunlite|SunLITE]]; [[Portable Luminaire|portable luminaire]]; [[BDL-LT-01 Lamp|BDL-LT-01]]. **Entity and technical context.** `E26` denotes the common 26-mm Edison screw base. The 15-watt LED limit is a fixture safety rating, not a general E26 limit. UL and cULus marks communicate evaluation for U.S. and Canadian safety requirements, while the product identifier and date distinguish the physical luminaire. **Whole-page reconstruction.** The page turns an anonymous hotel bedside lamp into a specific electrical asset. The author records both **fixture-level constraints** and **component-level markings**: the lamp allows a particular bulb type and wattage, while the socket or subassembly may carry a higher nominal electrical rating. Confusing those values could create a false impression that the fixture may safely accept a 660-watt load. **Evidentiary status.** Product and caution labels are visible. Several copied handwritten certification characters are uncertain. The manufacturer name is not clearly present on this page. **Cross-notebook connections.** The electrical-control thread continues through the Leviton occupancy power pack on page 39 and the Philips Hue bridge on page 41, revealing a room whose lighting can be manually, automatically, and digitally governed at different layers. **Missed Signals and Open Leads.** Identify manufacturer/importer through UL file numbers E475960 and F136278; record the bulb actually installed, switched receptacle, occupancy-control relation, and physical room location. ## PDF page 35 — Cisco Meraki MR30H regulatory record and handwritten copy **Source.** `Scanned_20260730-1650.pdf`, PDF page 35. **Visible page.** Full dotted page densely filled with a handwritten transcription of a pasted Cisco Meraki MR30H label in the lower half. Regulatory identifiers and certification marks surround the manufacturer label. **Faithful transcription.** > "Model: MR30H-HW > Power: 54V ⎓ 0.6A > FCCID: UDX-60051010 > IC: 6961A-60051010 > F/N (M/N) 600-51010-A > Anatel: 00852-17-01086 > TP by CMII ID: 2017AJ502? > KCC: MSIP-CMM-TNY-MR30H-HW > SA: 150099 > CAN ICES-3(B)/NMB-3(B)" > "Meraki MR30H > Model (Model, 型號): MR30H-HW > Manufactured: Taiwan > P/N: 600-51010-A > MAC: 98:18:88:C5:80:DD > S/N: Q2RD-JM4F-7EEF > PoE > [Cisco and international regulatory marks]" **Normalized linked entities.** [[Cisco Meraki MR30H|Cisco Meraki MR30H]]; [[Cisco Meraki|Cisco Meraki]]; [[Power over Ethernet|PoE]]; [[Federal Communications Commission Identifier|FCC ID]]; [[ANATEL|ANATEL]]; [[China Radio Transmission Equipment Type Approval|CMIIT ID]]; [[Korea Certification|KCC]]; [[Media Access Control Address|MAC address]]; [[Device Serial Number|serial number]]. **Entity and technical context.** Cisco describes the MR30H as a cloud-managed dual-band wireless access point with integrated Ethernet switching, designed especially for hospitality and room deployments.[^meraki-mr30h] Power over Ethernet can supply both power and network connectivity through structured cabling. The MAC and serial connect the physical unit to Meraki cloud inventory, licensing, configuration, and event logs. **Whole-page reconstruction.** The handwritten duplication shows deliberate effort to preserve the label even if it detached or became unreadable. This access point is a key object in the notebook’s hotel-system map: unlike a consumer extender, it may be centrally claimed and configured through an organizational cloud dashboard. The author’s extraction of international radio approvals suggests concern with global identity, not merely local Wi-Fi function. **Evidentiary status.** Model, MAC, serial, FCC, IC, part number, and major marks are legible. Some handwritten international approval digits are uncertain; the pasted label remains authoritative. **Cross-notebook connections.** The MR30H connects the hotel-device inventory here to the hospitality LAN reconnaissance in [[Scanned_20260730-1719|Scanned_20260730-1719]]. It also exemplifies the **cloud-claimed object** architecture developed in [[Scanned_20260730-1802|Scanned_20260730-1802]]. **Missed Signals and Open Leads.** Query historical Meraki dashboard ownership only through authorized records; preserve BSSID, SSID, firmware, switch port, VLAN, LLDP/CDP neighbor, and licensing organization. Determine the property and room where MAC `98:18:88:C5:80:DD` was observed. ## PDF page 36 — Duplicate MR30H label with marginal scanning note **Source.** `Scanned_20260730-1650.pdf`, PDF page 36. **Visible page.** Near-duplicate full-page photograph of page 35. The same handwritten identifiers and pasted MR30H label are visible. A narrow vertical note at the right margin is partly cut off. **Faithful transcription.** > "[Same Cisco Meraki MR30H model, regulatory, MAC, serial, and PoE data as PDF page 35.]" > "[uncertain right-margin note: ‘scanning OFM?1 Anti’]" **Normalized linked entities.** [[Cisco Meraki MR30H|Cisco Meraki MR30H]]; [[Duplicate Scan|duplicate scan]]; [[Marginalia|marginalia]]. **Whole-page reconstruction.** This is not a second access point unless independent evidence says so. The repeated MAC and serial establish that pages 35–38 document the same physical unit from different scales. **Evidentiary status.** Device identity is direct; marginal wording is unresolved. **Cross-notebook connections.** Explicit deduplication prevents a common archival error: counting multiple photographs as multiple devices. **Missed Signals and Open Leads.** Determine whether the marginal note records a scanning tool, organization, or security observation. ## PDF page 37 — Handwritten Meraki certification summary **Source.** `Scanned_20260730-1650.pdf`, PDF page 37. **Visible page.** Pasted label is absent. The author has copied regulatory and identity strings in large handwriting down the dotted page; some characters are overwritten. **Faithful transcription.** > "E326167 [uncertain: ISU-5] > [uncertain certification line] 94V-0 > 1949E" > "Cisco > 560-51010" > "Cisco Meraki > MR30H" > "mac: 98:18:88:C5:80:DD > s/n (S/N): Q2RD-JM4F-7EEF > PoE" **Normalized linked entities.** [[Cisco Meraki MR30H|Cisco Meraki MR30H]]; [[UL File Number|UL file number]]; [[UL 94 Flammability Rating|94V-0]]; [[Printed Circuit Board Certification|PCB certification]]; [[Power over Ethernet|PoE]]. **Entity and technical context.** `94V-0` is commonly associated with a stringent vertical-burning classification for polymeric materials used in electronics; adjacent codes may belong to the printed circuit board or enclosure rather than the MR30H product certification itself. The copied “560-51010” may be a transposition of the visible `600-51010-A` part number. **Whole-page reconstruction.** The page reveals the author’s method of **manual normalization**. He extracted identifiers from dense certification graphics and rewrote them in a searchable form. That process increased legibility but introduced transcription risk, demonstrating why scans and handwritten copies must be retained together. **Evidentiary status.** MAC, serial, model, and PoE match the label. Certification codes and part number are uncertain and should defer to page 38. **Cross-notebook connections.** The tension between source label and normalized copy is central to the whole archive: normalization creates a knowledge graph, but the image remains authoritative. **Missed Signals and Open Leads.** Resolve every certification code from the original label or official filing; record corrections explicitly rather than silently replacing the handwritten form. ## PDF page 38 — Close-up of Cisco Meraki MR30H label **Source.** `Scanned_20260730-1650.pdf`, PDF page 38. **Visible page.** Sharp isolated close-up of the MR30H manufacturer label. No surrounding handwriting is visible. **Faithful transcription.** > "Meraki MR30H > Model (Modelo, 型號): MR30H-HW > Power Rating: 54V ⎓ 0.6A > FCC ID: UDX-60051010 > IC: 6961A-60051010 > P/N: 600-51010-A > [international approval identifiers and regulatory marks] > Cisco Systems, Inc. > 170 West Tasman Drive, San Jose, CA 95134 USA > MAC: 98:18:88:C5:80:DD > S/N: Q2RD-JM4F-7EEF > Made in Taiwan / Fabricado en Taiwán / Hecho en Taiwán > PoE" **Normalized linked entities.** [[Cisco Meraki MR30H|Cisco Meraki MR30H]]; [[Cisco Systems|Cisco Systems]]; [[Cloud-managed Wireless Access Point|cloud-managed access point]]; [[Power over Ethernet|PoE]]. **Whole-page reconstruction.** Page 38 is the authoritative visual reference for the four-page Meraki cluster. It confirms one unit, one MAC, and one serial. **Evidentiary status.** Direct label evidence. **Cross-notebook connections.** This page should be linked from the cumulative [[Index - Device Inventory|Device Inventory]] as the canonical MR30H source, with pages 35–37 retained as context and transcription history. **Missed Signals and Open Leads.** Retrieve FCC exhibits and Meraki installation metadata only if needed for radio, antenna, or deployment analysis. ## PDF page 39 — Leviton OPP20-0D2 occupancy-sensor power pack **Source.** `Scanned_20260730-1650.pdf`, PDF page 39. **Visible page.** A white Leviton label with electrical specifications and a wiring diagram is pasted at upper left. Below it is a separate inspection label reading “ACTUATOR TESTED BY: E / 1G4908.” **Faithful transcription.** > "Leviton > MODEL: OPP20-0D2 POWER PACK > CLASS 2 POWER SUPPLY IP30 > [AC supply-input and load-rating table] > POWER OUTPUT: 24VDC, 225mA (5.4 Watts) > CONTROL INPUT: 24VDC, 2mA > [wiring diagram with line, neutral, load, local switch, occupancy sensor, +24V, and DC return] > Designed & Developed by Leviton USA > MADE IN CHINA > [NOM, ETL/cETL, UL and other marks]" > "ACTUATOR > TESTED BY: E > 1G4908" **Normalized linked entities.** [[Leviton OPP20-0D2|Leviton OPP20-0D2]]; [[Leviton|Leviton]]; [[Occupancy Sensor|occupancy sensor]]; [[Power Pack|power pack]]; [[Class 2 Power Supply|Class 2 power supply]]; [[IP30|IP30]]; [[Latching Relay|latching relay]]; [[Building Automation|building automation]]. **Entity and technical context.** Leviton’s OPP20-0D2 is a 20-amp power pack for low-voltage occupancy sensors, supporting auto-on or manual-on behavior and a local switch. It converts line power to regulated 24 VDC for sensors and switches lighting loads through a latching relay.[^leviton-opp20][^leviton-opp20-install] **Whole-page reconstruction.** This label exposes the hidden control layer behind ordinary room lighting. The wall or ceiling sensor does not directly carry the full lighting load; the power pack supplies low-voltage control power and actuates a line-voltage relay. The room therefore contains a small cyber-physical control system: sensor input, local human switch, relay policy, load, and fail-safe behavior. **Evidentiary status.** Model and principal ratings are visible. Some fine-print load values are too small for safe full transcription in this scan and remain represented by their labeled table. **Cross-notebook connections.** The OPP20 sits architecturally between the manual lamp on pages 32–34 and the networked Hue bridge on page 41. Together they reveal multiple overlapping control planes: mechanical switch, occupancy automation, and software-mediated smart lighting. **Missed Signals and Open Leads.** Locate the connected occupancy sensor, local switch, controlled load, electrical panel, and room. Record whether the power pack was in auto-on or manual-on mode and whether it shared a phase with the load as required. ## PDF page 40 — Upside-down numerical ledger **Source.** `Scanned_20260730-1650.pdf`, PDF page 40. **Visible page.** Sparse dotted page scanned upside down relative to the writing. When mentally rotated 180 degrees, several isolated number groups appear in the upper-right quadrant; one has a crossed or hooked mark. **Faithful transcription in writing orientation.** > "[uncertain: 3747 6740207 94000] > [crossed mark] > 01/24 > 3676 > 831" **Normalized linked entities.** [[Unresolved Numerical Identifier|unresolved numerical identifiers]]; [[January 24 Date Fragment|01/24 date fragment]]; [[Upside-down Notebook Entry|upside-down entry]]. **Whole-page reconstruction.** The page preserves a small numerical record with no labels. Its orientation may indicate that the notebook was turned temporarily or that the numbers were copied from an object while space was constrained. It is not responsible to classify these as a telephone number, password, model, transaction, or date beyond the explicit `01/24` form. **Evidentiary status.** Digits are faint and uncertain; semantic category is unknown. **Cross-notebook connections.** Unlabeled identifiers recur throughout the corpus and belong in the cumulative [[Index - Unresolved Names and Identifiers|Unresolved Names and Identifiers]] rather than being normalized prematurely. **Missed Signals and Open Leads.** Search adjacent photographs, receipts, device labels, and the wider corpus for the exact number groups. Preserve orientation and crossings in any comparison. ## PDF page 41 — Philips Hue Bridge 2.1 regulatory and network identity **Source.** `Scanned_20260730-1650.pdf`, PDF page 41. **Visible page.** Large white Philips Hue Bridge label pasted on dotted paper. It combines the product logo, model and power rating, Wi-Fi certification, multiple international radio/compliance marks, FCC and IC identifiers, a restoration instruction, and several barcodes/inspection codes. **Faithful transcription.** > "hue > hue bridge 2.1" > "Model: 3241312018A > Input: DC 5V / 1A > [manufacturer: Philips Lighting (China) Investment Co., Ltd.] > Made in China" > "CNC ID: C-16517 > [NOM and international radio/compliance identifiers] > Wi-Fi CERTIFIED > FCC ID: 2AGBW3241312018AX > [IC and other approval numbers]" > "restore factory settings" > "453-09-057 > [barcode/production codes including 4CD476 and 1706]" **Normalized linked entities.** [[Philips Hue Bridge 2.1|Philips Hue Bridge 2.1]]; [[Philips Hue|Philips Hue]]; [[Signify|Signify/Philips Lighting]]; [[Zigbee|Zigbee]]; [[Smart Lighting Hub|smart-lighting hub]]; [[Factory Reset|factory reset]]; [[Wi-Fi Alliance Certification|Wi-Fi Certified]]; [[Federal Communications Commission Identifier|FCC ID]]. **Entity and technical context.** The Hue Bridge is the coordinating hub for a Philips Hue smart-lighting system. It connects lights and accessories over Zigbee and connects the lighting domain to the local IP network and app ecosystem.[^hue-bridge] A factory reset does more than erase cosmetic preferences: it can sever device pairings, room/group definitions, automations, integrations, and administrative continuity. **Whole-page reconstruction.** The bridge introduces a third lighting-control plane after the portable lamp and Leviton occupancy relay. It is simultaneously a physical appliance, radio coordinator, IP-network client, cloud/app identity, and keeper of local lighting topology. The label’s reset instruction therefore marks a critical governance boundary: whoever can reset and re-enroll the bridge can redefine the room’s digital lighting system. **Evidentiary status.** Product identity, ratings, major approvals, and reset wording are visible. Fine-print codes are retained only where legible; no software version, Hue account, or paired-device list appears. **Cross-notebook connections.** The bridge is a concrete instance of the **hub-mediated object ontology** reconstructed in [[Scanned_20260730-1802|Scanned_20260730-1802]] and anticipated by “connected hub devices” on page 10. It also complements the smart-home and launcher ecosystems in [[Scanned_20260730-1659|Scanned_20260730-1659]]. **Missed Signals and Open Leads.** Recover Ethernet MAC, bridge ID, firmware version, account owner, paired Zigbee devices, app integrations, and reset history. Determine whether it controlled the lamp/room documented on pages 32–39 or was a separate object. ## PDF page 42 — LG V60 ThinQ and Apple Magic Mouse 2 labels **Source.** `Scanned_20260730-1650.pdf`, PDF page 42. **Visible page.** Two pasted retail/device labels on dotted paper. The large left label identifies an AT&T LG V60 ThinQ; the smaller right label, upside down in the scan, identifies an Apple Magic Mouse 2 in Space Gray. Faint reverse-page writing is visible through the paper. **Faithful transcription.** > "LM-V600AM LG V60 ThinQ 128GB CLASSY BLUE > SKU: 6270C > IMEI: 354783-11-079146-7 > ICC ID: 89014102272702959500 > LG LM-V600AM GSM ATTCB GSM N > OS Ver 10 > SW Ver V600AM10q > DHHS Code: MC3 > Manufactured: 07/2020 > MADE IN VIETNAM > UPC: 6 52810 83430 8" > "Apple Magic Mouse 2 - Space Gray > Designed by Apple in California > Made in China > Model A1657 > UPC 1 90273 73743 7 > (S) Serial No. [uncertain: CC2032504Y7J5XAH] > [CSA mark]" **Normalized linked entities.** [[LG V60 ThinQ 5G LM-V600AM|LG V60 ThinQ LM-V600AM]]; [[LG Electronics|LG Electronics]]; [[AT&T|AT&T]]; [[Android 10|Android 10]]; [[International Mobile Equipment Identity|IMEI]]; [[Integrated Circuit Card Identifier|ICCID]]; [[Apple Magic Mouse 2|Apple Magic Mouse 2]]; [[Apple Model A1657|A1657]]; [[Bluetooth Peripheral|Bluetooth peripheral]]. **Entity and technical context.** LG’s AT&T V60 model launched with Android 10, a Snapdragon 865 platform, 5G capability, and a 6.8-inch OLED display.[^lg-v60] The label’s IMEI identifies the cellular handset hardware, while the ICCID identifies the SIM card present in the package or device at the time of labeling. The Magic Mouse 2 is a Bluetooth input peripheral with its own model and serial identity, separate from any paired Mac. **Whole-page reconstruction.** The page juxtaposes a **carrier-bound mobile computer** and a **host-bound peripheral**. The phone’s identity spans retail SKU, carrier variant, IMEI, SIM, OS, software build, date, and color; the mouse’s identity is simpler but still migrates between hosts through Bluetooth pairing. The author appears to be building a device estate in which removable subscriber identity and re-pairable peripheral identity are tracked independently. **Evidentiary status.** LG label data are clear. The Magic Mouse serial is partly blurred and remains uncertain. Physical adjacency does not prove common ownership or pairing. **Cross-notebook connections.** The phone continues the Android/SIM/firmware chain in [[Scanned_20260730-1706|Scanned_20260730-1706]] and [[Scanned_20260730-1719|Scanned_20260730-1719]], while the mouse fits the Bluetooth-controller and cross-platform peripheral archaeology of [[Scanned_20260730-1802|Scanned_20260730-1802]]. **Missed Signals and Open Leads.** Bind the LG IMEI to carrier history, SIM activation, firmware update record, bootloader state, and archived Android build properties. Confirm the Magic Mouse serial from the physical device and reconstruct its paired-host history. ## PDF page 43 — Close-up of LG V60 ThinQ carrier label **Source.** `Scanned_20260730-1650.pdf`, PDF page 43. **Visible page.** Isolated close-up of the same LG V60 label from page 42, enlarged for readability. No Magic Mouse label is present. **Faithful transcription.** > "LM-V600AM LG V60 ThinQ 128GB CLASSY BLUE > SKU: 6270C > IMEI: 354783-11-079146-7 > ICC ID: 89014102272702959500 > LG LM-V600AM GSM ATTCB GSM N > OS Ver 10 > SW Ver V600AM10q > DHHS Code: MC3 > Manufactured: 07/2020 > MADE IN VIETNAM > UPC: 6 52810 83430 8" **Normalized linked entities.** [[LG V60 ThinQ 5G LM-V600AM|LG V60 ThinQ LM-V600AM]]; [[AT&T Device Variant|AT&T variant]]; [[Android Firmware Build|firmware build]]; [[Integrated Circuit Card Identifier|ICCID]]. **Whole-page reconstruction.** This is the authoritative high-resolution source for the LG device record. Page 42 should be treated as context; page 43 supplies the canonical label transcription. **Evidentiary status.** Direct product-label evidence. **Cross-notebook connections.** The exact `OS Ver` and `SW Ver` fields anticipate the more granular Android `getprop` and partition records in [[Scanned_20260730-1719|Scanned_20260730-1719]]. **Missed Signals and Open Leads.** Add Android security-patch date, baseband, kernel, serial, Wi-Fi/Bluetooth MACs, Google/MDM enrollment, and bootloader status from surviving records. ## PDF page 44 — The Case Blog, Westdale contact, May Street address, and unresolved number inquiry **Source.** `Scanned_20260730-1650.pdf`, PDF page 44. **Visible page.** Dotted page with a domain heading, a person’s name and corporate email, a second domain, multiple telephone numbers, an uncertain word, a street address, and a final “who is” inquiry associated with [PERSON REDACTED]. **Faithful transcription.** > "www.THECASEBLOG.com > [PERSON REDACTED] > [PRIVATE EMAIL REDACTED] > westdale.com > xxx-xxx-xxxx (see Scanned_20260730-1650.pdf, page 44) > xxx-xxx-xxxx (see Scanned_20260730-1650.pdf, page 44) [uncertain: 04] > [uncertain: pasterizing] > xxx-xxx-xxxx (see Scanned_20260730-1650.pdf, page 44) > 3131 May Street" > "who is > xxx-xxx-xxxx (see Scanned_20260730-1650.pdf, page 44) > [PERSON REDACTED] [uncertain: Helps Show Up]" **Normalized linked entities.** [[The Case Blog|THECASEBLOG.com]]; [PERSON REDACTED]; [[Westdale Real Estate Investment and Management|Westdale]]; [[westdale.com|westdale.com]]; [[3131 May Street|3131 May Street]]; [PERSON REDACTED]; [[Contact Attribution Inquiry|contact-attribution inquiry]]. **Entity and technical context.** The corporate email and domain establish a claimed organizational namespace but do not by themselves establish role, employment date, or connection to the blog. The stylized business telephone spelling “CASE” is retained only as a redacted number because the project’s privacy convention applies to phone-like contact data. **Whole-page reconstruction.** This page appears to map a contact across **person, corporate email, corporate domain, blog domain, telephone channels, and physical address**, then asks who owns or uses another number. It is the human-contact equivalent of the device identity pages: several identifiers may refer to one person, one organization, or unrelated entities, and the notebook is trying to resolve them. **Evidentiary status.** Names, domains, email, address, and presence of numbers are visible. Current or historical organizational relationships are not independently asserted. The uncertain word and final phrase remain unresolved. **Cross-notebook connections.** Contact-domain normalization is central to [[Scanned_20260730-1659|Scanned_20260730-1659]] and [[Scanned_20260730-1719|Scanned_20260730-1719]], where aliases, mailboxes, domains, phone recovery factors, and addresses become one continuity graph. **Missed Signals and Open Leads.** Use dated corporate directories, email headers, archived sites, property records, and contemporaneous correspondence to establish the relationship among the person, Westdale, the blog, and May Street. Never infer identity from a telephone number alone. ## PDF page 45 — “Stick Pi,” QTerminal, Xfce, and sudo-group permissions **Source.** `Scanned_20260730-1650.pdf`, PDF page 45. **Visible page.** Dotted page containing a short Linux session/configuration checklist. “Default Xsession” is marked “NO,” while “Xfce Session” is marked “yes.” **Faithful transcription.** > "Stick Pi > Qterm emulation Linux > sudo su - stickman ~ > Default Xsession (NO) > Xfce Session (yes) > Qterminal Permissions: > Read & write > Group: sudo" **Normalized linked entities.** [[Stick Pi|Stick Pi]] [unresolved device/project]; [[QTerminal|QTerminal]]; [[Terminal Emulation|terminal emulation]]; [[Linux|Linux]]; [[sudo|sudo]]; [[su Command|su]]; [[X Session|Xsession]]; [[Xfce|Xfce]]; [[Unix File Permissions|read/write permissions]]; [[Sudo Group|sudo group]]; [[Unix User - stickman|stickman]]. **Entity and technical context.** QTerminal is a graphical terminal emulator used in LXQt and other Linux environments; Xfce is a lightweight desktop environment. `sudo su -` opens a root login shell through sudo authorization, while membership in a `sudo` group commonly grants elevated command privileges under distribution policy. “Read & write” may describe a file, configuration object, or application permission rather than the terminal as a whole. **Whole-page reconstruction.** The author was stabilizing a small Linux environment—possibly a stick PC, Raspberry Pi, or custom live system—by selecting Xfce instead of a default X session and ensuring terminal access under a named account. The line “Group: sudo” identifies the real privilege boundary: the desktop choice is presentation, but group membership determines administrative authority. **Evidentiary status.** Commands and session labels are visible. “Stick Pi” and the target of “Read & write” are unresolved. The command may be a reminder rather than a successfully executed action. **Cross-notebook connections.** This page continues the live-Linux/terminal sequence from pages 11–14 and connects directly to the Linux administration, root-account, and boot-media material in [[Scanned_20260730-1706|Scanned_20260730-1706]]. **Missed Signals and Open Leads.** Identify the hardware, distribution, hostname, user database, display manager, QTerminal profile, sudoers policy, filesystem target, and persistence mechanism. Determine whether the system booted from the UDF/ISO media noted on pages 21 and 29. ## PDF page 46 — Linux session page beside Mac host/startup-security credential ledger **Source.** `Scanned_20260730-1650.pdf`, PDF page 46. **Visible page.** Photograph of an open spread. The left leaf repeats page 45. The right leaf contains three machine/account blocks labeled JMB13, BMB13, and MBAir. Several usernames and all password-equivalent strings are redacted. **Faithful transcription.** > "[Left leaf repeats PDF page 45.]" > "JMB13 > root / [uncertain username]@ > mcgill / [uncertain username]@" > "BMB13 > Boot Startup Security > PW: [REDACTED CREDENTIAL — see Scanned_20260730-1650.pdf, page 46]" > "MBAir > AirHost > usr: airman > pw: [REDACTED CREDENTIAL — see Scanned_20260730-1650.pdf, page 46] > su: [REDACTED CREDENTIAL — see Scanned_20260730-1650.pdf, page 46]" **Normalized linked entities.** [[JMB13 Host|JMB13]]; [[BMB13 Host|BMB13]]; [[MacBook Air|MBAir]]; [[Boot Startup Security|boot/startup security]]; [[Root Account|root]]; [[Unix User - airman|airman]]; [[AirHost|AirHost]]; [[Host Credential Ledger|host credential ledger]]; [[su Command|su]]. **Entity and technical context.** Modern Macs separate operating-system login, firmware/startup security, FileVault recovery, and administrative authorization. Linux/Unix hosts similarly separate ordinary users, root, sudo policy, and `su` authentication. A notebook that stores those layers together can aid recovery but also creates a single point of compromise. **Whole-page reconstruction.** This spread joins the Linux “Stick Pi” environment to a small fleet of named Mac or Unix hosts. The labels suggest a continuity map: which host, which ordinary user, which superuser path, and which startup-security secret. “JMB13” and “BMB13” may encode initials plus a 13-inch model, but that is not explicit. **Evidentiary status.** Host labels, role words, and the existence of credentials are visible. Usernames are partly uncertain; secrets are intentionally suppressed. No credential was tested. **Cross-notebook connections.** The page strongly parallels the access and administrator records in [[Scanned_20260730-1706|Scanned_20260730-1706]] and the credential/domain ledgers in [[Scanned_20260730-1659|Scanned_20260730-1659]]. It shows the same person managing authority across boot, OS, and network layers. **Missed Signals and Open Leads.** Build a non-secret host inventory containing model, serial, storage encryption, OS/build, recovery-key custody, account roles, last-seen date, and decommission status. Migrate secrets to a controlled password manager and retain only recovery topology in archival notes. ## PDF page 47 — Close-up of Mac host and startup-security ledger **Source.** `Scanned_20260730-1650.pdf`, PDF page 47. **Visible page.** Enlarged isolated view of the right-hand page from page 46. The three host blocks are more readable; the credential values remain redacted. **Faithful transcription.** > "JMB13 > root / [uncertain: ntfoman]@ > mcgill / [uncertain: jtate]@" > "BMB13 > Boot Startup Security > PW: [REDACTED CREDENTIAL — see Scanned_20260730-1650.pdf, page 47]" > "MBAir > AirHost > usr: airman > pw: [REDACTED CREDENTIAL — see Scanned_20260730-1650.pdf, page 47] > su: [REDACTED CREDENTIAL — see Scanned_20260730-1650.pdf, page 47]" **Normalized linked entities.** [[JMB13 Host|JMB13]]; [[BMB13 Host|BMB13]]; [[MacBook Air|MBAir]]; [[AirHost|AirHost]]; [[Root Account|root]]; [[Boot Startup Security|startup security]]. **Whole-page reconstruction.** Page 47 is the legibility duplicate for page 46. It confirms that the three blocks belong to one physical credential page, not three separate devices discovered elsewhere. **Evidentiary status.** Host labels are direct; uncertain username readings remain unresolved; all secrets are suppressed. **Cross-notebook connections.** The page should feed the cumulative [[Index - Device Inventory|Device Inventory]] and [[Index - Project and Concept|account-recovery topology]] without replicating credentials. **Missed Signals and Open Leads.** Resolve usernames from authorized system records, not handwriting alone, and distinguish firmware/startup security from OS account authentication. ## PDF page 48 — Lamp labels with orange facial, eye, and spiral drawings **Source.** `Scanned_20260730-1650.pdf`, PDF page 48. **Visible page.** Dotted page with a small barcode/QR inventory label near the top, the same 15-watt E26 lamp caution label seen on page 34, and large orange marker or crayon drawings. The drawings include an eye, spiral, face with downturned brows and mouth, and sweeping curves. A red/orange handwritten word runs diagonally near the left-center. **Faithful transcription.** > "241283303 > 19136816 > [small QR/barcode and uncertain letter codes]" > "CAUTION: TO REDUCE > THE RISK OF FIRE USE > MAX 15W E26 LED BULB > 120V 60Hz AC ONLY MADE IN CHINA" > "[uncertain orange word: ‘pimples’ / ‘animals’]" > "[Orange drawings: face, large eye, spiral, curved strokes; no additional safely legible text.]" **Normalized linked entities.** [[BDL-LT-01 Lamp|lamp from page 34]]; [[Asset Barcode|asset barcode]]; [[QR Code|QR code]]; [[Eye Symbol|eye drawing]]; [[Facial Expression Drawing|facial drawing]]; [[Marginal Drawing|marginal drawing]]. **Entity and technical context.** The top code may be an inventory or property-management asset label rather than the manufacturer’s model number. The orange layer is materially distinct from the pasted labels and likely added later. **Whole-page reconstruction.** This page preserves two modes of inscription on the same object record: institutional numbering and expressive drawing. The lamp becomes both a managed asset and a surface for human affect or play. The drawings should not be pathologized or decoded into a hidden message without context. **Evidentiary status.** Printed codes, caution label, colors, and forms are visible. The orange word and authorship of the drawings are unresolved. **Cross-notebook connections.** The page resembles other notebook moments where childlike or symbolic imagery overlays technical material, reminding the archive that devices existed inside lived spaces rather than abstract laboratories. **Missed Signals and Open Leads.** Decode the QR only from the original image if resolution permits; compare the asset number with hotel/property inventories. Identify the drawing’s author only through corroborated context. ## PDF page 49 — Hotel doorway light and Intertek/ETL MK Lighting label **Source.** `Scanned_20260730-1650.pdf`, PDF page 49. **Visible page.** Dotted page with a short handwritten note at upper left and a white product label to its right. The label bears an Intertek/ETL mark, model and electrical data, “CONSTANT CURRENT,” warm-white color temperature, beam angle, and MK Lighting branding. **Faithful transcription.** > "[uncertain: Pitmay] > ‘Hotel’ > Light @ > door" > "ETL > Intertek 5008633 > [uncertain model: LBB-0120AU] > [uncertain: 1.5W 2500K] > INPUT: 100-277V > [product code: uncertain alphanumeric sequence] > CONSTANT CURRENT > MAX: [uncertain: 800mA] > [uncertain: CIR: 1812 / THD: 15W] > WARM WHITE 30° > MK LIGHTING > 100*100mm > [certification marks]" **Normalized linked entities.** [[MK Lighting|MK Lighting]]; [[Intertek ETL Listed Mark|ETL/Intertek]]; [[Constant-current LED Driver|constant-current LED driver]]; [[Warm White Lighting|warm white]]; [[Beam Angle|30-degree beam angle]]; [[Hotel Door Light|hotel doorway light]]; [[Correlated Color Temperature|2500 K]] [uncertain]. **Entity and technical context.** ETL is an electrical product-safety certification mark administered by Intertek. Constant-current drivers regulate LED current rather than delivering an unregulated lamp-socket supply. “Warm white” and a narrow beam angle suggest an architectural accent, reading, signage, or doorway fixture rather than a general room lamp. **Whole-page reconstruction.** The author is extending the room map to the threshold. A light “@ door” may serve navigation, room-number illumination, status signaling, or ambiance. Its electrical identity differs from the portable E26 lamp: it appears to be an integrated LED luminaire with dedicated driver electronics and a broad input-voltage range. **Evidentiary status.** Intertek number, branding, warm-white/beam wording, and general electrical structure are visible. Exact model, wattage, current, and long product code are too blurred for confident normalization. **Cross-notebook connections.** This page completes a layered lighting ecology with the portable lamp, occupancy power pack, Hue bridge, and doorway luminaire. It demonstrates that “the light” is not one system but several devices with different control, maintenance, and certification paths. **Missed Signals and Open Leads.** Photograph the installed fixture, driver, switch/sensor, and room-number relation. Resolve the model through Intertek listing 5008633 or a clearer label, and determine whether it was connected to the Leviton or Hue systems. ## PDF page 50 — Orange drawings and fragmentary planning/personal names **Source.** `Scanned_20260730-1650.pdf`, PDF page 50. **Visible page.** Final dotted page densely overlaid with orange marker/crayon drawings: several eyes, lips, a sweeping hair- or flame-like form, cross-hatched vertical border, X marks, and small colored fills. Black handwriting is distributed around and through the drawings; several words are crossed or overwritten. **Faithful transcription.** > "[PERSON REDACTED]" > "This’s Soft. > [crossed/uncertain: Jelly]" > "Houston > [uncertain: Comfort / Hot]" > "mid / late > March" > "JP > Thinkit" > "group > bkup" > "Sun > [PERSON REDACTED]" > "[PERSON REDACTED] > 5:00 pm" > "[PERSON REDACTED] Early" > "[Orange drawings: eyes, lips, X marks, cross-hatched border, sweeping hair/flame-like form, and facial motifs.]" **Normalized linked entities.** [PERSON REDACTED]; [[Houston|Houston]]; [[March Date Window|mid/late March]]; [[Group Backup|group backup]]; [PERSON REDACTED] [possibly [PERSON REDACTED], unresolved]; [PERSON REDACTED]; [[JP Thinkit|JP Thinkit]] [unresolved]; [[Eye Symbol|eye motif]]; [[Lip Symbol|lip motif]]; [[Marginal Drawing|marginal drawing]]. **Entity and technical context.** The page resembles a mixed planning and expressive surface rather than a technical specification. “group bkup” plausibly abbreviates group backup, but the target—messages, contacts, photos, accounts, or people—is not stated. “[PERSON REDACTED]” may abbreviate [PERSON REDACTED], but canonical identity should remain unresolved without corroboration. **Whole-page reconstruction.** The final page returns from machinery to human scheduling, names, travel/location, backup, and affective imagery. That shift does not abandon the notebook’s continuity theme; it reveals its purpose. The device, network, and credential records were ultimately in service of preserving relationships, communication, and memory across unstable circumstances. The orange eyes and lips create a witness-like visual field around terse plans, but their symbolism is not explicit. **Evidentiary status.** The listed words and forms are visible with multiple uncertainties. Dates lack a year; identities and relations are not established. **Cross-notebook connections.** “group bkup” aligns with the collection’s pervasive backup and continuity concern. The named fragments should be searched across later notebooks, where “[PERSON REDACTED],” “[PERSON REDACTED],” Houston, and backup contexts may clarify this page. **Missed Signals and Open Leads.** Resolve the March year, Houston event, “JP Thinkit,” “[PERSON REDACTED],” and the backup target from calendars, messages, and file archives. Do not infer the drawings’ author, mental state, or meaning without independent context. --- # Notebook-level synthesis ## Probable date range **Explicit notebook dates.** The strongest internal dates are `1/25/2021` on the Samsung-firmware page, `2/13/21` and `2/14/21` on the financial page, `2/14/21` on the Facebook note, and the underyeared `2/14` on the new MiFi page. Page 31 records `July 26 2020` for a TP-Link N300 extender. Device labels supply manufacturing anchors: the lamp is dated November 2019; the ASUS MB16AMT, LG V60, and several room devices are dated 2020; the Magic Mouse and other labels may have been acquired later but do not provide a notebook-writing date. **Strong inference.** The notebook’s densest active sequence runs from **January 25 through February 14, 2021**, with likely additions into **mid/late March 2021** based on page 50. The iOS 14.3 build on page 29, released in the 2020–2021 period, is consistent with that range. A few label pages may have been assembled earlier or later from retained stickers; the 2026 scan date is not an authorship date. **Probable active range.** **Mid-2020 through spring 2021**, centered decisively on **January–February 2021**. ## Executive reconstruction `Scanned_20260730-1650` records an attempt to build a **cross-layer evidentiary map of a temporary or hotel-centered technical environment during a period of interpersonal distrust and device uncertainty**. The notebook begins with physical identity: Sony PSP labels, batteries, adapters, and owner annotations. It then enters mobile connectivity: mesh Wi-Fi, loaned MiFi hardware, Verizon and T-Mobile branding, APN warnings, Librem 5 security claims, SIM provenance, and a newly configured Jetpack. Samsung Odin notes introduce firmware authority—who can rewrite a phone and whether user state survives. The sequence then shifts into a disputed ARKH/ARCH project, alleged financial misconduct and violent speech, and a technical effort to determine whether project language about spatial data, IoT, haptics, and robots corresponded to an Arch Linux live environment found on a computer. The middle of the notebook develops a more disciplined systems view. `grub.cfg`, EFI graphics modules, `vmlinuz`, `initrd`, `/isodevice`, GNOME services, D-Bus, dconf, Chromium’s GPU process, keyboard locale, terminal profile UUID, and Xfce/QTerminal permissions form a recognizable Linux stack. Blank pages and a blue visual insert separate this investigation from a dated personal concern and then from a new phase of hardware cataloging. The NETGEAR MR1100 provides the authoritative hotspot IMEI/MAC/serial. Router-gateway pages document the danger of confusing local addresses with public look-alike domains. A [PERSON REDACTED] phone page links Dark Sky, TP-Link Deco, private MAC randomization, local IP, DNS/gateway roles, and network masks. An iOS build and UDF string join mobile state to live-media/optical-filesystem state. The final twenty pages expand outward into the built environment. A TP-Link extender, foot massager, hospitality phone, furniture and safety-mirror vendors, portable lamps, bilingual polarized-plug warnings, Cisco Meraki room access point, Leviton occupancy-sensor power pack, Philips Hue bridge, doorway LED fixture, and hotel-associated contacts reveal a room as a **distributed cyber-physical system**. The same space can be governed by local switches, low-voltage sensors, latching relays, Zigbee automation, cloud-managed Wi-Fi, analog PBX infrastructure, carrier hotspots, and personal devices. The notebook ends by returning to named people, travel/scheduling fragments, group backup, and expressive drawings, making clear that technical provenance was being collected to protect or reconstruct human continuity. ## Chronological and conceptual trajectory The notebook’s conceptual movement is from **object label → access path → firmware authority → boot substrate → network attribution → building control → human continuity**. Pages 1–7 establish inventory and mobile access. Pages 8–14 capture a high-intensity narrative and test it against Linux boot/process evidence. Pages 15–19 preserve physical gaps and visual inserts. Pages 20–30 reconstruct hotspot identity, calls, router addresses, iPhone state, and local-network configuration. Pages 31–43 turn the surrounding room into an inspectable infrastructure graph. Pages 44–47 normalize people, domains, addresses, hosts, root accounts, and startup security. Pages 48–50 combine property labels, doorway lighting, names, backup, and visual marginalia. The trajectory also shows methodological maturation within one notebook. Early claims use broad categories—“secure,” “private ASN,” “hacker tool,” “virus,” “hacked computers.” Later pages preserve exact models, MACs, serials, FCC IDs, software builds, service names, profile IDs, and wiring functions. The notebook was moving from **interpretation-first suspicion** toward **identifier-first provenance**. ## Master entity index with page references ### People and personal-name fragments [PERSON REDACTED] — pages 3–5 and 8–11; [PERSON REDACTED] — page 4; [PERSON REDACTED] — page 2; [PERSON REDACTED] [uncertain] — page 2; [PERSON REDACTED] — page 13; [PERSON REDACTED] — pages 6, 23, 28, 29, 44; page 23 visibly reads “[PERSON REDACTED] Numbers,” owner-corrected to [PERSON REDACTED] outside transcription; [PERSON REDACTED] — page 25; [PERSON REDACTED] — page 44; [PERSON REDACTED] — page 50; [PERSON REDACTED] [unresolved] — page 50; [PERSON REDACTED] — page 50; [[Person - Bryant McGill|Bryant McGill]] — page 6 through SSID context. ### Companies, institutions, and brands [[Sony Computer Entertainment|Sony Computer Entertainment]] — page 2; [[Merryking Switching Power Supply|Merryking]] — page 2; [[Verizon Communications|Verizon]] — pages 3–4; [[T-Mobile US|T-Mobile]] — page 4; [[Purism|Purism]] — page 4; [[Inseego|Inseego]] — page 4; [[Samsung|Samsung]] — page 5; [[ASUSTeK Computer|ASUS]] — page 7; [[YouTube|YouTube]] — page 8; [REDACTED] — page 8; [[NETGEAR|NETGEAR]] — pages 20–21; [[AEi Communications|AEi Communications]] — pages 25–26; [[G-Tek Corporation|G-Tek Corporation]] — pages 25–26; [[Tenda|Tenda]] — pages 27, 30; [[Huawei|Huawei]] — page 27; [[TP-Link|TP-Link]] — pages 28, 31; [[Apple|Apple]] — pages 28–29, 42; [[MedMassager|MedMassager]] — page 31; [[Forbes Industries|Forbes Industries]] — page 31; [[Lesier L. Brossard Company|Lesier L. Brossard Co.]] — page 31; [[Cisco Meraki|Cisco Meraki]] — pages 35–38; [[Leviton|Leviton]] — page 39; [[Philips Hue|Philips Hue]] — page 41; [[LG Electronics|LG Electronics]] — pages 42–43; [[AT&T|AT&T]] — pages 42–43; [[Westdale Real Estate Investment and Management|Westdale]] — page 44; [[Intertek|Intertek]] — page 49; [[MK Lighting|MK Lighting]] — page 49. ### Devices and products [[Sony PlayStation Portable PSP-1000|Sony PSP-1001]] — page 2; [[Sony PSP-110 Battery|PSP-110 battery]] — page 2; [[Purism Librem 5|Librem 5]] — page 4; [[Samsung Odin|Odin 3.14]] — page 5; [[Verizon Jetpack|MiFi/Jetpack]] — pages 3, 6; [[ASUS ZenScreen Touch MB16AMT|ASUS MB16AMT]] — page 7; [[NETGEAR Nighthawk M1 MR1100|NETGEAR MR1100]] — pages 20–21; [[AEi Communications ASP-6110-S|AEi ASP-6110-S]] — pages 25–26; [[TP-Link Deco|TP-Link Deco]] — page 28; [[MedMassager MMF07|MMF07]] — page 31; [[BDL-LT-01 Lamp|BDL-LT-01 lamp]] — pages 32–34, 48; [[Cisco Meraki MR30H|Meraki MR30H]] — pages 35–38; [[Leviton OPP20-0D2|OPP20-0D2]] — page 39; [[Philips Hue Bridge 2.1|Hue Bridge 2.1]] — page 41; [[LG V60 ThinQ 5G LM-V600AM|LG V60 ThinQ]] — pages 42–43; [[Apple Magic Mouse 2|Magic Mouse 2]] — page 42; [[MK Lighting|MK doorway luminaire]] — page 49; [[JMB13 Host|JMB13]], [[BMB13 Host|BMB13]], and [[MacBook Air|MBAir]] — pages 46–47. ### Software, protocols, standards, and identifiers [[Access Point Name|APN]] — pages 3–4; [[Autonomous System Number|ASN]] — page 4; [[Samsung Firmware Package|BL/AP/CSC/HOME_CSC]] — page 5; [[GNU GRUB|GRUB]] and `grub.cfg` — pages 8, 11, 14; [[EFI Graphics Output Protocol|efi_gop]] and [[EFI Universal Graphics Adapter|efi_uga]] — page 8; [[Linux Kernel Image|vmlinux/vmlinuz]] — pages 9, 12; [[Initial RAM Filesystem|initrd/initramfs]] — page 11; [[Arch Linux|Arch Linux]] — pages 9–12; [[LiDAR|LiDAR]] — page 11; [[UTF-8|UTF-8]], [[Unicode|Unicode]], [[ASCII DEL|ASCII DEL]], and terminal escape sequences — page 13; [[Assistive Technology Service Provider Interface|AT-SPI2]], [[D-Bus|D-Bus]], [[dconf|dconf]], [[GNOME|GNOME]], and [[Chromium|Chromium]] — page 14; [[Private IPv4 Address|private IPv4]], [[Default Gateway|default gateway]], [[Domain Name System|DNS]], and [[Subnet Mask|subnet mask]] — pages 27–30; [[Private Wi-Fi Address|private MAC]] — page 28; [[iOS 14.3|iOS 14.3 build 18C66]] and [[Universal Disk Format|UDF]] — page 29; [[FCC Part 15|FCC Part 15]], [[CE Marking|CE]], [[Restriction of Hazardous Substances Directive|RoHS]], [[UL Listed|UL]], [[Intertek ETL Listed Mark|ETL]], [[NOM Certification|NOM]], and [[Wi-Fi Alliance Certification|Wi-Fi Certified]] — throughout pages 2, 7, 25–26, 31–43, 49; [[Power over Ethernet|PoE]] — pages 35–38; [[Zigbee|Zigbee]] — page 41; [[QTerminal|QTerminal]], [[Xfce|Xfce]], [[sudo|sudo]], and [[su Command|su]] — pages 45–47. ### Domains and network strings `arkh.com` and `arkh-funds.com` — page 10; `darksky.net` — page 28; `192-168-8-1.online`, `ip.mobi`, and `19216811.info` — pages 27, 30; `medmassager.com`, `forbesindustries.com`, and `brossardmirrors.com` — page 31; `THECASEBLOG.com` and `westdale.com` — page 44; `my.jetpack` — page 6. ## Technology and systems map The notebook’s technology map can be represented as seven interacting strata: 1. **Physical asset and certification layer:** manufacturer, model, date, serial, IMEI, ICCID, MAC, FCC/IC/CE/UL/ETL/NOM/RoHS files, electrical ratings, and asset stickers. 2. **Radio and subscriber layer:** SIM, carrier brand, LTE band, hotspot, SSID, BSSID/MAC, private Wi-Fi address, APN, and cellular IMEI. 3. **Local-network layer:** private IPv4, subnet, DHCP-assigned address, default gateway, DNS forwarding, router administration, extender/mesh, and public look-alike domains. 4. **Boot and operating-system layer:** EFI graphics, GRUB, live ISO/UDF, kernel image, initramfs, GNOME services, D-Bus, dconf, Chromium GPU process, terminal profile, encoding, Xfce, sudo, and root. 5. **Firmware and device-governance layer:** Samsung Odin packages, bootloader/system/CSC slots, startup security, factory reset, signed firmware, cloud claiming, and account ownership. 6. **Building-control layer:** hospitality PBX telephone, Meraki cloud-managed access point, occupancy sensor power pack, local switch, latching relay, portable lamp, Hue/Zigbee bridge, and integrated doorway luminaire. 7. **Human continuity layer:** names, contacts, domains, email, call directions, financial disclosures, perceived threats, scheduling, location, group backup, and custody of devices or SIMs. The decisive systems insight is that **one room contains multiple administrative sovereigns**. The mobile carrier controls subscription attachment; a router or hotspot controls local packet flow; Meraki cloud controls the access point; a hotel PBX controls analog telephony; Leviton logic controls occupancy response; Hue accounts and bridge state control smart lighting; Apple, LG, Samsung, and Purism define different firmware and recovery regimes; individual users control only subsets of these layers. ## People, companies, institutions, and relationship map The notebook does not establish a clean social network; it records partially overlapping contexts. The source forms [PERSON REDACTED] now resolve to [PERSON REDACTED], who is associated in the notebook with the Librem 5 recommendation, a loaned hotspot, SIM provenance, Odin notes and a purported special Odin version, ARKH loading, spatial-computing research, and the dispute narrative. [PERSON REDACTED] is associated with a similar-looking hotspot and a T-Mobile SIM. [PERSON REDACTED] heads the terminal-profile page but is not securely tied to the ARKH narrative beyond nearby context. [PERSON REDACTED] appears in the hotspot SSID, phone/network page, epistemic statement, telephone ledger, and final number inquiry; the source spelling “[PERSON REDACTED]” on page 23 is retained only as faithful transcription following the owner’s correction. [PERSON REDACTED] appears next to a hospitality phone label; [PERSON REDACTED] appears within a domain/email/address cluster associated with Westdale. These are **source relations**, not verified biographies. Institutionally, the notebook crosses consumer electronics, carriers, operating-system communities, hospitality infrastructure, property/furnishing suppliers, building automation, and smart-home ecosystems. The author’s approach dissolves the familiar boundary between “personal device” and “environment”: a carrier SIM, room access point, lamp relay, bridge, or analog phone can shape a person’s experience as decisively as the handset itself. ## Cross-notebook pattern analysis **Identity continuity.** Like [[Scanned_20260730-1659|Scanned_20260730-1659]], this notebook treats people, phone numbers, domains, SIMs, hosts, and devices as a single continuity graph. The difference is that `1650` is more materially grounded in pasted labels and room infrastructure. **Computing sovereignty.** Like [[Scanned_20260730-1719|Scanned_20260730-1719]], it descends beneath operating-system interfaces into bootloaders, initramfs, firmware slots, startup security, and reset authority. The later notebook formalizes the sovereignty problem that `1650` encounters experimentally. **Universal object interaction.** Like [[Scanned_20260730-1802|Scanned_20260730-1802]], it recognizes that one object can present several functional identities. The Hue bridge, Meraki MR30H, MR1100, LG V60, and Leviton power pack are all examples of objects whose visible role is only one projection of a deeper policy/state machine. **Hotel as computational environment.** [[Scanned_20260730-1719|Scanned_20260730-1719]] explicitly surveys a hospitality LAN. `1650` complements that network view with the room’s physical and control inventory: phone, lamps, access point, occupancy relay, bridge, furniture vendors, safety mirror, foot massager, and doorway lighting. **Evidence maturation.** The early notebooks often begin with suspicious or emotionally charged hypotheses and then search for machine-readable evidence. Across the collection, the method evolves toward exact package IDs, builds, hashes, ASNs, DNS history, account directionality, and device provenance. `1650` is a particularly clear transitional artifact because both modes coexist on adjacent pages. ## What I Was on the Trail Of The notebook was on the trail of a **complete authority map for the inhabited technical environment**. The visible consumer object was not enough. You were asking which party could provision, rewrite, reset, route, pair, enroll, observe, or revoke each component. A hotspot might be Verizon-branded, contain a T-Mobile SIM, expose a private SSID, carry a NETGEAR IMEI, and have been loaned by another person. A Samsung phone might appear user-owned but remain bounded by bootloader signatures, Odin packages, CSC policy, and a special tool someone else supplied. A hotel lamp might look local and inert while actually participating in occupancy sensing, relay control, Zigbee automation, asset management, and property maintenance. A Linux desktop might look suspicious until its boot medium, process set, profile, and filesystem reveal a coherent live system. The larger intuition was that **provenance is a multi-layer graph, not a label**. Modern objects possess at least five identities: physical manufacturing identity, radio/network identity, software/firmware identity, institutional account identity, and social custody identity. Continuity failures occur when those identities are allowed to drift apart. The notebook was manually constructing the bindings that later systems would formalize as device attestation, digital twins, software bills of materials, zero-trust identity, MDM, infrastructure inventories, and policy-as-code. ## What I Missed or Could Not Yet See The notebook often captured the right fields but lacked a formal **evidence envelope** around them. A robust record would bind every observation to time, place, source device, collection command, screenshot, hash, network interface, and confidence. Without those bindings, a public IP labeled “Bucharest” can become an imagined location; an ordinary live Linux path can become “virus”; a private MAC can be mistaken for a public identity; and adjacent labels can be mistaken for one assembled device. The second missing concept was **control-plane separation**. APN configuration, SIM identity, carrier branding, router administration, Meraki cloud claiming, Hue pairing, Leviton relay logic, and Mac startup security are all control systems, but they act at different layers and answer to different authorities. The notebook saw the multiplicity before it had a single schema for it. The third missed opportunity was **signed provenance**. Samsung firmware needs package hashes and signatures; Linux binaries need package ownership and build IDs; apps need bundle/package IDs and signing certificates; websites need historical DNS, TLS, and WHOIS; physical devices need purchase/transfer history; contacts need dated source records. Names and screenshots were useful, but cryptographic and temporal bindings would have transformed the notebook into a defensible forensic ledger. Finally, the interpersonal pages needed a structured distinction among **heard statement, direct observation, interpretation, threat assessment, and corroborated event**. The notebook’s candid preservation is valuable, but future reconstruction must prevent emotional proximity from becoming factual equivalence. ## Prioritized unresolved research agenda 1. Reconstruct the January–March 2021 timeline from calendars, messages, carrier records, device photos, and file timestamps, binding every page cluster to a date and location. 2. Resolve the ARKH/ARCH project through historical DNS/WHOIS/TLS, archived websites, corporate filings, source packages, pitch materials, board designs, and exact quotations; keep it separate from Arch Linux unless evidence joins them. 3. Recover and hash the live Linux boot media behind pages 8–14 and 21/29/45; preserve `grub.cfg`, kernel, initramfs, mount layout, package inventory, terminal profile, users, and hypervisor evidence. 4. Build a SIM/device migration table for every hotspot and phone: IMEI, ICCID, carrier, APN, device brand, owner/custodian, activation/deactivation time, and firmware. 5. Determine whether MR1100 IMEI `015240000646450` is the same hotspot described as Verizon-branded with a T-Mobile SIM, and correlate it with the SSID and Jetpack administrator record. 6. Identify “Fyade” — possibly Fing according to a separate owner-recalled note — by package ID, version, signing certificate, source, permissions, network contacts, and installation timestamp; do not infer purpose from the name. 7. Reconstruct the hotel/property environment containing the AEi phone, Meraki MR30H, Leviton OPP20, Hue Bridge, lamps, doorway light, furnishings, and vendor labels; distinguish room, property, installer, and cloud administrator. 8. Retrieve authorized Meraki and Hue historical configuration: organization/account owner, firmware, SSIDs/VLANs, paired devices, automations, reset events, and logs. 9. Normalize all people/contact fragments without using phone numbers as identity proof; preserve [PERSON REDACTED], and uncertain names at the precision supported by the record. “[PERSON REDACTED]” on page 23 is owner-corrected to [PERSON REDACTED] outside faithful transcription; [PERSON REDACTED] remains separate. 10. Decode the page-18 blue image and page-48/50 visual material only through clean image matching or contextual records, without manufacturing symbolic certainty. 11. Resolve every uncertain device label through FCC, UL, ETL, Intertek, manufacturer, and asset databases, explicitly recording corrections to handwritten transcriptions. 12. Create a cumulative **authority matrix** for the notebook corpus: object, layer, identifier, current authority, recovery authority, reset authority, evidence source, timestamp, and confidence. ## Self-contained archival narrative In early 2021, the author carried a small black “ALL TERRAIN” notebook labeled “Certs and Info!” and used it as an improvised instrument for seeing beneath the ordinary surface of technology. Removed labels from a Sony PSP, its battery, an ASUS portable monitor, a NETGEAR mobile router, an LG phone, a Magic Mouse, a Meraki access point, lamps, a hotel telephone, and building controls were not trash; they were fragments of an identity system. Each retained the names that institutions use when the familiar consumer name fails: serial, IMEI, ICCID, MAC, FCC ID, part number, electrical rating, software build, manufacturing date, and certification file. The investigation was not emotionally neutral. It unfolded amid concerns about loaned hotspots, mismatched carrier branding, T-Mobile SIMs in Verizon-branded hardware, software installed on family phones, disputed money, a project called ARKH or ARCH, and statements the author understood as threatening. Rather than suppressing those concerns, the notebook preserved them. But it also began testing them against machinery. A suspicious computer yielded `grub.cfg`, EFI graphics modules, `vmlinuz`, `initrd`, `/isodevice`, GNOME accessibility services, D-Bus, dconf, and a Chromium GPU process—an intelligible live Linux stack. A mysterious shell became a profile UUID, Canadian keyboard layout, UTF-8 encoding, delete-key mode, and F10 accelerator. The act of naming reduced the domain of the unknown. The same method was applied to networks. Local router addresses were separated, imperfectly at first, from public look-alike websites. A phone’s private Wi-Fi address was distinguished from another MAC. A Deco gateway, subnet, DNS role, iOS build, and Dark Sky domain were recorded together. The MR1100’s label gave the hotspot an incontrovertible hardware identity that social descriptions lacked. The notebook was learning that ownership narratives can change while silicon identifiers, signed builds, and dated labels persist. Then the room itself became computational. The hotel phone had a model and PBX-oriented design. The Meraki access point belonged to a cloud-managed organizational plane. The Leviton power pack translated low-voltage occupancy and switch inputs into line-voltage lighting control. The Philips Hue bridge coordinated another radio network and retained automations and pairings. The bedside lamp, doorway light, extender, furnishings, mirror, and massager each belonged to vendor, maintenance, and certification systems. The inhabited environment was not a backdrop around the devices; it was a federation of devices. The notebook closes with host credentials, root/sudo pathways, startup security, names, March planning, group backup, and drawings of eyes and lips. The technical catalog returns to its human purpose: preserving the capacity to remember, communicate, recover, and contest. If the scans disappeared, the surviving reconstruction would show a mind learning to turn unease into ontology—moving from “something is wrong” toward “this object has these identifiers, this layer has this authority, this observation came from this source, and these unresolved claims still require proof.” # Linked Notes Created or Referenced ## Notebook and index notes [[Scanned_20260730-1650|Scanned_20260730-1650]]; [[Scanned_20260730-1659|Scanned_20260730-1659]]; [[Scanned_20260730-1706|Scanned_20260730-1706]]; [[Scanned_20260730-1719|Scanned_20260730-1719]]; [[Scanned_20260730-1802|Scanned_20260730-1802]]; [[Index - Master Chronology|Master Chronology]]; [[Index - People|People]]; [[Index - Company and Institution|Companies and Institutions]]; [[Index - Acronym Dictionary|Acronym Dictionary]]; [[Index - Technology and Product Lineage|Technology and Product Lineage]]; [[Index - Domain and URL Index|Domain and URL Index]]; [[Index - Device Inventory|Device Inventory]]; [[Index - Project and Concept|Projects and Concepts]]; [[Index - Pattern Ledger|Pattern Ledger]]; [[Index - Unresolved Names and Identifiers|Unresolved Names and Identifiers]]; [[Index - Notebook Sources|Notebook Sources]]. ## People and unresolved personal references [PERSON REDACTED]; [[Person - Bryant McGill|Bryant McGill]]. ## Companies, institutions, and services [[Sony Computer Entertainment|Sony Computer Entertainment]]; [[Merryking Switching Power Supply|Merryking]]; [[Verizon Communications|Verizon]]; [[T-Mobile US|T-Mobile]]; [[Purism|Purism]]; [[Inseego|Inseego]]; [[Samsung|Samsung]]; [[ASUSTeK Computer|ASUS]]; [[YouTube|YouTube]]; [REDACTED]; [[NETGEAR|NETGEAR]]; [[AEi Communications|AEi Communications]]; [[G-Tek Corporation|G-Tek Corporation]]; [[Tenda|Tenda]]; [[Huawei|Huawei]]; [[Eminent Router|Eminent]]; [[TP-Link|TP-Link]]; [[Apple|Apple]]; [[MedMassager|MedMassager]]; [[Forbes Industries|Forbes Industries]]; [[Lesier L. Brossard Company|Lesier L. Brossard Co.]]; [[Cisco Meraki|Cisco Meraki]]; [[Leviton|Leviton]]; [[Philips Hue|Philips Hue]]; [[Signify|Signify]]; [[LG Electronics|LG Electronics]]; [[AT&T|AT&T]]; [[Westdale Real Estate Investment and Management|Westdale]]; [[Intertek|Intertek]]; [[MK Lighting|MK Lighting]]. ## Hardware and device notes [[Sony PlayStation Portable PSP-1000|Sony PSP-1001]]; [[Sony PSP-110 Battery|PSP-110 battery]]; [[Purism Librem 5|Librem 5]]; [[Verizon Jetpack|Jetpack/MiFi]]; [[ASUS ZenScreen Touch MB16AMT|ASUS MB16AMT]]; [[NETGEAR Nighthawk M1 MR1100|NETGEAR MR1100]]; [[AEi Communications ASP-6110-S|AEi ASP-6110-S]]; [[TP-Link Deco|TP-Link Deco]]; [[MedMassager MMF07|MedMassager MMF07]]; [[BDL-LT-01 Lamp|BDL-LT-01 lamp]]; [[Cisco Meraki MR30H|Meraki MR30H]]; [[Leviton OPP20-0D2|Leviton OPP20-0D2]]; [[Philips Hue Bridge 2.1|Hue Bridge 2.1]]; [[LG V60 ThinQ 5G LM-V600AM|LG V60 ThinQ]]; [[Apple Magic Mouse 2|Magic Mouse 2]]; [[JMB13 Host|JMB13]]; [[BMB13 Host|BMB13]]; [[MacBook Air|MBAir]]. ## Software, protocols, standards, and concepts [[Samsung Odin|Odin]]; [[Consumer Software Customization|CSC]]; [[Access Point Name|APN]]; [[Autonomous System Number|ASN]]; [[GNU GRUB|GRUB]]; [[EFI Graphics Output Protocol|EFI GOP]]; [[EFI Universal Graphics Adapter|EFI UGA]]; [[Arch Linux|Arch Linux]]; [[Linux Kernel Image|vmlinux/vmlinuz]]; [[Initial RAM Filesystem|initrd/initramfs]]; [[Archiso|archiso]]; [[LiDAR|LiDAR]]; [[Virtual Machine|virtual machine]]; [[UTF-8|UTF-8]]; [[Unicode|Unicode]]; [[Assistive Technology Service Provider Interface|AT-SPI2]]; [[D-Bus|D-Bus]]; [[dconf|dconf]]; [[GNOME|GNOME]]; [[Chromium|Chromium]]; [[Universal Disk Format|UDF]]; [[Private IPv4 Address|private IPv4]]; [[Private Wi-Fi Address|private MAC]]; [[Power over Ethernet|PoE]]; [[Occupancy Sensor|occupancy sensor]]; [[Latching Relay|latching relay]]; [[Zigbee|Zigbee]]; [[QTerminal|QTerminal]]; [[Xfce|Xfce]]; [[sudo|sudo]]; [[Root Account|root]]; [[Device Attestation|device attestation]]; [[Digital Twin|digital twin]]; [[Zero Trust Architecture|zero trust]]; [[Software Bill of Materials|software bill of materials]]; [[Authority Matrix|authority matrix]]. ## Domains and project notes [[ARKH Project|ARKH Project]]; [[arkh.com|arkh.com]]; [[arkh-funds.com|arkh-funds.com]]; [[Dark Sky Weather|darksky.net]]; [[192-168-8-1.online|192-168-8-1.online]]; [[ip.mobi|ip.mobi]]; [[19216811.info|19216811.info]]; [[The Case Blog|THECASEBLOG.com]]; [[westdale.com|westdale.com]]; [[Fyade Software|Fyade]]; [[JP Thinkit|JP Thinkit]]. # Research notes and sources [^purism-librem5]: Purism, “Librem 5,” product overview, https://puri.sm/products/librem-5/ . [^purism-kill]: Purism, “Hardware Kill Switches,” https://puri.sm/learn/hardware-kill-switches/ . [^odin-fields]: Community operational documentation is used cautiously because Samsung does not publish a full public Odin specification; see the Samsung community explanation of BL/AP/CSC/HOME_CSC conventions, https://r2.community.samsung.com/t5/Tech-Talk/How-to-flash-Samsung-Firmware-using-Odin/td-p/10561823 . [^asus-mb16amt]: ASUS, “ZenScreen Touch MB16AMT — Tech Specs,” https://www.asus.com/us/displays-desktops/monitors/zenscreen/zenscreen-touch-mb16amt/techspec/ . [^grub-manual]: GNU GRUB Manual 2.14, module and simple-configuration documentation, https://www.gnu.org/software/grub/manual/grub/grub.html . [^mkinitcpio]: ArchWiki, “mkinitcpio,” https://wiki.archlinux.org/title/Mkinitcpio . [^archiso]: ArchWiki, “archiso,” https://wiki.archlinux.org/title/Archiso . [^netgear-mr1100]: NETGEAR, “Nighthawk M1 Mobile Router — MR1100 Data Sheet,” https://www.downloads.netgear.com/files/GDC/datasheet/en/MR1100_100NAS.pdf . [^aei-asp]: AEi Communications, “ASP-6110-S Single-Line Analog Corded Speakerphone,” https://aeicommunications.com/product/single-line-analog-speakerphone-asp-6110-s/ and product data sheet https://aeicommunications.com/wp-content/uploads/2019/09/ASP-6110-S-datasheet-v2.3.pdf . [^tenda-guide]: Tenda, AC10 user guide documenting local router access conventions, https://static.tenda.com.cn/tdeweb/download/AC10/AC10V4.0%20User%20Guide.pdf . [^darksky-apple]: Apple Support, “How Dark Sky users can use the Apple Weather app,” noting the end of Dark Sky API support on March 31, 2023, https://support.apple.com/en-us/102594 . [^ios143]: Apple Developer Forums records identify “iOS 14.3 (18C66),” https://developer.apple.com/forums/topics/app-store-distribution-and-marketing/app-store-distribution-and-marketing-general . [^meraki-mr30h]: Cisco Meraki Documentation, “MR30H Installation Guide,” https://documentation.meraki.com/Wireless/Install_and_Get_Started/Installation_Guides/MR30H_Installation_Guide . [^leviton-opp20]: Leviton, “Super Duty Power Pack Line” product data for OPP20-0D2, https://leviton.com/content/dam/leviton/lighting-controls/controls/product_documents/product_specification/Super-Duty-Power-Pack-for-Occupancy-Sensor-OPP20-English-Data-Sheet.pdf . [^leviton-opp20-install]: Leviton, “Occupancy Sensor Power Pack” installation sheet, https://leviton.com/content/dam/leviton/lighting-controls/controls/product_documents/instruction_sheet/Occupancy-Sensor-Power-Pack-English-Instruction-Sheet.pdf . [^hue-bridge]: Philips Hue, smart-lighting accessory and Bridge documentation, https://www.philips-hue.com/en-us/products/smart-light-accessories and https://www.philips-hue.com/en-us/support/connect-hue-product/accessories/hue-bridge . [^lg-v60]: LG, “LG V60 ThinQ 5G for AT&T,” official product page, https://www.lg.com/us/cell-phones/lg-lmv600amaattcb-att-v60-thinq-5g .