Tax60 Methodology Appendix

This appendix is printed in every Tax60 audit binder. It describes how the record was captured, classified, and computed; the authority for each rule applied; how to read provenance labels; what the contemporaneity proof establishes; and who held custody of the data. It is published at https://tax60.app/legal/methodology and is part of the Tax60 Terms of Service.

Record facts for this binder

---

1. Purpose and scope

This binder is a record of physical presence by calendar day and of hours worked by jurisdiction, with attached evidence, for the tax year stated above. It is prepared to support the presence test of Treas. Reg. § 1.937-1(c) and the source of compensation for services under IRC § 861 and Treas. Reg. § 1.861-4. It does not decide the tax-home test (Treas. Reg. § 1.937-1(d)) or the closer-connection test (Treas. Reg. § 1.937-1(e)); where the binder includes a questionnaire on those subjects, it collects the user's answers and documents and makes no determination. Bona fide residency under IRC § 937(a) requires all three tests.

Tax60 is a record-keeping tool. Nothing in this binder is tax, legal, or accounting advice, and every computed figure is an arithmetic statement about the recorded facts under the rules stated here.

2. Capture method: what was collected and what was not

Collected on the user's iPhone, with the user's permission:

• Significant-location-change fixes. iOS delivers a location when the device moves on the order of 500 meters or more, typically every few minutes while moving and rarely while stationary. Each fix carries latitude, longitude, a horizontal accuracy radius in meters, and a timestamp.
• Visit events. iOS reports arrival at and departure from places where the device dwelled, with an approximate coordinate and arrival and departure times.
• Geofence events. The app registers a small number of circular regions — a "here" region around the most recent good fix, which follows the device and whose exit is recorded as a departure; the Puerto Rico airports (SJU, BQN, PSE); a ring around Puerto Rico; and temporary regions around the user's current location while travelling — and records entry and exit events. No region is fixed around where the user lives: the app does not know, ask for, or store a home.
• Foreground fixes. When the app is open, at clock-in and clock-out, and when the user confirms a day, the app requests a short burst of location updates (up to ten seconds) to obtain a higher-quality fix.
• Work-session fixes. While the user is clocked in, the app may run a background activity session that delivers reduced-accuracy updates so that hours can be placed in a jurisdiction; this is the only reason the app declares the location background mode.
• Permission and health states. Changes to the app's location authorization (Always, While Using, Denied; Precise on or off), Background App Refresh, and Low Power Mode are recorded in the change log as coverage evidence.
• User entries. Daily confirmations, day type (work, travel or vacation), hours, trips, activity tags, exception tags with their checklists, attached documents, notes, corrections and edits with reasons, and history the user enters after the fact for a period of past days with a bulk upload (Section 8, Range-entered).

A day type is the user's own statement about the day. It changes neither how the day counts for the presence test nor where hours are placed, and a travel day is not the United States transit exception (Section 5, item 5), which needs its own recorded itinerary and attestation. Marking a day as vacation in the app — in the activity editor, or by confirming the day as vacation in the day sheet, a catch-up card or a bulk confirmation — also removes that day's clocked work: each work session with time on the day is voided, or cut back to its part on the neighboring day, and those hours leave every count. The change log records each removal as the user's own edit, which the user can undo while the Undo notice shows (about ten seconds, longer with VoiceOver or Switch Control). The one-tap confirmation from the evening notification removes nothing: a vacation stated there keeps the day's hours.

Not collected: continuous GPS traces (the app does not run navigation-grade tracking); coordinates at more than four decimal places (fixes are rounded to four decimals, about 11 meters, before storage); audio; photos other than documents the user attaches; the contents of other apps; any data from a health app; any data from third parties. No classification is done on Tax60's servers: the device classifies each fix, and the fixes and the results are uploaded to the user's Tax60 account (Section 11).

Gaps. A period of six hours or more without any fix is recorded as a gap unless the stationary dwell bridges it. Time in flight (Section 3) is not a gap. A silence of six to twenty hours between two unquarantined fixes from the primary device, with the same jurisdiction, marine band and time zone on both sides and no interruption of capture in between, is read as the device staying in that place when either (i) the two fixes lie within 250 meters of each other plus the larger of their accuracy radii (counting at most 500 meters of radius), or (ii) the "here" region recorded a departure after the first fix and no later than fifteen minutes after the second, with no device restart before it, in which case the dwell ends at the recorded departure. The stationary dwell is a data-quality device, not a legal rule: it never adds a jurisdiction to a day, because presence is read from fixes alone, and it affects only how gaps are counted and where clocked hours are placed. A gap of 24 hours or more produces a day marked NO DATA that only an explicit user attestation can fill. A gap is never interpolated into presence: it adds no jurisdiction to any day, and Section 5 (Work hours) states where hours worked during it are counted. The most common causes are the device being off or out of battery, Airplane Mode, the user changing the app's authorization to "While Using" in response to the periodic iOS prompt, or iOS suspending location delivery; the recorded permission states show which.

3. Classification: from a fix to a jurisdiction

Boundaries. Each fix is classified on the device against a bundled boundary set: national boundaries, and the boundaries of the fifty states and the District of Columbia, derived from Natural Earth 1:10m data and simplified so that the bundled outline stays within 1.5 kilometers of the source outline; Puerto Rico and the other possessions at Natural Earth's full resolution, with five small Puerto Rico islands that data omits added; the Puerto Rico coastline with the marine bands below; and a set of airport reference points. The bundle version is printed above. Classification is a point-in-polygon test against these boundaries; no external service is consulted. These lines are not surveyed lines: near a border the bundled line can lie several hundred meters to about two kilometers from the surveyed one. At Kansas City, the bundled line between Missouri and Kansas lies about 1.4 kilometers west of State Line Road; at El Paso, the bundled line between the United States and Mexico runs about 2 kilometers north of the Rio Grande, so a fix in downtown El Paso can be classified as Mexico; along the Detroit riverfront, the bundled line between the United States and Canada runs inland of the United States shore. Each fix is classified by the bundled line, and is ambiguous only when its own accuracy circle reaches it (below). A fix within about two kilometers of an international border can therefore be placed on the wrong side of it, and so can a fix near the 12-nautical-mile limit of a coast's territorial sea, which is measured from the coastline as the same data draws it, or near one of the lines that divide Puerto Rico's waters into the bands below, which are measured from Puerto Rico's coastline as the same data draws it; such a fix counts for the day as the place the bundled line puts it in. A user who was on the other side of such a line can say so for that day with I Was Somewhere Else; the statement and its reason are recorded with the day, and the location fixes are kept (Section 8). Near a line between two states, a fix on land can likewise be attributed to the neighboring state; it is a United States fix either way, and which state is named does not change how the day counts for any presence test, though it can change the states the record lists for the day and the notices the app sends about arriving in a state.

Buckets. Every fix resolves to one of: Puerto Rico; United States with the state or the District of Columbia, or without a state over water between two states' shores (below); Possession with a code (U.S. Virgin Islands, Guam, the Commonwealth of the Northern Mariana Islands, American Samoa); International with the country; or No data.

Ambiguity. A fix whose accuracy circle reaches a boundary between places that count differently for presence is marked ambiguous and never decides a day by itself. The accuracy circle has the radius the device reports for the fix, taken as at least 100 meters; no distance beyond it is considered, so a fix whose circle stops short of every such boundary is classified by the place it falls in, however near the boundary it is. A fix taken with Precise Location turned off reports a radius of a kilometer or more, so near a boundary it is more often ambiguous. The lines that divide Puerto Rico's marine bands are such boundaries, and a fix anywhere in Puerto Rico's 3–9 or 9–12 nautical-mile band is treated as the table below states. The places that count differently are Puerto Rico (its land and its waters within 3 nautical miles, which count alike, so its coastline is not such a boundary), Puerto Rico's 3–9 and 9–12 nautical-mile bands (each its own), each other possession, the United States, each foreign country, and international waters. The fifty states and the District of Columbia count alike, so a line between two states never makes a fix ambiguous: the fix is attributed to the state whose boundary contains it, or over water to the state of the nearest land. Over water within two kilometers of the line equidistant from two states' shores, or within the fix's accuracy circle of that line where the circle is larger, where the bundled shores are not precise enough to say which state the water belongs to, the fix is attributed to the United States without a state, and the record attributes it to the state named by the nearest fixes before and after it within three hours, when every such fix names the same state. This is a rule for naming the state, not for ambiguity: such a fix is never ambiguous. An ambiguous fix is resolved by neighboring unambiguous fixes, geofence events, a one-time full-accuracy request, or the user's confirmation; the resolution and its basis are recorded. Days whose classification rests on ambiguous fixes are marked with reduced confidence. Each fix is stored as it was classified when it was captured and is never altered. When the ruleset changes, the device holding the record derives it again from the stored fixes, and a fix stored as ambiguous is classified again under the current ruleset: if the current ruleset places it unambiguously, the day is derived from that place, while the stored fix keeps its original classification. A day restored from the account to another device is derived again in the same way when every fix its record counted was restored with it; a day missing any of those fixes keeps the record it was restored with.

Marine bands around Puerto Rico. No provision of IRC § 937 or Treas. Reg. § 1.937-1 states a presence rule for time at sea. The app classifies fixes over water as follows and states the basis of each band:

Any day on which the user also touched Puerto Rico land (for example, the Vieques and Culebra ferries, or day boating that departs from and returns to Puerto Rico) is a Puerto Rico day under the any-part-of-day rule in Section 5, and no attestation is required. Time in United States ports and territorial waters is classified as United States; time in a possession's waters as that possession.

Time in the air. Time in the air is never presence anywhere: a day's jurisdictions are those of the places where the user was on the ground or on the water. No provision of IRC § 937 or Treas. Reg. § 1.937-1 addresses air travel. For the substantial presence test of IRC § 7701(b), Treasury defines the "United States" to exclude "the air space over the United States" (Treas. Reg. § 301.7701(b)-1(c)(2)(ii)); the app reads the airspace over the United States, Puerto Rico, the other possessions, and foreign countries the same way. The device records no altitude or speed, so a fix taken in flight is recognized from the fixes the same device took around it. Each speed below is the distance between two fixes, less both accuracy radii, divided by the time between them, so an imprecise fix can only lower it:

1. A fix is taken in flight when reaching it from the nearest fix at least five minutes earlier, and leaving it for the nearest fix at least five minutes later, each required at least 250 kilometers per hour and one of them at least 400 kilometers per hour, with neither fix more than six hours away. Nothing on the ground or on the water sustains those speeds for five minutes; airliners exceed them in climb, cruise, and descent.
2. A fix less than five minutes older than the newest fix the device has recorded is treated as taken in flight when reaching it from the nearest fix at least five minutes and at most one hour earlier required at least 300 kilometers per hour, until later fixes decide it under item 1.
3. A fix is never taken in flight when it is a visit event, or when another fix taken one to thirty minutes before or after it shows the device moving no faster than 50 kilometers per hour even with both accuracy radii counted against standing still. A device at a gate, a connecting airport, or a hotel is on the ground, and its fixes count.

The stretch from the last fix on the ground before a flight to the first fix on the ground after it is recorded as In flight, and so is a silence of twenty minutes to six hours between two fixes on the ground that only flight could cover (at least 400 kilometers per hour). Any silence of six hours or more, before, during, or after a flight, remains a gap, because it could hide time on the ground. In flight is not a gap, places no clocked hours (time a session spends in it is shown as unplaced for the user's confirmation, and time a logged trip covers is travel, not work), and adds no jurisdiction to any day. A fix taken in flight is kept in the record with its coordinates and counted among the day's fixes, but it decides nothing. Fixes taken in flight between two fixes on the ground that lie within 50 kilometers and thirty minutes of each other are a stray reading rather than a flight: they are set aside the same way, and no In flight stretch is recorded. A logged trip never decides which fixes were taken in flight. A day on which fixes taken in flight were the only record of the United States or of Puerto Rico is queued for the user's review, and is counted as the fixes on the ground show it until the user states otherwise. A day whose only fixes were taken in flight is a NO DATA day that only the user's statement can fill.

Reverse geocoding. Place names shown in the app are for display only and play no part in classification.

4. The calendar-day convention

Treas. Reg. § 1.937-1(c)(3)(i)(A) counts a day of presence in a possession when the individual is "physically present in that possession at any time during the day," and (c)(3)(ii) applies the same phrase to presence in the United States. Neither IRC § 937, the regulation, IRS Publication 570, nor the Instructions for Form 8898 defines "day," names a controlling time zone, or contains a midnight, overnight, or majority-of-day rule. (By contrast, the foreign earned income rules in Treas. Reg. § 1.911-2(d)(2) define a "full day" as a 24-hour period beginning at midnight; § 937 uses no such rule.)

Tax60 therefore applies the following convention:

1. Each fix is assigned to the calendar date at its own coordinates. The date is computed in the IANA time zone of the fix's location (for Puerto Rico, America/Puerto_Rico, UTC−4 with no daylight-saving change). A fix taken in Miami at 11:30 p.m. Eastern belongs to that date in Miami.
2. A day's jurisdictions are all jurisdictions of all fixes assigned to that date, except fixes taken in flight (Section 3), with time ranges. A day that contains fixes in two places is a day in both.
3. Cross-check under a fixed Puerto Rico clock. The app also computes every day's classification as if all fixes were dated in America/Puerto_Rico. Any day whose bucket differs between the two conventions is flagged tz_convention_diverges, listed in the binder's day ledger with both results, and queued for the user's review. The count of such days for the year is printed above. Divergence arises only on midnight-crossing travel between time zones.
4. Overnight location is recorded but is not a rule. Where the user slept is shown for evidentiary richness and for state-law modules that use it; it plays no part in the § 937 counts.
5. Hours are dated by the day each second falls in. Each day's clock is the time zone of its first fix on the ground or on the water (a fix taken in flight, Section 3, never sets a clock). A day without such a fix that the user's own statement fills with a time zone uses that time zone: a bulk upload states, for each day, the time zone of the place where the day began — where the user was on the ground at that day's midnight or, for a day that began in the air, where the flight landed — and such a day also ends on that time zone, so the next day without a fix keeps it. Any other day without such a fix keeps the time zone of the last one before it, however long before; a day before any fix uses the time zone the iPhone is set to (which iOS sets from its location when Set Automatically is on) when the day is first recorded, and keeps it. A day runs from midnight on its own clock to midnight on the next day's clock, so consecutive days share their boundaries and every clocked second belongs to exactly one day. A day followed by one in a time zone behind it is longer than 24 hours (San Juan, then Los Angeles in winter: 28 hours); a day followed by one in a time zone ahead of it is shorter (Los Angeles, then San Juan in winter: 20 hours). This convention dates hours only: which jurisdictions a day touched is always read from its fixes under rule 1.

5. Rules applied to each day

The rules below are applied by the device to each calendar day in the order given; the rule that determined the day's treatment is printed in the ledger beside the day.

1. Any part of a day in Puerto Rico is a Puerto Rico day. Treas. Reg. § 1.937-1(c)(3)(i)(A). The same rule counts United States days: any part of a day in the United States is a United States day, subject to the exclusions below.
2. A day touching both Puerto Rico and the United States is a Puerto Rico day and is not a United States day. Treas. Reg. § 1.937-1(c)(3)(iii)(A). Section 7 states how such days are counted.
3. A day touching both Puerto Rico and another possession is a Puerto Rico day for a user whose tax home is in Puerto Rico. Treas. Reg. § 1.937-1(c)(3)(iii)(B).
4. A day wholly in another possession is neither a Puerto Rico day nor a United States day. The possessions are not part of the "United States" for this purpose (IRC § 7701(a)(9); Treas. Reg. § 1.937-1(h)). The ledger shows such days in a separate possession bucket.
5. United States transit exception. A day in the United States for fewer than 24 hours in transit between two points outside the United States is not a United States day (Treas. Reg. § 1.937-1(c)(3)(ii)(B)), provided the user did not conduct activities unrelated to completing the travel (Treas. Reg. § 301.7701(b)-3(d)). The app applies this only when the user has recorded the itinerary legs and attested that no unrelated activities took place; the attestation is printed with the day.
6. Medical exception. Days outside Puerto Rico during which the user was receiving, or was accompanying a parent, spouse, or child full-time who was receiving, qualifying medical treatment (inpatient care requiring an overnight stay, or treatment certified by a physician as required) are treated as Puerto Rico days and not United States days (Treas. Reg. § 1.937-1(c)(3)(i)(B), (c)(3)(ii)(A), (c)(4)). The app applies this only when the user has tagged the day and completed the evidence checklist; the regulation requires the supporting records to be producible within 30 days of an IRS request (Treas. Reg. § 1.937-1(c)(4)(iii)), and the tagged day's documents are indexed in the exhibit list.
7. Disaster exception. Days away from Puerto Rico within the 14-day period beginning with the date of a FEMA major-disaster declaration for Puerto Rico, or during a period covered by a mandatory evacuation order applying to the user's Puerto Rico residence, are treated as Puerto Rico days and not United States days (Treas. Reg. § 1.937-1(c)(3)(i)(C), (c)(3)(ii)(A)). Where the IRS has extended the period by notice, the app accepts the notice number and dates. The declaration number is printed with the day; the app does not apply this exception for declarations covering places other than Puerto Rico.
8. 30-day travel rule. Up to 30 days in the tax year spent outside both Puerto Rico and the United States are counted as Puerto Rico days for presence-test alternatives 1 and 2, but only if the user's actual Puerto Rico days exceed the user's actual United States days for the year, the United States days counted as Section 7 states, and never toward the 60-day minimum in alternative 2. Section 6 states the authority for this rule. It is applied at the year level and is never assigned to specific days; the ledger shows the year's count of candidate days (days spent wholly outside both Puerto Rico and the United States: abroad, in another possession, or in international waters), the number credited, and the counts with and without the rule.
9. No data. A day with no fix on the ground or on the water and no attestation is counted in no jurisdiction and is listed as NO DATA. It is not a Puerto Rico day.

The day's label. Each day carries one label, shown wherever the record shows the day — the app's calendar and lists of days, the web views of the record, the binder's ledger, and the day_kind column of the evidence bundle's day file (days.csv): a Puerto Rico day when any part of the day was in Puerto Rico under rules 1 to 3, including a day also spent in the United States, in another possession, or abroad; otherwise an international day when any part of the day was outside the United States — in a foreign country, in another possession, or in international waters, as the day's location fixes show — including a day also spent in the United States; otherwise a United States day when any part of the day was in the fifty states or the District of Columbia. A day that is none of these, because it is ambiguous or NO DATA, carries no label. A day the user has disputed with I Was Somewhere Else keeps the label of the record's own reading of the day: the places the user named are shown beside it as the user's statement and do not change its label. Until the user resolves the dispute, the day is counted the way that is less favorable to the presence tests: a day the user says was spent in the United States and not in Puerto Rico is also counted as a United States day, a day the user says included the United States is not a candidate under rule 8, and the user's statement never adds a Puerto Rico day. A day with an exception tag is labeled by the places where the user was. The label is a way of reading the record, not a presence rule: it changes no count and no presence-test result. Every count and every alternative below is computed by rules 1 to 9, so a day with any part in the United States and no part in Puerto Rico is a United States day under rule 1, subject to the exclusions in rules 5 to 7, even when its label is international; a day in both Puerto Rico and the United States is a Puerto Rico day and not a United States day under rule 2; and only a day spent wholly outside both Puerto Rico and the United States is a candidate under rule 8.

Presence-test alternatives. From the daily results the app computes each alternative in Treas. Reg. § 1.937-1(c)(1): (1) at least 183 Puerto Rico days in the year; (2) at least 549 Puerto Rico days over the year and the two preceding years with at least 60 Puerto Rico days in each; (3) no more than 90 United States days in the year; (4) United States earned income of no more than $3,000 and more Puerto Rico days than United States days; (5) no significant connection to the United States. Alternatives 4 and 5 are evaluated only from the user's attestations and are shown as "needs your input — not evaluated" until attested. A preceding year for which the record holds no day, or only days the app made with no location data and no fix (what remains where a statement was withdrawn), is a year without records: alternative 2 is shown as not evaluated until the year's counts are recorded or supplied. Alternatives 1 and 2 are always shown both with and without the 30-day travel rule; a result that depends on the rule is labeled "pass (Pub 570 rule)."

Work hours. Clocked sessions are cut to each day as Section 4, rule 5 dates them and intersected with the jurisdiction segments of that stretch of time, wherever the record files them, to produce hours per jurisdiction; time in flight (Section 3) carries no jurisdiction, so hours clocked in it are shown as unplaced until the user confirms them; a session that spans a jurisdiction change is split at the change and flagged for the user's confirmation, and a session across midnight is split between its days, so a day's hours always add up to the session's. On a day with fixes on the ground or on the water, hours worked at a time no fix places — during a gap (Section 2), before the day's first fix or after its last — count where the day's fixes put the day. When every fix that places hours that day is in one jurisdiction, they count in that jurisdiction. When the fixes are in several jurisdictions, a stretch between two fixes in the same jurisdiction counts in that jurisdiction, and a stretch between fixes in different jurisdictions, or before the first or after the last fix of such a day, is shown as unplaced. A flight the user logged bounds these stretches as a fix does, its departure in the jurisdiction it left from and its landing in the one it reached, and so makes the day one in several jurisdictions when it leaves or reaches another: the time before a departure from Puerto Rico, after the day's last fix there, counts in Puerto Rico, while the time after a landing elsewhere stays unplaced until a fix shows where the user was, and never counts in a jurisdiction no fix that day places. A flight the device recorded (Section 3) bounds them the same way, each end in the jurisdiction of the fix it took off from or landed at, and unplaced where no fix shows it. Time in flight and time at an ambiguous fix are never placed this way, and time a logged trip covers is travel, not work. No hours are placed this way in international waters; a fix there still counts as one of the day's jurisdictions. A day with no fix on the ground or on the water is shown as unplaced until the user states where they were that day, as below; on the current day, the device's provisional reading of the time since its last fix never places a day that has no fix of its own. This placement concerns hours only: it adds no jurisdiction to any day and never changes how a day counts for any presence test. A confirmation made under an earlier ruleset keeps the hours by place it stated. On a day with no fix on the ground or on the water that the user's own statement fills, hours are placed where the statement places them. When flights logged that day count on it, by the flights: before the first departure in its origin, between two flights in the connection's place and after the last landing in the destination, time in the air being travel and not work, and a part in a place the statement does not name shown as unplaced. With no flight, in the one place it names, or, when it names several, shown as unplaced. Time the iPhone recorded in flight on such a day stays unplaced. A day with fixes is placed by its fixes, as above, never by a statement's places. The evidence bundle's per-session file (work_sessions.csv) and the per-session allocations in its JSON file (tax60-export.json) report each session as the fixes alone place it, so they list the time no fix places, on any day, without a location; the day's statements (day_statements.csv, and the same JSON file), the app's totals and every other export place it as above. Compensation for services is sourced where the services are physically performed (IRC § 861(a)(3), § 937(b); Treas. Reg. § 1.861-4), with allocation on a time basis; the working day is the default unit and sub-day units are permitted, which is why hours are recorded. The binder's per-state table counts, for each state, the days on which the user was present in that state and the days on which the user worked there.

6. Authority statement

The rules in Section 5 rest on the following sources, and the binder cites each rule to the source that states it:

• Treasury Regulation § 1.937-1 (T.D. 9248, 71 FR 5001, Jan. 31, 2006; amended by T.D. 9297, 71 FR 66234, Nov. 14, 2006, and T.D. 9391, 73 FR 19370, Apr. 9, 2008): the five presence-test alternatives, the any-part-of-day rule, the dual-presence rules for Puerto Rico with the United States and with another possession, the transit, medical, and disaster exceptions, and the tax-home and closer-connection tests.
• IRC § 937, § 933, § 861, § 7701(a)(9) and Treas. Reg. § 1.861-4, § 301.7701(b)-1(c)(2)(ii) and § 301.7701(b)-3(d).
• 48 U.S.C. § 749 and Presidential Proclamation 5928 for the marine bands in Section 3.
• IRS Publication 570, Tax Guide for Individuals With Income From U.S. Territories, chapter 1, "Presence test," and the Instructions for Form 8898 (Rev. October 2024), "Presence test," item 4, and Internal Revenue Manual 21.8.1.5.2.1, for the 30-day travel rule in Section 5, item 8.

On the 30-day travel rule. This rule appears in IRS Publication 570, in the Instructions for Form 8898, and in the Internal Revenue Manual. It does not appear in Treasury Regulation § 1.937-1. Tax60 cites Publication 570 and the Form 8898 instructions for this rule, labels every figure that uses it "30-day travel rule (Pub 570)," and prints every affected count both with and without it, so that the reader can apply either treatment.

On dual-presence days. Treasury Regulation § 1.937-1(c)(3)(iii)(A) provides: "If, during a single day, an individual is physically present in the United States and in the relevant possession, that day is considered a day of presence in the relevant possession." The binder applies the rule as written: such a day is a day of presence in Puerto Rico and is not a day of presence in the United States, for every alternative and every comparison. Section 7 states how such days are counted.

On the definition of "day." No statute, regulation, publication, or form instruction for § 937 defines the term or specifies a time zone. Section 4 states the convention applied and prints the cross-check.

7. Days in both Puerto Rico and the United States

A day on which the user was physically present in both Puerto Rico and the United States is a day of presence in Puerto Rico and is not a United States day (Treas. Reg. § 1.937-1(c)(3)(iii)(A); Section 5, rule 2). Such a day is counted once, as a Puerto Rico day:

• It is included in the Puerto Rico days of alternatives 1 and 2, in the Puerto Rico days compared in alternative 4 and for the 30-day travel rule, and on Form 8898, line 5.
• It is excluded from the United States days: the 90-day United States cap of alternative 3, the Puerto Rico-days-versus-United States-days condition of alternative 4, the condition for the 30-day travel rule (Section 5, rule 8), and Form 8898, line 6.

The app and the binder keep one United States day count, computed this way, and use it for every pass/fail result, warning, notification, and pace figure. A day in the United States and in a foreign country or another possession, and not in Puerto Rico, is a United States day (Treas. Reg. § 1.937-1(c)(3)(ii)) unless the transit exception (Section 5, rule 5) applies. Days in both Puerto Rico and the United States are marked us_day_basis = dual in the ledger, and the binder prints the year's number of such days beside the United States day count. In the evidence bundle's day file (days.csv) such a day has pr_day 1 and us_day 0; in each day record of its JSON file (tax60-export.json), the United States day count is written under both of the keys usDayConservative and usDayAllocation, which keep the names earlier rulesets gave them and hold the same value. Ruleset 2026.10.19 adopted this treatment; a binder generated under an earlier ruleset carries that ruleset's appendix, which printed a second United States day count that also included these days.

8. Provenance labels

Every row in the day ledger, and every hour entry, carries one of the following labels, printed in these words:

Location fixes and server receipt times are machine records. Confirmations, attestations, edits, and entries are the user's statements, and their weight rests on when they were made (Section 9) and on corroboration (Section 10).

9. Contemporaneity proof: what the commitment chain establishes

1. On the device. Each day record, work session, trip, confirmation, edit, document, and profile version is serialized and hashed with SHA-256, and the record and its hash are uploaded to the user's Tax60 account over TLS as soon as connectivity allows, usually within minutes and, when the device is offline, when it reconnects.
2. On the server. For each uploaded record the server computes the SHA-256 hash of the exact bytes it received, refuses the record if that hash differs from the one the device computed, and creates a commitment containing the record's hash, the hash of the user's previous commitment, the server's receipt time, and an Ed25519 signature over all of these made with a server key whose public half is published with its validity period at https://tax60.app/legal/keys. The commitment is returned to the device and stored beside the record. Commitments form an append-only chain per user; the chain's latest hash and time are the chain anchor printed above.
3. What a commitment proves. That a record with exactly this hash existed no later than the server receipt time printed with it; that the record has not been altered since (an altered record produces a different hash, which will not match the chain); and that the record's position in the chain — before and after its neighbors — is fixed. Because the server signs only what it received and when, a device cannot create a commitment bearing an earlier server time than the time of upload. Because the device keeps a copy of every commitment, and each binder and every page of each calendar PDF the user downloads prints the chain anchor, a later change to a record by anyone, including Tax60, is detectable: the changed record no longer matches the commitment the user holds, and a rewritten chain no longer matches the anchor printed in earlier binders and calendar PDFs.
4. What a commitment does not prove. It does not prove that the content of the record is true; that the device's clock was correct (the device's own timestamp is stored separately and is labeled as device-reported); that a location fix was accurate; or that the person carrying the device was the user.
5. Contemporaneous capture percentage. The figure printed above is the share of days in the year whose day record received its first commitment within 72 hours of the end of that day. Imported and range-entered days are counted as not contemporaneous. The 72-hour window accommodates travel without connectivity; the ledger prints the exact commitment time for every day so the reader can apply a stricter window.
6. Verification. Any record in this binder can be verified by computing its SHA-256 hash and checking the hash and the signature against the commitment and the published server public key. The exhibit index lists the SHA-256 hash of every attached document. No cooperation from Tax60 is needed to verify a commitment.

10. Evidentiary note

• The records in this binder are corroborative. A location record from a device the user carried is a machine-generated record of where that device was; a confirmation or attestation is the user's own statement. Neither is stronger than the third-party records that examiners rely on — airline and boarding records, card and bank transactions with merchant locations, hotel folios, mobile-carrier records, toll and building-access logs — and the binder is designed to be paired with them. Days away from Puerto Rico that have a linked third-party document are marked third-party corroborated in the ledger; the exhibit index lists each document by day. A range-entered day away from Puerto Rico with a linked boarding pass or receipt is marked third-party corroborated like any other; corroboration never makes it contemporaneous.
• No tax authority, court, or tribunal has adopted a rule accepting or rejecting records of this kind by name, and Tax60 makes no claim that any authority has accepted or will accept this record. Examiners and courts weigh the evidence as a whole, and machine-generated records that conflict with a user's statements have been given greater weight than the statements.
• Ambiguous fixes, gaps, reduced-confidence days, and permission changes are shown rather than hidden, because a record that overstates its own precision invites the whole record to be discounted.
• Custodian declarations. PLUSH LLC will, on request, sign a declaration under Federal Rule of Evidence 902(11) and 902(13), or the equivalent under the rules of the forum, describing the system in this appendix and confirming that a presented record's hash appears in the commitment chain at the stated time. The declaration addresses the system, the chain, and whether a presented record matches what Tax60 stored; it does not vouch for the truth of the record's content. Requests are made under the Legal Process and Data Custody Policy (https://tax60.app/legal/legal-process).

11. Custody statement

The data in this binder was captured, classified, and computed on the user's iPhone. As each record was made, the device sent it over an encrypted connection (TLS) to the user's Tax60 account, where PLUSH LLC stores it (a managed PostgreSQL database and private object storage hosted on Amazon Web Services in the us-east-2 region, Ohio, United States), encrypted at rest and protected by access controls: only the user, the professionals the user invites, and a small number of authorized Tax60 staff, acting only for support the user asked for, security, and valid legal process, can access it. Stored records are insert-only: a correction is a new version, and the original is kept. Every record's SHA-256 hash is committed to the server-signed chain described in Section 9 when the record arrives, and the device keeps a copy of each commitment, so a later change to a record by anyone, including Tax60, is detectable. Where the record includes entries made before the user agreed to storage in their account, those entries were encrypted on the device before upload; when the user agreed, the device converted them, and each kept its original commitment and server receipt time. This binder was generated by the user, or by a professional the user invited, from the record on the user's device or in the user's account. The SHA-256 hash of every exhibit and the commitment-chain anchor are printed in this binder. Tax60 makes no claim that this record has been accepted by the Internal Revenue Service, the Puerto Rico Department of the Treasury, the Department of Economic Development and Commerce, or any other authority.

12. Retention and legal-hold statement

Retention of the raw location fixes in the user's account is governed by the retention tier in effect for the account, printed above: Full evidence keeps them for the life of the account; Balanced keeps them for three years; Minimal keeps them for 90 days. Day records, work sessions, documents, the change log, and the commitment chain are kept for the life of the account under every tier and are never deleted automatically. Any date range the user deleted is listed above with its dates; the deletion itself is recorded in the change log and cannot be removed from it.

A legal hold (an audit hold the user asked for, or a hold placed by Tax60 on receipt of legal process) suspends retention pruning, date-range deletion, and account deletion while it is in effect. The hold status at the time this binder was generated is printed above. Holds, their dates, and who placed them are recorded in the change log.

13. Versions

This appendix describes ruleset 2026.10.19. The ruleset version actually applied to this binder, the app version, and the boundary bundle version are printed in the record facts above; the app prints all three on the cover as well. Changes to the ruleset (a rule, a threshold, a citation, or the boundary data) produce a new version identifier and an updated appendix; the version history, with the effective dates of each change, is published at https://tax60.app/legal/methodology/versions. A binder generated under an earlier ruleset carries that ruleset's appendix.