Grant dossiers — steps

Record status

Record ID

field-guide:grant-dossiers

Parent lifecycle

candidate

Page lane

plan

Lane lifecycle

proposed

Owner

Tilly

Owner role

Not separately recorded

Owner status

Not separately recorded

Qualification result

NOT RUN · held for evidence and human review

Working browser surface: Field guides — documentation — Inspect the guide and persist local checkpoints. This route is local-only; provider, credential, database, customer, publication, deployment, and production effects remain held.

Ordered procedure

1. Create a proposed grant dossier project owned by Tilly and link the supplied source record, related jobs, and source reference agents/index.html#tilly.
2. Capture each available opportunity, requirement, or instruction as a source-labelled record; preserve canonical ID, origin, source locator, source SHA-256 when available, provenance, revision, lifecycle, tags, links, and attachments.
3. Separate observed source text from interpretation by marking assumptions, unknowns, and unresolved questions explicitly; do not convert a named grant or job into a claim of eligibility, availability, or qualification.
4. Build a requirement matrix in Notebook Notes or Projects, with one row per requirement and a direct source locator or an explicit evidence gap.
5. Create evidence records and local file references in Files; inspect type and size, link each file to the relevant requirement, and keep upload or protected storage held where the route indicates it is held.
6. Draft each response section in Paper or Notes, linking every material assertion to evidence and recording limits, assumptions, and revision history.
7. Create a deadline workback in To-dos using dueAt, priority, tags, completion state, and dependencies; use Agenda only to inspect or draft schedule changes, with external writes held.
8. Run an independent review focused on source fidelity, completeness, unsupported claims, conflicts, accessibility of the dossier structure, and whether every deadline has an owner.
9. Reconcile reviewer findings against source and evidence records; preserve disagreements rather than silently choosing a side, and create a held question when the source does not resolve the conflict.
10. Prepare a human-review package in Approvals containing the dossier summary, evidence map, unresolved items, deadline workback, draft status, and explicit authority boundaries.
11. Record the local decision as Needs review, Approved, or Held with a receipt; treat Approved as a local proposal decision only, not as submission or qualification.
12. Inspect Agent Logs and Search to confirm provenance, current work, visibility boundaries, revisions, and linked receipts before marking the guide complete.

Deadline and chronology rules

• Use only dates stated in the supplied source records or explicitly entered by a human; otherwise mark the date unknown.
• Record timezone, cutoff time, and submission method only when supplied; never infer them.
• Create internal workback targets before the source-stated deadline, but label them internal targets rather than external requirements.
• Assign every deadline task an owner, dueAt, priority, and dependency where known.
• If a deadline is missing, ambiguous, passed, or conflicting, branch to Held and create a review question.
• Do not write to an external calendar, provider, grant portal, customer system, or production database; Agenda changes remain drafts.
• Do not mark a dossier submitted, funded, eligible, qualified, published, or connected.

Failure branches during execution

• A grant name or related job may be mistaken for proof that an opportunity is active, applicable, eligible, or qualified.
• Copied requirements can lose source context, version, cutoff time, or amendment history.
• Unsupported narrative claims may enter drafts through paraphrase or stale evidence.
• Conflicting sources may be silently reconciled instead of preserved and escalated.
• An internal workback date may be mistaken for the funder's deadline.
• Local approval may be mistaken for external submission or funding approval.
• Prototype routes may be mistaken for connected production features.
• Sensitive application material may be placed in an unapproved file or visibility surface.
• Accessibility failures may hide status, deadlines, errors, or held states.

Sources and evidence

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

• source_record:field-guide:grant-dossiers
• agents/index.html#tilly
• Observed native contract: Notebook collections and lifecycle
• Observed native contract: Notebook deadlines and workback payload
• Observed native contract: provenance, canonical IDs, source locators, SHA-256, revisions, and attachments
• Observed native contract: PointGuard context surface and specialist-app record ownership
• Observed app routes supplied for Guth Hub, PointGuard, Notebook, Business, and related review surfaces
• Allowed verified-instrument directory supplied; no instrument selected because this dossier procedure has no demonstrated calculation requirement