# OCF v0.3 Planning Notes These are planning notes for the next schema iteration. They are not part of OCF v0.2 and should not be treated as implemented fields until the schema changes. The goal for v0.3 is not to make OCF bigger for its own sake. The goal is to add small concepts that emerged repeatedly in real use and that improve memory, honesty, curation, and reuse. ## Experimental / Incubating Shapes OCF may publish experimental shapes before making them normative. The point is to let users and tools try the same idea in roughly the same way without pretending the schema contract is settled. Working convention: - Experimental user-owned data should live under `extensions.user.local`. - Experimental vendor/tool data should live under the vendor's extension namespace. - Tools should preserve experimental data on round-trip. - Tools should not depend on experimental data unless they explicitly support that experiment. - Experimental shapes may be promoted, renamed, or dropped in a later release. - When an experimental shape graduates, the next release should include migration notes. The likely v0.3 incubating areas are `talkingPoints`, richer voice calibration, and `reviewStatus`. The likely direct enum addition is `sourceArtifact.kind: "job-description"`, which is simple enough that it may not need incubation. ## Candidate Addition: Talking Points Likely field name: `talkingPoints`. Alternate names considered: `careerNarratives`, `synthesizedNarratives`. Problem: some career stories are real, polished, and reusable, but they are not a single achievement, a raw private reflection, or a narrative variant of one item. Senior candidates often have a few cross-role stories they use repeatedly: - "four startups, four outcomes"; - "regulated systems from rough to scaled"; - "technical operator who became the bridge to customers and revenue"; - "builder who repeatedly turns undefined functions into repeatable operating systems." These are valuable for cover letters, interviews, profile summaries, and screens. They should not be hidden in vendor extensions if they are a common career-memory shape. Counterpoint: less senior users may not have polished narratives yet. The same concept should help them discover value, not only store finished executive positioning. Prompts and tools should ask questions that pull out under-described evidence: - What changed because of this work? - What was hard about the environment? - What did you personally own? - What would your manager or teammates say improved? - What did you learn that applies to the next role? - What pattern appears across your internships, projects, volunteer work, military service, school work, or early-career roles? Open design questions: - Is this top-level, person-level, or attached to experiences? - Should narratives link to supporting achievements and reflections? - Should they have `audiences`, `visibility`, `provenance`, `cautions`, and `sourceArtifactId`? - How do we distinguish a reusable narrative from a summary/headline? Likely requirement: each narrative should link to supporting evidence. A polished story without links is too easy to overuse. Minimal candidate shape: ```json { "id": "four-startups-four-outcomes", "label": "Four startups, four outcomes", "statement": "I have repeatedly joined companies at moments of customer or operating ambiguity and helped turn them into repeatable functions.", "uses": ["cover-letter", "screening-call", "executive-summary"], "audiences": ["startup-leadership", "customer-success", "sales-enablement"], "visibility": "shared", "supportingItemIds": [ "docusign-csa-operating-model", "bigid-cs-function-buildout", "rail-client-success-scale" ], "provenance": { "source": "interview-derived", "date": "2026-05-25", "operation": "synthesized-cross-role-narrative", "confidence": 0.8 } } ``` Open design note: `talkingPoints` should not become a loophole for unsupported claims. Curation should treat them as reusable framing backed by linked evidence, not as facts that stand on their own. Two anonymized example directions: ```json { "id": "regulated-buildouts-pattern", "label": "Repeated regulated buildouts", "statement": "I have repeatedly joined regulated organizations at moments when the operating model was still forming and helped turn ambiguous work into repeatable systems.", "uses": ["cover-letter", "screening-call", "executive-summary"], "audiences": ["regulated-operations", "security-leadership", "platform-buildout"], "visibility": "shared", "supportingItemIds": [ "healthbridge-soc-buildout", "northstar-compliance-platform", "meridian-incident-response" ], "voicePatternIds": ["take-first", "three-points", "filter-preempt"], "sampleTellings": [ { "label": "Cover letter version", "text": "I tend to be most useful when the system works well enough to prove demand, but not yet well enough to scale without judgment.", "visibility": "private" } ], "provenance": { "source": "interview-derived", "date": "2026-05-25", "operation": "synthesized-cross-role-narrative", "confidence": 0.8 } } ``` ```json { "id": "steady-operations-owner", "label": "Steady operations owner", "statement": "I do my best work when expectations are clear, the work matters, and the team needs someone reliable to own outcomes and keep the process moving without drama.", "uses": ["resume-summary", "cover-letter", "screening-call"], "audiences": ["operations", "customer-support", "administrative", "healthcare-office"], "visibility": "shared", "supportingItemIds": [ "clinic-scheduling-backlog-cleanup", "inventory-closeout-process", "support-queue-weekend-coverage" ], "voicePatternIds": ["plain-direct", "specific-proof", "no-overclaim"], "sampleTellings": [ { "label": "Screening-call version", "text": "I am happy to own outcomes. I just tend to be better at managing problems than managing people. Give me the boundaries, the priorities, and the people who need help, and I will keep the work moving.", "visibility": "shared" } ], "provenance": { "source": "interview-derived", "date": "2026-05-25", "operation": "synthesized-cross-role-narrative", "confidence": 0.8 } } ``` These examples are deliberately different. `talkingPoints` should not only support executive or founder-style arcs. It should also help people describe steady, bounded, reliable work without forcing every career story into leadership theater. ## Candidate Addition: User-Local Extension Namespace Likely namespace: `extensions.user.local`. Alternate namespace considered: `extensions.x-ocf-user`. Problem: the schema recommends domain-name extension keys for vendor/tool-owned data. But users and local workflows also need scratch space that no vendor owns. Early LLM workflows used invented namespaces such as `extensions.private.ocf.local` for user-local notes. Open design questions: - Should OCF reserve one local namespace? - Should it be explicitly non-portable? - Should tools preserve it but avoid interpreting it unless asked? - Is this better solved by normal schema fields rather than extensions? Likely direction: reserve `extensions.user.local` for user-local scratch metadata and make clear that portable concepts should graduate into schema fields only after repeated use. Suggested rules: - Tools must preserve `extensions.user.local` on round-trip. - Tools should not treat it as vendor-owned metadata. - Tools should not rely on it for cross-tool interoperability. - Users may store local constraints, notes, temporary mappings, or experimental structures there. - If multiple tools start using the same local shape, that is evidence for a future first-class schema field. ## Candidate Addition: Review Status Lifecycle Likely field name: `reviewStatus`. Problem: v0.2 reserves space for review status but does not define values. Real imports and LLM conversations repeatedly need to distinguish: - imported but not reviewed; - user-confirmed; - source-supported; - conflicting; - stale; - do not use; - needs attribution clarification; - superseded. The field would help importers, curators, and validators avoid treating "in the file" as equal to "safe to use." Open design questions: - Should values be simple enum strings or richer objects? - Should review status live on every durable item or only claims/achievements/variants/source artifacts? - How does it interact with `provenance.confidence`? - Does "manager-attested" or "document-supported" belong here, or is that a future trust/verification layer? Likely direction: start with a small review lifecycle for imported and LLM-suggested material. Leave formal verification tiers for later after more usage data. Minimal candidate values: - `unreviewed`: imported, inferred, or LLM-suggested material the subject has not reviewed. - `needs-review`: potentially useful, but a specific question blocks confident use. - `user-confirmed`: reviewed and accepted by the subject. - `source-supported`: supported by a source artifact, document, or system record, but not necessarily independently verified. - `conflicting`: multiple sources disagree or the item conflicts with another item. - `do-not-use`: retained for memory, caution, or provenance, but should not be used in outputs. - `superseded`: historically useful, but replaced by a newer or more accurate item. Potential lightweight object form: ```json { "reviewStatus": "needs-review", "reviewNote": "Confirm whether MEDICC meant MEDDIC or MEDDPICC before using in a resume.", "reviewedBy": "subject", "reviewedDate": "2026-05-25" } ``` Open design note: `reviewStatus` is not the same as truth verification. It is workflow state for whether the item is safe to use in curation. A future trust/verification model may add stronger evidence labels later. ## Candidate Addition: Job Descriptions As Source Artifacts Likely enum value: `sourceArtifact.kind: "job-description"`. Problem: OCF v0.2 encourages resume-plus-job-description workflows, but the `sourceArtifact.kind` enum does not include `job-description`. Tools currently have to use `application-draft`, `manual-note`, or `other`, which blurs a very common artifact type. Why it matters: - job descriptions are target evidence, not career facts; - they drive curation, gap analysis, and open questions; - they should be preserved for provenance when an output was tailored to a specific role; - future stale-export or lineage checks may need to know which target JD was used. Likely direction: add `job-description` to the enum in v0.3. This is a small compatibility expansion and should not require a new object shape. ## Candidate Addition: Role, Work, And Residence Location Problem: OCF v0.2 can represent organization addresses, but organization location is not the same as where the subject worked, was assigned, lived, or had tax-sensitive presence. Remote, hybrid, split-city, travel-heavy, military, consulting, and relocation situations make this distinction important. The schema should not force tools to infer residence from employer location. A company may be based in a high-tax state while the person lived elsewhere. A resume may show the company office or market location without intending to disclose residence, tax posture, or where work was actually performed. Locations to distinguish: - organization location: where the employer, client, base, office, or market is located; - role/work location: where the person was assigned, expected to work, or primarily performed work; - residence/private location: where the person actually lived or spent time; - travel/coverage region: geography served without implying residence or worksite. Candidate direction: ```json { "locations": [ { "label": "New York, NY", "renderAs": "New York / remote", "kind": "role-location", "structured": { "city": "New York", "region": "NY", "country": "US" }, "dateRange": { "start": { "year": 2025, "month": 1 } }, "visibility": "shared", "note": "Public-facing company market / role location." }, { "label": "Las Vegas, NV", "renderAs": "US-based", "kind": "residence", "structured": { "city": "Las Vegas", "region": "NV", "country": "US" }, "dateRange": { "start": { "year": 2025, "month": 1 } }, "visibility": "private", "note": "Private residence detail; do not infer into public outputs." } ] } ``` Like `person.name.renderAs`, location likely needs both canonical/private detail and intentional display text. A person may want to preserve where they really were while rendering a different, truthful phrase such as "New York / remote", "US-based", or "Greater Chicago Area." Some workflows need a free-form display value; others require structured city, region, postal code, or country fields. Full home street address is different from city/region location. Street number and street name are highly sensitive and should not be normalized into ordinary resume/application curation. If a workflow asks for full home address, a tool should ask how the user wants that handled: continue, pause, substitute a less-specific location if accepted, provide it only at a later stage, or stop the application. Different users will make different choices, and most will appreciate being asked before a tool discloses that detail. Open design questions: - Should this live on `person`, `experience`, `position`, or all three? - Should location entries use structured city/region/country/postal fields, a display `label`, `renderAs`, or all three? - Should `residence` always default to private? - Should full street address be excluded entirely, stored only under a separate high-sensitivity field, or handled only by extensions? - How should a file record the user's application preference when a form requires street address before an offer or late-stage process? - Should tools have a standard prompt pattern for address requests: warn, pause, ask, substitute less-specific location, continue, or stop? - How should curators choose between company location, role location, and residence for resumes in different regions? - How should tools avoid retaining unnecessary tax-sensitive location details? Likely direction: add position-level or reusable location entries with explicit `kind`, `renderAs`, optional structured city/region/country fields, `dateRange`, and `visibility`. Default residence/tax-sensitive location details to private. Treat full street address as high-sensitivity and require explicit user choice before a curator or exporter includes it in an application workflow. ## Candidate Addition: Richer Voice Calibration Likely location: top-level `voice` plus richer profile material under a first-class field or `extensions.user.local`. Problem: OCF v0.2 has a useful top-level `voice` field for broad style, preferred phrases, avoid phrases, and notes. Real LLM-assisted cover-letter work showed a deeper need: the tool must learn how this person writes, what makes prior drafts sound unlike them, and which structures reliably produce authentic output. The key lesson is that voice is not just vocabulary. It can include: - structural templates, such as "intro / three points / outro"; - authentic calibration samples; - anti-pattern samples that were AI-heavy or lightly edited but still not the user's voice; - named patterns, such as take-first opener, filter-preempt paragraph, or responsive close; - sample sentences that demonstrate cadence and point of view; - rules about when a pattern applies, instead of blindly copying an old signoff or phrase; - process rules, such as "if the user says this is not me, fix structure before word choice." Candidate shape to explore: ```json { "voice": { "style": "plain-direct", "avoidPhrases": ["uniquely positioned", "drive impact"], "preferredPhrases": ["worth knowing", "I've been in it"], "notes": "Short, declarative, concrete. Prefer a point of view over credential stacking." }, "extensions": { "user.local": { "writingVoiceProfile": { "calibrationSources": { "authentic": ["cover-letter-2021-cs"], "antiPatterns": ["cover-letter-2024-ai-1"], "canonicalExample": "tabs-cover-letter-2026-05" }, "structuralTemplates": [ { "kind": "cover-letter", "name": "intro-three-points-outro", "rule": "Use a short take-first opener, three concrete points, and a direct close. Do not pad to meet a length target." } ], "namedPatterns": [ { "name": "filter-preempt", "rule": "If a reader may filter the subject out for an obvious reason, name it directly and explain why it should not disqualify them." }, { "name": "responsive-close", "rule": "Only use a playful or unusual close when it responds to a specific prompt, value, or question in the target artifact." } ], "processRules": [ "If the user says a draft does not sound like them, revise structure before swapping words.", "Prefer one concrete proof per claim, then stop." ] } } } } ``` Open design questions: - How much of this belongs in first-class `voice` versus a user-local profile? - Should `voice` point to `sourceArtifacts` that represent authentic and anti-pattern writing samples? - Should anti-pattern samples be stored as source artifacts, private notes, or only summarized? - Can this be generalized without overfitting to highly reflective users? - How should tools avoid copying an old voice pattern into a new context where it no longer applies? Likely direction: keep v0.2 `voice` as the portable simple layer, document richer calibration under `extensions.user.local` for now, and revisit after more users test whether voice profiles help future LLMs react to them rather than to a generic professional ideal. ## Candidate Addition: Trust Review Space Problem: OCF v0.2 has provenance and confidence, but not a formal verification model. That is acceptable for v0.2. A premature verification enum risks implying a rigor the file may not have. Direction for v0.3: leave space for trust review without overdesigning it. The schema should support future outside review, recruiter/headhunter review, document support, peer review, manager attestation, credential verification, or other signals, but the first release should avoid pretending we know the right model before more people use the format. Practical near-term note: a headhunter, coach, or third-party tool may create a `third-party-working` OCF about a subject and mark which items that workflow has reviewed. That review may never enter the subject's candidate-owned master. The schema must stay clear about subject, controller, and editor. ## Candidate Addition: v0.2 Compatibility Renames v0.2 still contains several `derived` names even though the public language has moved toward curation and export: - `meta.derivedFrom` - `meta.derivedFromVersion` - `meta.derivationNotes` - `meta.source.kind: "derived"` v0.3 should replace these with curation/export language. v0.2 tools should continue to read and preserve them for compatibility until a migration path exists. The provenance value `interview-derived` remains useful and should not be removed merely because it contains the word `derived`; it means a fact came from a conversation rather than from a static artifact. ## Candidate Addition: Export Lineage and Staleness Problem: when a master changes after an export, users and tools need a way to know whether the exported artifact is stale. v0.2 has lineage-adjacent fields but does not fully define export freshness behavior. Possible direction: - make export-ready files record source master file ID and version; - define how a tool checks whether an export was prepared from the latest master; - preserve exact source item IDs for selected material; - keep this as metadata, not a rendering rule. ## Deferred Ideas These may be useful but should not pull v0.3 away from the core: - formal Open Badges / W3C VC verification support; - a companion job-description schema; - complex time-decay semantics beyond review timestamps and curation judgment; - full scoring models for candidate-role fit; - reference renderers that imply one canonical resume layout. The narrower pattern is still the project center: preserve career memory accurately, curate it for a purpose, and export what the recipient needs.