Logbook Hygiene Rules

Hamtrax keeps your logbook organized by refusing bad data up front instead of cleaning it up later. Every way a contact can enter or change in your logbook — the QSO form, the live activation logger, the Hunting page, the CLI, file and QRZ imports, and later edits — passes through the same filing checks before anything is saved.

This page lists all of those rules in one place. Filing is the part that is never negotiable; the one place Hamtrax deliberately flags a problem rather than refusing the save is a contact you log during a live activation, where turning away a QSO mid-pileup would cost you the contact.

The one rule behind everything

A contact can never sit in a folder it doesn't match.

Every save is checked against its destination folder. If the contact and the folder disagree, Hamtrax rejects the save and tells you why — a contact is never quietly filed somewhere it doesn't belong.

What each folder accepts

Folder	What it accepts
All Contacts (root)	Folders only — the complete view, not a contact destination
Activations and Hunting (categories)	Folders only — pure containers
An activation folder (e.g. KA8H@US-1515-20260301)	Only contacts made at that folder's park
A monthly hunting folder (e.g. June 2026)	Contacts with no MY activation identity in that UTC month; a program-scoped folder also requires the same Hunt program and a valid reference for it
Your custom folders	Only contacts no program claims — no park, no repeater, no foreign country. A program contact an older version filed there stays editable in that same folder

These matching rules — program/reference for activations, and UTC month plus a valid reference for the same Hunt program in program-scoped hunting folders — are the heart of auto-organization. Released POTA YYYY-MM folders deliberately retain month-only handling for blank-program legacy contacts, but still reject an explicit other program; future siblings cannot search, reuse, or absorb that POTA row. Contact rows display the UTC day and time they are stored under (unless you opt into local display in Settings → Preferences → Logbook), so a contact can never look like it landed in the wrong month.

An automatic folder must also identify exactly one supported program and carry a valid park reference or monthly key. Hamtrax blocks new or moved contacts when that identity is missing, malformed, or contradictory. Older folders are interpreted only when their saved details point to one unambiguous answer; existing records stay visible while an unresolved case waits for attention instead of being guessed into a different folder. In the Logbook folder tree, those unresolved folders are listed under an Unrecognized program heading — fully visible and still openable, exportable, deletable, and, for an activation folder whose park reference is the problem, repairable with the folder-header edit action. See Folders.

Why park, and deliberately not date

An activation folder checks the park and not the date, because a real activation routinely crosses 0000 UTC — an evening outing west of UTC crosses it almost every time, and those post-midnight contacts genuinely belong to that session. A date rule here would reject your own live log.

That matches how POTA counts them:

"Multiple activities at the same park in the same state/province/entity and the same UTC day count as a single activation, provided that the ten or more QSOs combined were made."

— POTA Rules

The Add/Edit form's folder chooser additionally checks an entered date against the activation's inclusive UTC session-day span. It accepts both days of an overnight session instead of forcing every contact onto the opening day, and it does not treat an abandoned open folder as active today. This choice-time check preserves the live logger's ability to cross midnight.

Monthly hunting folders are the opposite case and do hard-check the date: nothing about a hunt spans months, so the UTC month is exact. They also reject MY activation identity because a contact made from a park belongs to the activation/P2P log, not the month. A program-scoped monthly folder additionally requires the same Hunt program and a valid reference for it; released POTA YYYY-MM folders preserve month-only compatibility for blank-program legacy contacts while blocking an explicit other program.

When you log a contact

• A record never disappears during repair. An activation contact's activation ID is also its folder ID, so Hamtrax restores that exact folder if an older saved copy is incomplete or points elsewhere. A non-activation contact with no folder ID at all is filed by its own program: a blank or legacy program keeps POTA's released YYYY-MM month, while a registered Hunt program — DX Chasing or Repeaters — gets that program's own month. If a saved folder has not loaded on the current device — or an older folder's program/reference metadata is unresolved — the contact stays visible where it was saved and repair waits. So does a contact no Hunt program can claim: an unknown program, a program Hamtrax doesn't hunt, a reference that program rejects, or MY activation identity that belongs in an activation folder. Nothing is created for those, so a month you never hunted never turns up empty in your folder tree. Hamtrax never guesses a replacement folder.
• Choosing a folder and filling the form work in either order. The full form's Folder dropdown starts on Auto-organize for a general Add Contact, or on the launch folder for an activation/custom handoff. A fresh form offers every valid destination; untouched date/time and profile-location defaults do not count as entered facts. Existing values disable incompatible folders with a readable reason. A folder selection may supply missing identity and constrain fields, but it never silently rewrites conflicting entered or saved facts. See the form's folder rules.
• A custom folder refuses a contact that belongs to a program — at every door. The importer has always kept POTA, DX, and repeater contacts out of custom folders; the full form, a custom folder's quick-add card, the CLI, edits, Move, and Merge now apply the same rule, and the cloud checks it once more before accepting the save. In the full form, the moment a park, a repeater, or a foreign country makes the contact a program's, every custom folder greys out with the reason beneath its row — POTA contacts are filed in their monthly Hunting folder. — New beside Folder is disabled with that same reason, and a custom folder you had already chosen hands the contact to Auto-organize, which files it in its program's folder; remove that detail and your folder comes back. A custom folder's quick-add card refuses such a save with the same message. Contacts no program claims — no activity at all, a program Hamtrax doesn't run such as SOTA, or a station in your own country — go wherever you like. A foreign country counts as one only once Hamtrax knows your own: the country your callsign or profile places you in, or failing that your browser's locale.
• Adding a contact to an activation pre-locks its identity. A selected activation supplies missing MY program/park and locks its park, accepted UTC date, and operating location. A compatible entered date survives, including a later day of an overnight session; otherwise a fresh form uses the recorded session's starting day. An entered date outside that session makes the destination unavailable.
• A hunt made from a park files into your activation. While exactly one activation is live, hunted contacts join its folder rather than the monthly one — they were made at that park, so the activation folder's park rule accepts them. A POTA hunt joins as park-to-park; a DX contact joins as an ordinary activation QSO, because park-to-park needs the other station to be at a park too. With no live activation (or several live activations), or when a contact is dated before the activation's UTC day, the contact stays monthly. See Hunting From a Park.
• Logging a repeater contact never puts it in your activation. POTA doesn't count a contact made through a repeater toward an activation, so the contact form disables Their Repeater while your own park is set. A repeater contact you log while activating — from the full form or its own month folder in the Logbook — files into its repeater month. See Repeaters.
• Hunted contacts, quick-add cards, and CLI logging use the same door. There is no side entrance: every entry surface saves through the same validation as the full QSO form. Program-bound monthly forms require a real selected target, use that target as the source of the worked-station location, and reject future contact times. A monthly compact-to-full handoff retains its program and entered date on Auto-organize, so the date still selects the program's month. The duplicate rules below preserve valid POTA and DX contacts on different bands or modes.
• The full form reviews before it creates. Auto-organize previews one exact destination using the shared manual/import filing policy, while an explicit folder choice remains authoritative; the one exception is a chosen custom folder, which hands a contact a program claims to Auto-organize. Both are re-checked against the current saved destination and any required activation history immediately before save. Otherwise, a deleted or newly incompatible selected folder produces an error, not a fallback. Monthly and custom contacts can use this device's folder copy while syncing; cloud validation still runs before the command is accepted. The write door requires an explicit activation, monthly, or custom folder ID; it cannot silently create a generic month or fall into whichever folder happens to be open. A stale activation is excluded from live routing, a missing safe automatic route requires a custom-folder choice, and a future contact creates nothing. See saving a contact.
• A callsign on your account is required to log. Contacts carry your callsign for folder naming and export.

When you edit a contact

• The selected folder constrains its defining fields. In an activation folder, the matching MY park, accepted date, and your operating location are read-only, each with an explanation. In a monthly folder, Date stays editable within that UTC month, and the same Hunt program/reference is required. Custom folders lock no field, but cannot receive a contact that belongs to a program's automatic folders. A program contact an older version filed in a custom folder stays editable there — notes, equipment, QSL details, and coordinates all save, and a country the callsign lookup fills in is never held against it — but an edit that first gives a contact a park or a repeater, even one with a foreign country, cannot keep it in that folder: Update Contact moves it to its program's folder instead, where it now belongs. If you choose a historical month before entering a date, a conflicting default of today is cleared so you enter the actual day. See folder restrictions.
• Every edit is re-checked. Even beyond the locked fields, a save that would leave the contact mismatched with its folder is rejected with a clear message.
• An edit can't create a duplicate either. Changing a hunted contact's identity so it collides with another contact you already have is refused. The Edit not applied notice uses the same program-specific duplicate rule as a new contact, including band and mode for POTA and DX. Editing unrelated details on an existing contact does not change its duplicate identity.
• Concurrent filing changes fail safely. Hamtrax re-checks the current saved folder before a contact changes membership or an automatic folder changes identity. If another change made the request stale, Hamtrax stops and asks you to reload rather than applying an old decision to newer data.
• Pending changes stay protected while syncing. An older incoming update cannot replace a newer local edit, hide a pending contact or folder, or bring back a contact you are deleting. That protection remains until the accepted result reaches this device's logbook. Permanently rejected work follows the Needs Filing rules below.
• An edit may move one contact to a compatible folder. The form starts with its current Folder selected. A different destination must accept the contact's entered and saved facts, and the move happens on Update Contact, preserving the same contact. A custom destination never accepts a contact a program claims — an activation contact, a POTA hunt, a DX contact, or a repeater contact stays in its program's folder, and that includes a program contact an older version left in a different custom folder — so an activation contact can no longer be edited into a custom folder. Unclaimed contacts move between custom folders freely. The fully updated contact must pass the destination's hygiene and duplicate checks. If the whole activation is at the wrong park, use park correction to fix it together.
• A single-contact edit is successful only after it is queued durably. Its contact and source/destination counts update locally after storage succeeds, then cloud sync follows. If queueing fails, the original contact is restored; a later permanent cloud refusal follows the review rules below.
• Dedicated custom-folder Move and Merge commands remain online and all-or-nothing. These separate row/Bulk Edit/whole-folder commands need a connection — offline, the action reads Needs a connection. Every selected contact moves or nothing changes, with at most 250 contacts at a time. Both are greyed out with a reason — Some of these contacts belong in their program's folder and cannot move to a custom folder. — whenever a contact a program claims is among those moving, and Merge only ever joins two custom folders. These limits do not apply to the single-contact edit flow. See moving contacts.

When the cloud rejects a pending command

A temporary connection or service failure stays pending and retries automatically. A resettable cloud safety pause behaves the same way: the exact idempotent command stays in the device queue, the drain stops before later rows can hammer the server, and processing resumes after the server's reset. It does not enter Needs Filing merely because it was throttled.

The emergency account safety ceiling is different because it has no timer. The exact command remains retained, the queue stops, and automatic retries pause for support review. It is never discarded or silently treated as accepted.

If the cloud permanently rejects a contact command that still needs attention, Hamtrax moves that command into the Logbook's Needs Filing review instead of losing it or pretending it synced — and tells you the moment it happens. A warning notification ("Contact needs filing — the cloud guard rejected a saved contact. Review it under Needs Filing in your logbook.") appears when the rejection lands, whether it was a new contact, an edit, or a delete, so a save that looked successful never disappears in silence. A burst of rejections (for example a rejected offline import) shows the notification once rather than once per contact. Deleting a contact that is already absent is different: the requested result is already true, so it succeeds without creating a review item.

• The original command, available contact details, and typed rejection reason stay on this browser or device. Needs Filing translates that structure into a plain outcome, reason, and next step; it never exposes a storage id or raw server message as the explanation. Each card identifies the contact by callsign and any available date, band, user-facing mode, and MY/THEIR activity references. If those details are unavailable, it says so instead of substituting an opaque id. Items survive signing out, so signing back into the same account on the same device brings the review item back. They are not cloud-backed or available on another device while they remain in Needs Filing.
• Rejected work never masquerades as the active logbook. A rejected new contact stays out of normal folder and contact views. For a rejected update, the last valid cloud copy may still appear while the failed change waits separately for review.
• The action matches the reason and command. Needs Filing does not guess that every rejection is a folder problem:

Rejected command	What Needs Filing does
New contact — folder hygiene	Says Contact not filed and offers Choose folder. Review the saved draft and select a compatible destination in the full form's Folder dropdown; Auto-organize is offered there too once the draft has a ready automatic destination, which is the only valid choice for a contact a program claims whose monthly folder does not exist yet, since custom folders refuse it. Expand parent rows to reach their leaf folders; the headings cannot hold contacts. A folder that conflicts with the draft is greyed out with its reason. The destination is checked again at Save, which either confirms filing or explains why it was refused.
New contact — contact limit	Offers View plans. A folder choice cannot fix an account limit, so Choose folder is not offered. The original command stays retained for review.
Other rejected new contact	Says the contact was not added, explains the typed reason in plain language, and keeps the command review-only. Only a create specifically classified as folder hygiene is eligible for refiling.
Rejected update	Says the original contact is unchanged and keeps the failed change review-only. It is never retried as a create, so the existing contact cannot be duplicated.
Rejected delete	An already-absent contact counts as successfully deleted and never appears here. For another definite failure, Needs Filing says the contact was not deleted and tells you to reload the Logbook before trying again. The request is never converted into a new contact.

• A contact rejected because of its folder says so. When the cloud refuses the folder an import or a save was creating, every contact aimed at it is refused too — and the review row now names that folder in place of the guard's reason: "The folder “August 2026” could not be created, so this contact had nowhere to go." That is what makes the rule above — one failed save, one notification, arriving on the contact rather than the folder — honest rather than merely quiet. Without it the row quoted a rule about a folder that does not exist, and the real cause was invisible. A contact also waits for its folder's answer before it is sent, so a folder that was merely slow — or a connection that dropped partway through an import — never turns the contacts behind it into rejections. Only a folder your logbook genuinely refused sends its contacts here.

Refiling an eligible new contact does not erase the original merely because the replacement was saved locally. Once that local save succeeds, the review item shows Saving corrected contact until the cloud accepts the replacement. Only that cloud-authoritative success removes it from Needs Filing; canceling or another rejection leaves the original available for review without creating a second recovery item. A re-rejected refile deliberately shows no notification — the review row you are looking at reverts from Saving corrected contact, and that row is the answer. The same is true when the cloud rejects an automatic folder creation: the notification arrives on the rejected contact, not the folder, so one failed save never announces itself twice.

Wrong park? The one way to change an activation's park

While a contact stays in its activation folder, its park remains locked to that activation. Correcting the whole activation changes the folder and its contacts together.

Activated US-1234 but logged the whole session under US-1243? Open the activation folder in the Logbook, tap its folder-name card, and choose Change Park from Folder options. The live activation header carries a Wrong park? button next to the park, so you can catch it mid-session. Search for the park you actually activated; Update Park arms once your pick resolves to a real park and differs from the current one.

Changing the park requires an internet connection. Hamtrax first validates the corrected folder, every contact, and the destination identity, then commits the folder and all of its contacts as one all-or-nothing change. An interruption cannot leave a half-corrected activation; retrying the same correction safely returns the completed result instead of applying it twice.

It also handles the harder case: a folder whose saved park was never usable at all — a park name stored where a reference like US-1234 belongs. Those folders sit under Unrecognized program and refuse new contacts, and correcting the park is how you get them back. You do not need a valid park in order to set one.

Three things the correction won't do:

• It won't merge activations. If another activation folder already exists for the corrected park on the same date, Hamtrax refuses the change and names the folder that's in the way. Nothing is written.
• It won't tell POTA. If the log was already submitted, arrange a replacement through POTA's log-support process. Hamtrax does not update or resubmit it; see POTA upload protections.
• It won't split an unusually large correction into risky pieces. If the activation is too large to update safely in one operation, Hamtrax leaves it unchanged rather than creating a partial correction.

When you import

• Every contact is auto-routed through its program capability. Supported activations go to that program's activation folders, supported hunts go to that program's monthly folders, and unsupported or ambiguous activity stays unchanged in a custom folder you choose — see how contacts are sorted. Three programs are installed today: POTA, DX Chasing, and Repeaters. Monthly folders are scoped to their program: a DX contact can never enter a POTA month, a POTA hunt can never enter a DX month, and a repeater contact belongs to neither, even when the months match. The rule runs in both directions: the Logbook's form, edits, Move, and Merge refuse to put a contact a program claims into a custom folder, so hand-filing can never undo what the importer decided.
• Activation and Hunting destinations can't be overridden. During import review you may exclude a contact, but you can't redirect it into a folder that doesn't match it.
• Files can't dictate their own filing. Folder paths embedded in an ADIF file are ignored; Hamtrax always re-derives the correct destination from the contact itself.
• Malformed records are rejected before they reach a folder. Contacts with an invalid or missing callsign, or an unreadable date, are turned away at the door — and every rejected or skipped record is listed with its reason, so every record is accounted for.
• Cross-program references stay honest. A SOTA or WWFF reference is never re-labeled as a POTA park, and one the file wrote in that program's own ADIF field instead of the SIG pair still counts as that activity rather than being read as a plain country chase.
• A program code that names no reference is dropped rather than read as an activation. A MY_SIG with no MY_SIG_INFO beside it identifies nothing — it can't select an activation folder and can't earn a program's credit. Some loggers stamp the log type's code on every row of a session-typed log whether or not you recorded a location, so treating it as an activation would keep an ordinary hunt out of its month for nothing. Hamtrax removes that empty half and files the contact on its hunted side. The guard rules themselves have not moved an inch: a contact that still carries a MY_SIG when it reaches a monthly folder is refused exactly as it always was. This is a decision about what an import reads, not a hole in what the guard accepts. A MY side that does name a reference is untouched, whatever program it names.
• A file import never runs against a logbook this device hasn't finished loading. Skipping duplicates means comparing your file against the copy of your logbook on this device. A device that has never finished loading that copy — a new browser or phone, or one whose site data was cleared — would read as an empty logbook, and every contact you already have would look new. Hamtrax loads the logbook first, and when it still can't confirm it has all of it the import stops before review with a plain message and a Retry, keeping your file, instead of planning a full re-import. The write door that files an import asks the same question, so the proof can't be lost between review and filing. Logging a single contact by hand is deliberately left alone — a wrong block there would end field logging on a fresh phone, and one contact is not a logbook.

Duplicate hunted contacts are blocked

The contacted callsign, program, normalized reference, and UTC day form the starting point. Each recognized Hunt program adds its own repeat-contact criteria:

Program	What must also match for a duplicate
POTA	Band, mode, and recorded park-region information. A supplied submode takes precedence over mode, so FT8 and FT4 remain distinct, as do DMR and C4FM. Time alone does not distinguish a repeat.
DX	Band and mode. Working the same station and entity on 20m and 40m remains two contacts. Time alone does not distinguish a repeat.
Repeaters	Band, mode, and time. A later conversation through the same repeater remains a separate contact.

POTA permits another contact with the same activator that UTC day when the band, mode, park reference, or park state/province changes. See POTA's repeat-contact guidance and logging requirements. Hamtrax compares the location information actually recorded: a list of states is not treated as one selected state, and a missing value is not filled by guessing. These checks do not establish which POTA account owns a callsign. An older contact with no recorded region can remain separate from an incoming record that supplies one; Hamtrax does not infer or backfill that missing history.

The contact's program controls this rule, not its folder. An older POTA hunt already stored in a custom folder still uses POTA's duplicate rule. A contact under another program stays separate even when the callsign and reference text match. An unknown or unsupported Hunt program gets no assumed daily limit; exact duplicate detection still applies during import. Contacts with a MY-side park reference, including park-to-park contacts, are outside this Hunt blocking rule and use the activation behavior below.

Imports also skip exact repeats. Exact matching compares the contacted callsign, UTC day and time, band, mode/submode, both program-qualified references, and the contacted activity's recorded region. It applies across folders and within the source. Each row is checked both as supplied and as Hamtrax will store it, so filing that adds a DX identity cannot make the same row look new on the next import. These checks block or skip new duplicates; they do not merge or delete existing contacts. Automatic POTA imports can separately add proven missing park-to-park information to one existing contact; see POTA contact sync.

The cloud checks competing saves too. Before accepting a create or an identity-changing edit, the cloud checks the same duplicate rules against saved contacts. Competing imports or a manual save arriving during an import cannot both add a contact that those rules reject. This does not impose exact-contact rejection on manual custom-folder or activation logging where repeats are allowed. Older mobile builds that still save directly to the database remain outside this protection until updated.

While logging as the activator, problems are flagged — not blocked

This activation warning policy is separate from the Hunt duplicate checks above. The live activation logger always saves to that activation's folder, with the park, date, and your operating location locked. But the quality of what you type is deliberately never a gate. Refusing a contact mid-pileup would cost you the QSO, so Hamtrax logs it and flags it instead.

Five things get flagged on a contact you log as the activator:

Flagged	What it means
Duplicate	The same callsign is already logged in this activation. Hamtrax's current activation warning checks callsigns regardless of frequency or mode; it does not block saving.
Callsign doesn't look valid	The callsign fails a basic sanity check (letters and digits, sane length, no stray characters). Portable and prefixed calls like SV2/HB9ABCD/P pass.
No frequency logged	The frequency field was empty.
No mode logged	The mode field was empty.
Logged in the future	The contact's time is later than now.

You see each one twice, from one shared checker so they can never disagree: the contact's row is shaded red in the Log tab list with the reason stated beneath its callsign, and the Finish tab counts them all in a red N issues found banner whose Edit link jumps back to the offending row. Fixing the contact clears both. The banner also offers Ignore and proceed anyway per issue, for when you decide a flag doesn't need fixing — that dismisses it from the Finish banner only: the row stays red, a visible ignored count with Restore makes the decision reversible on the spot, and a resumed session flags everything fresh. See Activating.

Folder operations follow the same discipline

• Only custom folders are yours to create and reorganize. Create them from the custom-folders section, the contact form, or on the spot while moving contacts. Category folders and automatic activation/monthly folders keep their place under their program, and dedicated Move/Merge controls stay custom-only and move only contacts no program claims. The full contact form separately permits compatible single-contact reassignment; it never changes a destination's rules. A display label never changes folder identity, and a rename that impersonates a different activation's park, date, or callsign is refused. A folder whose stored program cannot be resolved remains visible under Unrecognized program with its contacts intact.
• Deleting a folder never spills its contacts upward. Folder deletion requires an internet connection and covers at most 250 contacts at a time, so Hamtrax can account for the complete tree before changing anything. Deleting removes the folder tree and its contacts together as one all-or-nothing change; a parent category is never used as a fallback destination. If the operation is too large to complete safely at once, Hamtrax leaves the source unchanged. QRZ sync leaves QRZ records intact when their Hamtrax contacts are deleted, and remembers known counterparts as excluded from automatic re-import.
• Keeping the contacts is a separate, deliberate choice. Deletion never quietly rescues them. Deleting a custom folder that still holds contacts reminds you that Merge keeps them; cancel deletion and choose the destination in that separate action.
• Merging is a move plus a delete, judged as one change. Merge moves every contact of a custom folder into another custom folder and then deletes the emptied folder together with its notes, photos, and stream links. It obeys the dedicated Move command's connection, 250-contact, and all-or-nothing rules, it is never offered on an empty folder or on an automatic one, and it is greyed out, with the reason shown, while the folder still holds a contact a program claims.

Why so strict?

Because the payoff is a logbook you never have to tidy. Every activation folder is exactly one program reference on one outing, and every program-scoped monthly folder is exactly one program and month of hunting. Released POTA months preserve month-only compatibility for blank-program legacy contacts and reject explicit other programs. The guardrails do the organizing so you can spend your time on the air.

The rules aren't Hamtrax's opinion, either. Each one is shaped to the way POTA actually counts activations, credits hunters, and accepts logs — the folder name is POTA's own log filename, the UTC day is POTA's scoring unit, and an activation folder exports as the single ADIF file POTA asks for. A clean logbook here is a submittable log there.

Related pages

• Folders
• Manual Logging
• Importing Contacts
• Logging Overview
• Hunting From a Park — the park-to-park routing rule in full