Knowledgebase · How-To · source-bounded methods
Practical AI workflow guides organized by canonical search intent and linked to existing deep-dive articles and tools. The first-five order follows the KD04 handoff. Guides share this one index route; no near-duplicate article routes were created.
Choose the task, follow the steps, then verify against the declared acceptance check. These are methods and design guidance, not unmeasured performance promises. Check current primary documentation for provider-specific behavior and prices.
How-to library · 20 guides
1 Reduce repeated AI context without losing requirements
Canonical search intent: how to reduce repeated AI context
Quick answer: First write down the task requirements, then remove only repeated or irrelevant text. Compare the old and new inputs and reject any change that drops a binding requirement; a shorter prompt alone is not proof of improvement.
How to do it
- Save a copy of the current prompt and label the model/runtime and task version.
- List each requirement in plain language: output, constraints, sources, format, forbidden actions, and completion checks.
- Mark repeated boilerplate and stale context; do not remove any requirement merely because it uses many tokens.
- Make one change at a time and compare exact transmitted request bytes/tokens using the target runtime.
- Run the same representative fixtures against the original and edited prompt.
- Have an independent checker map each requirement to output evidence; reject missing or degraded requirements.
- Keep the change only if accepted outcomes remain within the declared rubric and the measured request boundary improves.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
Read the related existing article →
Open a related existing tool →
Inline glossary terms for this guide
Prompt compiler
Plain English: Software that turns a structured job description into a model-ready request.
Technical: Deterministic transformation with validation/rejection rules; structural retention does not prove semantic equivalence.
Example: A compiler can reject a job missing acceptance criteria rather than silently dropping them.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-002
Structural retention
Plain English: Evidence that required fields or words remain in a transformed prompt; it does not prove the model will behave the same.
Technical: Syntactic/structural comparison of extracted requirement units across representations.
Example: A compiler may keep every labelled field yet still alter meaning.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-002
Pillar page
Plain English: A broad main guide that explains a topic and links to focused supporting pages.
Technical: Canonical hub with broad intent; supporting pages target distinct sub-intents.
Example: The token optimisation overview links to measurement and workflow-specific guides.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-002
Supporting page
Plain English: A focused page answering one narrower question under a broader topic.
Technical: Distinct intent node with a defined parent/pillar and non-overlapping query ownership.
Example: A token counting procedure can support a definition/pillar without repeating it.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-002
Thin content
Plain English: A page that adds little useful detail beyond what another page already says.
Technical: Low-distinctiveness/low-utility content lacking sufficient original task value or evidence.
Example: A one-paragraph definition may belong in a glossary index instead of a standalone page.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-002
2 Measure AI token usage at the actual request boundary
Canonical search intent: how to measure tokens in an AI request
Quick answer: Count the exact request with the tokenizer/runtime used by the target model. A word-count estimate or a count of only the visible prompt may omit message framing, tools, schemas, files, or images.
How to do it
- Select the exact model and provider/runtime version.
- Capture the complete request structure, including system/developer/user messages, tools, schemas, and attached inputs where available.
- Use the provider/runtime usage field for a completed request; for preflight estimates, use the model-matched tokenizer and label the count estimated.
- Record input, cached input, output, reasoning, and other billable categories separately when exposed.
- Save timestamp, model/version, tokenizer, request hash, and whether the count is actual or estimated.
- Compare the recorded result with provider usage/billing records when available.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
Read the related existing article →
Open a related existing tool →
Inline glossary terms for this guide
Input token
Plain English: A token included in what you send to a model.
Technical: Provider accounting may distinguish uncached, cached, tool, or other input categories.
Example: Instructions and attached context may contribute to input, depending on the interface.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-001
Context utilization
Plain English: How much of a context capacity is occupied by the current request/state.
Technical: Observed tokens divided by a declared context limit; the accounting boundary must match.
Example: A percentage is meaningful only if both used and maximum values use the same runtime scope.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-001
Prefill
Plain English: The model processing the input before generating the answer.
Technical: Input-side transformer computation and cache construction; timing/usage depend on implementation.
Example: A large prompt can increase prefill work even if the answer is short.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-001
Search intent
Plain English: What the person is trying to accomplish with a query.
Technical: Task/information/decision goal inferred from query and context; not search-volume evidence.
Example: “How do I resume a session?” is a recovery task.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-001
3 Estimate the cost of an AI job from token usage
Canonical search intent: how to estimate an AI API job cost
Quick answer: Estimate one job by multiplying each billable token category by the current price for that category, then add other billed items and retries. A token estimate is not an invoice; check actual usage and the provider rate card.
How to do it
- Choose the job and a representative sample; avoid extrapolating from one unusually short or long request.
- Record actual usage by billing category, including input, cached input, output, tool/image charges, and retries if applicable.
- Retrieve the provider’s official current price table for the exact model/tier and date it.
- Compute each category separately: quantity in pricing units × applicable rate.
- Add explicit non-token charges and taxes only when applicable and supported by billing data.
- Use actual invoice/usage records to reconcile the estimate; retain unknown fields as unknown.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
Read the related existing article →
Open a related existing tool →
Inline glossary terms for this guide
Output token
Plain English: A token generated by a model in its response.
Technical: Provider-specific usage field for generated tokens; reasoning/output categories can differ by service.
Example: A longer response may increase usage without increasing accepted value.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-010
Reasoning token
Plain English: A provider/model-specific accounting category associated with internal reasoning capacity or usage.
Technical: Meaning, visibility, and billing are product-specific; do not assume all systems expose it.
Example: Keep it separate from visible answer tokens when the provider reports a distinct field.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-010
Total cost of ownership
Plain English: The full cost of operating something over a chosen period, not only its purchase price.
Technical: Lifecycle cost over explicit boundary including capital, energy, maintenance, services, labour and other included items.
Example: A GPU purchase price does not include power or staff time.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-010
How-to guide
Plain English: A procedure that helps a reader complete a task and check the result.
Technical: Task-oriented content with prerequisites, steps, failure handling, verification and evidence.
Example: A guide to estimate an API job bill includes dated rates and an audit check.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-010
Derived value
Plain English: A value calculated from other recorded values.
Technical: Transformation of parent inputs under an explicit formula; inherits their uncertainty and limitations.
Example: Energy cost calculated from measured kWh and a dated tariff is derived.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-010
4 Choose when an AI task needs a larger model
Canonical search intent: how to choose an AI model for a task
Quick answer: Choose the least costly model that passes a predeclared task acceptance test, and escalate only when a defined test fails or risk requires it. Model size or brand does not establish task suitability.
How to do it
- Define the job, acceptable output, risk level, latency needs, and data boundary.
- Create a small representative fixture set, including edge and failure cases.
- Select candidate models and pin provider/model/version and settings.
- Run every fixture under the same instructions and tool permissions.
- Grade outputs against predeclared criteria without relying only on model self-evaluation.
- Record all attempts, retries, latency, usage, and price basis.
- Choose the least costly route that satisfies the task/risk criteria; define escalation on a specific failure signal.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
Read the related existing article →
Open a related existing tool →
Inline glossary terms for this guide
Escalation threshold
Plain English: A defined signal that triggers a move to a more capable route or human review.
Technical: A predeclared decision condition evaluated from task state or verifier output.
Example: Escalate after a schema verifier fails, not because the response “feels weak.”
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-014
5 Compare local AI and cloud AI on the same work
Canonical search intent: how to compare local AI vs cloud AI
Quick answer: Run local and cloud routes on the same approved inputs, settings, acceptance tests, and accounting boundary. Compare accepted work, failures, latency, privacy controls, and fully included costs.
How to do it
- Write one task specification, privacy boundary, and independent acceptance rubric.
- Create identical authorized fixtures for local and cloud routes; pin model/runtime/quantization and provider version.
- Check model rights and provider data terms before sending sensitive inputs or using a local model commercially.
- Run both routes with matched tools, context, retries, and output constraints.
- Count all attempts and accepted results; measure route latency, local energy, API invoice, maintenance, and human time where in scope.
- Compare cost per accepted result and capability separately; mark missing measures unknown.
- Choose a route for this workload only, and document conditions that would change the choice.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
Read the related existing article →
Open a related existing tool →
Inline glossary terms for this guide
Local inference
Plain English: Running a model on hardware you or your organization operate.
Technical: Inference on locally controlled compute; data path, licence, energy, operations and security still need review.
Example: A local model can avoid sending a prompt to a hosted provider, but logs and network paths still matter.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-021
Cloud inference
Plain English: Sending a request to a model service operated by a provider.
Technical: Remote inference over a provider endpoint under its current terms, account settings and pricing.
Example: Check the provider’s current data retention and billing settings.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-021
Useful life
Plain English: The period an asset is expected to remain useful for the chosen purpose.
Technical: Scenario/accounting assumption or observed lifecycle period; must be identified as such.
Example: A calculator input is not a measured hardware lifespan.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-021
Residual value
Plain English: What an asset may be worth at the end of the chosen useful period.
Technical: Estimated or realized terminal value used in capital allocation.
Example: Set unknown or scenario value explicitly; do not call it measured without a sale/valuation.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-021
Data boundary
Plain English: Where information goes and who can access it during a workflow.
Technical: Documented data flow, processing location, retention, access, logging, and egress scope.
Example: A “local” app may still send telemetry or use a remote service.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-021
Assumption
Plain English: An input chosen for a scenario because it has not been observed.
Technical: Explicit model parameter not claimed as measured/current fact.
Example: A scenario useful life should be labelled an assumption.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-021
6 Find and resume the right OpenCode session
Canonical search intent: how to find and resume an OpenCode session
Quick answer: Identify the exact project and session first, preserve session data, then use commands supported by the installed OpenCode version to resume. Verify the requested artifacts; a stored session is not proof the job finished.
How to do it
- Record OpenCode version and the project working directory.
- Before repair/import/cleanup, preserve a private backup of relevant OpenCode data; protect session IDs and exports.
- Check whether the original process/server is still active; avoid starting duplicate generation until its state is known.
- Use the installed version’s official CLI documentation to list sessions and identify the exact project/session; do not assume newest is correct.
- Resume/continue that session using the documented version-specific command and session ID.
- Inspect the last tool results, files, and task state; compare against the original task requirements.
- Run independent acceptance checks and record unfinished work as incomplete.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
7 Prevent duplicate AI jobs with idempotency
Canonical search intent: how to prevent duplicate AI jobs
Quick answer: Give each logical job a stable idempotency key and record side effects against it. On retry, return or inspect the existing result instead of repeating a non-idempotent action.
How to do it
- Choose a stable identifier for the logical job; include an input/version hash if changed inputs represent a new job.
- Persist the key and an explicit state such as received, running, succeeded, failed, or outcome-unknown.
- Before a side effect, check whether that key already has a committed result.
- Make the side effect and state transition atomic where the storage system supports it; otherwise use an outbox/receipt reconciliation pattern.
- On retry, return the committed receipt or query the destination instead of repeating the action.
- Test duplicate delivery, timeout after commit, process crash, and concurrent requests.
- Retain enough audit data to investigate without storing unnecessary sensitive payloads.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
Read the related existing article →
Inline glossary terms for this guide
Idempotency key
Plain English: A stable identifier that marks retries as the same logical operation.
Technical: Client-generated/request key used by a service or workflow to deduplicate execution within defined scope/retention.
Example: Re-use the key after a timeout for the same operation; use a new key for changed intent.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-031
8 Checkpoint a long-running AI job safely
Canonical search intent: how to checkpoint a long-running AI job
Quick answer: Persist a versioned, integrity-checked checkpoint at safe boundaries. Include only state needed to reproduce or continue the work, and test a resume from a copied checkpoint before relying on it.
How to do it
- Define a safe checkpoint boundary where no untracked side effect is in progress.
- Create a versioned schema with job ID, state version, completed steps, pending steps, artifact references, and integrity metadata.
- Exclude secrets; store credential references or reacquire authorization through approved flows.
- Write atomically or via temporary file + validated replacement appropriate to the storage system.
- Record the checkpoint only after durable storage confirms the write.
- On resume, validate schema version, integrity, job identity, and idempotency status.
- Run fault-injection tests at each boundary and verify outputs after resume.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
Read the related existing article →
Inline glossary terms for this guide
Checkpoint integrity
Plain English: Confidence that a saved checkpoint is complete and has not been corrupted or mixed up.
Technical: Validation of schema, identity, version, digest, and consistency with external side effects.
Example: Reject a checkpoint with the wrong job ID or schema version.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-033
9 Resume an interrupted AI job without repeating side effects
Canonical search intent: how to resume an AI job after a crash
Quick answer: Stop duplicate execution, preserve logs and artifacts, identify the last durable boundary, then resume only after checking idempotency and current state. Re-verify all outputs after recovery.
How to do it
- Stop or isolate duplicate workers; determine whether the original process is still active.
- Preserve logs, receipts, checkpoint, and generated artifacts before cleanup.
- Classify the last known state: no side effect, side effect committed, or outcome unknown.
- Reconcile external state using a stable job/operation ID; do not blindly repeat a timed-out write.
- Restore the latest valid checkpoint or resume from an idempotent step using the documented runtime.
- Re-run independent verification for all required outputs and side effects.
- Close the incident with a clear completed/incomplete/unknown status and a recovery note.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
Read the related existing article →
Inline glossary terms for this guide
Resume operation
Plain English: Continuing a paused or interrupted job from saved state.
Technical: State restoration plus reconciliation/idempotency checks before executing pending transitions.
Example: Recheck whether the last external write already committed before resuming.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-036
10 Tell a resource wait from a stalled AI agent
Canonical search intent: how to detect a stalled AI agent
Quick answer: A heartbeat says a process recently emitted a liveness signal; semantic progress means task state or an accepted artifact changed. Treat missing heartbeat, unchanged task state, and explicit resource wait as different signals.
How to do it
- Observe process liveness separately from task progress and acceptance.
- Define a heartbeat interval/expiry based on system behavior, not a universal default.
- Emit semantic progress events only at meaningful transitions: accepted input, step completion, durable artifact, wait entry/exit.
- Record state version, last progress timestamp, current wait reason/resource, and owner.
- Alert differently for heartbeat lost, heartbeat alive but no semantic progress, WAIT_RESOURCE, and completed-but-unverified.
- Inspect logs/resource queue before terminating; preserve state and avoid duplicate execution.
- Declare success only after artifact-level verification.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
11 Implement WAIT_RESOURCE as an explicit workflow state
Canonical search intent: how to implement WAIT_RESOURCE
Quick answer: Represent WAIT_RESOURCE as a typed, observable, resumable state with resource identity, entry time, retry policy, deadline, and escalation. Do not turn it into an unbounded sleep loop.
How to do it
- Define WAIT_RESOURCE as a state in the workflow state machine, not as free-form text.
- On entry, persist job ID, resource type/identifier, reason, start time, state version, and safe resume point.
- Set bounded retry/backoff and a deadline based on service policy; expose values as configuration.
- Subscribe to a resource-available event when supported; otherwise schedule a bounded retry.
- If deadline passes, escalate, cancel, or return an explicit blocked result; never wait forever silently.
- On wake, re-check resource ownership and job idempotency before continuing.
- Log wait duration and outcome without leaking sensitive input.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
12 Implement WAIT_AUTH for expired or invalid credentials
Canonical search intent: how to implement WAIT_AUTH
Quick answer: Represent missing/expired authorization as WAIT_AUTH, stop protected actions, request reauthorization through the approved provider flow, then validate the granted scopes and resume from a safe boundary.
How to do it
- Classify auth failures using provider status/error code from sanitized logs.
- Stop protected calls and transition to WAIT_AUTH; do not retry credentials indefinitely.
- Check expiry, audience, scopes, consent, account status, and provider incident status through approved interfaces.
- Request reauthorization using the provider’s supported interactive/OAuth flow; never solicit or log raw secrets.
- Store credentials in the approved secret manager and request the minimum needed scopes.
- Verify with a non-destructive request and confirm the returned identity/scopes.
- Resume from a durable, idempotent checkpoint and record the authorization event metadata.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
Read the related existing article →
Open a related existing tool →
Inline glossary terms for this guide
Knowledgebase entry
Plain English: A reference page defining a term, status, command, or recurring troubleshooting fact.
Technical: Structured reference object scoped by platform/version with source and review metadata.
Example: A WAIT_AUTH entry defines state; a separate guide explains a recovery flow.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-043
13 Verify an AI agent completed the requested work
Canonical search intent: how to verify AI agent completion
Quick answer: Check the requested artifacts and acceptance criteria independently, inspect test/source evidence, and list unknowns. A completion message is an assertion, not an independent verifier.
How to do it
- Read the original request and convert each binding requirement into an observable check.
- Confirm required files/records exist and are the expected revision; inspect hashes or schemas where suitable.
- Run tests or deterministic checks selected before seeing the model’s completion message.
- Check factual claims against traceable source references and verify citations resolve to the supporting claim.
- Inspect failures, retries, warnings, and external side effects.
- Separate structural pass from semantic/factual pass; note what was not checked.
- Report complete only when required checks pass; otherwise state partial, failed, or unknown.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
Read the related existing article →
Open a related existing tool →
Inline glossary terms for this guide
Binding requirement
Plain English: A condition the result must satisfy to count as correct.
Technical: A testable constraint linked to independent output evidence or a verifier.
Example: “Do not change these values” should map to an explicit comparison check.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-047
Acceptance criterion
Plain English: A check that determines whether the requested work is good enough to accept.
Technical: Predeclared predicate/rubric applied independently to an artifact or outcome.
Example: A generated file exists, parses, and passes the requested tests.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-047
Independent verification
Plain English: A check of the result that does not rely only on the model saying it is correct.
Technical: External/deterministic or separately reviewed predicate against requirements and evidence.
Example: Run tests or compare a generated file against expected bytes.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-047
Artifact hash
Plain English: A compact fingerprint used to detect whether a file changed.
Technical: Cryptographic digest over exact bytes under a named algorithm and normalization boundary.
Example: Compare a generated file’s SHA-256 to the expected digest.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-047
Exact-byte verification
Plain English: Checking that output bytes match an expected byte sequence exactly.
Technical: Byte-for-byte equality after defining encoding/newline policy; stricter than semantic equivalence.
Example: A config output with required exact formatting can be compared bytewise.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-047
Source ledger
Plain English: A structured list connecting claims to the sources that support them.
Technical: Evidence registry with source IDs, versions, retrieval dates, claim links and limitations.
Example: A price claim links to the dated official rate page.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-047
Claim ledger
Plain English: A list of factual statements and the evidence/review state for each.
Technical: Claim-level provenance, classification, source references and release status.
Example: Mark an unsourced savings percentage as blocked, not as fact.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-047
Evidence provenance
Plain English: Where evidence came from and how it was collected.
Technical: Traceable source/run/version/date/method chain for a claim or measurement.
Example: Link a measured value to the exact run ledger and method.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-047
14 Automate a WordPress draft with preflight and readback
Canonical search intent: how to automate WordPress drafts safely
Quick answer: Before any WordPress write, perform fresh read-only duplicate/canonical checks, validate the exact payload and authorization, keep a recovery path, then independently read back the resulting draft. KD04 performs no site writes.
How to do it
- Prepare a manifest with candidate canonical identity, exact body revision/hash, destination type, slug candidate, and field mapping.
- Perform a fresh read-only inventory of matching titles, slugs, IDs, and canonical IDs; pause on ambiguity.
- Confirm no protected or unresolved identity is being duplicated (including post 40).
- Validate content, links, metadata ownership, permissions, backup/restore plan, and exact draft-only authorization.
- Submit only through the KD10-approved workflow; KD04 supplies no WordPress write.
- Read back the stored draft independently and compare ID, status, route, revision/hash, and expected fields.
- Record discrepancy/rollback plan; keep publishing as a separate authorization gate.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
Read the related existing article →
Open a related existing tool →
Inline glossary terms for this guide
Rollback
Plain English: A controlled way to undo or compensate for a change.
Technical: Restoration/compensation operation with defined reversibility, authorization and consistency semantics.
Example: Use a backup/readback plan before an automated content change.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-050
Internal link graph
Plain English: A map of links connecting pages and their roles.
Technical: Directed graph of URL nodes and contextual edges with route-state constraints.
Example: A how-to can link to its hub, background experiment, and glossary definitions.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-050
WordPress REST API
Plain English: A web interface that lets software read or change WordPress content through HTTP requests.
Technical: WordPress REST endpoints with authentication, permissions, object schemas and method semantics.
Example: KD10 must use authorized endpoints and verify the stored draft.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-050
Readback verification
Plain English: Reading saved data after a write to confirm it matches what was intended.
Technical: Independent retrieval of persisted object and comparison against expected revision/fields/status.
Example: Fetch a created draft and compare its ID, status, slug, and body hash.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-050
Draft import
Plain English: Creating or updating unpublished content from a prepared handoff.
Technical: Authorized content mutation to draft state with field mapping and identity checks.
Example: A draft import does not authorize publication.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-050
15 Choose what to keep, summarize, or retrieve from context
Canonical search intent: how to reduce context size safely
Quick answer: Keep exact constraints, current task state, required source references, and acceptance tests. Summarize only information whose loss is acceptable; retrieve source material when it must remain auditable.
How to do it
- List what the next step must know: constraints, current state, evidence, output schema, and failure conditions.
- Classify each context item as binding, useful reference, redundant, stale, or sensitive.
- Keep binding and provenance-bearing information verbatim or losslessly represented.
- Summarize only stable background where a source link or retrieval route remains available.
- Move large reference corpora to retrieval when the workflow can retrieve exact relevant passages.
- Measure source coverage, token boundary, and task acceptance before and after.
- Restore the original context if a source/requirement is missing or acceptance regresses.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
Read the related existing article →
Inline glossary terms for this guide
Token budget
Plain English: The amount of model input/output capacity or usage allocated to a task.
Technical: A request-level or workflow-level constraint on tokens, whose scope depends on runtime/provider.
Example: Reserve room for the answer and tool results rather than filling all capacity with history.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-005
Context compression
Plain English: A way of representing prior information more compactly, often by summarizing or selecting it.
Technical: Transformation of context that may be lossy; must preserve requirements and provenance.
Example: A summary should retain source references for facts that need verification.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-005
Retrieval-augmented generation
Plain English: A method where relevant source passages are fetched and supplied when needed instead of sending every document every time.
Technical: A retrieval pipeline selects indexed evidence and conditions model generation on retrieved content.
Example: Retrieve the exact policy section relevant to the current question.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-005
16 Measure cost per independently verified AI result
Canonical search intent: how to calculate AI cost per verified result
Quick answer: Divide the total included workflow cost by the number of independently accepted results. Include failed attempts and retries in the numerator; if accepted results are zero, the ratio is undefined.
How to do it
- Define the accepted result unit and independent pass criteria before the run.
- Include all model calls, retries, tool charges, compute/energy and human work that belong to the chosen boundary.
- Count only independently accepted outputs in the denominator.
- Compute included cost divided by accepted count; if count is zero, report undefined rather than zero.
- Report excluded costs and time period; compare routes only on matched jobs.
- Preserve raw ledger rows so the aggregate can be audited.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
Read the related existing article →
Inline glossary terms for this guide
Cost per accepted result
Plain English: All costs included in a chosen boundary divided by independently accepted useful results.
Technical: C/A where C is included cost and A accepted outputs; undefined for A=0.
Example: Include failed attempts in costs but not in accepted count.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-011
Verified useful output
Plain English: An output that passes an independent check and is useful for the task.
Technical: Outcome counted under a predeclared acceptance rubric, with provenance and failure denominator.
Example: Count a generated report only after required checks pass.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-011
17 Compare two AI models with a matched benchmark
Canonical search intent: how to compare AI models fairly
Quick answer: Use the same task fixtures, prompt budget, settings, tool access, acceptance rubric, and retry policy for both models. Report each attempt and uncertainty rather than selecting a winner from one anecdote.
How to do it
- Define comparison question, task mix, acceptance rubric, and stopping rule.
- Pin exact model IDs/versions, quantization, runtime, prompts, tools, context, and decoding settings.
- Use the same fixture set and randomization/repetition plan for each route.
- Run all cases, capturing every error, timeout, retry, and partial output.
- Have a blind or deterministic verifier apply the predeclared rubric.
- Report acceptance, cost, latency, and uncertainty separately; do not collapse into one unqualified winner.
- Publish limitations, excluded cases, and evidence references.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
Read the related existing article →
Inline glossary terms for this guide
Semantic equivalence
Plain English: Two prompts or outputs mean the same thing for the task.
Technical: A task-relative relation requiring evaluation; token similarity alone cannot establish it.
Example: A shorter paraphrase must pass the same task acceptance rubric.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-016
Decode
Plain English: The stage where the model generates output tokens.
Technical: Autoregressive token generation after prompt processing; speed depends on model/runtime/hardware/settings.
Example: Do not infer decode speed from total job wall time that includes tools and waits.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-016
Model digest
Plain English: A stable fingerprint identifying the exact model artifact/version used.
Technical: Cryptographic/content digest of a model artifact or immutable revision.
Example: Record the digest so a later test uses the same weights.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-016
Raw throughput
Plain English: How much a system produces per unit time without necessarily checking whether it is correct.
Technical: Unfiltered output units/time under a declared measurement boundary.
Example: Tokens per second does not say how many accepted tasks completed.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-016
Matched benchmark
Plain English: A comparison where important conditions are kept the same across alternatives.
Technical: Controlled evaluation with equivalent fixtures, acceptance, settings, resource boundary and attempt accounting.
Example: Run both models on the same task set and verify both the same way.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-016
18 Measure whole-system energy for local AI
Canonical search intent: how to measure local AI energy use
Quick answer: Measure energy at the whole-system boundary with a meter over a defined interval, record an idle baseline and task manifest, and report the tariff separately. Do not infer watts from tokens or elapsed time.
How to do it
- Choose a meter that captures the complete computer/system boundary relevant to the claim.
- Record idle baseline under a stated configuration and measurement interval.
- Pin task, model digest, runtime, hardware, settings, and run IDs.
- Measure during representative inference and record total energy plus interval; repeat only under a stated protocol.
- Record tariff/date separately; energy is not the full ownership cost.
- Count successful and failed attempts and independently accepted outputs.
- Calculate only with the available measurements; leave missing watts, energy, or accepted-output cost unknown.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
Read the related existing article →
Inline glossary terms for this guide
Inference
Plain English: A model producing an answer from input.
Technical: Execution of a trained model for a request, with runtime-specific prefill/decode and resource behavior.
Example: A local inference run may use GPU memory and system power.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-019
Idle power
Plain English: Electricity a system uses while waiting or doing no measured task.
Technical: Baseline power over a defined state/interval; allocation methodology must be stated.
Example: A whole-system meter can measure idle draw under a recorded configuration.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-019
Incremental power
Plain English: Extra power used because a task is running compared with its baseline.
Technical: Difference between workload power/energy and a specified idle/control baseline.
Example: Report meter placement and interval, not just GPU board power if claiming system cost.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-019
Energy per inference
Plain English: Electricity consumed for a defined model task/run.
Technical: Metered energy over a defined run boundary; attribution of idle/shared loads must be disclosed.
Example: If wall power was not measured, energy per result remains unknown.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-019
Resource contention
Plain English: Multiple jobs competing for the same limited hardware or service capacity.
Technical: Shared-resource scheduling interference that can change latency/throughput/failure behavior.
Example: Concurrent local models may compete for GPU memory.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-019
Measured value
Plain English: A value observed using a stated instrument or source and method.
Technical: Observed datum with unit, scope, instrument/source, time, and uncertainty/limitations.
Example: A wall meter reading is measured only for its defined boundary.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-019
Unknown value
Plain English: A value that has not been established.
Technical: Null/unknown evidence state; must not be silently treated as zero.
Example: No watt reading means local electricity cost is unknown.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-019
19 Recover an OpenCode session after a machine restart
Canonical search intent: how to recover OpenCode after restart
Quick answer: Back up relevant local state, identify the project and session, check the installed OpenCode CLI reference, resume deliberately, and verify files/tests. The KD12 guide documents commands but reports no general recovery success rate.
How to do it
- Record restart time, OS/build, OpenCode version, and project directory.
- Preserve a private backup of relevant OpenCode data; do not edit its database manually.
- Check for still-running server/TUI/backend processes.
- Use the installed CLI’s official docs to list candidate sessions and match project, session ID, model, and time.
- Resume the selected session with the documented command; do not assume recent activity means active execution.
- Inspect the last interaction and determine whether the original task ended, failed, or is incomplete.
- Verify artifacts and tests; document anything not recovered.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
20 Record all attempts, waits, failures, and human interventions
Canonical search intent: how to measure AI workflow outcomes
Quick answer: Record one row per attempt, including retries, wait states, failure reason, verification result, and human intervention. Report the full denominator, not only successful completions.
How to do it
- Assign a stable workflow/run ID and a unique attempt ID per execution.
- Record start/end times, model/provider/runtime version, and state transitions.
- Record retries, timeouts, resource/auth waits, failures, cancellation, and external receipts.
- Record verification result and accepted-output ID separately from model self-report.
- Track human active review/correction and blocked time separately with a declared method.
- Redact secrets and minimize payload retention; test access and retention policies.
- Compute rates using all eligible jobs and explicitly state exclusions.
Common failure modes
- Removing a required constraint while shortening context.
- Counting only the visible prompt and missing tools, schemas, retries, or runtime-added content.
- Treating one run, a heartbeat, or a model summary as proof of general success.
Limitations
- No universal threshold, timeout, cost, speed, quality, or acceptance rate is asserted.
- Provider/runtime behavior can change; confirm current official documentation for implementation details.
- Local KD12 evidence is narrow and does not establish general production performance or savings.
- This draft is an editorial candidate; KD07 canonical admission and KD10 live-site dedupe/design/review remain necessary.
Read the related existing article →
Inline glossary terms for this guide
Observability
Plain English: Having enough records to understand what a workflow did and where it stopped.
Technical: Instrumentation for logs, metrics, traces, state transitions and outcomes with privacy boundaries.
Example: A run ID and state timeline help investigate an interruption.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-045
Trace
Plain English: A linked record of steps and requests belonging to one workflow run.
Technical: Correlated spans/events under trace and parent IDs; content capture should be privacy-minimized.
Example: Follow one run from queue entry through model call, tool action, and verifier.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-045
Attempt ledger
Plain English: A record of every try, including successes, failures, retries, and waits.
Technical: Append-oriented event/row structure with stable job/run/attempt IDs and outcome fields.
Example: Do not store only successful rows when calculating a pass rate.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-045
Failure denominator
Plain English: The complete set of attempted jobs used when calculating a failure or success rate.
Technical: Eligible attempts under a declared inclusion/exclusion policy, including retries or job-level distinct counts as specified.
Example: State whether a rate counts attempts or logical jobs.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-045
Acceptance rate
Plain English: The share of attempted outputs that pass the chosen acceptance checks.
Technical: Accepted units divided by declared eligible attempts or jobs; denominator must be explicit.
Example: Report retries separately so the rate is interpretable.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-045
Additional inline glossary definitions
These terms remain definitions attached to their KD04 parent-guide keys, not separate glossary or article routes.
Cached input token
Plain English: Repeated input a provider recognizes as cacheable under its rules; price and eligibility vary.
Technical: Input usage assigned to a provider-defined cached tier after matching cache conditions.
Example: Check returned usage and billing rather than assuming a stable prompt was cached.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-012
Context overflow
Plain English: When a request/state exceeds a system’s usable context capacity or is truncated/rejected.
Technical: Runtime/provider-specific limit failure or truncation condition.
Example: A long session may fail when previous turns are resent with new tool output.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-006
Prompt contract
Plain English: A clear work instruction that says what the model should do, what it must not do, and how success will be checked.
Technical: Versioned task specification including objective, constraints, inputs, output schema, acceptance criteria and stop conditions.
Example: Require a file plus a test result, not just a “done” message.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-007
System instruction
Plain English: Stable high-level guidance supplied to a model by an application.
Technical: A role/message category whose priority and persistence depend on API/runtime semantics.
Example: Do not assume moving text into a system message reduces billed input.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-006
Fallback route
Plain English: A backup model or service used when the preferred route cannot complete the task.
Technical: A controlled transition with bounded attempts, state transfer, idempotency, and acceptance gates.
Example: If a provider times out, query the original operation before submitting elsewhere.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-015
Model card
Plain English: A document describing a model’s intended use, limits, data, and evaluation information.
Technical: Model documentation accompanying a release; completeness and legal terms vary.
Example: Read the card alongside the actual licence before deployment.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-020
KV cache
Plain English: Temporary stored model state that can avoid recomputing earlier context in some runtimes.
Technical: Key/value tensors retained during autoregressive inference; consumes memory and has runtime-specific lifecycle.
Example: Longer context can require more KV-cache memory.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-018
Subscription plan
Plain English: A recurring fee for access to a product under plan-specific limits and terms.
Technical: Entitlement product not necessarily equivalent to metered API use; limits and features can change.
Example: A chat subscription is not automatically a fixed pool of API tokens.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-012
Retry
Plain English: Another attempt after an earlier attempt did not return a usable/known result.
Technical: Subsequent execution linked to the same logical job; may incur cost or repeat side effects.
Example: A timeout retry may duplicate a write unless the action is idempotent.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-032
Retry budget
Plain English: A limit on how many or how much retry work a job may use.
Technical: Bounded attempts/time/cost policy with terminal conditions and backoff.
Example: Stop after a configured budget and surface an error instead of looping.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-032
Human active time
Plain English: Time a person is actively working on prompting, reviewing, correcting, or operating the job.
Technical: Measured human-attention intervals under a declared scope; distinct from model elapsed time.
Example: Record minutes spent checking an output separately from the model’s runtime.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-054
Elapsed time
Plain English: Clock time from a chosen start event to a chosen end event.
Technical: Wall-clock duration including any included waits, retries, and handoffs.
Example: A task can take a long time while using little active human time.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-054
Blocked time
Plain English: Time a person or dependent workflow cannot proceed because it is waiting on this task.
Technical: Observed interval where another activity is prevented; not equal to total model latency.
Example: Only price waiting as labor/opportunity cost if the person is genuinely blocked under the chosen model.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-054
Opportunity cost
Plain English: The value of the best alternative use of time or resources.
Technical: Counterfactual economic value requiring an explicit alternative and assumption.
Example: A waiting minute is not automatically a lost billable minute.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-054
Canonical URL
Plain English: The chosen primary web address for a page or topic.
Technical: Preferred URL identity; must align with page identity, redirects, duplicates, and indexing policy.
Example: Supporting guides should link to the one admitted pillar route.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-051
Canonical content identity
Plain English: The record that says which underlying content item a draft or page belongs to.
Technical: Stable content ID distinct from slug/body revision; requires admission and revision binding.
Example: A slug match alone does not prove two drafts share the same canonical content.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-051
Keyword cannibalisation
Plain English: When multiple pages compete for the same main question and confuse readers/search systems.
Technical: Intent overlap among URLs without distinct roles/canonical mapping.
Example: One page defines token optimization; another should target agent-specific implementation.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-051
Model licence
Plain English: The legal terms governing how a specific model can be used.
Technical: Version-specific licence/terms attached to weights or service; scope can differ from model card.
Example: Check exact weights and intended commercial use before deployment.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-020
Least privilege
Plain English: Giving a tool or agent only the access it needs.
Technical: Authorization minimized by scope, action, resource, duration and identity.
Example: A writing workflow should not receive admin access if draft-only scope suffices.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-030
Rate limit
Plain English: A cap on how quickly or how much a service can be used.
Technical: Provider/runtime quota policy expressed over time/account/resource; reset rules vary.
Example: Use documented retry guidance rather than sending a burst after a limit response.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-032
Timeout
Plain English: A limit after which a system stops waiting for a response.
Technical: Deadline on an operation; expiry does not prove the remote operation failed.
Example: Query the operation receipt after a timeout before retrying a write.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-032
Backoff
Plain English: A delay strategy between retries, often increasing wait to reduce overload.
Technical: Retry scheduling function; jitter/limits and provider hints should be explicit.
Example: Wait longer after repeated transient errors rather than retrying continuously.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-032
Circuit breaker
Plain English: A control that pauses calls to a failing service for a period.
Technical: Stateful failure threshold/cooldown mechanism preventing repeated calls to an unhealthy dependency.
Example: Stop routing new jobs to a provider while its failure state is active.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-015
Duplicate preflight
Plain English: A check for an existing page or conflicting identity before importing content.
Technical: Fresh read-only candidate/live inventory comparison by ID, canonical identity, slug, title and revision.
Example: Pause if an existing post’s identity is unresolved.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-051
Plan economics
Plain English: Comparing a plan’s fee and included use with alternatives and actual value received.
Technical: Decision model over dated terms, actual usage, displaced spend, capability and opportunity cost.
Example: A fixed fee can be compared with metered use only for equivalent tasks and period.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-012
Parallelism
Plain English: Doing independent tasks at the same time.
Technical: Concurrent execution of tasks with coordination, contention, ordering and retry effects.
Example: Two independent documents may be processed concurrently if final merge is checked.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-030
Concurrency
Plain English: How many tasks are running at the same time.
Technical: Active in-flight operations under a scheduling/resource policy.
Example: A concurrency cap can protect a shared provider quota.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-030
Fan-out/fan-in
Plain English: Splitting a job into independent parts, then gathering their results.
Technical: Parallel decomposition followed by deterministic aggregation/verification.
Example: Split independent research topics, then deduplicate and check citations at merge.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-030
Human-in-the-loop
Plain English: A person reviews, approves, or supplies judgment during an automated workflow.
Technical: Human decision/authorization stage with role, evidence, timing and escalation semantics.
Example: Require a person’s approval before an external write.
DEFINITIONAL; platform-specific meanings require current primary documentation. · Parent guide key: HT-030
Research, visuals and tools
Open the Research Questions, Infographics, or existing tools. Community evidence remains UNVERIFIED COMMUNITY DATA until supported and reviewed.