Source: https://guthlabs.ai/docs/jobs/rebecca-post-performance-records/qualification/ job / candidate # Post-performance records — qualification The distinct qualification record for Post-performance records. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: job:rebecca:post-performance-records **Parent lifecycle**: candidate **Page lane**: qualification **Lane lifecycle**: proposed **Owner**: Rebecca **Owner role**: Social media operating agent **Owner status**: PROPOSED **Qualification result**: NOT RUN · held for evidence and human review **Working browser surface:** [Agent jobs — builder overview]() — Inspect the package and stage a local project. This route is local-only; provider, credential, database, customer, publication, deployment, and production effects remain held. ## Qualification status **Result**: NOT RUN **Disposition**: HELD **Reviewer**: Not recorded **Receipt**: Not recorded This page defines proposed acceptance criteria for the qualification lane. It does not execute tests, establish compliance, qualify the subject, or authorize an effect. ### Lane-specific instrument aids [date-duration-calculatoroptional · Check observation-window duration and chronology using explicit dates and times.]()[countdown-days-until-timeroptional · Draft a human-visible deadline or follow-up countdown; it must not trigger publication or messaging.]() ## Outcome definitions **Verified**: All stated evidence and acceptance requirements passed for the exact reviewed revision; this still does not authorize deployment or an external effect. **Failed**: One or more deterministic acceptance requirements failed with an inspectable reason. **Needs review**: Evidence or interpretation is incomplete, conflicting, or awaits an identified human reviewer. **Held**: Authority, required evidence, safe execution conditions, or a principal gate is absent. The current record remains NOT RUN / HELD. These definitions describe candidate outcomes only. ## Proposed deterministic acceptance tests Route-resolution and distinct-content checks apply only to the admitted canonical routes in this record. Held source-proposed extensions are non-resolving proposals and are excluded. - Qualification passes only when the exact post content version has an approval record, the account matches the approved account, chronology fields are complete, every claimed metric has a source locator and capture time, and no negative test is triggered. - A draft without approval fails as unauthorized and is marked rejected or held. - Approval for one content version does not qualify a revised content version. - A scheduled calendar entry does not qualify as published without a receipt or equivalent source-bound publication evidence. - A publication claim with no timestamp, timezone, source locator, or receipt reference fails the source and chronology tests. - An observation window ending before it starts fails chronology validation. - An observation captured before publication fails chronology validation unless explicitly labelled as a pre-publication baseline. - A metric with a missing value, unit, source, or capture time fails the metric completeness test and is held. - Conflicting source values are preserved as separate observations and marked needs-review; they are not averaged or resolved automatically. - A customer name, handle, message, image, or testimonial without an explicit authorization record fails the privacy test. - Invented customer proof, invented engagement, inferred conversion, or unsupported causal language fails the evidence test. - Use of an unapproved account fails the authority test even if the content itself was approved. - Any paid-promotion action or direct-message commitment without separate human approval fails the principal-gate test. - The record must remain private or access-controlled until a human reviewer approves any public-facing summary. - Accessibility passes only when every form control has a label, keyboard access, visible focus, non-color status cues, readable error text, and an equivalent text representation for attachments or media evidence. - A failed external provider request, missing credential, unavailable database, or held upload must produce an explicit held state with retry or human-review instructions and no claim of completion. - The record must preserve canonical ID, origin, source locator, source hash when available, provenance, revision, lifecycle, links, and attachments without overwriting prior observations. - The record must remain proposal-only and must not claim deployment, provider connection, publication, customer indexing, or production qualification. ## Negative and held-state tests - Confusing a content calendar schedule with publication evidence - Self-authorizing publication or treating a native surface name as a connected provider feature - Recording engagement or customer outcomes without source evidence - Publishing personally identifying customer information or private direct-message content - Mixing metrics from different accounts, posts, versions, windows, or timezones - Overwriting contradictory observations instead of preserving revisions - Treating an unavailable receipt, credential, database, upload, or provider response as success - Using color-only status indicators or inaccessible attachment evidence - Allowing a performance summary to imply causation from observational metrics - Retaining unnecessary customer data or raw private communications ## Qualification claim boundary ### Potentially allowed only after the stated evidence - A draft, approval, schedule, observation, or hold exists in a local proposal record when the corresponding record and state are explicitly shown. - A metric was recorded from a named source at a stated time when the source locator and capture metadata are preserved. - A publication receipt was supplied or publication remains held, using the exact recorded state. - A post was approved for a specified account and content version when a matching approval record exists. ### Still held - The post was published unless publication evidence is source-bound and chronology-complete. - The post generated customers, conversions, revenue, or positive business impact without verified evidence. - Any customer testimonial, customer identity, or customer proof is authentic, authorized, or publishable. - An account connection, credential, database, provider, or external publication path is active. - A metric is live, complete, current, or representative when its source state has not been verified. - Rebecca may self-authorize publication, paid promotion, account use, or direct-message commitments. - The job package is deployed, indexed as customer data, or qualified for production. - Any causal claim linking the post to observed performance. ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `agents/index.html#rebecca` - `source_record:job:rebecca:post-performance-records` - `Observed native contract: NotebookCollectionKind project and fieldGuide collections` - `Observed native contract: NotebookTodoPayload deadlines and scheduled/deadline views` - `Observed native contract: Notebook record provenance, source locators, hashes, revisions, lifecycle, links, and attachments` - `Observed native contract: PointGuard context surface and specialist-app ownership` - `Observed app routes: /app/notebook/agent-logs/` - `Observed app routes: /app/notebook/approvals/` - `Observed app routes: /app/notebook/messages/` - `Observed app routes: /app/notebook/notes/` - `Observed app routes: /app/notebook/files/` - `Observed app routes: /app/notebook/projects/` - `Observed app boundary: provider, credential, database, customer, publication, and production effects are held`