Pablo Zavala · AI Safety Evaluation · Research Engineering
JROS: Resource OS With Receipts
JROS turns job search into governed resource work: sources, claims, packets, validation, and human approval gates over application-volume automation.
JROS began with a practical constraint: application work creates too many small claims for memory alone. A role has a source, a freshness state, a fit thesis, a risk tier, a private-data boundary, and a decision cost. Therefore, the hard problem extends beyond finding openings. The hard problem is acting while preserving evidence, judgment, and control.
JROS, the Job Search Resource OS, became my first real dogfood of NUDG's Resource OS idea. The system treats job search as governed resource work: sources, claims, packets, validation runs, session notes, and approval gates. The purpose is inspectable delegation rather than application volume.
Application Work Needs Receipts
Application automation often starts from the wrong measure. More submissions look like more progress, so the system learns to reward weak sourcing, stale roles, generic materials, and unreviewed external action.
JROS uses a stricter measure. A lead becomes useful only after the system can answer concrete questions:
- Which official or high-quality source supports the role?
- Which facts support the fit thesis?
- Which evidence has become stale?
- Which fields require private or strategic judgment?
- Which action has delegated authority?
- Which action must stop for human approval?
Consequently, the unit of work becomes a resource, source, claim, validation, packet, session note, or governance row that another agent can inspect later.
Operating Loop
The operating loop stays deliberately plain.
First, JROS discovers leads from configured sources and external research. Search results and aggregators can suggest leads, while official company or ATS pages verify them. A role moves forward only when the source remains current enough for action.
Second, the system scores and routes the lead. JROS records the source, company, role, and validation state. Then the system can capture the job description, prepare a packet, and summarize the exact decision I need to make.
Third, the autonomy policy classifies the action. `A0` means research or draft only. `A1` means routine prepare-to-submit under narrow conditions. `A2` means ask before submission. `A3` means hard stop. Because sensitive, strategic, and external actions carry reputational cost, final submission remains human-controlled unless a later authorization names the exact action.
Fourth, the system writes the result back into the ledger. A correction becomes a new entry. A stale posting becomes an explicit state. A blocker becomes a reusable lesson.
That last step matters because append-only records make correction humane. The operator can read what changed, and the correction becomes part of the work rather than a hidden edit.
Evidence Date And Proof Surface
The material date for this essay is 2026-07-06. A local JROS database query at or before that date returned 824 resources, 1,934 source rows, 303 claims, 1,403 entities, 52,906 validation runs, and 7,129 governance rows. A documentation audit run on 2026-07-06 passed with 16,349 files, 824 resources, 1,934 sources, 303 claims, and zero warnings.
Those numbers describe the system's shape. JROS works as a local control plane for evidence-backed action.
The proof surface has five layers:
- Resource and source ledgers give materials stable IDs and source tiers, while the private database remains private.
- The claim ledger lets important assertions point to observed, measured, or externally verified support, while weak or stale support stays visible.
- Validation runs check structure, claim trace, documentation, and official-posting state, while `needs_review` stays distinct from a pass.
- The governance log gives runs, decisions, assumptions, and product questions durable references, while append-only history improves auditability without becoming legal or cryptographic proof.
- The HUD feed shows what changed, what remains blocked, and which actions remain human-only, while the HUD stays read-only.
The latest defensible evidence date matters because a future-dated local governance row for 2026-07-18 exists. This essay treats that row as a chronology anomaly rather than progress evidence.
Approval Boundary Carries Product Authority
The defining design choice is the approval boundary.
JROS keeps private mailbox content private. The system leaves screenshots out of public proof. Public profiles remain unchanged. Messages remain unsent. Security controls remain respected. Sensitive answers route to me. Strategic applications stop at an approval gate.
The system can prepare, verify, draft, compare, and summarize. When a form would transmit an application, send a message, answer a sensitive question, or change a public artifact, the system stops. That boundary turns delegated agents from fluent assistants into governed workers.
Because authority stays explicit, narrow, and revocable, the system can move faster without pretending that every action deserves automation.
Bottleneck Moved
Early JROS work asked whether agents could find enough plausible roles and materials. By the 2026-07-04 weekly review, lead supply had become healthy. The active bottleneck had moved to decision compression: same-company variants, packet choices, sensitive gates, and reading burden.
That diagnosis changed the product surface. A useful system should present one recommended action, a small number of alternates, evidence links, and an explicit gate. Inventory creates pressure; a well-bounded next decision creates agency.
Therefore, the most valuable interface became a decision cockpit rather than a larger queue.
What JROS Teaches NUDG
NUDG is about governed agent-run resource use: propose, authorize, execute, verify, and leave a receipt. JROS tests that idea in a domain where mistakes have concrete costs. A job search touches personal data, reputation, timing, private documents, external forms, and irreversible clicks.
The lesson is modest and strong. A useful Resource OS starts by making resources legible. The system names the source. The system names the claim. The system names the gate. The system names the human decision. Then the system records the run.
That places JROS in the human-augmentation tradition, narrowly. Licklider argued for computers that help people formulate problems and make decisions under human criteria. Engelbart described systems that combine artifacts, language, methodology, and training to improve human capability. JROS remains smaller and local: a working pattern for making agent labor inspectable.
The practical claim is compact:
delegated agents need receipts, boundaries, and refusal states before they touch real resources.
Inspection Is The Test
JROS should be judged by inspection rather than confidence. Many systems can generate confident recommendations. A governed resource system should let another agent, or me, answer harder questions later:
- What source justified this action?
- What claim supported the recommendation?
- Which validation passed, failed, or needed review?
- Which authority did the agent have?
- Where did the system stop?
- What changed after correction?
When those questions have answers, the system preserves judgment instead of merely producing output. That is the point of a Resource OS: receipts over motion and volume.
Sources
- Private JROS evidence snapshot reviewed on 2026-07-06; underlying repository, database, packets, sessions, and mailbox-derived records remain private.
- JROS source visualization created from local ledger counts on 2026-07-06, then refined with AI for the social image.
- William Strunk Jr., *The Elements of Style*.
- J. C. R. Licklider, "Man-Computer Symbiosis", 1960.
- Douglas Engelbart, "Augmenting Human Intellect: A Conceptual Framework", 1962.
- W3C, PROV-DM: The PROV Data Model.