Files
jobtrackingapp/docs/redesign/phase-3/AI_INTERACTION_MODEL.md
T
2026-09-10 18:15:05 +02:00

5.6 KiB

AI interaction model

ARC-11; PRES-W03, PRES-W05, PRES-W06, PRES-W09, PRES-W10, PRES-C03, PRES-C04, PRES-C11, PRES-S04, PRES-E09. NEW-07 is shared contextual access, not a new autonomous agent platform.

Grounding contract

AI must never invent experience, skills, qualifications, education, employment, achievements/metrics, certifications, languages, dates or personal facts. Job requirements describe the employer's needs, not the user's abilities. Unknown is distinct from absent.

Source context is explicit: current canonical items, selected CV overrides, known job text, user-supplied notes or specifically included attachments. Show source identity/last-known revision where available. Existing models do not supply universal claim-level provenance; a source attachment chip is not proof that every generated sentence is grounded. New structured claim references/unsupported-claim validation need a separately scoped API/evaluation contract.

When source support is missing: omit the claim, mark it unverified for review or ask the user to add truthful information. Never invent numeric achievements or add a job keyword as an asserted skill. Treat imported job/document content as data, not instructions to change permissions, transmit private files or bypass review. Keep existing server AI privacy/entitlement and source ownership controls.

Three entry surfaces, one domain action

  1. Inline action beside a summary, letter, answer or section.
  2. Contextual panel listing the small set of actions valid for the current job/CV/profile.
  3. Command entry routing to that same action/review surface.

The panel uses explicit context and selected source; it does not scrape unrelated routes or retain A's context after switching accounts. No hidden conversation memory, automatic generation on navigation, broad tools or background writes. Commands can open review but cannot silently apply changes.

Suggestion states

State Presentation / available actions Mutation boundary
Ready Target scope and selected sources, action controls No change
Generating Cancel when supported, bounded progress, request identity No accepted content written
Review Current / Proposed / Sources; readable diff and edit proposal Original retained
Accepted into draft “Applied to this draft/CV” with resulting save state Existing domain action only; distinguish explicit Save vs builder autosave
Rejected / closed Proposal cleared; original editor restored No PUT/save implied
Regenerating Keep original and prior proposal until replacement succeeds; clear prior acceptance No automatic acceptance of replacement
Invalid/unsupported Explain structure/source validation error; retry or edit manually Cannot Apply malformed/missing/duplicate block IDs
Failed/timeout/busy Safe message, retry when allowed, retain original No stale/partial silent apply
Provider unavailable / privacy disabled / Free locked Explain supported reason; manual workflow and settings/plan link as applicable No new request/charge, no fake output
Context changed / account expired Discard or require a fresh review against current content Cannot apply response to different owner/resource

An accepted suggestion is not proof of factual accuracy; meaningful support/review checks remain mandatory. Generation failure and legitimate “no supported improvement” are different states.

Review interaction

Use the existing current-versus-suggested UI first. Text diff has insert/delete labels and screen-readable order, not color alone. Never force acceptance of all changes when only part is supported; per-change acceptance is a future extension where the existing action supports whole output only. Manual edit before Accept remains.

Target label is beside Apply: “Apply to this CV,” “Use in this letter draft,” or “Review changes to Career Profile.” No ambiguous universal “Save everything.” Translate changes language without changing facts; show target document language separately from UI language.

If source/editor changes during generation, require refreshed review against the current value. Do not rebase proposals silently or imply this solves server optimistic concurrency. API payload IDs/source selection must remain owner-scoped; stale-response rejection follows B02. Regenerate/Retry is user-initiated and respects limits; no retry loop on every render.

Domain specifics

  • Match: distinguish deterministic requirement comparison from optional AI explanation. Show scoring method/sample/freshness limits, not a promise of hiring probability.
  • CV: preserve per-section and whole-document flows and strict original block matching; accepted edits update only variant settings.
  • Profile extraction: explicit low-confidence selection and discard; don't convert extracted guesses into canonical facts.
  • Letter/answers: retain original until accepted into job draft; no auto-send.
  • Interview: generated questions/prep are proposals; Add to prep is deliberate. Suggested answers cannot invent personal examples.
  • Correspondence: AI draft preparation is distinct from provider send confirmation/attempt identity. Never auto-resend uncertain delivery.

Evidence before consolidation

Phase 2 AI tests cover reject/close/no-write, edit then accept, invalid/missing/duplicate block IDs and CV-only mutation. Preserve those oracles when extracting presentation. Add delayed-response/context-change, cancelled generation, unavailable provider, keyboard diff and two-account scenarios. Model factuality needs controlled known-source evaluations; mocked suggestions prove UI boundaries only. No “hallucination-proof” certification is claimed.