Rename + Mapping

How to use this docs page

This page is meant to answer one operational stage of the DullyPDF workflow well enough that you can run a controlled test without guessing. Read the sections below, validate the behavior against one representative document, and only then move to the next linked page.

That order matters because most setup failures come from mixing detection, mapping, fill validation, and sharing into one unstructured pass. A narrower review loop keeps troubleshooting faster and makes the template easier to trust once you save it for reuse.

When to run each action

• Rename: use when geometry is acceptable but field names are inconsistent.
• Map: use when names are already acceptable and you only need schema alignment.
• Rename + Map: use when you need both in a single flow.
• Base costs per bucket: Rename=1, Remap=1, Rename+Map=2.
• Server pricing formula: total credits = baseCost x ceil(pageCount / bucketSize).
• Current bucket size default is 5 pages, and server page count is used for final billing.

OpenAI data boundaries

Rename and mapping can send PDF page imagery, field overlay tags, and schema headers. CSV/Excel/JSON row values and in-editor field input values are not sent.

The product asks for explicit confirmation before these requests run. Mapping-only requests send database headers + PDF field tags. Combined Rename + Map sends PDF + headers + tags.

Interpreting results

• renameConfidence measures name quality; fieldConfidence measures whether it is likely a true field; mappingConfidence measures schema alignment confidence.
• Review checkbox metadata (`groupKey`, `optionKey`, `optionLabel`) after rename/map runs.
• High-confidence radioGroupSuggestions auto-apply so explicit radio groups are created before publish; lower-confidence suggestions stay review-only.
• Treat AI output as recommendations and validate before production usage.

Concrete mapping examples

• Text field: map insured_name or employee_first_name directly to a stable string column.
• Checkbox enum: map one group to values like single, married, or other categorical tokens via enum rules.
• Radio group: keep one explicit group key and distinct option keys so a single selected value does not drift into multi-select behavior later.

Checkbox rules and precedence

Checkbox rules support four operations: yes_no, presence, enum, and list.

• yes_no: boolean semantics with optional true/false option mapping.
• presence: truthy means select positive option; falsey usually leaves group unset unless mapped.
• enum: select the first valid option from a categorical value.
• list: split multi-value strings on , ; | / for multi-select groups.

Search & Fill applies checkbox/radio logic in this order:

1. Direct field-name boolean match.
2. Direct option-key match.
3. Direct group-value match (`i_...`, `checkbox_...`, or raw group key).
4. checkboxRules.
5. Built-in alias fallback groups.

Boolean token values used by Search & Fill

Truthy tokens include: true, 1, yes, y, on, checked, t, x, selected.

False tokens include: false, 0, no, n, off, unchecked, f, unselected.

Ambiguous tokens return null and do not coerce booleans: y/n, yes/no, true/false, t/f, 0/1, 1/0.

Presence-false tokens include: n/a, none, unknown, not available,null, blank, and related variants.

Schema hygiene anti-patterns

• Headers that change spelling or casing between exports.
• Multiple columns that mean the same thing but are not normalized intentionally.
• Boolean or checkbox values that mix yes/no, 1/0, blanks, and custom tokens without a documented rule.
• Mapping directly from vague field names such as Text1 or duplicated labels when Rename should have run first.

Rename-only warning

Rename without map can standardize names, but complex checkbox groups and non-matching checkbox columns may still fail to fill correctly until schema mapping is also applied.