Source: https://guthlabs.ai/docs/jobs/wick-response-triage/forms/

job / candidate

# Response triage — forms

The distinct forms record for Response triage. This page is proposal-only.

Status: **proposed**Lifecycle: **candidate**

## Record status

**Record ID**: job:wick:response-triage

**Parent lifecycle**: candidate

**Page lane**: package

**Lane lifecycle**: proposed

**Owner**: Wick

**Owner role**: World posts and outreach agent

**Owner status**: HELD

**Qualification result**: NOT RUN · held for evidence and human review

**Working browser surface:** [Agent jobs — builder overview](<https://guthlabs.ai/guth.html#builder>) — Inspect the package and stage a local project. This route is local-only; provider, credential, database, customer, publication, deployment, and production effects remain held.

## Proposed form sections

Each section is a candidate schema for inspectable records. Required-field presence does not establish factual truth.

### Request context

Identify the response, source context, and intended channel without assuming external access.

- request title

- requesting person or agent

- received timestamp

- channel or route label

- source locator

- source SHA-256 if available

- source lock state

- requested outcome

### Account and relationship context

Capture only verified account and relationship facts needed for triage.

- account name

- account dossier record ID

- contact name and role

- contact history record ID

- verified relationship facts

- unknown or conflicting facts

- account access status

- identity and representation constraints

### Response classification

Classify the item and expose reasons for escalation or holding.

- response category

- urgency

- sentiment or tone note

- intent summary

- relationship commitment involved

- pricing statement involved

- personal or sensitive information present

- recommended action

- confidence

- unsupported-claim flags

### Draft and review

Prepare a bounded draft and a reviewable receipt without sending or publishing.

- draft text

- proposed subject or post title

- recipient or audience

- attachments or linked records

- route verification result

- required reviewer

- review deadline

- approval state

- hold reason

- revision note

### Accessible state contract

- Every field requires a visible and programmatic label.

- Required and optional fields must be stated in text.

- Invalid entries require an actionable message linked to the field.

- Blocked and Held states remain visible without relying on color alone.

## Supporting documentation fields

These fields come from the docs_urls lane and remain separate from the primary operating form.

### Response context

Identify the response and preserve its source boundary before interpretation.

- response record ID

- source locator

- received-at timestamp

- channel or route label

- account or contact reference

- linked world packet or outreach item

- source SHA-256 when available

- visibility state

### Response classification

Record a bounded interpretation without inventing intent or relationship history.

- classification: interested, question, objection, decline, referral, logistics, spam, unclear

- confidence: high, medium, low

- specific claims observed in source

- requested follow-up, if explicitly stated

- unresolved ambiguity

- relationship-history evidence reference

### Draft action

Prepare a reviewable next action while keeping external effects held.

- proposed action: no reply, draft reply, request clarification, route to owner, hold

- draft text

- pricing statement present: yes/no

- relationship commitment present: yes/no

- account-access request present: yes/no

- reply deadline

- human reviewer

- approval state

### Review receipt

Make ownership, gates, and disposition inspectable.

- reviewer identity

- review decision: needs review, approved locally, held

- decision timestamp

- reason for hold or revision

- source records consulted

- next review date

- revision identifier

## Required or proposed record references

No record existence is asserted by this documentation page.

- Source-linked world packet

- Outreach queue item

- Account dossier

- Contact history

- Response classification

- Draft message

- Human review receipt

- Source lock and provenance metadata

- job:wick:response-triage

- source-linked world post or response record

- outreach queue item

- response classification

- account dossier or contact history when referenced

- draft message

- approval receipt

## Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

- `agents/index.html#wick`

- `source_record:job:wick:response-triage`

- `observed_native_contract:records`

- `observed_native_contract:pointguard`

- `observed_native_contract:deadlines`

- `app_route:/app/notebook/messages/`

- `app_route:/app/notebook/approvals/`

- `app_route:/app/notebook/agent-logs/`

- `app_route:/app/notebook/field-guides/`

- `Observed native contract: Notebook records preserve canonical IDs, provenance, revisions, lifecycle, tags, links, attachments, and record revisions.`

- `Observed native contract: PointGuard is a persistent cross-app context surface; specialist apps remain execution and canonical-record owners.`

- `Observed native contract: current GuthHub app routes are local prototypes or indexes and provider, credential, database, customer, publication, and production effects are held.`

- `App route: /app/notebook/messages/`

- `App route: /app/notebook/approvals/`

- `App route: /app/notebook/agent-logs/`

- `App route: /app/pointguard/`