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
- Inline action beside a summary, letter, answer or section.
- Contextual panel listing the small set of actions valid for the current job/CV/profile.
- 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.