Job Discovery App Development

BrainDrive Development
1

@DJJones

Job Discovery evaluation package — Host receipt ruling needed

Dave J, Dave W has completed the owner-facing Job Discovery package review.

The V1 scope is confirmed, the visual-authority decision is closed, and the controlled Search-fixture boundary is accepted. The only remaining authority blocker for this package is the shared Host operation/run/execution-receipt lifecycle already identified as Internet Search Q7.

Please confirm or revise this proposed lifecycle

  1. Operation
    Each web.search@1 or web.read@1 call has its own opaque operation identifier and typed result.

  2. Owner-initiated run
    The Host issues one run identifier covering all Search and Read operations belonging to that bounded Job Discovery run. One failed operation does not automatically erase completed work or fail the entire run.

  3. Host execution receipt
    The Host creates an owner-visible receipt for the run and exposes a bounded, non-secret projection to Job Discovery.

  4. Job Discovery projection
    The projection needs enough information for Job Discovery to summarize the run accurately and link to the full Host receipt. Please confirm the exact schema, including:

    • selected provider profile;
    • each query;
    • each adapted query and its recorded reason;
    • attempted reads or canonical URLs;
    • operation outcomes and correctly typed failures;
    • the limit or stop reason;
    • completed-work and usage counts; and
    • the immutable disclosure-version reference governing the run.

    It must exclude credentials, internal traces, private diagnostic data, and raw retrieved page content.

  5. Replay and retry behavior
    Opening a receipt is read-only and never reruns or rebills anything. Repeating a search creates a new run and new operation identities. Please confirm how retries are represented and joined without making them look like new owner requests.

  6. Optional Billing entry
    A Billing entry exists only for a BrainDrive-managed billable operation. It joins to the run and operation records but remains metadata-only, with no query, URL, result, or page content. Owner-managed and unbilled operations create no BrainDrive Billing entry.

  7. Retention and viewing
    Please confirm the Host storage, viewer, access controls, export behavior, and joins consistent with the accepted Internet Search retention policy: owner-private execution receipts retained for thirty days by default and deletable sooner; restricted content-free diagnostics retained for thirty days.

Once you ratify or revise this lifecycle and projection, we can close Job Discovery’s receipt blocker, update its specification, evaluation plan, manifest, fixtures, and kit in one coordinated versioned revision, and rerun independent review.

Reference documents:

2

@djjones — I completed another product-owner review of Job Discovery for submission to BrainDrive-Docs. This is a re-review of the specification we previously worked through, not its first review.

BrainDrive-Docs PR #85 now carries v0.12 at docs/apps/job-discovery/job-discovery-spec.md. The owner-facing V1 scope and all 11 user stories are unchanged.

The update states the current contract directly, moves Job Discovery to Internet Search v0.11, inherits App Host revision 6 APP-1–APP-8, adds the current risk and failure sections, and removes the retired Browser Use reference from Application Preparation’s scope.

The build-relevant change is the App Host revision 6 pin. Please check the current build against APP-6 through APP-8: host actions reaching the model as durable conversation context, current workspace state and receipts being available, and each app-chat session exposing only the app’s declared tools. Search/Read Host admission and the shared receipt lifecycle remain explicit blockers.

Please review PR #85 and reply here with either “matches” or the differences you see in the build or shared Host contracts.

3

differences

Docs PR #85 / Job Discovery v0.12 matches my reading of the intended contract: no owner-facing V1 story changed; the build-relevant delta
is the App Host rev6 APP-6 through APP-8 inheritance plus Internet Search v0.11.

Current build status does not fully match APP-6 through APP-8 yet.

APP-6 is partial: Candidate 11 covers durable host messages for completed/cancelled direct Resume Builder Create Resume / Export PDF paths,
including browser/desktop export outcome. I do not see the matching durable host-origin failure message for failed controls, so APP-6.3
remains a gap.

APP-7 is not matched: current state read is app-specific (resume.state.read). Rev6 requires a host-provided no-argument workspace-state
read with one cross-app shape: workspace documents/revisions/status, registered artifacts, most recent export receipt, and pending
confirmation. The app-specific read can remain additive, but it does not satisfy APP-7 by itself.

APP-8 is partial: app-chat model context is scoped to declared workspace actions, which is good, but the missing host workspace read means
the exposed tool set is not the rev6 set yet, and I do not see the exposed tool list recorded in the session record for evaluation
evidence.

Search/Read admission exists at the host/capability boundary, but for Job Discovery I still treat exact Search/Read admission scopes,
accepted schemas, provider qualification, and the shared receipt lifecycle/projection as blockers, matching the PR text.

4

@djjones — thanks, the differences match my reading. Recording them here so the evaluation plan re-derivation has a target.

Accepted as build gaps against App Host revision 6 (owner-facing V1 stories unchanged; these are host conformance items, not Job Discovery scope):

  1. APP-6.3 — durable host-origin failure message for failed controls is missing. Candidate 11 covers completed and cancelled Create Resume / Export PDF only.
  2. APP-7 — no host-provided, no-argument workspace-state read with the cross-app shape (documents/revisions/status, registered artifacts, most recent export receipt, pending confirmation). resume.state.read stays as an additive app read but does not satisfy APP-7.
  3. APP-8 — exposed tool set is not yet the revision 6 set (follows from item 2), and the exposed tool list is not recorded in the session record as evaluation evidence.

I will carry these as expected-fail evidence in the Job Discovery evaluation plan revision rather than wait for the next candidate. If you would rather I hold until candidate 12, say so.

Narrowed Q7 ask. I am not asking you to fix the projection schema (point 4) or retention/viewer details (point 7) before Search is built standalone. Those can follow working code. What I need ratified now, so the plan and kit stop guessing, is the identifier and join model only:

  • Operation — each web.search@1 / web.read@1 call gets its own opaque operation id and typed result. Confirm.
  • Run — one Host-issued run id covers every operation in a bounded Job Discovery run; one failed operation does not fail the run or erase completed work. Confirm.
  • Retry — a retry creates new operation ids inside the same run id and is marked as a retry of the prior operation; it never appears as a new owner request. Confirm or give your join rule.
  • Billing entry — exists only for a BrainDrive-managed billable operation, joins to run + operation ids, metadata-only (no query, URL, result, or page content); owner-managed and unbilled operations create none. Confirm.
  • Replay — opening a receipt is read-only and never reruns or rebills. Confirm.

A “confirmed” on those five, or your revisions, closes the identifier half of the receipt blocker. Projection schema and retention stay open on Internet Search Q7 until you have the standalone Search path running.

Search/Read admission scopes, accepted schemas, and provider qualification remain blockers as you stated; nothing here changes that.

5

@DJJones if the above doesn’t make sense or needs more discussion we can discuss in the call tomorrow.

Thanks,
Dave W.

6

Confirmed, with one naming constraint.

Do not hold the Job Discovery evaluation re-derivation for Candidate 12. Carry APP-6.3, APP-7, and APP-8 as expected-fail / build-gap
evidence against App Host rev6.

For Q7 identifier/join model:

Operation: confirmed. Each web.search@1 / web.read@1 call gets one opaque per-operation identifier and one typed result envelope. The
canonical wire field is currently request_id; if we use “operation id” in prose, it means that same value, not a second identifier.

Run: confirmed. One Host-issued run_id covers every operation in a bounded owner-initiated Job Discovery run. One failed operation does
not erase completed work or automatically fail the whole run; the run outcome may be success, partial, blocked, or failed based on the
consumer’s accepted criteria and completed operation set.

Retry: confirmed. A retry stays inside the same run_id, gets a new request_id, and records retry_of_request_id or equivalent join
metadata to the prior operation. It must not appear as a new owner request.

Billing entry: confirmed. A billing entry exists only for a BrainDrive-managed billable operation. It joins to run_id + billable
request_id, is metadata-only, and contains no query, URL, result, page content, prompt, document, credential, or provider payload. Owner-
managed and unbilled operations create no billing entry.

Replay: confirmed. Opening a receipt is read-only. It never reruns an operation, retries a provider call, creates a new request id, changes
the run, or rebills.

That closes the identifier/join half of Q7 for the plan and kit. Projection schema, receipt viewers, redaction, retention, export behavior,
and standalone Search implementation details remain open under Internet Search Q7/Q4 as you said.

That response lines up with the current Internet Search contract’s proposed lifecycle while avoiding a future “two IDs for the same
operation” mess.

7

@djjones — thanks, confirmed and recorded as decision D472 with your request_id naming constraint. The identifier/join half of Q7 is closed; projection, viewers, redaction, retention, export, and standalone Search stay open under Internet Search Q7/Q4.

Job Discovery evaluation plan revision 7 is done and independently reviewed. It carries your three rev6 gaps as expected-fail evidence and is not held for Candidate 12.

We are pausing further work on this package. The latest Resume Builder evaluation run surfaced app issues and process improvements we need to make to the Factory’s evaluation section first. Job Discovery re-pins once those land. Nothing on your side is waiting on us.

We can cover the Resume Builder findings and process changes on the call.