Render a caller-computed runway
well_render_runwayPut a runway YOU computed onto the runway card.
This tool measures nothing. It takes the cash and the burn you measured as input and returns them for rendering. Call it only after you have measured both yourself — never to "get" a cash or a burn.
The division is the server's. Send the cash and the burn with no months and no status, and the server divides them by the rule Well's own chat answers with: it classifies the result, rounds it to a tenth and returns months and status in this tool's result. Write the headline from those two returned values, never from your own division.
The card carries the months, the moment, the burn's own window when you send one (a bare month count when you do not) and a health badge. At its wider sizes it also draws the cash projected toward zero, which the server derives from your cash and burn, after the month-end cash that led to it when you send balance_history. The cash amount and the burn amount are REQUIRED. They reach the card only through the projection it derives; they are not drawn as figures. partial is REQUIRED and is not drawn. The projection is the card's drawing, not figures for your reply: in any reply, however it is framed, state no projected balance for a month and no day or month in which cash reaches zero. The months are the figure. The card names the day the cash runs out on, counted from as_of. Everything else comes back in this tool's text result, which is what you write the prose from, the division included. The card is the measure; the explanation is yours.
REQUIRED:
cash— the dividend, amount and currency. SIGNED: an overdrawn workspace is negative.nullONLY under "insufficient_data", so a half you could not measure is reported rather than invented.avg_burn— the divisor as a POSITIVE magnitude, its currency, and thetrailing_monthsit averagedas_of— the moment the reading is valid forpartial— whether the cash may be a floor (the skills'is_floor), because an account with no readable balance or no rate was left out of it. It never means a cut-short read: a cut-short balances read or sum stops the run before this call.
OPTIONAL, and leave both off: the server derives them from the two figures.
monthsandstatus— sent together or not at all. When you send them, the server checks them against its own division and refuses a pair it does not give.
OPTIONAL, and a runway almost never carries it:
covers_day— the UTC day the figures cover,YYYY-MM-DD. A runway divides the cash on hand NOW by a trailing average, so it covers no day and this field stays off. Send it only for a past-period runway you computed yourself, and stampas_ofas that day's close,<day>T23:59:59Z. Anything earlier is refused: the projection counts forward fromas_of, so two stamps on one day draw two different first months. Sending it on a live reading is an error this tool cannot catch: it costs the reader the resolution into their own zone that a live reading is meant to get.
OPTIONAL, and send it whenever you measured the cash position's history:
balance_history— the month-end cash beforeas_of, oldest first, up to 12 months, incash.currency: exactly thebalance_historyyou sentwell_render_cash_position. Anullamount is a month no stored row covered; send it as a gap, never a zero. The card draws it and nothing else: it changes no figure and is not for your reply.
OPTIONAL, and send it whenever you are sending a burn:
window— the months the burn averaged, inclusive start and EXCLUSIVE end, each on a month start. The card names those months instead of a bare count, so a reader can see which months the figure stands on. Without it the card can only pair the cash moment with the number of months, which reads as a window ending at that moment whatever months you actually averaged. Send NONE whenavg_burnisnull.
The statuses carry two distinctions worth stating, because both are easy to collapse:
Zero months is DATA when the cash is gone. A workspace already underwater has a real runway of zero, status "ok" — not "insufficient_data", which means the inputs could not be measured at all.
Unbounded is not the same as long. "infinite" means the workspace is not burning; "capped" means it burns slowly enough that the figure passes the 36-month window the product reports in.
REFUSED rather than rendered, each because your own figures disagree:
monthswithoutstatus, orstatuswithoutmonthsmonthsthat is notcash ÷ avg_burn— the division is the figure's whole claima cash currency that differs from the burn's; one division needs one currency
a negative
avg_burn; it is a magnitude, so a negative one means a subtotal was re-signed"infinite" with a non-zero burn, or a zero burn reported as anything else
"capped" whose division lands inside the window, or which reports a number other than 36
a division past the window reported as "ok" instead of "capped"
non-positive cash reported as anything but a real zero
"insufficient_data" carrying a months figure, or a null figure under any other status
an unbounded runway reporting anything but the 36-month sentinel
an
as_ofin the futurea
covers_daythat is not the dayas_offalls ona
windowwhose bounds are not each the first of a month, or that spans no montha
windowthat spans a different number of months thanavg_burn.trailing_months— the two state one fact, and a reader cannot tell which is the liea
windowsent with no burn to average — an unmeasured burn averaged no monthsa
windowreaching into a month that has not ended yeta
windowbound naming no calendar month, or an unknown key on the objecta
balance_historythat repeats a month, runs out of order, reaches a month that had not ended atas_of, or comes with no cash
OPTIONAL, and send it whenever you computed a cash-flow bridge over the same cash:
cash_bridge—{ unexplained, closing }, the two terms you sentwell_render_cash_flow_bridge, in this card's currency. The server applies the bridge's own tolerance and returnscash_check."provisional": the bridge does not reconcile, the gap is inunexplained_gap, and the card marks the figure Provisional; say so in prose too: the figure stands on cash with an unexplained gap of that amount."reconciled": say nothing about it. Leavecash_bridgeoff when you computed no bridge: the result iscash_check: "not_checked"and the card marks the figure Not checked.
When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cash | Yes | ||
| as_of | Yes | ||
| months | No | ||
| status | No | ||
| window | No | Inclusive start and EXCLUSIVE end of the months the burn averaged, YYYY-MM-DD. | |
| partial | Yes | ||
| avg_burn | Yes | ||
| covers_day | No | ||
| cash_bridge | No | The cash-flow bridge over the same cash, when you computed one. The server decides whether it reconciles and returns the figure's `cash_check`. Leave it off when you computed no bridge: the figure is then `not_checked`. | |
| workspace_id | No | Target workspace. Omit when the token authorizes one workspace. Required when it authorizes several: this read reports one workspace's own figures and will not choose which. | |
| balance_history | No | Month-end cash before `as_of`, oldest first, in the cash currency: the cash position's own balance history. Drawn only. | |
| conversation_id | No | The conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation. | |
| workspace_scope | No | Restrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cash | Yes | ||
| as_of | Yes | ||
| months | Yes | ||
| status | Yes | ||
| window | No | ||
| partial | Yes | ||
| success | Yes | ||
| avg_burn | Yes | ||
| cash_check | No | ||
| covers_day | No | ||
| projection | No | ||
| computed_by | Yes | ||
| balance_history | No | ||
| conversation_id | No | The conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation. | |
| newly_connected | No | Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later. | |
| unexplained_gap | No | ||
| resolved_workspace | No | The workspace that answered, when the caller named none and the token authorizes several. | |
| conversation_id_note | No | Present only when the server opened a fresh lane, stating that no choice recorded earlier was read. | |
| conversation_id_source | No | Where the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened. |