A guide to the proposal and the record
School grant workflows
Early-access product guide
Make the case.
Keep the record clear.
Turn a proposed project into an explanation a reviewer can follow. Keep the request, the application state and the financial result precise enough to trust.
Explore the built shared school grant records and calculations through an original fictional application. Proposal writing remains human work; funder application remains manual in the current routing branches.
Open the application guideCedar Grove School
Field-learning
kits
Original fictional project- Program reference
- Neighborhood Learning Fund
Fictional fund; no live opportunity - Illustrative request
- $1,200 / 120,000 cents
- Example record state
- Draft
- Submission boundary
- Manual application required
01The project case
Start with work someone can understand and evaluate.
A grant proposal connects a defined need to a practical activity and a reason to fund it. Give the reader enough detail to understand that connection before asking a status label or a polished sentence to carry the argument.
Describe the proposed change.
Our original fictional example follows Cedar Grove School and a proposed set of shared field-learning kits. Teachers want a reusable collection of observation materials that classes can take outside. The illustrative request is twelve hundred dollars from the fictional Neighborhood Learning Fund.
Those names and amounts are teaching examples. This page does not identify an available funding opportunity, report an actual school need or show an application submitted by a customer. The example lets us follow the same proposed work through several different kinds of record.
Begin by describing what the project makes possible. A kit is an item; a class using it for a particular learning activity is the proposed work. The proposal should make that activity understandable without inventing outcomes that have already occurred.
Separate the observation from the plan.
A teacher might supply an inventory, an example lesson and a description of how materials are shared. Those are possible inputs to the human writing process. The writer checks what the evidence actually establishes before describing the problem.
The planned activity belongs in a different sentence. For Cedar Grove, the proposal could describe rotating kits between classes and collecting teacher observations about their use. It should not claim that the rotation has improved learning before the activity has happened.
The shared grant application action records a title, requested amount and optional campaign reference under a program. It does not verify the educational need, write this project explanation or store a complete proposal narrative through that action.
Cedar Grove proposes a shared collection of field-learning kits for teacher-led observation activities. The request covers the materials listed in the project budget. Teachers would plan the activities and document how the shared materials are used; this proposal does not claim results from work that has already taken place.
Make the scope small enough to question.
A review group needs to know what it is being asked to support. Name the proposed materials, the people responsible for the activity and the intended use. If the proposal depends on a separate approval, describe that dependency in the working draft rather than treating it as a completed decision.
Ask what the school can explain from its own records and what needs another conversation. A supplier estimate may support a cost assumption. It does not establish a funder’s eligibility rules. A teacher’s proposed lesson explains an intended use. It does not prove a measured result.
This distinction helps the writer choose useful revisions. Replace a broad claim about transforming learning with a concrete explanation of the activity, the materials it requires and how the school plans to review the work. The result is a clearer human-authored proposal, not a generated assessment.
Keep the project brief with the actual material the team uses. The shared record’s title can help identify the request, but the title is not a substitute for the brief. A successful application-record response does not demonstrate that supporting documents or review notes were saved.
Grantwriter.software is an early-access product guide grounded in shared school grant capabilities. The writing methods here are recommendations for organizing a proposal. They do not establish a deployed dedicated proposal editor, an automatic funder-matching service or an AI proposal writer.
02The program record
Give the opportunity a clear source and a usable reference.
A program record helps a school organize a funding opportunity it has identified. It records supplied information; it does not turn an entered name or link into a verified, current offer from a funder.
Enter the opportunity the team is actually considering.
The shared program-create action accepts a name, source category, optional application link and optional description. The source categories include foundation, government, corporate, DonorsChoose and other. An omitted category uses other; the choice classifies the record rather than proving a partner connection.
The name is required and limited to two hundred characters. The description and application link have their own length limits. A supplied application link must use an accepted HTTP or HTTPS form. The action does not substitute a guessed destination for an absent link.
On success, the service saves the school’s program record, sets its active flag, records the creation in the audit and returns the program. These are concrete recordkeeping results. They are separate from checking whether the funder accepts this school or this proposed activity.
Read the list as the school's entered directory.
The corresponding list action returns stored programs and their routing posture. For our fictional example, the school could enter Neighborhood Learning Fund with a foundation source and a description of the opportunity it intends to investigate.
No real application address is supplied in this guide. In an actual workflow, an operator should use a destination established through the funder’s own material. A missing destination remains missing in the routing result; the service does not discover an alternative portal.
These routes require the applicable school authority. School or district administrators and the specified adviser, co-adviser or editor-in-chief staff roles can qualify. The gate also refuses the relevant minor-held or commerce-restricted participation conditions.
| Supplied field | What the record means |
|---|---|
| Program name | The school has named the opportunity it is organizing |
| Source category | The record uses that source classification |
| Application link | The supplied accepted web address is available as a reference |
| Description | The operator's short description accompanies the program |
| Active flag on creation | The new record is marked active in this workflow |
Keep external requirements with their actual source.
A funding opportunity can have conditions that do not fit into a short program description. The team may need to read application instructions, confirm the intended applicant and check the deadline in the funder’s material. This page does not certify those conditions or provide a live opportunity recommendation.
A useful human program note names the source of each important requirement and when the team reviewed it. That is a working practice, not a dedicated source-verification field created by the program action. Keep the actual reference in the material your team can retrieve.
For Cedar Grove, the writer might discover that the proposed kits fit the project idea but that a particular cost needs clarification. The next useful step is to resolve that point with the appropriate source. Changing the program’s descriptive category does not answer it.
The active flag also has a limited meaning. Program creation sets it to true, but the application-create route does not use that flag as an eligibility approval. Do not read a saved active program as permission from the funder or proof that an application period remains open.
When reviewing the program list, distinguish two questions: whether the school has a usable internal reference and whether it has confirmed the external opportunity. The shared list answers the first through the entered records. The second requires the actual funder information and the school’s review.
03The application record
Create a precise record of the request you mean to make.
An application identity gives the team a stable reference for a particular request. Be equally precise about what the shared action saves and what remains in the proposal material maintained by the writers.
Supply the title, amount and optional campaign relationship.
The shared create action takes the selected program and a request containing a title, requested cents and an optional campaign reference. It obtains the school identity from the program, then checks the operator’s authority for that school. A missing program receives a not-found refusal.
The title must contain between one and two hundred characters. The requested amount is a nonnegative integer number of cents, within the action’s maximum. Omitting it records zero. The optional campaign reference is a separate relationship, not a promise that money has been collected.
For the illustrative Cedar Grove request, Field-learning kits is a possible title and one hundred twenty thousand cents represents twelve hundred dollars. Those values explain the input shape. They are not a quote, an award or a live application shown by this page.
Inspect the returned draft record.
A successful create saves the application under the program and school, with draft status and the computed routing source. Submitted and decided timestamps begin empty. The service records the creation in the audit and returns the application together with its routing posture.
The school-scoped list action retrieves stored applications. That makes the named request more than a calculation over an unsaved example. The particular persistence environment still matters: the code includes an in-memory repository and a database-backed repository implementation.
Source availability does not prove which environment a visitor has, or that this public page provisions one. In a walkthrough, the useful check is whether the authorized environment returns and retrieves the record the operator actually created.
| Record element | Cedar Grove example | Limit of the result |
|---|---|---|
| Program | Neighborhood Learning Fund | An entered fictional program in this guide |
| Title | Field-learning kits | A short request identity, not the narrative |
| Requested amount | 120,000 cents | An amount requested, not approved or received |
| Campaign relationship | Optional supplied campaign reference | A relationship used by the award-booking condition |
| Initial status | Draft | A saved workflow state, not funder receipt |
Keep the full proposal visible in the team's process.
The application-create request does not accept a rich narrative body, supporting attachments, a proposal deadline or a named writing owner. A saved title should therefore point the team toward the actual proposal material through its working process, without claiming those other items were uploaded by this action.
The status-update route has a similarly narrow purpose. It accepts a status transition and updates the associated timestamps. It is not an editor for the request title, amount or narrative. A demonstration of a status change does not establish that the proposal text was revised.
That boundary matters when the project changes. If the human budget review changes the requested amount, first distinguish the revised proposal from the application record already saved. Do not assume that submitting a new status silently updates the amount alongside it.
For an internal review, show the request identity and the actual version of the narrative being discussed. Two applications can have similar titles, and a familiar title can hide an outdated amount. The team needs a clear human association between the saved request and the supporting material.
The creation response also includes routing information because saving a school record and sending a funder application are different actions. The current routing branches require manual application. A new draft, even one with a valid program link, has not been transmitted to the funder by this handler.
04The proposal narrative
Make the explanation follow the work and the budget.
The writer's job is to connect the project's need, activity, resources and intended review. The shared records support an orderly discussion of the request; the argument itself remains a human-authored piece of work.
Give each paragraph a question to answer.
For Cedar Grove, the opening establishes the proposed field-learning activity. A second passage can explain how teachers intend to share the materials. A budget explanation can then connect the requested items to that activity, followed by a description of how the school plans to review their use.
This is an illustrative writing structure, not a funder template generated by the service. The actual application may ask different questions or impose a different format. The writer should work from those instructions rather than assuming that the order in this guide satisfies them.
Use evidence at the point where it supports a claim. An inventory can explain what materials are available. An estimate can support a proposed cost. A teacher’s plan can explain intended use. None of those inputs should be stretched into an outcome it does not establish.
Reconcile the amount with the explanation.
The shared application record stores a requested amount, but it does not itemize the project budget in that create action. The writer and reviewer maintain the detailed explanation in their actual proposal material and compare its total with the record they intend to use.
In the fictional example, the request is twelve hundred dollars. The team might organize a working budget around observation materials, reusable containers and printed activity materials. Those categories are illustrative planning choices, not stored line items or validated supplier prices.
If the narrative promises activities that the budget does not support, resolve the inconsistency before handoff. If the budget includes an item the narrative never explains, ask what role it plays. The service does not automatically reconcile those passages or approve the expense.
| Passage | Input to examine | Useful revision result |
|---|---|---|
| Need | The school's actual supporting information | A claim that stays within the evidence |
| Activity | The proposed work and responsible people | A concrete description of what is planned |
| Budget explanation | The team's actual estimates and itemization | An amount that matches the intended request |
| Review of the work | The school's proposed way to observe use | A plan without invented completed outcomes |
| Funder questions | The actual application instructions | Answers organized for the intended reader |
Review language without surrendering responsibility for the claim.
A sentence can be grammatically correct and still overstate the evidence. Read the draft for that difference. Replace unsupported certainty with a precise statement of what the school knows, what it proposes and what remains an assumption in the working plan.
A separate shared grammar-checking service can return flags for supplied text in its authorized school context. A successful response explicitly leaves changes unapplied. Its roster-name pass follows a successful checker response when enabled; it is not a fallback that operates after an unavailable checker.
When the configured checker is unavailable or its endpoint is invalid, the grammar action returns an unavailable result. That branch does not produce an edited proposal. Even a successful flag list does not verify a budget, substantiate an educational outcome or certify an application’s eligibility.
No proposal-generating action is established by the grant routes described here. A consortium draft can carry a narrative reference, but that is a supplied reference rather than generated narrative text. The generic AI service also has its own configuration-dependent behavior; it is not evidence of a grant-writing generator.
For the final human pass, ask someone unfamiliar with the project to explain the proposed work back to the team. Where their explanation differs, revise the draft or clarify the plan. This produces a more understandable proposal without pretending that a saved amount or a language check approves its substance.
05Application states
Let the status say exactly what the school has recorded.
A controlled transition helps prevent an arbitrary jump through the application record. It does not replace external evidence of submission, a funder's decision or the separate financial record created by the award action.
Follow the six-state application workflow.
The stored application begins in draft. From draft, the status action permits submitted or withdrawn. From submitted, it permits approved, declined or withdrawn. From approved, it permits awarded, declined or withdrawn. Awarded, declined and withdrawn have no outgoing transition in this model.
A repeated status is not treated as a new valid move, and the handler refuses an illegal transition with an unprocessable result. A missing application receives a not-found result. The action also checks the operator’s authority for the school attached to the application.
On success, the service saves the new status and update time and records an audit. Entering submitted sets the submitted timestamp. Entering approved, awarded or declined sets the decided timestamp. These times describe the record action; the route does not obtain a receipt from the funder.
Agree what each recorded step means in practice.
For Cedar Grove, the team can use its own process to determine who confirms the external submission and who records a decision. That assignment belongs to the school’s operating practice. The status request itself does not accept a named reviewer, decision letter or portal receipt.
A writer should therefore distinguish a funder’s actual response from the internal status entered after someone reviews that response. The saved label makes the school’s record visible. It does not independently authenticate the outside event.
The same distinction applies to the word awarded. The ordinary status action permits approved to awarded without creating a disbursement. A record carrying that label alone does not establish a pending disbursement, a ledger donation or a transfer of funds.
| Current state | Permitted next state | Interpretation limit |
|---|---|---|
| Draft | Submitted or withdrawn | Submitted is recorded locally; the handler does not send the proposal |
| Submitted | Approved, declined or withdrawn | A saved decision state is not an imported decision letter |
| Approved | Awarded, declined or withdrawn | The ordinary awarded transition does not create a disbursement |
| Awarded / declined / withdrawn | None | The model does not provide an outgoing status change |
Choose the correct action before changing the record.
The dedicated award action is separate and requires an application that is currently approved. It creates the award’s disbursement record and then advances the application to awarded. It is not an action to perform after first using the ordinary status route to mark the application awarded.
That ordering is a concrete boundary, not a suggestion to work around the transition rules. If the existing record does not fit the action’s required state, the handler refuses it. The team should examine the actual record and its process rather than assuming a label can be freely reversed.
For an internal review, describe the evidence behind a proposed transition before entering it. In our example, the writer might bring the actual submitted material and the relevant external confirmation to the person responsible for the school record. The example itself contains no such real confirmation.
The status route also leaves the title and requested amount outside its update request. If the human proposal changes during review, a status action does not synchronize those changes into the saved application. Keep the distinction visible when comparing the proposal with the record.
Finally, do not mix this six-state stored workflow with the separate five-stage pipeline calculation. Their labels and permitted moves differ. A result from the caller-supplied pipeline does not automatically transition this application or import its state.
06Manual submission
Keep the funder's application step visible and separate.
The current routing logic returns a manual application requirement in both of its key-configuration branches. Saving a program, entering an application or changing a status does not send a proposal to a funder.
Read both routing conditions.
When the relevant partner key is absent, the routing result identifies the source as unconfigured, requires manual application and reports the partner operation as off. It carries the supplied application link if one exists, or a null value if it does not.
When the key is present, the current function returns a manual source and still requires manual application. Its partner-off flag changes, but no submission adapter executes in that branch. The changed flag must not be presented as proof that a partner application can be sent.
This means the operator’s practical next step remains manual in either case. The page does not offer an activation promise, a connected submission button or a claim that adding credentials turns this route into a funder integration.
Prepare the material for the actual destination.
For the fictional Neighborhood Learning Fund example, the writer first needs the funder’s real instructions in an actual use case. This guide deliberately supplies no application address because the fund itself is invented. The visual dossier is a teaching example, not a portal.
In a real workflow, the responsible person follows the established external process and confirms what it requests. The proposal may need to be entered into an outside form or provided through another accepted channel. The shared school record does not perform that work.
A useful human handoff identifies the exact proposal material, the person handling the external step and the evidence the school expects them to bring back. Those are operating agreements; the application-create and status requests do not save that entire handoff.
| Condition | Returned posture | What the operator can conclude |
|---|---|---|
| Relevant key absent | Unconfigured source; manual application required; partner operation off | No partner submission is performed |
| Relevant key present | Manual source; manual application still required | The changed flag does not supply a submission adapter |
| Application link supplied | The supplied accepted address is returned | A reference is available, not proof of delivery |
| Application link absent | No application address is returned | The service does not invent a destination |
Bring external evidence back into the team's discussion.
After an actual manual submission, the team needs the evidence appropriate to that outside process. A receipt, confirmation or copy of the submitted material can help explain what happened. This is a human recordkeeping recommendation, not a claim that the shared route downloads or stores those artifacts.
The submitted status can reflect the school’s recorded understanding after its review. The handler itself only updates its own record and timestamp. Do not label that timestamp as the funder’s receipt time unless the actual outside evidence separately establishes it.
This distinction remains useful when an application fails outside the platform. A browser error, an incomplete outside form or a returned message needs attention in the external process. Creating another local draft does not resolve that failure or prove a later attempt succeeded.
For Cedar Grove, the internal conversation can use a simple question: which exact version of the proposal does the outside confirmation refer to? The answer comes from the actual material and confirmation the team retains. There is no automatic proposal-version reconciliation claimed by these grant routes.
An early-access inquiry can discuss how the school organizes that handoff and demonstrate the shared record actions available in its authorized environment. It does not submit the request, connect a funder account or guarantee that an application meets external requirements.
07The supplied pipeline
Compare opportunities without pretending the calculation saved them.
A separate grant-seeking workflow calculates a view from opportunities supplied by the caller. It can order deadlines, total amounts and evaluate a stage change, while leaving opportunity storage outside those calculation actions.
Bring the opportunity data and the review time.
The pipeline action accepts a list of opportunities and an explicit time for the review. Each opportunity supplies a grant reference, award amount in cents, deadline time and stage. The route accepts up to one thousand entries and checks the shape of those inputs.
Its response includes the opportunities ordered by deadline, stage totals, an overdue view and a computed audit summary. Equal deadlines use the grant reference to make the ordering stable. These results describe the data supplied in that request, not an automatically discovered funding market.
The five pipeline stages are identified, drafting, submitted, awarded and declined. Potential amounts come from identified, drafting and submitted entries. Awarded and declined amounts are reported separately. All of those amounts are caller-supplied values, not independently verified receipts.
Use overdue to answer its actual question.
The overdue calculation considers identified and drafting entries whose deadlines are earlier than the supplied review time. A deadline equal to that time is not counted as past. Submitted, awarded and declined entries do not enter this overdue group.
That is narrower than a universal deadline monitor. The action does not read an automatic calendar, send reminders or confirm that an external application was submitted before a funder closed its portal. The caller chooses the time and supplies the opportunity information.
For Cedar Grove, a team could compare several internally prepared opportunity rows during a meeting. The resulting order can guide a human discussion about what needs attention. It does not create those opportunities as saved application records.
| Question | Stored application workflow | Caller-supplied pipeline |
|---|---|---|
| Where does the input come from? | An application saved under a program | Opportunity rows supplied in the request |
| Which state model applies? | Draft, submitted, approved, awarded, declined, withdrawn | Identified, drafting, submitted, awarded, declined |
| What does a transition change? | The stored application's permitted status fields | The returned opportunity value; a transition audit is recorded |
| Does it submit to a funder? | No submission in the described action | No submission in the described action |
Keep the returned transition with the caller's own data process.
The separate pipeline transition action permits identified to drafting, drafting to submitted and submitted to awarded or declined. It refuses unsupported stage values and illegal jumps. A successful call returns a new opportunity value and records a transition audit.
That saved audit does not mean the opportunity itself was saved. The handler does not persist the returned opportunity as a school application or update the six-state record described earlier. The caller must keep its own data process clear when using the returned value.
Suppose the team supplies an identified opportunity and asks to jump directly to awarded. The transition is refused rather than filling in the missing steps. That refusal protects the declared pipeline order; it does not assess whether the school has an external award letter.
Similarly, a large potential total can help compare the supplied pipeline but cannot be described as secured funding. Several opportunities may never become applications. The team should use the total to understand its entered possibilities, with the actual stage definitions visible.
A useful meeting ends with a human decision about the next task, its owner and its source material. The pipeline calculation can inform that decision. It does not assign the task, synchronize a calendar or create the saved application that a later recordkeeping step requires.
08Allocation checks
Test the amount and purpose before interpreting a financial result.
The grant allocation action evaluates supplied values against a supplied award and purpose restriction. Its response distinguishes an accepted calculation from a disbursement, and the route passes no payment rail to the disbursement helper.
Supply the grant and the proposed allocation.
The caller provides the grant reference, awarded cents, allocated cents and an optional restricted-purpose reference. The proposed allocation supplies an integer amount and an optional purpose reference. These are inputs to a calculation, not values automatically loaded from the saved application record.
The gate first checks that the grant and amount are valid, including a positive allocation amount. It then checks the purpose restriction and whether the amount exceeds the remaining award. A rejected calculation returns the original grant value with the refusal verdict.
If the grant has no restricted-purpose reference, the purpose check accepts any supplied purpose. If it has a restriction, the allocation’s purpose reference must match it exactly. This is a reference comparison, not an interpretation of the narrative or a determination that an expense meets a funder’s rules.
Read the accepted result as an updated value.
When the check accepts the allocation, the helper returns a new grant value with the allocated amount increased. The route also returns the verdict and a computed audit summary. It does not save the new allocation into a grant account through this action.
For an illustrative calculation, suppose the supplied award is one hundred twenty thousand cents and thirty thousand cents are already allocated. The remaining amount is ninety thousand cents. A proposed twenty-thousand-cent allocation that satisfies the purpose condition can produce an updated allocated total of fifty thousand cents.
That arithmetic says nothing about a bank balance. The award and earlier allocation were supplied by the caller. The result does not verify them against a funder, a campaign ledger or a financial institution.
| Supplied request | Condition | Result to expect |
|---|---|---|
| 20,000 cents against 90,000 remaining | Valid grant and matching required purpose | Accepted calculation; updated grant value returned |
| 100,000 cents against 90,000 remaining | Amount exceeds the remainder | Allocation refused; original grant value returned |
| A different purpose reference | The grant requires an exact purpose reference | Allocation refused for purpose mismatch |
| Zero or a negative amount | The amount is not positive | Allocation refused as an invalid amount |
Keep the no-rail result alongside the verdict.
The route calls the disbursement helper with a null rail dependency. When the allocation passes its checks, this route therefore returns an honest-off, no-rail disbursement result and no disbursement reference. An accepted allocation is not a payment initiated by the action.
When the allocation is denied, the disbursement result reports that it is blocked by the denied allocation. Those are different branches: one accepts the proposed calculation while withholding a rail operation, and the other rejects the allocation itself.
The underlying helper supports a supplied rail dependency in other usage. That does not change the behavior of this specific route, which supplies null. The page describes this reachable route’s result without making a universal claim that every financial service always refuses every operation.
For Cedar Grove, the calculation can support a human review of whether a proposed use fits the entered remainder and purpose reference. The team still needs the actual award conditions and the appropriate financial process. The calculator does not interpret a grant agreement or authorize a purchase.
Keep the returned value and the real record separate in a handoff. If someone quotes the new allocated total, ask whether it came from this supplied calculation or from an independently saved financial record. The route does not silently turn one into the other.
09Award and ledger records
Record the award without confusing a ledger entry with a payment.
The dedicated award action has a real saved result even when ledger booking is off. Its state requirements, pending branch and conditional donation linkage should remain visible whenever the team describes what the action accomplished.
Begin with an approved application.
The award action requires an existing application in approved status and an authorized operator for that application’s school. The amount must be a positive integer number of cents within the route’s limit. An application in any other state is refused.
The handler also looks for an existing disbursement for that application and refuses a detected duplicate. This is a distinct award-record action. The ordinary status transition to awarded does not create this financial record, and performing that transition first leaves the application outside this action’s approved-state requirement.
On the successful award path, the service creates a disbursement record, advances the application to awarded, updates its decision time and records the award audit. The returned response includes the disbursement and whether it has a linked ledger donation.
Preserve the pending branch's actual saved effects.
Ledger booking requires both the configured money-booking switch, STRIPE_LIVE, and a campaign reference on the application. If the switch is off or the campaign reference is absent, the award still creates a pending disbursement with no donation link.
The application still advances to awarded on that successful path. The response reports that it is not booked on the ledger. It would therefore be inaccurate to describe this condition as a refusal that saves nothing, or to describe the pending record as funded.
The name of the configuration switch does not mean this award handler invokes Stripe. The traced route and its grant repository methods create records; they do not call a card processor, a funder application system or a bank-transfer service.
| Condition | Disbursement result | Meaning of the response |
|---|---|---|
| Application is not approved | Action refused | No successful award result from this request |
| Existing disbursement is detected | Duplicate award refused | A second successful award is not returned |
| Booking switch off, or no campaign reference | Pending record; no donation link | Application advances; booked-on-ledger is false |
| Booking switch on and campaign reference present | Repository creates linked campaign donation and funded record | Ledger linkage exists; this is not proof of a bank transfer |
Read the repository result before naming the outcome.
In the conditional booking branch, the repository creates a campaign donation for the award amount and links the disbursement to it. The database-backed implementation performs that donation and disbursement creation together in its transaction. The in-memory implementation stores the corresponding values in memory.
The funded status in this operation describes the linked ledger result. The returned booked-on-ledger value depends on the actual donation reference in the disbursement, rather than merely echoing the intention to book. Neither fact establishes that this action collected money from the funder.
For the fictional twelve-hundred-dollar request, an actual approved application could receive an award amount supplied by an authorized operator. That amount may differ from the request. The example does not claim that any fictional amount was approved, booked or received.
A human financial handoff should identify which evidence establishes the outside award and which record the action created. The disbursement record, the application status, the campaign donation and an external payment confirmation answer different questions. A single word such as funded should not collapse them.
This is why the page keeps the booking condition beside the capability. The shared action can produce a pending award record or a linked ledger result under its stated conditions. It does not offer automatic funder payout, card collection or bank settlement.
10A consortium draft
Describe the shared application before claiming a shared submission.
The consortium action builds a draft from supplied school references, member details and an optional narrative reference. It validates that structure and returns it to the caller; it does not save or submit a joint application.
Supply distinct members and a lead who belongs to the group.
A consortium draft requires a consortium reference, grant reference and lead-school reference. It needs at least two member schools. Each member supplies a nonempty school reference and a list of eligibility tags, with an optional display label.
The builder refuses duplicate member references, an empty required reference, a malformed eligibility tag or a lead school that is absent from the members. The requested amount defaults to zero and must be a safe nonnegative integer number of cents.
These conditions establish a coherent supplied draft structure. They do not verify that the schools agreed to apply together, that the caller has authority to speak for every member or that a funder accepts the proposed consortium.
Read the copied draft and its apply result.
On success, the builder returns a draft with the supplied references, copied member fields, requested amount and optional narrative reference. The status is draft. The route also returns an apply result that says the application was not submitted and remains a draft.
The route persists none of this draft. A successful response gives the caller a value to retain through its own process. It does not create a stored consortium application, distribute a document to the member schools or send a proposal to a funder.
This action has a separate finance-workspace gate and requires the school-finance module. It should not be presented as an operation available to every proposal writer simply because they can read this page or use a different school grant route.
| Input | Example or question | Boundary |
|---|---|---|
| Member schools | Cedar Grove and fictional Harbor School | Two distinct supplied school references are required |
| Lead school | One of the listed members | An unlisted lead is refused |
| Eligibility tags | The supplied tags for each member | The draft action copies and validates tags; it does not verify qualification |
| Narrative reference | An optional reference to separately maintained material | The reference is not the proposal body |
| Requested amount | The group's supplied integer-cent request | The builder does not negotiate or approve the budget |
Keep the human agreement outside the structural result.
In the illustrative extension, Cedar Grove and Harbor could discuss sharing an approach to field-learning materials. Before describing that as a joint proposal, the people involved need to agree on the work, responsibilities and actual application requirements. The returned draft does not conduct that agreement.
A narrative reference can help the caller associate the draft with material held elsewhere. It is an opaque supplied value. The builder does not fetch that material, assess its completeness or generate a joint narrative from the member list.
The member tags also have a narrow role in this route. Although the shared library contains separate eligibility functions, the draft endpoint does not invoke an eligibility matcher. Its successful structural validation is not a finding that the group meets a program’s conditions.
A separate finance-workspace catalog action filters its existing program data using a supplied date string and catalog conditions, including rolling or qualifying deadline entries and exclusion of fiscal-sponsor-only entries. That filtered result is not a live confirmation of a particular consortium’s eligibility or a current funder offer.
Read refusal payloads as part of the result, too. A structurally rejected draft returns a reason with an unsuccessful result; the route can return that payload without using an error HTTP status for every builder refusal. The caller must inspect whether the draft was actually built.
11Review and handoff
Pass on the evidence behind the record, not just its label.
A useful grant handoff tells the next person what was written, what was saved, what was calculated and what happened outside the system. Those distinctions make the work easier to continue without turning an internal result into an unsupported external claim.
Name the material the reviewer is meant to read.
For Cedar Grove, the review might include the project explanation, the actual working budget and the school’s application reference. The writer should identify the version of the proposal material being discussed, especially if the requested amount or activity changed during drafting.
This is a human handoff method. The described grant actions do not provide a specialist proposal-version editor, an attachment bundle or an automatic comparison between the current narrative and the saved requested amount. The team needs to use material it can actually retrieve.
Give the reviewer a concrete question. They might check whether the activity explains each budget category, whether the request matches the entered amount or whether a proposed status change has the appropriate external support. A vague request to approve everything hides those separate decisions.
Distinguish the origin of each result.
A retrieved program or application is a stored record in the applicable repository environment. A pipeline total is a calculation over supplied rows. A successful consortium draft is a returned value that the route does not persist. A grammar flag is a review suggestion that is not automatically applied.
The award record adds another distinction. It can be pending with no ledger donation, or conditionally linked to a donation under the booking requirements. An external funder decision or actual payment confirmation must be understood from its own evidence.
These categories help the next person ask the right follow-up. They can inspect a saved application, check the inputs behind a calculation or locate the separately retained external material, instead of assuming every result is stored and verified in the same way.
| Item being discussed | Question for the person handing it over |
|---|---|
| Proposal narrative | Which actual material should the reviewer read, and what changed? |
| Saved application | Which record, amount and state are being referenced? |
| Pipeline total | Which supplied rows and review time produced it? |
| Consortium draft | Where is the returned draft retained, and who has agreed to the plan? |
| Award result | Is the record pending or linked to a ledger donation? |
| External event | What actual evidence establishes submission, decision or payment? |
Use the audit for what the action records.
The shared program, application, status and award actions record audits of their respective changes. The separate pipeline transition also records an audit even though it does not save the opportunity value. An audit therefore needs to be read in the context of the action it describes.
It is not a universal attachment store or a substitute for the proposal body. The presence of a transition audit does not prove that the funder received a file. The presence of an award audit does not prove that a bank transferred the award amount.
The team can make its working handoff clear without promising an automatic export. A person can identify the relevant records and provide the actual proposal material through the process they already use. These grant routes do not establish a generated funder-ready document bundle or a delivery service for reviewers.
If someone cannot access the material, resolve the real access issue before depending on their review. An inquiry link on this public guide does not grant school authority or the finance-module entitlement. The grants being discussed here are financial grants, distinct from any script-participation permission records elsewhere in the platform.
Close the human review with an explicit understanding of the next step. That could be revising a paragraph, checking an amount, completing the manual funder process or asking an authorized operator to inspect a saved record. The route result should support that decision without claiming to have performed the human task.
12Access and working boundaries
Judge the workflow by the exact result it returns.
An early-access conversation is most useful when it starts with a real task and a clear boundary. Ask to see the authorized shared action, its actual input and its returned or saved result, then keep the remaining human work visible.
Bring a representative request to the discussion.
A school team can begin with a short project description, an entered program reference and the request amount it wants to organize. For a calculation, it can bring the opportunity rows or allocation values it intends to compare. For a consortium, it can bring the proposed members and the question the draft needs to answer.
Use appropriate illustrative material for an initial walkthrough. The examples on this page are fictional and contain no real applicants, commitments or awards. They explain the shape of the work without pretending to show a customer's live funding activity.
The public page is an early-access product guide. Its contact link opens an inquiry. It does not create an account, provision a dedicated Grantwriter workspace, grant a school role, enable a finance module or activate a funder submission service.
Match the capability to its operating condition.
The stored grant routes require the applicable school authority and enforce their stated input and lifecycle rules. The consortium calculation uses a separate finance-workspace gate. A successful action in one area does not establish permission for every other action.
Repository-backed records also depend on the actual environment. The traced implementation includes in-memory storage and database-backed methods. A source file or public guide cannot establish which storage is provisioned for a particular visitor or promise that a demonstration record survives an environment reset.
During a walkthrough, inspect the actual record returned and retrieved by that environment. For computations that do not persist their inputs, inspect the returned value and identify who retains it. Those are different demonstrations with different outcomes.
| Topic | Present behavior described by this guide |
|---|---|
| Proposal writing | Human-authored method; no grant proposal generator is established |
| Grammar review | Flags after checker success; unavailable checker returns an unavailable result |
| Funder submission | Manual application is required in both current key branches |
| Allocation | Calculated result; this route supplies no disbursement rail |
| Award booking | Pending record unless the switch and campaign conditions permit ledger linkage |
| Consortium application | Returned draft; no persistence or submission in the described action |
Keep AI and money claims attached to their named operations.
The generic AI service has a specific unconfigured-provider refusal and also supports configured or injected implementations. That source does not justify saying that all AI always refuses. It also does not establish a grant-specific narrative generator, application scorer or evidence-checking assistant.
The grammar service is similarly precise: its unavailable-checker branch returns an unavailable result, while successful checks return flags with automatic application disabled. The page does not promise a rewritten proposal, a corrected saved application or a fallback check after that failure.
Money behavior is described through the actual grant action. The allocation route has no rail. The award action can save a pending record while ledger booking is off, and it can create a linked ledger donation when its booking conditions are satisfied. Neither description becomes a bank-payout promise.
For manual submission, the configured-key branch still returns a manual requirement. For consortium work, the apply result remains unsubmitted and draft. Those are present-tense outcomes, not hints that a credential, inquiry or later activation unlocks a different workflow described by this page.
The practical value is a more exact conversation about the school’s work. A writer can improve the proposal, an authorized operator can inspect the shared record, and a reviewer can distinguish a calculation from an outside event. The early-access discussion should preserve those distinctions from the first example to the final handoff.
Start with a real question
Bring the project.
Examine the workflow.
Discuss how your school develops a proposal, records its application and hands the work to the next person. Ask to see the exact shared action and the conditions that shape its result.
Discuss early accessAn inquiry does not provision a workspace, submit an application or activate a payment or AI service.