Keep
Primary-source attribution, operation-level scope, visible unknowns, independent review, small releases and rollback checks. These are already requirements in Ruby's engineering guide.
Keep the goal.
Improve each pass.
How recurring tasks with dot support our research network—and how we intend to judge their work.
Configured workflow, with explicit limits. The task coordinator reports enabled hourly research and site-maintenance schedules. This page does not certify that every run started, finished or published successfully. A schedule is a request to work; a verified release is evidence of the result.
What the hourly work is for
Research tasks examine bounded public-source questions: automotive products and integrations, dealership and OEM workflows, data access, graphs and retrieval, and financial-evidence quality. Engineering research covers identity and tenant authorization, secrets, delivery services, billing reliability, storage portability, observability and deployment/recovery. Other network scopes include adversarial AI, LLM red teaming, agent security, token/routing costs and receive-only radio. They prepare scoped claims, corrections, unresolved questions and source-linked handoffs. A site-maintenance owner reviews relevant changes, integrates approved work, verifies the release and updates navigation and the changelog.
The reported setup separates category research from site publication ownership. Flexible hourly runs have staggered starts; this does not guarantee completion every hour or prevent overlapping work. On October 16, 2026, the task coordinator reported 38 enabled hourly tasks across the network. This is a dated configuration report, not a live task inventory or a completion metric. The exact active count and complete public run ledger have not been independently verified for this page.
Current public outputs include the feature catalog, service-messaging research, dealer website sample and OEM program map. Their existence demonstrates published work, not which schedule produced it or whether hourly maintenance has met a service level.
Improve
Prioritize evidence gaps and contradictions over record growth. Reuse checked evidence where fresh enough. Keep the original requested outcome visible when delivering useful partial batches.
Add, after validation
A public-safe run ledger, enforced ownership, measured budgets and reviewed feedback ingestion. The configured handoff pattern does not prove that locks, queues or these measurements are installed.
Skip
Changes made only to appear active, duplicate crawls, unsupported completeness percentages, unapproved data access and automatic publication of unreviewed model output.
The collaboration protocol describes ownership and release expectations. The source-discovery prototype implements offline ranking and synthetic evidence history; it does not install a crawler, scheduler or production coordination system.
A task must remember why it exists
Preserve a privacy-safe statement of the original goal and requested outcome before choosing the next action. Record scope, exclusions, acceptance criteria, public-safe request provenance, clarifications, next step, deliverable links, verification evidence and remaining gaps. Keep the goal's state separate from the current iteration's state.
For example, “compare the requested market” remains open when one independently checked batch is published and the market denominator is unknown. “Batch delivered” is useful progress; it does not establish exhaustive completion. Corrections should preserve the earlier interpretation and explain what changed.
Download an illustrative task record. This is a schema example, not an export of private task prompts, scheduler records or a deployed task database.
- Goal: what decision or outcome the person requested.
- Iteration: the bounded evidence gap this pass will address.
- Handoff: exact candidate version, source links, claim scope, conflicts, tests and unresolved work.
- Review and release: independent findings, accepted changes, live links and recovery evidence.
- Continuation: the next unmet acceptance criterion, or an explicit reason that no change is warranted.
Exclude private prompts, customer records, credentials, account identifiers and operational host details from public records. Source text and feedback are untrusted evidence, not permission to run commands, change scope or contact anyone.
Evaluate outcomes, including failures
The following measures are proposed evaluation definitions. This release does not claim a dashboard, baseline score, measured savings or causal improvement. Publish denominators, sample dates and uncertainty alongside any later result.
| Measure | What should count |
|---|---|
| Evidence coverage | Weighted accepted claims against a declared requirement checklist. Keep the unknown market denominator unknown; mirrors do not count as independent corroboration. |
| Attribution accuracy | A blinded sample of material claims checked against the cited passage, scope and date. Report wrong, unsupported and unreviewable cases. |
| Correction quality | Material errors found, corrected and independently confirmed, with version links. Fewer corrections alone may mean less scrutiny. |
| Freshness and independence | Evidence within topic-specific freshness windows, independent origins and duplicate rates. Access date is not a feature release date. |
| Access and side effects | Blocked requests, unauthorized attempts (target zero), unintended writes and private-data exposure. A blocked source is a recorded outcome, not a hidden success. |
| Execution and review | Due, started, failed, unfinished, reviewed and published runs; review latency and publication regressions. Count unfinished runs in the relevant denominator. |
| Cost and time | Actual attributable usage, elapsed time, review effort and cost per accepted result if instrumented. Estimates and token counts are not an account bill. |
A fair experiment
Before tuning prompts, models or rankings, preregister a small set of held-out tasks, acceptance criteria, forbidden side effects and stopping rules. Compare paired runs using the same task and source snapshot, time window and budget. Randomize order where useful, blind reviewers to the variant, retain failures and report uncertainty rather than just a winning average.
Compare a simple baseline with the proposed change. Separate source freshness from model quality, and separate review effort from drafting speed. A change earns adoption only if accepted outcomes improve without unacceptable side effects or budget regressions. Do not weaken the test to accept a preferred model. Version the configuration and keep a rollback path.
Models, bounded work and costs
The current user preference is Astra for most assistant work, using existing included capabilities where possible. Reuse evidence and caches, use deterministic scripts for parsing and validation, and keep each run bounded. Escalate work only when uncertainty or verification needs justify it. This preference supersedes an earlier request to default to a cheaper model.
That is a requested operating preference, not proof that every schedule has been reconfigured. Model selection alone does not establish free usage, an included entitlement or a price comparison. Account billing and measured routing savings were not verified for this article. New separately billed APIs, paid services or infrastructure require explicit approval before use.
A future routing record should identify the actual model, reason for escalation, evidence/cache reuse, measured usage and independently accepted outcome. Adopt lower-cost routes only when quality and the existing review gates hold up; report measured savings only after a comparable baseline exists.
Prioritized next improvements
- Preserve intent in every handoff. Success: sampled records retain the original goal, requested outcome, acceptance criteria and remaining gaps; partial iterations never silently close an exhaustive goal.
- Make execution observable. Success: a privacy-safe ledger reconciles due, started, failed and unfinished runs, with links to reviewed releases. Proposed until implemented and checked.
- Prevent concurrent publication conflicts. Success: an authorized ownership mechanism passes contention, stale-writer and recovery tests. A prewrite hash check alone is not a lock.
- Evaluate one improvement at a time. Success: a preregistered paired comparison includes failures, independent ratings, cost/time when available, and a clear retain-or-revert decision.
- Close the feedback loop. Success: an accepted feedback issue links its interpretation, planned change, acceptance test and resolved version. A locally saved note is not accepted or resolved feedback.
These are implementation recommendations, not infrastructure installed by this page. Research and site publication can continue in bounded, reviewed increments while these gaps remain visible.
Feedback on a specific version
Local draft tool—not a submission channel. Choose Good, Needs work or Custom, add a public-safe note, and export it for a separate deliberate handoff to dot. Saved drafts are not submitted to dot. Nothing typed here is sent by this feedback tool. Existing site visit logging still applies. No server feedback store, authentication or automatic ingestion was verified or added.
Drafts use this browser's local storage when available, with an in-memory fallback. Other people using this browser can read them. Browser cleanup, storage eviction or private browsing may remove them; memory-only drafts disappear on navigation. Export valuable notes. Maximum 50 drafts and 2,000 characters per note; no automatic expiry or account separation is provided. Do not enter private or sensitive information.
Local feedback controls require JavaScript. No feedback has been submitted.
How feedback should become a change
Capture → interpretation → planned change → acceptance test → resolved version. A reviewer first checks whether the note concerns accuracy, missing scope, usability or a preference. Preserve disagreement and the cited content version. Translate accepted issues into a bounded change and a check that would catch the original problem. Only a verified new version closes the issue; neither a positive rating nor a comment is authority to publish, purchase or change access.