Keep connector proof tied to the same operator stack
Agent Hub should now feel like the connector and delivery lane inside the same workspace, not a sidecar tool. Use it when launch, analytics, or provider proof needs signed read or delivery evidence.
GET api/master-ai.php?view=command_surfaces
Returns the cross-app navigation spec, public IDs, safe embed summaries, and recommended launch URLs the agent app can use to open the exact hiring record it should work against.
WritePOST api/master-ai.php
Send signed headers plus JSON with a contract action such as job.create, application.status, message.send, or onboarding.retry. The launch URLs are only for context. All writes still go through the signed contract lane.
Legacy token routes
api/jobs.php and api/applications.php still work for the old token flow, but the active integration path is now the dedicated Master AI contract lane plus the command surface read view.
curl -X POST https://yourdomain.com/hiring_site/api/master-ai.php -H "Content-Type: application/json" -H "X-Master-AI-Key: master-ai" -H "X-Master-AI-Request-Id: req_20260329_001" -H "X-Master-AI-Timestamp: 2026-03-29T18:00:00Z" -H "X-Idempotency-Key: req_job_create_20260329_001" -H "X-Master-AI-Signature: HMAC_SHA256(timestamp + request_id + raw_body)" -d '{"action":"job.create","idempotency_key":"req_job_create_20260329_001","context":{"origin_app":"master_ai","org_public_id":"ORG_PUBLIC_ID","location_public_id":"LOCATION_PUBLIC_ID","actor":{"type":"agent","label":"Master AI","session_ref":"talent_case_4021","action_ref":"draft_job_refresh"}},"payload":{"job":{"title":"Kitchen Manager","company_slug":"sunset-hospitality-group","company_name":"Sunset Hospitality Group","city":"Nashville","state":"TN","team":"Kitchen","employment_type":"Full-time","schedule":"Evenings and weekends","pay_min":"23","pay_max":"28","pay_period":"hour","summary":"Lead prep, line flow, and closing standards for a busy neighborhood concept.","tags":["Urgent","Leadership","Scratch kitchen"]}}}'Edit role facts, publish state, and provider evidence in the hiring app. Master AI should launch into the hiring record, not shadow-edit it elsewhere.
System of record: hiring_appStage moves, notes, tasks, interviews, scorecards, hire packets, and onboarding all remain visible in the hiring app even when Master AI initiated the work.
System of record: hiring_appMaster AI can request actions and carry context, but final approval state must remain reviewable in the hiring app.
System of record: shared_review_boundaryThe agent app should read the proof surfaces and context summaries here instead of inferring state from raw notes or guessed status.
System of record: hiring_app_proofGood for Master AI case cards and queue previews without duplicating the full record editor.
applicant_name, status, job_title, company_name, location, fit_score, next_actionGood for cross-job truth summaries and duplicate review context.
candidate_name, primary_email, connected_application_count, attachment_count, merge_state, latest_roleGood for operator review queues and backlink launches into the exact hiring record being reviewed.
approval_public_id, action_type, status_code, requested_by, target_record_type, target_record_idGood for downstream execution visibility without pretending the other system owns the hire packet.
handoff_public_id, status_code, stack_function_label, destination_system_label, latest_receipt_state, retry_countContext the agent app can launch with right now
This application stays owned in the hiring app. Master AI should link here, read the safe summary, and use the signed contract for writes.
- application public id: A48F43B665C51D6DF605F94B26
- candidate public id: 42ADF98B8AC8062214B5BBB9F1
- job public id: A69CA9599C94E52C72DCBC82F5
- location public id: 01HW0LOC00000000000000001
- org public id: F9A2523C3AA20885DC2C9EEBEF
The candidate master record stays in the hiring app so duplicate review, attachments, and cross-job history remain visible in one place.
- candidate public id: 42ADF98B8AC8062214B5BBB9F1
- application public id: A48F43B665C51D6DF605F94B26
- job public id: A69CA9599C94E52C72DCBC82F5
- location public id: 01HW0LOC00000000000000001
- org public id: F9A2523C3AA20885DC2C9EEBEF
Master AI may request this action, but the approval and audit outcome remain visible in the hiring app.
- approval public id: DE0BFC7332CA5DC33EF1A9A0F9
The hiring app owns the onboarding handoff and receipt trail even when the downstream system is outside HospiEdge.
- handoff public id: 01HW0HAND0000000000000001
- application public id: 8787A9FD3F73069F353904D95D
- candidate public id: AA482673A7D3167690DAD5AE19
- job public id: FF85EE0AA36720068C684CAFD3
- location public id: 01HW0LOC00000000000000003
- org public id: 716E7B72D8793BAECE3DB1D31F
Analytics surfaces the agent app should trust
The analytics view returns proof-oriented hiring metrics, why-this-changed signals, actions-needed panels, and agent follow-through evidence. Use the operator page for human review and the signed analytics contract view for machine reads.
See grounded movement, queue drag, offer proof, onboarding receipts, and agent value in one place.
Open analyticsUse GET api/master-ai.php?view=analytics for report-grade reads that stay tied to deterministic workflow facts.
Use GET api/master-ai.php?view=command_surfaces when the agent app needs exact public IDs, backlinks, and a safe embed card for a hiring record.
Inbound proof from the updated Master AI connector
Signed read-only GET requests now leave a visible proof trail on the hiring side too. That gives rollout review a second source of truth instead of keeping all connector evidence inside the Master AI app.
Use the local proof script to verify the updated signed-read lane and confirm the inbound proof ledger records the request.
php scripts/run_production_connector_proof.php --jsonUse GET api/master-ai.php?view=contract_history for the latest signed-read proof summary and recent proof rows.
Before planning the driver flip, verify the SQL stack, snapshot, and proof-ledger table are all in the staged cutover package.
php scripts/run_live_cutover_execution_prep.php --jsonLatest read-only connector proofs
Payload hash 9ede36d30ba00c18 · checked 2026-04-02T03:00:26+00:00
Sections: summary, itemsPayload hash 598f427e46fe619c · checked 2026-04-02T03:00:25+00:00
Sections:Payload hash 26352306813c5fb6 · checked 2026-04-02T03:00:25+00:00
Sections:Payload hash b1715552340adde6 · checked 2026-04-02T03:00:25+00:00
Sections:Payload hash 351d6ad4e09cf32d · checked 2026-04-02T03:00:25+00:00
Sections:Payload hash 65bc64877f24fc8b · checked 2026-04-02T03:00:25+00:00
Sections: proof, command_surfaces, rollout_proof, providers, communications, analyticsEvent deliveries that still need visible operator handling
Replay or hold this delivery before calling the cross-app sync lane clean.
Target master_ai_webhook · Event ref C67714F27FBBADF7C6422D0E78 · Attempts 0 · Retries 0 · Callbacks 0 Last success not recorded · Last callback noneUse replay when the companion app is ready to receive the event, record webhook success only when you have proof, and keep dead-letter notes visible until the replay is actually closed.
1 pending · 0 failed · 0 dead-letter · 0 callbacks
Last success not recordedRecord the first callback proof from Agent Hub or run the Pass 50 verification script.
Keep agent work signed, scoped, reviewable, and recoverable
- Every side-effecting request carries a request ID, timestamp, signature, actor metadata, and idempotency key.
- Approval-required actions return explicit machine-readable review state instead of guessing or silently writing.
- Cross-app public IDs, backlinks, queue jobs, candidate master records, message receipts, and onboarding receipts now create a real operator context layer instead of loose copied links.
- Onboarding destinations are tied to the main function that must happen next, so non-HospiEdge employers can still be handled honestly through external or manual lanes.
- The hiring app remains the hiring system of record while Master AI operates through a visible integration boundary.