hyreflow-ai Shortlist API

openapi: 3.2.0
info:
  title: hyreflow engine (local) Shortlist API
  version: 0.1.0
tags:
- name: Shortlist
paths:
  /shortlist:
    post:
      summary: Shortlist
      description: 'Bulk screen candidates against a job spec via the structured-decision model — the fast,

        cheap pass BEFORE /qualify''s deep-dive. One decide() call per row returns a calibrated `fit`

        score (normalized to the /qualify 0-10 scale), a confidence, a per-must-have probability, and a

        deterministic tier (tier_1 / tier_2 / no_fit).


        The question set is the caller''s to shape. Pass `questions` to screen on a JD-specific set — score

        ladders with written level criteria, noul gates, choice buckets — and every question outside the

        ranking one and the `must_have_i` gates comes back verbatim under `shortlist.answers`. Omit it and

        the question set for this job description is generated once, stored, and reused by every later

        screen of it (`regenerate_questions` replaces it); rows rank on its category composite.

        `must_haves` adds one pass/fail gate per requirement on top of either.


        Body: {"job_spec": "", "candidates": [Person, …] (or "input": ""),

        "must_haves": ["…"] (optional — one noul gate per requirement),

        "questions": {…} (optional — the agent''s own {name: {type, instructions, criteria}} set,

        drafted off the job spec; needs one `score` question to rank on),

        "regenerate_questions": , "min_score": ,

        "allow_thin_profiles": ,

        "concurrency": }


        Every screen is a run: the candidates are seeded into a dataset, the run walks them, and the

        request waits up to _SHORTLIST_WAIT_S for it. Finished in time → the ranked result

        {run_id, status:"completed", count, scored, candidates, _meta}. Not yet → a handle

        {run_id, dataset_id, status, progress, poll_after_s}; GET /shortlist/runs/{run_id} answers with

        the same ranked result once it is done. The first screen of a job description also generates its

        question set, inside the run. Ranked rows are compact — identity, `row` (its index in dataset_id)

        and the `shortlist` cell; the full rows stay in the dataset. An identical request inside

        enrich_batches.TTL_SECONDS returns the first one''s run, charged 0. An `async` key is ignored.

        A row the batch never scored (an error, or the session spend cap) carries `score: None`;

        `min_score` drops it from `candidates` like a reject, so the count and the first reason are

        reported as `_meta.not_scored` / `_meta.not_scored_reason`.'
      operationId: shortlist_shortlist_post
      requestBody:
        content:
          application/json:
            schema:
              additionalProperties: true
              type: object
              title: Body
              default: {}
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema: {}
        '422':
          description: Validation Error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/HTTPValidationError'
      security:
      - HTTPBearer: []
      tags:
      - Shortlist
  /shortlist/runs/{run_id}:
    get:
      summary: Shortlist Run
      description: 'A screen''s state: the ranked result once it has finished (the same body POST /shortlist

        answers with), else its handle and progress. Free — it reads the run and its dataset only.

        `min_score` defaults to the one the screen was submitted with.'
      operationId: shortlist_run_shortlist_runs__run_id__get
      security:
      - HTTPBearer: []
      parameters:
      - name: run_id
        in: path
        required: true
        schema:
          type: string
          title: Run Id
      - name: min_score
        in: query
        required: false
        schema:
          anyOf:
          - type: number
          - type: 'null'
          title: Min Score
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema: {}
        '422':
          description: Validation Error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/HTTPValidationError'
      tags:
      - Shortlist
components:
  schemas:
    HTTPValidationError:
      properties:
        detail:
          items:
            $ref: '#/components/schemas/ValidationError'
          type: array
          title: Detail
      type: object
      title: HTTPValidationError
    ValidationError:
      properties:
        loc:
          items:
            anyOf:
            - type: string
            - type: integer
          type: array
          title: Location
        msg:
          type: string
          title: Message
        type:
          type: string
          title: Error Type
        input:
          title: Input
        ctx:
          type: object
          title: Context
      type: object
      required:
      - loc
      - msg
      - type
      title: ValidationError
  securitySchemes:
    HTTPBearer:
      type: http
      scheme: bearer