How does OfferLetter draft the letter?

Last updated: 2026-09-16

How the drafting process starts

I begin by asking the founder to fill three fields: the job title, the total compensation package, and the preferred start date. These inputs are stored as plain text in a simple form. No extra metadata is required at this stage.

Collecting core data

• Job title is entered exactly as it will appear on the letter, for example “Senior Software Engineer”.
• Compensation is typed as a number with currency, such as “120000 USD” or “150000 EUR plus 0.1% equity”.
• Start date is chosen via a calendar picker; the system stores the ISO‑8601 string.

Choosing a base template

• The system selects a master template that matches the company’s default tone and branding.
• If the founder has saved a custom template, that version is loaded instead.
• The template contains placeholders for role, compensation, start date, and standard clauses.

Role‑based clause selection

Once the role is known, the engine looks up a rule set that maps titles to clause groups. This mapping is maintained in a JSON file that the founder can edit.

Matching seniority

• For entry‑level titles the engine adds a probation clause and a learning‑development stipend.
• For mid‑level titles it inserts a performance‑review schedule and a discretionary bonus target.
• For senior or executive titles it includes a severance notice period, equity vesting schedule, and confidentiality obligations that survive termination.

Adding functional specifics

• If the title contains “Engineer” the system appends an intellectual‑property assignment clause.
• If the title contains “Sales” it adds a commission plan reference and a non‑solicitation of customers clause.
• If the title contains “Lead” or “Manager” it adds a team‑size reporting requirement and a mandatory training clause.

Compensation and benefits block

The compensation section is built from the raw number entered by the founder. The engine splits the input into base salary, variable pay, and equity, then formats each part according to local payroll conventions.

Salary, bonus, equity

• Base salary is rendered as “$120,000 per year”.
• If a bonus percentage is supplied, the line reads “Eligible for an annual bonus up to 15% of base salary, subject to performance”.
• Equity is shown as “Grant of 0.1% of the company’s ordinary shares, subject to a four‑year vesting schedule with a one‑year cliff”.

Benefits summary

• The system inserts a standard benefits paragraph that lists health insurance, dental, vision, 401(k) matching, and paid time off.
• If the founder has enabled a custom benefits list, those items replace the default paragraph.
• All benefit lines are written in plain language to avoid legal jargon.

Role level	Typical base salary (USD)	Common equity range
Entry‑level	70,000 – 90,000	0.02% – 0.05%
Mid‑level	90,000 – 130,000	0.05% – 0.15%
Senior	130,000 – 180,000	0.15% – 0.30%
Executive	180,000 – 250,000+	0.30% – 1.00%

Start date and contingencies

The start date field drives the effective date of the offer and triggers any contingency checks that the founder has enabled.

Effective date logic

• The letter states “Your employment will commence on [start date]”.
• If the start date falls on a weekend, the system automatically shifts the effective date to the following Monday and adds a note about the adjustment.
• The founder can override this shift by checking a box that says “Keep exact date”.

Background check, visa, etc.

• When the founder enables the background‑check contingency, the clause reads “This offer is contingent upon the successful completion of a background check”.
• If visa sponsorship is required, the line becomes “This offer is contingent upon obtaining the necessary work authorization”.
• Each contingency is added as a separate bullet point so the founder can see which conditions are active.

Legal and compliance overlay

After the core content is assembled, the system runs a lightweight compliance layer that inserts standard protections and flags any AI‑related risks that may arise from using language models to generate text.

Standard protections

• The engine adds an at‑will employment statement (where applicable) and a confidentiality clause that survives termination.
• It inserts a governing‑law paragraph that defaults to the state of the company’s headquarters, editable by the founder.
• An entire agreement clause is included to prevent reliance on prior discussions.

AI risk considerations

• Because the draft is produced by a language model, I refer to the OWASP Top 10 for LLM Applications (https://owasp.org/www-project-top-10-for-large-language-model-applications) to verify that the output does not contain disallowed content such as prompt injection or data leakage.
• I also consult the NIST AI Risk Management Framework (https://www.nist.gov/itl/ai-risk-management-framework) to ensure the generated text respects fairness, transparency, and accountability principles.
• The system logs the model version, the prompt used, and a hash of the final draft for audit purposes.

What this is NOT

I want to be clear about the limits of the tool so founders set realistic expectations.

No guarantee of perfection

• The letter is a starting point; it does not replace a legal review.
• Errors in data entry, such as a typo in the salary figure, will appear in the draft exactly as entered.
• The system does not verify that the compensation number complies with local minimum‑wage laws.

Not a replacement for counsel

• If the company operates in a jurisdiction with specific statutory requirements, a lawyer must confirm that the generated clauses meet those rules.
• The tool does not provide advice on tax implications of equity grants or bonus structures.
• Founders should treat the output as a draft that they edit before sending to a candidate.

Editing and version control

Once the draft appears on screen, the founder can modify any section directly. The editor tracks changes so the founder can revert to the auto‑generated version if needed.

Inline edits

• Clicking a paragraph makes it editable; the founder can change wording, add or remove clauses, or adjust formatting.
• The editor highlights placeholders that have not been replaced, preventing accidental leaving of {{role}} or {{compensation}} in the final letter.
• All edits are stored locally in the browser until the founder chooses to save.

Change history

• Each time the founder clicks “Save draft”, the system creates a new version with a timestamp.
• The history panel lists every saved version, allowing side‑by‑side comparison of two drafts.
• If the founder decides to start over, they can reset the form and generate a fresh letter from the original inputs.

Operator checklist for How does OfferLetter draft the letter?

I keep a written checklist next to every release that touches this topic. The list is boring on purpose: name the owner, name the evidence artifact, and name the rollback. If a step cannot produce a file, a ticket, or a log line, it is not a step — it is a wish.

Before you change production

• Freeze the branch or config revision you will measure against.
• Record the current failure mode with one concrete input and one concrete output.
• Confirm which identity the job runs as, and whether that identity can reach data it should not.
• Open the primary references you will cite: https://owasp.org/www-project-top-10-for-large-language-model-applications, https://www.nist.gov/itl/ai-risk-management-framework.

While you run the check

• Prefer one reproducible path over ten anecdotal screenshots.
• Write the expected safe outcome before you trigger the tool or query.
• Capture the exact command, prompt, schema, or regex under test — not a paraphrase.
• If the system can act (send, write, delete, transfer), require a confirmation boundary in the same pass.

After you finish

• File residual risk with an owner and a date, even when the scan is clean.
• Do not convert a green check into sales language that claims completeness.
• Re-run the same checklist when the model, tool schema, or validation rules change.

Signal	What to record	Stop-ship?
Unexpected write or send	Tool name, args, identity	Yes until gated
Missing confirmation on destructive action	Call path and bypass	Yes
Untrusted text treated as instruction	Source surface and resulting action	Yes for agent reach
Scanner clean, judgment open	Deferred items + owner	Only if core path safe

offerletter helps with the measurable first pass. Architecture choices, legal sign-off, and customer-facing claims still need a human owner. Treat every checklist row as decision support, not a certificate.

How I explain limits to buyers

When a prospect asks whether the product "covers everything," I answer with the boundary: automated checks catch known patterns; novel chains and policy judgment still need review. That honesty keeps support load down and keeps the blog aligned with what the product actually does.

If you need a second opinion, pair this write-up with the references below and with your own staging reproduction. Do not skip the reproduction step just because a model wrote a confident summary.

References

• https://owasp.org/www-project-top-10-for-large-language-model-applications
• https://www.nist.gov/itl/ai-risk-management-framework

Frequently asked questions

What is How does OfferLetter draft the letter??

A clean offer letter, drafted in a minute.

References

• Plain language / decision-support framing
• FTC advertising guidance

Try OfferLetter

Related reads

• What is OfferLetter?
• The LX AI Micro-SaaS Topic Matrix