Tax60 Methodology Appendix

This appendix is printed in every Tax60 audit binder and evidence export. 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 — the user's home base, the Puerto Rico airports (SJU, BQN, PSE), a ring around Puerto Rico, and temporary regions around the user's current travel location — and records entry and exit events.
• 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, vacation, holiday, sick), hours and payor, activity tags, exception tags with their checklists, attached documents, notes, and edits with reasons.

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 location is ever collected by Tax60's servers, which receive only encrypted data (Section 11).

Gaps. A period of six hours or more without any fix, outside a period bracketed by home-dwell visit events, is recorded as a gap. A gap of 24 hours or more produces a day marked NO DATA that only an explicit user attestation can fill. Gaps are never interpolated. 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 first-level subdivisions (states, provinces) derived from Natural Earth data; United States state boundaries from the U.S. Census Bureau TIGER/Line files where border precision matters; 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.

Buckets. Every fix resolves to one of: Puerto Rico; United States with the state or the District of Columbia; 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 crosses a boundary, or whose center lies within two kilometers of one, is marked ambiguous and never decides a day by itself. 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.

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 is never classified as presence anywhere; a day's jurisdictions are those of the places where the user was on the ground or on the water.

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, 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. 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. Treas. Reg. § 1.937-1(c)(3)(iii)(A). Its treatment as a United States day is addressed in Section 7.
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)(A)), 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)(B), (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)(C)). 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, 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 (international days and possession-only days), the number credited, and the counts with and without the rule.
9. No data. A day with no fixes and no attestation is counted in no jurisdiction and is listed as NO DATA. It is not a Puerto Rico day.

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. 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 intersected with the day's jurisdiction segments to produce hours per jurisdiction; a session that spans a jurisdiction change is split at the change and flagged for the user's confirmation. Hours are attributed to the payor the user selected. 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 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 that a day of presence in both Puerto Rico and the United States is a day of presence in Puerto Rico. The regulation does not state whether such a day is also a day of presence in the United States for purposes of alternative 3 and the Puerto Rico-days-versus-United States-days comparisons. Section 7 states how the binder handles this.

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. Dual-day treatment: two United States day counts

Because the regulation does not state whether a day spent in both Puerto Rico and the United States also counts as a United States day, the binder computes and prints two United States day counts and labels every figure that depends on them:

• Conservative count — dual-presence days are included as United States days. This count is used for every pass/fail result, warning, and pace figure in the app and the binder. It is the count that yields the smaller number of Puerto Rico-favorable outcomes.
• Allocation count — dual-presence days are excluded from United States days, so that each day is allocated to one place, as the regulation does for days shared between two possessions (Treas. Reg. § 1.937-1(c)(3)(iii)(B)). This count is printed beside the conservative count and labeled "practitioner reading."

Presence-test alternative 3 (the 90-day United States cap), the Puerto Rico-days-versus-United States-days condition in alternative 4, and the condition for the 30-day travel rule are each shown under both counts. Days in the dual-presence category are marked us_day_basis = dual in the ledger. The reader can apply either treatment from the printed figures.

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, edit, document, and profile version is serialized, hashed with SHA-256, and encrypted with the user's key. The hash of the plaintext and the ciphertext are uploaded to Tax60's servers 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 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, and Tax60 cannot alter a record's content, because it cannot read it.
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 decrypting it, 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.
• 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. Because Tax60 cannot read the record, the declaration addresses the system and the chain, not 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. Every record was encrypted on that device with AES-256-GCM using a key generated on the device and held only by the user (wrapped in the user's iCloud Keychain and recoverable from a recovery phrase the user holds). PLUSH LLC's servers (a managed PostgreSQL database and private object storage hosted on Amazon Web Services in the us-east-2 region, Ohio, United States) stored ciphertext and the signed hash commitments described in Section 9, together with account and device metadata. Tax60 holds no decryption key and has at no time had the ability to read, alter, or produce readable versions of the user's location, jurisdiction, day, hours, payor, document, or decree data. This binder was generated on the user's device, or in the user's browser from data decrypted there, by the user, and its contents were not seen by Tax60. 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 underlying encrypted data is governed by the retention tier the user selected, printed above: Full evidence keeps raw location sample chunks for the life of the decree plus seven years; 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 placed by the user, 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 act60-2026.09.1. 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.