Evidence grounded career decision safety for high agency operators.
VocationOS is a local first career decision safety system. It makes consequential automation conditional on evidence, reversibility, stakes, scoped human authorization, and verifiable completion evidence.
Website: onourimpram.github.io/vocation-os
Version 0.5.0 is the canonical local profile, document, and application operations release.
It includes the deterministic safety kernel, claim and packet integrity, persistent kill switch state, scoped approvals, trusted submission collectors, a migrated encrypted SQLite event store, checksummed schema migrations, encrypted backup and restore, a content addressed encrypted artifact vault, resumable onboarding, real PDF and DOCX profile parsing, hash bound import plans, event sourced product repositories, claim bound PDF and DOCX rendering with parse back verification, an application tracker, policy bound answer memory, and the existing Career Digital Twin, opportunity, portfolio, outcome, theory, and VocationBench foundations.
vocationd is the shipped single writer for consequential local runtime mutations. Product domain records, artifact manifests, profile import plans, onboarding transitions, tracker transitions, auto apply state, legacy import, audit checkpoints, and approver changes go through authenticated IPC with request idempotency. Desktop workbench, browser extension, twenty four GA discovery connectors, the verified company catalog, full interview and offer labs, production collector key custody, and production execution adapters remain roadmap work.
Version 0.5.0 ships no production auto apply adapter. Its compiled execution boundary permits only local-fixture with a synthetic profile. Adding an adapter string to config cannot grant production execution authority.
A draft, a public claim, an outreach message, a submitted application, a licensing decision, and an international relocation do not have the same reversibility.
Most career tooling optimizes output volume. VocationOS optimizes decision quality and prevents unsupported claims, stale evidence, replayed approvals, unsafe automation, and false completion records.
| Control | Runtime behavior |
|---|---|
| Claim integrity | Canonical claim hashes and packet hashes are recomputed before automation. |
| Document integrity | Every packet document must exist inside an explicit root and match its content hash. |
| Recency | Time sensitive claims use explicit policy windows and stale evidence blocks action. |
| Reversibility | Every Approved Auto action requires scoped approval. R3 cannot be downgraded. R4 never auto submits. |
| High stakes | Every high stakes flag requires an explicit boolean assessment. Any positive flag blocks auto mode. |
| Risk observations | CAPTCHA, anti bot, payment, identity, ToS, license, and fabrication signals must all be observed. |
| Authorization | Ed25519 approval binds a trusted approver, opportunity, packet, adapter, action intent, allowed field, and expiry. |
| Rate limit | Submission usage is calculated only from the daemon owned encrypted ledger. Caller counters and draft events are ignored. |
| Kill switch | Kill, rearm, and enable are separate idempotent daemon operations persisted in the encrypted event store. |
| Completion proof | Only a trusted Ed25519 collector receipt bound to attempt, action intent, packet, and adapter can confirm submission. |
| Local privacy | Sensitive event payloads and the chain head are encrypted with AES 256 GCM and authenticated before read. |
| Artifact privacy | CV, PDF, DOCX, and generated artifacts use an independent AES 256 GCM vault key and keyed storage locators. Raw source paths are not persisted. |
| Import integrity | Profile parsing runs in a bounded child process. Apply requires the exact persisted plan hash and imported facts remain analysis only until claim review. |
| Render integrity | PDF and DOCX are written only after every content node traces to one verified claim and both formats pass parse back verification. |
| Runtime authority | HMAC authenticated IPC, monotonic request sequences, durable command receipts, and a single instance lock protect the local writer boundary. |
| Rollback detection | Ed25519 checkpoints bind the database, migration version, event count, chain head, and prior checkpoint digest. The latest digest is retained outside SQLite. |
| Agent separation | Registered worker manifests enforce phase capabilities. Execute scopes are distinct. A generator cannot self-evaluate and only a human can approve. |
Version 0.5.0 is a source-first GitHub release. Registry installation remains intentionally unavailable until the typed SDK and root package complete a separate npm release pass.
npm ci
npm run typecheck
npm run test
npm run validate:schemas
npm run build
node dist/cli.js doctorRun the complete synthetic onboarding journey with one command. The CLI starts the local daemon when needed:
vocation init --demoImport a real local PDF, DOCX, Markdown, or UTF-8 profile source. This stores the encrypted artifact, creates a hash bound plan, and stops at claim review:
vocation init --profile /absolute/path/to/profile.pdf
vocation profile-import-apply sha256:<reviewed-plan-hash>The same flow can be declared in a schema validated config file with version, mode, and profilePath:
vocation init --config ./vocation-init.jsonThe default daemon uses the native OS credential store. A non graphical host can use an encrypted passphrase backed credential vault without environment variables or command line secrets:
vocationd start --headless
vocation daemon-status --headless
vocation onboarding-status --headless
vocation daemon-stop --headlessEvery CLI command that connects to a headless daemon must include --headless. VocationOS detects a headless credential vault and returns an actionable provider mismatch error instead of silently selecting the OS keyring.
Inspect authority health, product records, tracker state, or plan a non destructive legacy import:
vocation daemon-status
vocation daemon-stop
vocation onboarding-status
vocation domain-list opportunities
vocation tracker-list
vocation legacy-import-plan
vocation legacy-import-apply sha256:<approved-plan-hash>Run the complete release gate:
npm run safe:publish-checkCareer Digital Twin
-> Opportunity provenance and labor market graph
-> Deterministic intake and hard gates
-> Theory grounded planning
-> Claim first document AST
-> Independent evaluation
-> Scoped human ApprovalReference
-> Allowlisted application operator
-> Trusted collector SubmissionProof
-> Encrypted event and outcome history
-> Calibrated learning
The agent controller follows:
Observe -> Normalize -> Gate -> Plan -> Generate
-> Evaluate -> Approve -> Execute -> Verify -> Learn
No LLM, plugin, adapter, or worker owns the final side effect boundary. The deterministic controller and human approval gate do.
Temporal facts carry validity windows, evidence status, source pointers, confidence, sensitivity, and allowed uses. Sensitive facts cannot be exposed through public profile use.
Greenhouse, Lever, and Ashby payloads have pure normalization adapters. Opportunity records retain canonical URLs, source payload hashes, description hashes, fingerprints, freshness, remote eligibility, and extraction confidence.
O*NET, ESCO, and local occupation concepts can be attached with taxonomy version provenance. Current matching is a deterministic foundation, not a learned labor market model.
Jobs, fellowships, postdocs, grants, consulting, teaching, speaking, publishing, and venture routes share a multi objective evaluation surface. Hard gated options are excluded before utility scoring. Pareto efficiency and weighted regret remain visible.
Every content node in Document AST v2 uses verbatim-claim binding to exactly one claim ID and the canonical claim text hash. Its normalized text must match the verified claim text. Missing, inflated, unverified, private, or disallowed claims prevent rendering. Hidden Unicode text is rejected. PDF and DOCX output uses packaged Noto Sans fonts and must pass parse back verification before it is written. Human-approved synthesis over multiple claims remains a later, separately gated contract.
Profiles, opportunities, documents, campaigns, applications, tasks, outcomes, and application answers are versioned encrypted aggregates. Optimistic concurrency and request replay checks protect mutations. Application records use lifecycle specific tracker operations, so generic domain writes cannot manufacture an approved or confirmed status.
Answer memory is scope, sensitivity, expiry, evidence, and use mode aware. Work authorization, visa, relocation, compensation, and licensing answers require per opportunity confirmation and cannot be used in Approved Auto. EEO responses are never resolved for reuse.
npx tsx src/cli.ts demo-career-twin
npx tsx src/cli.ts demo-opportunity-intake
npx tsx src/cli.ts demo-portfolio
npx tsx src/cli.ts demo-skill-coach
npx tsx src/cli.ts demo-advisory
npx tsx src/cli.ts demo-auto-apply-decision
npx tsx src/cli.ts benchmark
npx tsx src/cli.ts list-workersProduct commands are available from the compiled CLI:
vocation init --demo
vocation init --profile ./profile.docx
vocation profile-import-plan-show
vocation artifact-list
vocation domain-list profiles
vocation tracker-list
vocation document-render ./document-v2.json ./claim-graph.json ./exportsWith vocationd stopped, verify the canonical encrypted store or create an interactive encrypted backup:
vocation store-verify
vocation store-backup ./backups/vocation.vocationbakstore-doctor remains a compatibility alias for store-verify through the next minor release. No passphrase is accepted through process arguments or environment variables.
VocationBench materializes deterministic synthetic stubs for 500 profiles, 1,000 opportunities, 200 adversarial cases, and 100 completion proof cases. Full synthetic Career Digital Twins and executable baseline adapters remain part of the benchmark expansion.
The harness implements NDCG, Brier score, expected calibration error, F1, false allow rate, and false confirmation rate. Current code establishes the benchmark protocol and metric engine. A public competitor leaderboard requires reproducible baseline runs and is not yet claimed.
The values below are checked by npm run docs:check.
| Metric | Count |
|---|---|
| Modes | 21 |
| Theories | 28 |
| Rubric dimensions | 20 |
| Schemas | 30 |
| CLI commands | 65 |
| Evaluator tests | 19 |
VocationOS is not an autonomous hiring system.
It is not a legal, immigration, clinical, financial, tax, or licensing authority.
It does not rank, reject, or filter candidates for employers.
It does not bypass CAPTCHA, anti bot controls, identity checks, platform terms, or application rules.
It does not treat an application as complete from caller supplied text or tracker status.
It is not yet a finished v1 desktop product. Version 0.5.0 is a tested local profile, document, and application operations foundation for that product.
VocationOS is scoped to individual career decision support. Employer side ranking, filtering, rejection, and hiring decisions remain out of scope.
See SAFETY.md, GOVERNANCE.md, PRIVACY.md, docs/ARCHITECTURE.md, docs/THREAT_MODEL.md, and docs/V0.4_MIGRATION.md.
Every new mode requires a schema, unit tests, adversarial tests, evaluator coverage, documentation, and a high stakes assessment.
Public fixtures must remain synthetic. Safety policy changes require dedicated review and cannot be hidden inside feature work.