# Master-Staleness & User-Reported History — Reference Companion to the **Master-staleness override path** in `../SKILL.md`. Read this when Rob reports the master resume or tool depth map is missing real history and asks you to "rewrite to include X" or "you said I didn't have Y, but I do." Use the 2026-07-25 Lumen example as the template for the response structure. --- ## The 4-column conflict table — template When Rob surfaces a claim that conflicts with the master, build this table before any verdict. The table is the evidence; do not paraphrase it into prose. | Tool / employer | Rob's claim | Depth map says | Master resume says (with line refs) | |---|---|---|---| | AEM | "Used at Lumen during the CenturyLink→Lumen rebrand; helped dev team on critical website changes; my team was Marketo, not day-to-day AEM owner" | `familiar` (line 82) | No Lumen bullet mentions AEM or the rebrand | | Adobe Target | "Implemented and owned at Level 3; drove the change from WebTrends; got certified (historical — operational depth continues regardless of cert currency)" | Certifications section (line 99), no employer tied to it | Not in any job bullet | | Adobe Analytics | "Implemented and owned at Level 3, plus Trimble and PMI" | `expert` (line 36) — tied to PMI + Trimble only | Trimble bullet mentions implementation; PMI bullet mentions workspaces; Level 3 not in master | | 6sense | "Learned about it in AI education — predictive analytics, AI agents, account targeting" | `aware` (line 29) — "Know the category, haven't used" | Not in master | | Optimizely | "Used in the past, not extensively" | Not in depth map | Not in master | | Level 3 Communications (employer) | "Former employer, owned Adobe Analytics + Adobe Target relationship" | N/A (employer not in depth map) | **Not in master resume experience section at all** — only in `data/referral_network.json` and the 6/27 handoff "559% organic traffic" proof point | The table tells Rob exactly what the project says today, and exactly where the gaps are. Without it, the conversation is "trust me" vs "trust me." --- ## The three options — always offer, recommend the first **Recommended — Add to master first, then rewrite.** Add the missing employer (Level 3) to `data/master-resume.md` with dates, title, and bullets Rob provides; update `data/docs/rob-blake-tool-depth-map.md` for the conflicting tools; then rewrite the Lumen resume and cover letter. The fix is permanent. Future tailoring at every company inherits the corrected record. **Alt A — Lumen-only reframe (per-job JSON only).** Edit only the per-job JSON for this tailoring to claim the new depth. Skip Level 3 entirely. Master is unchanged. Fast but the next tailoring will re-hit the same wall. **Alt B — Verify first, then decide.** Pause until Rob provides dates, title, and what he actually owned. Don't guess dates or scope. The cost is one round-trip; the upside is the master addition is accurate, not synthesized. If Rob picks **Alt A**, note in the vault memo that the depth claim is sourced from user assertion, not from a corrected master. Future sessions that re-tailor Lumen will see the per-job JSON and not know the master is still stale. Follow up with the master correction as a separate task. If Rob picks **the recommended path**, do the minimum master correction needed for this one tailoring, render the resume, then continue the master reframe as a separate project task. The application doesn't block; the master still gets corrected. If Rob picks **Alt B**, ask for: company (employer), start date, end date, title, 2–4 bullets, and what tools/ownership he had. Don't accept vague answers — the bullets are what go into the master. --- ## Hidden constraint to surface: deliberate curation rules A "fix the master" recommendation can collide with a curation rule the user has set. The 2026-07-25 Lumen rewrite hit this: the project master is deliberately curated to "last 10 years" partly to avoid surfacing age. When the recommended path would add an employer from outside the curation window, surface the conflict **before** editing the master — don't silently override the rule, and don't silently demote the claim. In the Lumen case the user explicitly resolved the conflict by adding Level 3 (2011–2015) anyway, because the telecom lineage and Adobe Target origin story outweighed the age-signal risk for that specific JD. That is a **per-JD exception**, not a permanent change to the curation rule. Before adding an employer whose dates fall outside the active curation window: 1. **State the conflict in one sentence.** "Adding Level 3 (2011–2015) makes the resume's earliest date 4 years earlier than the master's current 2015 floor." 2. **State the trade-off in one sentence.** "It strengthens the Lumen fit (telecom lineage, Adobe Target origin) but also surfaces 4 more years of tenure to a reviewer scanning dates." 3. **Ask the user to pick the per-JD exception vs. a permanent curation change.** The default is per-JD: the master is updated, but other tailoring will inherit the change too — so a permanent reframe is the user's call, not yours. Other curation rules that have come up: the master omits any employer/title that Rob doesn't want surfaced in cold applications (e.g. agencies, freelance-only contracts), and the master uses "Pipeline Layer LLC" as the consulting entity even when the actual work was solo. Don't edit the master without naming the rule that's being changed. --- ## Depth disclosures, not gap admissions The cover letter is the surface where this pattern most often fails. The old pattern in the 2026-07-23 Lumen cover letter was the **gap admission**: > "I am honest about the gap. AEM, ContextHub, Targeted Content, Adobe Target, 6sense, and Optimizely are adjacent for me rather than proven at scale." That reads as defensive. The 2026-07-25 reframe replaced it with a **depth disclosure**: > "The strongest fit for this role is the throughline I have on the Adobe experience stack. At Level 3 Communications, I built the business case and managed the Adobe vendor relationship for the migration from Webtrends to Adobe Analytics, DTM, and Target across all customer-facing web properties… On the AEM side, I worked hands-on during the CenturyLink to Lumen rebrand — the Marketo team was not the day-to-day owner, but we partnered with the dev team on critical website changes for the launch, so I know the authoring and component model well enough to ramp quickly to daily ownership. On 6sense, I have studied the category in my current AI education work… Optimizely I have used in past engagements, not extensively. I am honest about which depth each tool currently sits at." The pattern: | | Gap admission (don't write) | Depth disclosure (write this) | |---|---|---| | Tone | Defensive, apologetic | Confident, honest | | Structure | "X, Y, Z are gaps for me" | "X origin: [employer + scope]. Y: [employer + scope]. Z: [learning context]." | | Calibration | Single label ("familiar") per tool | Per-tool depth + the reason for that depth | | Closing | "I would rather be upfront than overstate" | "I am honest about which depth each tool currently sits at" | | Reader reaction | "what's missing?" | "this person knows exactly what they bring" | Use depth disclosures for any cover letter that lists tools at different depth tiers, not just for master-staleness cases. The pattern applies whenever a JD asks for tools the candidate has used at mixed depth. --- ## Attachments as verification material When Rob attaches a file (storyboard, portfolio, references doc, prior resume, JD screenshot) to support a master-staleness claim, **treat the attachment as authoritative** for the facts in it. Don't ask Rob to re-paste the bullets. Don't second-guess the dates. The 2026-07-25 Lumen case: Rob attached `Robs Storyboard Outlines.docx`, which contained a full Level 3 Communications entry with dates, title, location, and 7 bullets — more detail than the master, but consistent with the `data/referral_network.json` Level 3 entry and the 6/27 handoff "559% organic traffic" proof point. The right move was to read the attachment, pull the verified facts, and ask only the gaps the attachment didn't cover (employment dates — those came in chat on the second pass). Pitfall: an attachment that contradicts the master is **not** automatically a fabrication. It's evidence to compare against. Build the 4-column conflict table using both the attachment and the master, then ask Rob to confirm the difference. Pitfall: an attachment that matches the master is a signal the master is *currently correct*, not that it's *complete*. The 2026-07-25 storyboard was an attachment that filled gaps; the 6/23 job search tracker is an attachment that confirmed gaps. Same shape, opposite direction. --- ## What the user-asserted claim does and does not authorize A user assertion is evidence, not proof. The hard rule against fabrication is symmetric: - The user asserting "I have hands-on with X" does **not** authorize writing a new employer bullet into a per-job JSON as a workaround. That bakes the unverified claim into the application and any later audit will see a job that isn't in the master. - The user asserting "I have hands-on with X" **does** authorize: (a) using the claim as the new depth for this one tailoring *if* Rob explicitly says "for this application, claim X at Y depth," or (b) correcting the master upstream so every future tailoring inherits the correction. - Either path is honest. Mixing them — claim the depth in a per-job JSON without correcting the master and without explicit per-application authorization — is the failure mode. --- ## Files to touch for the recommended path (master-first) In order. Don't skip ahead. 1. `data/master-resume.md` — add the missing employer with bullets Rob provided. Use the existing bullet style (problem → approach → outcome; no banned phrases from the 6/27 handoff). 2. `data/docs/rob-blake-tool-depth-map.md` — update the conflicting rows. Add `Context` column entries tying tools to specific employers (e.g. "Adobe Target — used at Level 3 Communications, expert, drove WebTrends→Adobe migration; certifications are historical, operational depth continues"). This file is the canonical depth source for Stage 3 of the workflow. 3. `data/referral_network.json` — usually already has the employer, but verify. If a former colleague at the missing employer is in the network, this confirms the employer is real. 4. `Session Handoffs/` — write a short session handoff noting the master correction. Future sessions searching for "master reframe" or the employer name will find it. 5. Per-job JSON for the tailoring at hand — now editable with the new depth. 6. The DOCX itself — render, layout QA, save to vault. 7. Vault memo — "Strongest verified matches" section should now reflect the corrected history, not the old "fast ramp" framing. Update the "Material gaps preserved" section accordingly. After step 5, the next tailoring at a different company inherits the correction automatically because Stage 3 reads from the depth map and the master. Don't redo the audit next time. --- ## Job order — ask before you reorder The skill's workflow step 8 says "Reorder jobs so the strongest JD-relevant role comes first." That's the right default for insider-anchor / referral / Manager-as-thought-partner cases, but it's the **wrong** default for a user who reads resumes in strict reverse-chronological order. The 2026-07-25 Lumen rewrite started with Lumen first (insider-anchor), then Level 3 second (Adobe Target origin), then the rest reverse-chronological. After layout QA and ATS run, the user said "keep the job order chronological" — meaning standard US reverse-chronological (newest first) end-to-end. The whole resume had to be re-rendered and re-QA'd. Before the reorder step, ask one question if the JD has both an insider-anchor candidate (e.g. former employer) and a tool-origin candidate (e.g. an older employer where a JD-listed tool was first used): > "Do you want standard reverse-chronological (newest first), insider-anchor-first, or the JD-relevance-first order I usually default to?" Three valid choices, all honest, all ATS-clean. The cost of asking is one extra turn. The cost of re-rendering twice is one full layout-QA cycle + ATS re-run + vault memo update. Always ask. --- ## Real example — 2026-07-25 Lumen Digital Experience Strategist (RESOLVED) - **JD:** Lumen Technologies, Digital Experience Strategist, req 342726, remote US, $88,860–$118,480 in CO, deadline 2026-08-03. - **Previous tailoring:** 2026-07-23 session generated `Rob_Blake_Resume_Lumen_Digital-Experience-Strategist.docx` and `Rob_Blake_Cover_Lumen_Digital-Experience-Strategist.docx` in the vault. Cover letter explicitly framed AEM, ContextHub, Targeted Content, Adobe Target, 6sense, and Optimizely as "fast ramp" / "familiar" / "adjacent" — honest against the master, but losing the user's real history. - **User correction (2026-07-25):** the message that triggered the rewrite. Rob reported: AEM at Lumen during the CenturyLink→Lumen rebrand (familiar; helped dev team on critical website changes; not the day-to-day owner); Adobe Analytics + Adobe Target at Level 3 Communications (expert; drove the change from WebTrends; got certified in both; certifications are historical, operational depth continues regardless of cert currency); Optimizely in the past but not extensively (familiar); 6sense via AI education (familiar, understands predictive analytics and AI agents). - **Storyboard attachment:** `Robs Storyboard Outlines.docx` (a 126-line interview-prep doc Rob had built independently) contained the full Level 3 entry with title, location, dates, and 7 bullets. Storyboard content was treated as authoritative verification, not chat. - **Hidden constraint surfaced mid-conversation:** Rob disclosed that the master is curated to "last 10 years" partly to avoid surfacing age, and that he is 63. Adding Level 3 (2011–2015) is a per-JD exception, not a permanent master change. Rob confirmed the per-JD exception is worth it for the Lumen fit (telecom lineage, Adobe Target origin). - **Final path chosen:** recommended path (master-first), with the per-JD age-curation exception explicitly noted in the vault memo. Level 3 was added to the master with 6 bullets. AEM was reframed as `familiar` (not `proficient`) in the depth map because Rob was not the day-to-day AEM owner. Cover letter PARA_2 was rewritten as a depth disclosure. - **Job order correction:** initial render used Lumen-first as the insider-anchor; user then asked for reverse-chronological. Re-rendered, re-QA'd, ATS re-scored 76% STRONG (unchanged from the first render). - **Status:** **resolved.** The 2026-07-25 version of the resume and cover letter are the current state. Staged files for the master + depth map updates live in the vault `_lumen_rewrite_staging/` folder awaiting manual apply on Connie. - **ATS:** 76% cluster / 70% direct phrase — STRONG, identical to the 7/23 first run. The reframe deepened content quality without inflating scores. - **Layout QA:** 3 pages resume, 1 page cover, no clipping, no orphan headings, dates on role lines, locations on company lines. All pages visually inspected. --- ## What this pattern is NOT - **Not a referral override.** Referral overrides (Pantheon, 2026-07-23) lower application cost; they don't change what's true about Rob's history. - **Not a strategy override.** Architect-track / target-company overrides accept that the role is off-strategy; they don't add new facts to the master. - **Not a BLOCK-override.** Macmillan and Global Payments overrides are about scope, not about the master being incomplete. - **Not a per-job JSON edit.** The master-staleness path's per-job JSON option (Alt A) is honest *only* if Rob explicitly authorizes it for that one application. Default behavior is master-first. The pattern is: when the verified record is incomplete, the fix is upstream. Tailoring is the wrong layer to correct the record. --- ## Two pitfalls specific to this override class ### Pitfall 1 — Don't over-disclose "lapsed" certifications for senior operators The depth map's Certifications section is for *historical accuracy*, not for the depth claim. For a candidate with 15+ years of MarOps experience, recency on enterprise tools (Adobe Analytics, Adobe Target, Google Analytics IQ, SOASTA/mPulse) is the norm, not the exception — most enterprise MarTech stacks run on the Adobe experience cloud, and a 15-year operator has never been "far away" from the core tools. Marking certifications as "lapsed" in the working files is the wrong default for senior operators. It reads as defensive and bleeds into the cover letter and resume. **Default framing for senior operators (15+ years):** - Depth map: `Certifications (Historical — operational depth continues regardless of cert currency)` with a note that the depth claim comes from operational work, not the cert PDF. - Cover letter: do not surface the cert framing at all. The depth claim stands on operational continuity, not on the certificate. - Resume: do not list certifications inline unless the JD specifically asks. The depth lives in the experience bullets and the competencies section. **When to use the "lapsed" framing instead:** Rob is early-career (under ~7 years of relevant experience), or the JD specifically asks "do you have an active certification in X?" Otherwise, the "lapsed" framing is overcautious for a senior operator and the user will push back. Real example (2026-07-25 Lumen, after the user correction): the first render used "Certifications (Lapsed)" everywhere; Rob said "no that's fine... everyone knows, if you've done this as long as I have, you're never too far away from Adobe Analytics/Target since most enterprise level companies use both." The cert framing in the depth map, reference file, and vault memo was rewritten to "historical / operational depth continues" in the same session. The resume and cover letter were never affected — they never said "lapsed" in the first place. ### Pitfall 2 — Don't append "honest call before you submit" disclaimers after the user accepts the work When the reframe is complete and Rob has accepted the deliverable (e.g. "no that's fine"), the right close is: ship the work, surface the manual copy step, and stop. Do not append a "Honest call before you submit" block that re-litigates risk the user already accepted. The user has already heard the trade-off (age curation, cert framing, etc.) when those issues were live. Re-surfacing them at delivery time reads as the agent second-guessing the user's decision. **Pattern that works:** close with the manual-copy PowerShell block, the file paths in the vault, and one line on what was staged for later apply on Connie. Stop there. **Pattern that doesn't work:** close with a long "Honest call" block listing edge cases the user might want to reconsider, or asking the user to confirm a framing they already accepted earlier in the same session. The user will hear that as the agent hedging its own work. Real example (2026-07-25 Lumen, end of session): the first close was a 4-paragraph "Honest call before you submit" block about the Adobe Analytics/Target certifications being lapsed, the recency question, and whether the user wanted a parenthetical added. The user said "certification is not a deal breaker at all." The right close was: ship the work, do the cert framing cleanup in the working files, ship the PowerShell block, stop. The "Honest call" block was the agent doing extra work the user did not ask for. **When the "honest call" pattern is correct:** during preflight (gating the work), not after delivery (re-litigating the work). The BLOCK-override section of the SKILL.md has the right pattern — surface the trade-off before generating, not after.