Open Career Format logo Open Career Format

Readable HTML version. View the Markdown source.

OCF v0.4 Planning Notes

These are early planning notes for ideas that should not pull v0.3 away from its core. They are not part of OCF v0.3 and should not be treated as implemented fields.

The goal for v0.4 is to collect evidence for larger organizing concepts before standardizing them. v0.3 should make these experiments easier by adding stronger IDs, review status, cleaner lineage, and first-class talking points.

Candidate Direction: Career Tracks

Likely incubating namespace: extensions.user.local.careerTracks.

Problem: a person may have several overlapping career tracks that are all real, useful, and audience-dependent. These are not always separate jobs or separate timelines. They may be different lenses over the same career evidence.

Examples:

These are not aberrations. OCF should not assume one clean career timeline, and tools should not collapse overlapping roles into one vague experience just because they share an institution or date range.

Likely direction: tracks are top-level views over the whole OCF, not fields under person and not separate master files. A track may cite positions, achievements, education, certifications, memberships, governance, service, reflections, cautions, talking points, and source artifacts.

Incubating shape:

{
  "extensions": {
    "user.local": {
      "careerTracks": [
        {
          "id": "school-operations-track",
          "label": "School operations",
          "description": "Employment and operational work at the school.",
          "itemIds": ["school-staff-role", "student-support-achievement"],
          "audiences": ["school-operations", "education-administration"],
          "notes": "Use when positioning the staff/operations side of the overlapping school history."
        },
        {
          "id": "teaching-track",
          "label": "Teaching and instruction",
          "description": "Teaching, curriculum, and student-facing instructional work.",
          "itemIds": ["adjunct-teaching-role", "curriculum-design-achievement"],
          "audiences": ["teaching", "instructional-design"],
          "notes": "Use when the teaching relationship matters more than the employment relationship."
        },
        {
          "id": "education-track",
          "label": "Graduate study",
          "description": "The person's student relationship to the same institution.",
          "itemIds": ["graduate-program", "capstone-project"],
          "audiences": ["academic", "credentialing"],
          "notes": "Use when the education path is the relevant lens."
        }
      ]
    }
  }
}

Working rules for experiments:

Open design questions:

Candidate Direction: Occupational Classifications And Alignments

OCF v0.3 has two partial mechanisms for external classifications:

ONET-SOC and ESCO occupation mappings expose a different need. A role may align with several external occupation concepts even when none of those concepts was an official title or classification assigned by the employer. The distinction matters: an MOS, GS series, or employer classification may be a source-supported fact, while an ONET or ESCO match is often a reviewed interpretation used for matching, portability, or export.

v0.4 should consider keeping position.occupationalCode for formal classifications while incubating a separate collection of occupation alignments. Likely incubating namespace: extensions.user.local.occupationAlignments.

Possible experimental shape:

{
  "extensions": {
    "user.local": {
      "occupationAlignments": [
        {
          "id": "customer-success-role-onet-alignment",
          "positionId": "customer-success-role",
          "system": "onet-soc",
          "code": "framework-specific-code",
          "title": "Framework occupation title",
          "relationship": "primary-role",
          "version": "framework version",
          "supportingItemIds": ["customer-success-role"],
          "reviewStatus": "user-confirmed",
          "provenance": {
            "source": "llm-suggested",
            "date": "2026-07-17"
          }
        },
        {
          "id": "customer-success-role-esco-alignment",
          "positionId": "customer-success-role",
          "system": "esco",
          "uri": "http://data.europa.eu/esco/occupation/example",
          "title": "Framework occupation title",
          "relationship": "primary-role",
          "version": "framework version",
          "supportingItemIds": ["customer-success-role"],
          "reviewStatus": "user-confirmed",
          "provenance": {
            "source": "llm-suggested",
            "date": "2026-07-17"
          }
        }
      ]
    }
  }
}

Working rules for experiments:

Even several codes may be insufficient without describing how the person engaged with the classified work. A person may have performed the work directly, owned or led the function, managed people doing it, advised practitioners, partnered with the function, regulated it, supported it, sold to it, or built products for it. These relationships are different, but they do not form a simple seniority or exposure ladder. relationship describes the nature of the engagement; confidence, if retained, would instead describe certainty that the mapping is appropriate. Supporting item IDs should point back to the positions, achievements, projects, or other evidence that makes the relationship defensible.

For example, a compliance professional may cover a foreign-exchange desk, focus on several kinds of transactions, and ensure that restricted countries are avoided. Mapping only to "Compliance Officer" loses the market and transaction context. Adding "Foreign Exchange Dealer" without qualification falsely implies that the person traded FX. Treating sanctions controls or transaction monitoring as occupations confuses regulatory responsibilities and competencies with occupations. A reviewed alignment might say that the person regulated or oversaw work associated with an FX occupation while the underlying OCF positions, achievements, skills, and regulatory context preserve what they actually did.

This complexity is evidence against rushing occupation alignments into the core schema. Occupational classifications are useful indexes into someone else's labor-market taxonomy; they are not complete descriptions of a person's work. If a useful alignment model requires an exhaustive relationship vocabulary or duplicates attribution already present in the underlying evidence, OCF may be better served by keeping the detailed career memory and allowing matching or export tools to construct the classification view they need.

The planned junior Customer Success / first-manager example is a useful stress test. Customer Success roles often combine account management, service, adoption, commercial influence, and informal leadership. If one taxonomy code flattens that work, the example should demonstrate why alignments are optional, multiple, and reviewable.

One v0.3 description also needs correction during the v0.4 pass: the skills[].taxonomies guidance uses ONET-SOC code 15-1252.00 as though it identifies the skill "Python." It is an occupation code. ONET technology-skill data associates named technologies with O*NET-SOC occupations; it does not make the occupation code a stable identifier for the technology itself. The future field guide should use a valid framework-specific skill identifier or explain the association without presenting an occupation code as a skill code.

Open design questions:

Candidate Direction: Location Modeling

Location remains important but easy to overbuild. The next version should collect examples before standardizing a broad location model.

Pressures to test:

v0.4 should consider whether OCF needs reusable location entries with kind, renderAs, structured city/region/country fields, date ranges, and visibility. Full street address should remain high-sensitivity and should require explicit user choice before inclusion in an output.

Candidate Direction: Richer Voice Calibration

OCF v0.3 should keep voice calibration mostly incubating. v0.4 may revisit whether to standardize richer voice provenance after more examples exist.

Questions to answer before standardizing:

Candidate Direction: Trust Review

OCF is not a proof system, and v0.3 should avoid formal verification tiers. v0.4 may revisit trust review only after examples show repeated needs beyond provenance, cautions, source artifacts, review status, and open questions.

Possible future signals:

Any future trust model should point to external evidence rules rather than mirror every registry, board, employer, school, or court system.

Tool-vendor-attested signals are already appearing in public career surfaces: a CRM, marketing platform, design tool, coding assistant, analytics product, or other connected app may make an app-authored statement about how a person uses it. This is not the same as self-authored OCF content. The person is the subject of the record, but the app or platform is the author. These signals may be useful evidence, but they can also be platform-hosted, non-editable, continuously updated, only-positive, and vendor-incentivized.

OCF should not try to become the proof system for these claims. The likely pattern is to preserve the signal as evidence or provenance attached to a user-controlled claim:

Possible future homes include sourceArtifacts, item-level provenance, a future evidence/trust model, or an extension convention. The important boundary is ownership: OCF should let a candidate preserve, question, curate, and reuse external attestations without making the platform or vendor the owner of their career memory.

Candidate Direction: Context Profiles Before Physical Sharding

Large OCF masters and the full schema can exceed what a model needs for one task. The first response should be selective loading, not immediately splitting the canonical career record across files.

A context profile is optional local operating configuration that identifies which parts of the complete master a tool or model needs to know at that time. A generated context view may omit long-form reflection text, achievement longform, private compensation detail, source material, or voice samples while retaining stable IDs and enough metadata to request the full item later. Absence from the current context must mean not loaded, not does not exist.

Working boundary:

Long-form stories are the likely first pressure test because they are valuable, private, individually retrievable, and expensive to load into every conversation. Start with one career-summary profile and test whether models can work from compact story metadata, recognize that full text was withheld, and request a specific story by ID when interview preparation, story mining, or voice-sensitive drafting requires it.

Physical sharding remains deferred. Context-profile usage should first reveal which material is loaded together, what references must survive omission, and whether stories are retrieved individually, by role, or as a complete story bank. Any later shard or package design should grow from those observed access patterns rather than from a temporary manifest shape.

The non-normative context-profile design note and dependency-free reference script document the first conservative experiment. The initial goal is to prove explicit omission and selective retrieval, not to maximize size reduction.

Candidate Workflow: Local Insertion Placeholders For Sensitive Content

An item can be appropriate for a particular output without being appropriate to disclose to the model drafting that output. Clearance history, compensation, confidential customer names, internal metrics, health information, and protected project details are examples. This is a trust-boundary and tooling problem, not necessarily a schema problem.

v0.4 guidance should consider an optional local-insertion workflow. A hosted drafting model receives only the curated context the user is willing to disclose and emits a conspicuous placeholder where approved sensitive wording may later be inserted locally. For example:

[[INSERT APPROVED CLEARANCE STATEMENT HERE]]

Working principles:

The Maria Reyes conversation uses clearance history to illustrate the underlying conflict: permission to publish a statement in one application is separate from permission to send the underlying private information to the drafting model.

Candidate Direction: Durable Question Lifecycle

OCF cannot assume a future LLM or tool will have access to prior chat history. The file should preserve enough durable question state for a new conversation to continue responsibly without storing complete transcripts.

The v0.3 openQuestions array is intentionally minimal. It records what should be revisited, but cannot distinguish a question that has never been asked from one the user deferred, declined, answered, or resolved as a confirmed gap. That ambiguity can make a new model repeat a question the user already answered or chose not to answer.

v0.4 should consider renaming openQuestions to questions and adding a small lifecycle model. A possible shape is:

{
  "id": "hipaa-responsibility",
  "question": "What direct HIPAA Security Rule responsibility did Maria own?",
  "status": "confirmed-gap",
  "lastAskedDate": {
    "year": 2026,
    "month": 7,
    "day": 17
  },
  "answerSummary": "Maria confirmed that she supported healthcare security but did not own HIPAA compliance.",
  "resultingItemIds": [
    "caution-no-hipaa-ownership"
  ],
  "visibility": "private"
}

Candidate statuses:

Working principles:

Until a future schema standardizes this lifecycle, v0.3 tools may summarize a deferral, decline, partial answer, or resolution in reviewNote or provenance. That prose is a compatibility workaround, not a machine-readable lifecycle contract.

Candidate Corrections From v0.3 Use

These are considerations for a future schema design pass, not approved v0.4 fields and not changes to the frozen v0.3 schema.

Dates

Identity And Required Content

Certification Issuers

The v0.3 certification issuer accepts either a display string or a structured object. The structured form is more elaborate than most OCF use requires and accidentally remains open to unknown properties. A future pass should consider a smaller closed object centered on name and optional url. More specialized issuer identifiers or verification metadata should earn first-class space through real interoperability use rather than anticipation.

Grants And Funding

The current schema contains similar funding structures with different names and shapes, including grantNumber in one place and grantId in another. Before normalizing them, determine whether OCF has enough real grant and funding use to justify first-class fields. A future release may instead remove lightly proven funding structures and publish an incubating extension convention under the appropriate user-local or producer-owned namespace. Job-search funding history and external grant-system records should not be modeled merely because fields already exist.

Deferred Or Separate Work

These ideas may deserve future exploration, but they should remain outside v0.3:

The project center remains narrow: preserve career memory accurately, curate it for a purpose, and export what the recipient needs.