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	Anything — this is your free space

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 Wrong park?. 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

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.
• Adding a contact to an activation pre-locks its identity. The park, date, and your operating location are seeded from the activation and shown as locked — they can't be typed over, so the contact can't drift away from the activation it belongs to.
• 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. No live activation (or several live activations), a contact dated before the activation's UTC day, and walkthrough practice all stay monthly. See Hunting From a Park.
• Repeater contacts are refused rather than filed while you're activating. POTA doesn't count a contact made through a repeater toward an activation, so the Repeaters hunt tab withdraws its logging controls for the duration and a save that reaches the write door anyway is rejected outright — the one place Hamtrax blocks a save during an activation instead of filing it somewhere. The order matters and is deliberate: the contact's UTC day is tested before the program's policy, so a back-dated repeater contact is never refused, and adding one from its own month folder in the Logbook always works, because a card opened on a folder never consults your activation. 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 compact and full forms share one payload/save path, require a real selected target, use that target as the only source of the worked-station location, and reject future contact times. Their duplicate key follows the award: POTA blocks the same station + park + UTC day; DX blocks the same station + entity + UTC day + band + mode.
• The global Add Contact form reviews before it creates. It previews one exact destination using the shared manual/import filing policy, then re-checks current folders and contacts immediately before save. 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, a missing safe route requires a custom-folder choice, and a future contact creates nothing.
• A callsign on your account is required to log. Contacts carry your callsign for folder naming and export.

When you edit a contact

• Folder-defining fields are locked. In an activation folder, the park, date, and your operating location are read-only, each with an explanation (e.g. "Park is locked to US-2325 for this activation."). In a monthly folder, the date is read-only. Custom folders lock nothing. These locks stay put even now that a park can be corrected — the park changes for the whole folder at once, never on one contact. See locked fields.
• 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 callsign, reference, or date so it collides with another contact you already have is refused, and the Edit not applied notice states the same program-worded reason the Contacted button gives — per park, per UTC day for POTA; per country, band, and mode for DX; and for Repeaters, only when the edited contact becomes an exact re-log of one you already have.
• 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 work stays visible through refreshes. A cloud refresh cannot silently replace a newer local save or make a contact or folder disappear while its upload is pending. Hamtrax keeps the pending record visible and reconciles it after the save finishes.
• Edits don't move contacts between folders. The edit form changes a contact's details, not its home. Log through the right flow instead of relocating after the fact — with one exception: if the whole activation is at the wrong park, you fix it at the folder level, not the contact level. See Wrong park? below.

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, 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.

• The original command, contact details, and typed rejection reason stay on this browser or device. They survive signing out, so signing back into the same account on the same device brings the review item back. It is not cloud-backed or available on another device while it remains 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	Offers File contact. Review the saved draft and choose a destination. All Contacts and the Activations / Hunting headings are greyed out — they organize folders rather than hold contacts — though you can still expand them to reach the folders inside. Month and park matching is judged when you save, not in the picker, so Save either confirms the contact was filed or tells you exactly why the guard refused the destination.
New contact — contact limit	Offers Upgrade plan. A folder choice cannot fix an account limit, so File contact is not offered. The original command stays retained for review.
Other rejected new contact	Shows the exact reason and keeps the command review-only. Only a create specifically classified as folder hygiene is eligible for refiling.
Rejected update	Keeps the failed change review-only. It is never retried as a create, so the existing contact cannot be duplicated.
Rejected delete	Shows that deletion was not confirmed and keeps the request review-only. It is never converted into a new contact.

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 Filing pending 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 Filing pending, 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

Everything above says a contact's park can't be edited. That stays true one contact at a time — which is exactly why the fix works the other way around.

Activated US-1234 but logged the whole session under US-1243? Open the activation folder in the Logbook and click the faint Wrong park? button under the folder name. The live activation header carries the same 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. Already submitted that log? Re-upload the corrected export — the dialog reminds you. Hamtrax never edits your POTA submission for you.
• 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.
• 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.

Duplicate hunted contacts are blocked

• One hunted contact per activator, per program-normalized reference, per UTC day. Within one program, tapping Contacted again later that day or a re-import collapses to the single contact you actually made (an immediate double-tap never even gets that far — the button ignores taps while it saves). The day-level programs ignore the QSO time entirely, so a second save a few hours off collapses too; Repeaters is the exception, because it keeps every distinct check-in and a different time is a different contact. The contact's explicit program identity is part of the comparison, so a contact recorded for another program remains separate even when the callsign and reference text are identical. Contacts you log as the activator are covered by the flagging rules below, not by this one; walkthrough practice contacts are also exempt.

  Each program decides how finely that day is cut, because the award programs count differently. POTA scores one contact per park per UTC day whatever the band, so band, mode, and time are all ignored. DXCC credit is awarded per band and per mode, so a DX contact only collapses when the activator, entity, UTC day, band, and mode all match — the same country worked on 20m and on 40m is two separate contacts and Hamtrax keeps both. Repeaters count every QSO: two conversations through the same machine on the same afternoon are two real contacts, so a repeater contact is only a duplicate when it repeats an existing one exactly — same station, machine, UTC day, band, mode, and time. A contact whose program can't be resolved falls back to the stricter per-day rule.

• Imports skip contacts you already have. An exact re-import (same callsign, UTC day, time, band, mode, and both program-qualified references) is recognized and skipped, whether the duplicate is already in your logbook or repeated within the same file.

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

Filing is still absolute: an activation contact can only ever land in 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. (The one thing an activation does refuse outright is a repeater contact, above — that is a POTA scoring rule about the contact, not a judgement about what you typed.) 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. A callsign counts once per activation, so a repeat is flagged no matter the frequency or mode.
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 move. Create them from the custom-folders section of the folder tree. Category folders and auto-created activation/monthly folders keep their place, so the structure your contacts rely on can't be rearranged out from under them. (Renaming is allowed on everything except categories, and a name really is just a label — changing it never changes a folder's rules, and an activation folder you rename keeps its submission identity, stays under its program, and keeps accepting contacts. The one name Hamtrax refuses is a label that impersonates a different log: on an activation folder, a name in the callsign@reference-YYYYMMDD form that claims a park, date, or callsign the activation does not have. Call it "Spring Mountain Trip" if you like — just not somebody else's activation.) The one heading that can change is the program card a folder is listed under, and only when its saved program details cannot be resolved at all — the folder itself, its name, and its contacts stay put.
• Deleting a folder never spills its contacts upward. Folder deletion requires an internet connection so Hamtrax can account for the complete tree before changing anything. Delete everything removes the folder tree and its contacts together; Move to new folder creates a custom destination, then moves every contact there and removes the source tree as one all-or-nothing change. If the operation is too large to complete safely at once, Hamtrax leaves the source unchanged. A parent category is never used as a fallback destination. With QRZ auto-push on, contacts that are actually deleted are removed from QRZ as well.

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