Acronym Table Builder

Overview & Role#

The Acronym Table Builder (acronym-table-builder) belongs to CLIN 0002 — Proposal & capture in src/data/catalog.ts. It scans finished or near-final proposal draft text to find every acronym, verify first-use expansion, detect conflicting definitions or unused entries, and produce the clean definition table reviewers expect.

As noted in Answer every requirement, reviewers evaluate many proposals under tight timelines. An acronym table built from the finished text—rather than copied from an old template—ensures every term in the proposal is defined and nothing extraneous is listed.

Governing Regulations & Sources#

• FAR Part 15 & Section L Formatting Instructions: Many solicitations explicitly require an acronym list (either counted within or excluded from volume page limits) and require every acronym to be spelled out on first use.
• Section L Precedence: Whether an acronym list belongs in front matter, an appendix, or inline only is governed by Section L (Instructions, conditions, and notices to offerors) or FAR Part 12 Instructions to Offerors.
• Standard Federal & DoD Acronym Conventions: Bundles a read-only JSON dictionary of common public federal acquisition acronyms (e.g., FAR, DFARS, CLIN, COR, CO, PWS, SOW, SOO, RFP, RFQ, IFB, SAM, NAICS, PSC, CUI, NIST, CMMC, ATO, PoP) strictly as suggested defaults that the user can accept, edit, or override.

Inputs, Processing Logic & Outputs#

Inputs

Deterministic Processing Logic

1. Inline definition detection: Scans for explicit expansion patterns in the draft:
   • Full Term Name (ACRONYM) — e.g., "Performance Work Statement (PWS)"
   • ACRONYM (Full Term Name) — e.g., "CUI (Controlled Unclassified Information)"
2. Standalone acronym extraction: Matches uppercase/alphanumeric tokens (e.g., FAR, CMMC, ISO, 800-171 excluded as pure numeric, DoD, FedRAMP via mixed-case allowlist) and records total occurrence count plus character/line index of first appearance.
3. First-use compliance check: Flags any acronym whose first appearance in draftText precedes its first inline expansion, or which appears without any inline expansion in the draft.
4. Collision & orphan detection:
   • Multi-meaning collision: Flags an acronym defined two different ways in the same draft (e.g., PO defined as both Project Officer and Purchase Order).
   • Defined-but-unused orphan: Flags entries present in existingAcronymList that appear zero times in draftText.
5. Alphabetical normalization: Sorts unique acronyms case-insensitively (A–Z) and formats a clean two-column table (Acronym, Definition).

Outputs

• Acronym Definition Table: Sorted table with Acronym, Definition (editable inline), Occurrences, First Use Status (Defined at first use | Defined late | Undefined), and Flags (Collision, Unused).
• QA Summary: Counts of unique acronyms, undefined acronyms, late-defined acronyms, collisions, and unused entries.
• Local Exports: Markdown table, CSV, and plain-text tab-separated exports for direct paste into Word, LibreOffice, or Markdown proposal drafts.

Clean-Room & 5-Condition QA Requirements#

1. Browser-only execution: All regex scanning, dictionary lookup, and export formatting run in browser memory.
2. Strict Content Security Policy (connect-src 'self'): Enforces default-src 'self'; connect-src 'self'; form-action 'none'. Draft proposal text never leaves the user's device.
3. Zero tracking or accounts: No accounts, analytics, cookies, or beacons. Any optional localStorage state is disclosed and paired with a Clear local data button.
4. Offline execution: All federal acronym suggestion dictionaries and parsing logic are bundled in the static repo and work without internet access.
5. Worked examples, citations & scope limits: Verified with synthetic test vectors, cites FAR Part 15 / Section L conventions, includes an MIT LICENSE, and notes that domain-specific acronyms absent from the bundled public dictionary require human confirmation so incorrect expansions are never silently inserted.

Worked Example & Verification#

Synthetic Input (draftText):

The Performance Work Statement (PWS) requires compliance with NIST SP 800-171.
The Contracting Officer (CO) will review the PWS deliverables.
Later, the CO acts as the Change Order (CO) approver, and the SLA applies.

Synthetic existingAcronymList: RFP: Request for Proposal

Expected Deterministic Output:

Verification assertions:

• PWS is captured once with count 2 and status Defined at first use.
• CO triggers a collision warning because "Contracting Officer (CO)" and "Change Order (CO)" both bind to CO.
• RFP triggers an Unused warning because its occurrence count in draftText is 0.

Related pages#

• Answer every requirement
• Read a solicitation
• Check a tool’s answer
• Shakedown specification