[{"slug":"ZV-2026-0229","server_name":"app.datavrn.com","severity":"breaking","title":"app.datavrn.com: Tool assert_previous_year_no_activity was removed.","summary":"[breaking] Tool assert_previous_year_no_activity was removed. [breaking] Tool confirm_complete_chart was removed. [breaking] Tool get_comparative_source_state was removed. [breaking] Tool list_chart_rebaselines was removed. [breaking] Tool list_replacements was removed. [breaking] Tool preview_chart_rebaseline was removed. [breaking] Tool preview_replacement_restore was removed. [breaking] Tool restore_replacement was removed. [safe] Description of confirm_capture_review changed (13% word delta). [risky] Description of create_upload_link changed (61% word delta). [safe] Description of declare_capture_na changed (19% word delta). [risky] Description of get_consolidated_statements changed (38% word delta). [risky] Description of get_pending_work changed (43% word delta). [safe] Description of get_statement_figures changed (18% word delta). [risky] Description of ingest_upload changed (67% word delta). [breaking] Field removal_count was removed from ingest_upload input; consumers still sending it may be rejected or silently ignored. [breaking] Field removal_token was removed from ingest_upload input; consumers still sending it may be rejected or silently ignored. [breaking] Field acknowledged_state_digest was removed from ingest_upload input; consumers still sending it may be rejected or silently ignored. [safe] Description of revoke_capture_declaration changed (19% word delta). [risky] Description of save_disclosures changed (89% word delta). [breaking] Field removal_count was removed from save_disclosures input; consumers still sending it may be rejected or silently ignored. [breaking] Field removal_token was removed from save_disclosures input; consumers still sending it may be rejected or silently ignored. [risky] Description of upload_trial_balance changed (35% word delta).","changes":[{"kind":"tool_removed","tool":"assert_previous_year_no_activity","detail":"Tool `assert_previous_year_no_activity` was removed.","severity":"breaking"},{"kind":"tool_removed","tool":"confirm_complete_chart","detail":"Tool `confirm_complete_chart` was removed.","severity":"breaking"},{"kind":"tool_removed","tool":"get_comparative_source_state","detail":"Tool `get_comparative_source_state` was removed.","severity":"breaking"},{"kind":"tool_removed","tool":"list_chart_rebaselines","detail":"Tool `list_chart_rebaselines` was removed.","severity":"breaking"},{"kind":"tool_removed","tool":"list_replacements","detail":"Tool `list_replacements` was removed.","severity":"breaking"},{"kind":"tool_removed","tool":"preview_chart_rebaseline","detail":"Tool `preview_chart_rebaseline` was removed.","severity":"breaking"},{"kind":"tool_removed","tool":"preview_replacement_restore","detail":"Tool `preview_replacement_restore` was removed.","severity":"breaking"},{"kind":"tool_removed","tool":"restore_replacement","detail":"Tool `restore_replacement` was removed.","severity":"breaking"},{"kind":"description_changed","tool":"confirm_capture_review","after":"Record your user’s confirmation that they have REVIEWED a whole section and it is complete — the entire previous-year comparative column, or the entire disclosure set. A review confirmation is your user’s professional assertion, recorded as authorised by them. Before calling this, show them what you are confirming — the whole comparative, or the whole disclosure set — and get their explicit go-ahead. Never confirm a review that has not happened. Saving figures or text does NOT complete these two sections and never has; only this confirmation does. The confirmation is pinned to the exact set that was reviewed, so ANY later save to that section withdraws it — if a confirmation appears not to stick, the next step is to re-review and confirm again, never to retry. Only two sections take a review confirmation: the previous-year comparative and the disclosure set. Every other section is answered by saving its rows, or by declare_capture_na. Datavrn notifies the member you name that this was recorded in their name. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.","before":"Record your user’s confirmation that they have REVIEWED a whole section and it is complete — the entire previous-year comparative column, or the entire disclosure set. A review confirmation is your user’s professional assertion, recorded as authorised by them. Before calling this, show them what you are confirming — the whole comparative, or the whole disclosure set — and get their explicit go-ahead. Never confirm a review that has not happened. Saving figures or text does NOT complete these two sections and never has; only this confirmation does. The confirmation is pinned to the exact set that was reviewed, so ANY later save to that section withdraws it — if a confirmation appears not to stick, the next step is to re-review and confirm again, never to retry. Confirming again after such a change supersedes the earlier confirmation: it is marked withdrawn (it stays on the record) and the response names what was withdrawn. Re-confirming also invalidates any finalise approval you already hold. Only two sections take a review confirmation: the previous-year comparative and the disclosure set. Every other section is answered by saving its rows, or by declare_capture_na. Datavrn notifies the member you name that this was recorded in their name. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.","detail":"Description of `confirm_capture_review` changed (13% word delta).","severity":"safe","descriptionDelta":0.13043478260869568},{"kind":"description_changed","tool":"create_upload_link","after":"Mint a single-use, login-free upload link so YOUR USER can give Datavrn a file directly from their browser — the file never passes through you, so it cannot truncate or corrupt. Use this whenever a human has the file (a trial balance export, etc.). The link stages the file for ONE entity and expires in about 15 minutes; nothing is ingested until the column mapping is confirmed.","before":"Mint a single-use, login-free upload link so a file reaches Datavrn WITHOUT passing through your context, where it cannot truncate or corrupt. Use this whenever a human has the file (a trial balance export, etc.) — and also whenever YOU hold the file and it is larger than about 10 KB. This is the RELIABLE path at that size: inlined base64 mutates often enough that the damage arrives as a plausible-looking trial balance rather than an obvious error, while the link delivers the bytes byte-perfect. Two ways to deliver the file: a HUMAN opens upload_url in their browser and chooses the file; a PROGRAMMATIC caller that already holds the file on disk POSTs it to the SEPARATE upload_post_url as a multipart form with a single `file` field (upload_url is the human page and will not accept a POST). The POST reply carries received_file_hash — compare it to your local sha256 before confirming the mapping. The link stages the file for ONE entity and expires in about 15 minutes; nothing is ingested until the column mapping is confirmed.","detail":"Description of `create_upload_link` changed (61% word delta).","severity":"risky","descriptionDelta":0.6147540983606558},{"kind":"description_changed","tool":"declare_capture_na","after":"Record that a capture section had NOTHING to report this period, DOES NOT APPLY to this entity, or that this is the entity’s FIRST YEAR (previous-year figures only). These are three different statements and are not interchangeable: \"nothing this period\" means the section applies but had no activity; \"does not apply\" means it never applies to this entity at all. This is your user’s professional assertion, recorded as authorised by them — ask which one is true, and never guess. NOT every reason is available for every section — call get_schedule3_workspace and read allowed_reason_codes on the section before you ask your user, so you never put a choice to them that Datavrn will refuse. The restrictions: Settings takes NO answer here at all (it is only answered by saving the settings); share capital and partner capital take only \"nothing this period\", because those sections are shown only for statement formats they apply to, so \"does not apply\" can never be true; and \"first year\" belongs only to previous-year figures. To record a REVIEW being complete (previous-year figures, disclosures) use confirm_capture_review instead; this tool cannot make that assertion. A section can only hold one active answer: to change one, revoke it with revoke_capture_declaration and record a new one — an answer is never edited in place. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.","before":"Record that a capture section had NOTHING to report this period, DOES NOT APPLY to this entity, or that this is the entity’s FIRST YEAR (previous-year figures only). These are three different statements and are not interchangeable: \"nothing this period\" means the section applies but had no activity; \"does not apply\" means it never applies to this entity at all. This is your user’s professional assertion, recorded as authorised by them — ask which one is true, and never guess. NOT every reason is available for every section — call get_schedule3_workspace and read allowed_reason_codes on the section before you ask your user, so you never put a choice to them that Datavrn will refuse. The restrictions: Settings takes NO answer here at all (it is only answered by saving the settings); share capital and partner capital take only \"nothing this period\", because those sections are shown only for statement formats they apply to, so \"does not apply\" can never be true; and \"first year\" belongs only to previous-year figures. To record a REVIEW being complete (previous-year figures, disclosures) use confirm_capture_review instead; this tool cannot make that assertion. A section can only hold one active answer. If the section’s current answer is still standing, this call refuses — revoke it with revoke_capture_declaration first. If the current answer was already WITHDRAWN by later changes (Datavrn shows the section as unanswered), this call supersedes it: the old answer is marked withdrawn and stays on the record, and the response names what was withdrawn. An answer is never edited in place. Superseding or changing an answer invalidates any finalise approval you already hold — the next finalise_statement will ask you to review the current state again. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.","detail":"Description of `declare_capture_na` changed (19% word delta).","severity":"safe","descriptionDelta":0.1920529801324503},{"kind":"description_changed","tool":"get_consolidated_statements","after":"CONSOLIDATED data class. Read one sealed group profit-and-loss, balance-sheet, or cash-flow face for an exact periodicity and period. The response exposes presentation currency and exactly one decimal-string amount per line: section-natural for P&L/BS, signed cash movement for CFS. Amounts are persisted on the sealed run; P&L/BS labels are current display metadata and the signed page_token is source-fingerprinted across the complete safe face, so a changed value or label requires restarting at page 1. A stale sealed run is disclosed on every page and is never called current. Member names, components, eliminations, journal references and lineage are not returned. QUALIFICATIONS. A response may carry `owned_share_capital_caveat` (at seal, share capital owned by the group could not be eliminated, so those amounts remained inside consolidated share capital as the engine computed it; the DISPLAYED line may differ in either direction where a manual journal also moved it, so never characterise the direction from this field alone) and always carries `domestic_cash_flow_caveat`. These qualify specific statement lines. When a caveat is present, any figure it qualifies MUST be presented together with its qualification — never the number alone. `owned_share_capital_caveat` is null when the run was read and carries no such qualification, and `{status: \"unavailable\"}` when the run’s qualification record could not be read at all, which is not the same as clean: say so rather than presenting the figures as final. Consolidated cash-flow is available only for an all-domestic group in v1. If any member uses a foreign currency, Datavrn does not present a consolidated cash-flow statement.","before":"CONSOLIDATED data class. Read one sealed group profit-and-loss, balance-sheet, or cash-flow face for an exact periodicity and period. The response exposes presentation currency and exactly one decimal-string amount per line: section-natural for P&L/BS, signed cash movement for CFS. Amounts are persisted on the sealed run; P&L/BS labels are current display metadata and the signed page_token is source-fingerprinted across the complete safe face, so a changed value or label requires restarting at page 1. A stale sealed run is disclosed on every page and is never called current. Member names, components, eliminations, journal references and lineage are not returned. QUALIFICATIONS. A response may carry `owned_share_capital_caveat` (at seal, share capital owned by the group could not be eliminated, so those amounts remained inside consolidated share capital as the engine computed it; the DISPLAYED line may differ in either direction where a manual journal also moved it, so never characterise the direction from this field alone) and always carries `domestic_cash_flow_caveat`. These qualify specific statement lines. When a caveat is present, any figure it qualifies MUST be presented together with its qualification — never the number alone. `owned_share_capital_caveat` is null when the run was read and carries no such qualification, and `{status: \"unavailable\"}` when the run’s qualification record could not be read at all, which is not the same as clean: say so rather than presenting the figures as final. WITHHELD CASH FLOW. `cash_flow_status` may say the cash flow was not presented — for a group with a foreign member, or for a window with no opening balance sheet to measure from. An empty `cash_flow` then means the statement was WITHHELD, never that the group had no cash movements: say so. For the missing-opening-basis case `cash_flow_refusal` carries the cause, the message and `remedies`, each tagged with the channel that can perform it — `agent_or_app` you can do here, `app_only` needs a person in the Datavrn app. Never present an app_only remedy as something you will do. `cash_flow_opening_basis` states what a PRESENTED statement measured from; \"not_recorded\" means the run was sealed before Datavrn recorded that, so its basis is unknown — do not assume a prior period. ROW ROLES. Every statement row carries `row_role`: \"line\" participates in its section total, \"total\" restates it (Profit after tax), \"attribution\" splits a total (the amounts attributable to the owners and to the minority interest). To total a section, sum ONLY rows whose row_role is \"line\" — including a total or attribution row would double-count the group’s profit. Present the attribution rows as the split of profit after tax, never as additional income. Consolidated cash-flow is available only for an all-domestic group in v1. If any member uses a foreign currency, Datavrn does not present a consolidated cash-flow statement. Where it is presented, it is prepared by the indirect method from balance-sheet movements rather than from cash records, and classified into operating, investing and financing activities using each entity’s reporting-line mapping. Interest paid and taxes paid are not disclosed separately, so they remain inside the operating movement; a movement whose reporting line carries no cash classification is shown under “Unclassified movements — review” rather than assigned to an activity. Datavrn does not present other comprehensive income or total comprehensive income in the consolidated output.","detail":"Description of `get_consolidated_statements` changed (38% word delta).","severity":"risky","descriptionDelta":0.3831417624521073},{"kind":"description_changed","tool":"get_pending_work","after":"Answer \"what's left to do?\" across every entity you can see — one row per entity, with what is blocking its Schedule III statement: whether the trial balance is in, how many accounts are still ungrouped, the latest generated version, and whether it has been finalised. Pass period_label to pick a period, or omit to default to the period most of your entities have a trial balance for (not necessarily the newest — one entity uploading a future period early will not flip the board). Rows include deep links that open the Datavrn web app (a login is needed there).","before":"Answer \"what's left to do?\" across every entity you can see — one row per entity, with what is blocking its Schedule III statement: whether the trial balance is in, how many accounts are still ungrouped, the latest generated version, and whether it has been finalised. Pass period_label to pick a period, or omit to default to the period most of your entities have a trial balance for (not necessarily the newest — one entity uploading a future period early will not flip the board). Rows include deep links that open the Datavrn web app (a login is needed there). It also answers a second question nothing else here does: restorable_replacements lists automatic connector syncs that REPLACED an entity's data and can still be undone, soonest-closing first, each with the date its 30-day undo window shuts — after that the replaced data cannot be put back, and no message ever announces that clock running out, so raise these with your user rather than waiting to be asked (use list_replacements and preview_replacement_restore on the ids given; restorable_replacements_omitted says how many more were not listed).","detail":"Description of `get_pending_work` changed (43% word delta).","severity":"risky","descriptionDelta":0.4328358208955224},{"kind":"description_changed","tool":"get_statement_figures","after":"Read a generated Schedule III statement's figures: the balance-sheet and profit-and-loss faces, current-year and previous-year balance-sheet tie verdicts separately (a null verdict means UNKNOWN, never a pass: either no comparative was captured, or the version predates per-column balance recording), the unclassified count, and the notes listed by number. Also returns bounded exception counts by rule/severity and the frozen control changes versus the immediately previous recorded version; it never recomputes either from live books. Figures come from a generated version (the latest unless you pass a specific version) and match the workbook exactly. If the version was generated before figure reads existed it returns available:false with reason \"figures_not_available\" and only the legacy flat tie verdict; tell the user to generate the statement again, read the latest version, then retry. For a note's line-by-line breakdown, use its note_index entry with get_statement_notes. Amounts are decimal strings in rupees. Figures are Datavrn's deterministic engine output; interpretation is your assistant's.","before":"Read a generated Schedule III statement's figures: the balance-sheet and profit-and-loss faces, current-year and previous-year balance-sheet tie verdicts separately (a null verdict means UNKNOWN, never a pass: either no comparative was captured, or the version predates per-column balance recording), the unclassified count, and the notes listed by number. Also returns bounded exception counts by rule/severity and the frozen control changes versus the immediately previous recorded version; it never recomputes either from live books. Figures come from a generated version (the latest unless you pass a specific version) and match the workbook exactly. If the version was generated before figure reads existed it returns available:false with reason \"figures_not_available\" and only the legacy flat tie verdict; tell the user to generate the statement again, read the latest version, then retry. For a note's line-by-line breakdown, use its note_index entry with get_statement_notes. Amounts are decimal strings in rupees. ONE EXCEPTION: the profit-and-loss face ends with the statutory earnings-per-share rows, marked kind:\"eps\". Their figures are ₹ PER SHARE, not rupees of profit — report them as EPS and never add them into a face total. They are null until the weighted average share counts are saved in statement settings. Figures are Datavrn's deterministic engine output; interpretation is your assistant's.","detail":"Description of `get_statement_figures` changed (18% word delta).","severity":"safe","descriptionDelta":0.1811594202898551},{"kind":"description_changed","tool":"ingest_upload","after":"Commit a validated upload into the entity’s books. If validation produced WARNINGS, this refuses until acknowledge_warnings=true — present every warning to your user and obtain their explicit go-ahead first; never acknowledge warnings the user has not seen. Returns the ingestion outcome including any notices.","before":"Commit a validated upload into the entity’s books. This is a TWO-CALL approval: if the upload has any warnings, or would permanently delete existing trial-balance rows for a period it covers, the first call writes NOTHING and refuses with every warning, the exact record counts, and a short-lived removal_token. Show your user every warning and both counts, get their explicit go-ahead, then resend the SAME call adding removal_token and removal_count exactly as returned. acknowledge_warnings is IGNORED on this connection — the token is the only acknowledgment, so sending it changes nothing. A clean, additive ingest needs no token and succeeds on the first call. Returns the ingestion outcome including any notices.","detail":"Description of `ingest_upload` changed (67% word delta).","severity":"risky","descriptionDelta":0.6666666666666667},{"kind":"input_property_removed","path":"inputSchema.properties.removal_count","tool":"ingest_upload","before":{"type":"integer","minimum":0,"description":"The exact removal count returned by the removal preview."},"detail":"Field `removal_count` was removed from `ingest_upload` input; consumers still sending it may be rejected or silently ignored.","severity":"breaking"},{"kind":"input_property_removed","path":"inputSchema.properties.removal_token","tool":"ingest_upload","before":{"type":"string","maxLength":200,"minLength":20,"description":"Only include the short-lived token returned by the removal preview for this exact upload."},"detail":"Field `removal_token` was removed from `ingest_upload` input; consumers still sending it may be rejected or silently ignored.","severity":"breaking"},{"kind":"input_property_removed","path":"inputSchema.properties.acknowledged_state_digest","tool":"ingest_upload","before":{"type":"string","pattern":"^[0-9a-f]{64}$","description":"Browser/REST only, and IGNORED on the agent connection exactly as acknowledge_warnings is: the destroy_state_digest returned by the confirm-mapping step, resent unchanged so the server can prove the acknowledgment was given against the data that is still there. On this connection the removal_token already pins the rows at risk, so sending this changes nothing."},"detail":"Field `acknowledged_state_digest` was removed from `ingest_upload` input; consumers still sending it may be rejected or silently ignored.","severity":"breaking"},{"kind":"description_changed","tool":"revoke_capture_declaration","after":"Withdraw a recorded capture answer or review confirmation. Statement readiness will show that section as unanswered again. A version you have already generated is NOT affected — if you do not want that version finalised, answer the section again and generate a fresh version. Nothing is deleted: the withdrawn answer stays on the record with who recorded it and who withdrew it, and recording a new answer afterwards creates a new entry rather than overwriting the old one. One thing on this connection is affected immediately: if you already called get_finalise_readiness and hold an approval for that version, withdrawing an answer invalidates it, and the next finalise_statement will refuse and ask you to review the current state again.","before":"Withdraw a recorded capture answer or review confirmation. What happens next depends on what answers the section: withdrawing a “nothing to record”/“does not apply” answer or a review confirmation makes Statement readiness show the section as UNANSWERED again; withdrawing a leftover earlier note from a section that is answered by its saved rows removes the record and the section STAYS answered. A version you have already generated is NOT affected — if you do not want that version finalised, answer the section again and generate a fresh version. Nothing is deleted: the withdrawn answer stays on the record with who recorded it and who withdrew it, and recording a new answer afterwards creates a new entry rather than overwriting the old one. One thing on this connection is affected immediately: if you already called get_finalise_readiness and hold an approval for that version, withdrawing an answer invalidates it, and the next finalise_statement will refuse and ask you to review the current state again.","detail":"Description of `revoke_capture_declaration` changed (19% word delta).","severity":"safe","descriptionDelta":0.1910112359550562},{"kind":"description_changed","tool":"save_disclosures","after":"Save the notes/disclosures text sections the user provides for the statement. Some of these sections IDENTIFY PEOPLE BY NAME — shareholders, promoters and related parties — so send only what your user has given you, exactly as they gave it.","before":"Save the notes/disclosures sections the user provides for the statement. Some of these sections IDENTIFY PEOPLE BY NAME — shareholders, promoters and related parties — so send only what your user has given you, exactly as they gave it. SECTIONS YOU DO NOT SEND ARE LEFT ALONE. Send only the sections you are changing; every other section keeps exactly what is saved. Within a section you DO send, the rows you send REPLACE every row saved for that section — there is no row-level merge, so always send that section complete. To CLEAR a section, send it explicitly with its own empty value: [] for corporateInfo, contingent, shareholders5pct, promoters, relatedParties and msmeAmounts; {} for ratioReasons; null for auditorPayments, csr, proposedDividend and the DSCR amounts. The three ageing sections take [] or null. Clearing removes saved content, so Datavrn saves nothing and returns an approval request naming the sections and how many rows each holds. Show your user exactly what would be cleared; only if they mean to, resend the identical call adding removal_token and removal_count from that response. The approval is single-use and lapses after five minutes — if it lapses, call again for a fresh one. Saving here re-opens the disclosure review — after your last change, confirm the disclosure review again with confirm_capture_review before generating. ratioReasons is keyed by the ratio IDENTIFIER, never its display label: current_ratio | debt_equity | dscr | roe | inv_turnover | tr_turnover | tp_turnover | ncap_turnover | net_profit | roce | roi. msmeAmounts is a POSITIONAL list of exactly five items, in this statutory order: 1. Principal amount and interest due thereon remaining unpaid at the year end (shown separately) | 2. Interest paid under section 16 of the MSMED Act, with the payment made beyond the appointed day | 3. Interest due and payable for delay in payment (paid beyond the appointed day), excluding MSMED-specified interest | 4. Interest accrued and remaining unpaid at the year end | 5. Further interest remaining due and payable in succeeding years (section 23 disallowance) — send all five, using {\"currentPaise\": null, \"previousPaise\": null} for an item with nothing to report. Dashes and capitalisation are forgiven when matching a row label (a hyphen for an en dash is fine) and Datavrn stores the prescribed spelling; the wording itself is not forgiven. PRESCRIBED ROWS BY STATEMENT FORMAT — a row label or sub-head that is not one of these is refused rather than stored (a value already saved on this statement stays editable): Division I (Non-Ind AS) (\"schedule_iii_div1\") — trAgeing: 6 buckets in this order [Not due | < 6 months | 6 months – 1 year | 1 – 2 years | 2 – 3 years | > 3 years], rows [Undisputed — considered good | Undisputed — considered doubtful | Disputed — considered good | Disputed — considered doubtful | Unbilled dues]; tpAgeing: 5 buckets in this order [Not due | < 1 year | 1 – 2 years | 2 – 3 years | > 3 years], rows [MSME | Others | Disputed dues — MSME | Disputed dues — Others | Unbilled dues]; cwipAgeing: 4 buckets in this order [< 1 year | 1 – 2 years | 2 – 3 years | > 3 years], rows [Projects in progress | Projects temporarily suspended]. contingent.subhead ∈ contingent liabilities [Claims against the company not acknowledged as debt | Guarantees | Other money for which the company is contingently liable] or commitments [Estimated amount of contracts remaining to be executed on capital account (net of advances) | Uncalled liability on shares and other investments partly paid | Other commitments] — set group to \"contingent\" or \"commitment\" to match, or the row is totalled under contingent liabilities (or leave subhead out and the row prints as its own line under its group). Division II (Ind AS) (\"schedule_iii_div2\") — trAgeing: 6 buckets in this order [Not due | < 6 months | 6 months – 1 year | 1 – 2 years | 2 – 3 years | > 3 years], rows [Undisputed — considered good | Undisputed — significant increase in credit risk | Undisputed — credit impaired | Disputed — considered good | Disputed — significant increase in credit risk | Disputed — credit impaired | Unbilled dues]; tpAgeing: 5 buckets in this order [Not due | < 1 year | 1 – 2 years | 2 – 3 years | > 3 years], rows [MSME | Others | Disputed dues — MSME | Disputed dues — Others | Unbilled dues]; cwipAgeing: 4 buckets in this order [< 1 year | 1 – 2 years | 2 – 3 years | > 3 years], rows [Projects in progress | Projects temporarily suspended]. contingent.subhead ∈ contingent liabilities [Claims against the company not acknowledged as debt | Guarantees excluding financial guarantees | Other money for which the company is contingently liable] or commitments [Estimated amount of contracts remaining to be executed on capital account (net of advances) | Uncalled liability on shares and other investments partly paid | Other commitments] — set group to \"contingent\" or \"commitment\" to match, or the row is totalled under contingent liabilities (or leave subhead out and the row prints as its own line under its group). Non-Corporate Entity (\"icai_nce\") and LLP (\"icai_llp\") — no ageing tables at all — trAgeing/tpAgeing/cwipAgeing are refused. contingent.subhead ∈ contingent liabilities [Claims against the entity not acknowledged as debt | Guarantees given on behalf of others | Other money for which the entity is contingently liable] or commitments [Estimated amount of contracts remaining to be executed on capital account (net of advances) | Uncalled liability on investments partly paid | Other commitments] — set group to \"contingent\" or \"commitment\" to match, or the row is totalled under contingent liabilities (or leave subhead out and the row prints as its own line under its group).","detail":"Description of `save_disclosures` changed (89% word delta).","severity":"risky","descriptionDelta":0.8855218855218855},{"kind":"input_property_removed","path":"inputSchema.properties.removal_count","tool":"save_disclosures","before":{"type":"integer","maximum":2000,"minimum":1},"detail":"Field `removal_count` was removed from `save_disclosures` input; consumers still sending it may be rejected or silently ignored.","severity":"breaking"},{"kind":"input_property_removed","path":"inputSchema.properties.removal_token","tool":"save_disclosures","before":{"type":"string","maxLength":200,"minLength":20},"detail":"Field `removal_token` was removed from `save_disclosures` input; consumers still sending it may be rejected or silently ignored.","severity":"breaking"},{"kind":"description_changed","tool":"upload_trial_balance","after":"Stage a Trial Balance spreadsheet (xlsx or csv, max 4 MB) for an entity by INLINING its bytes as base64. This path is ONLY for programmatic callers (a script, Claude Code, an automation) that already have the raw file on disk. If a HUMAN has the file — e.g. they attached it to this chat — do NOT use this tool and do NOT base64-encode the file: call create_upload_link instead and give them the link to upload it in their browser. File size does not change this: even a small attached file goes through create_upload_link — inlining a human-supplied file is unreliable and its bytes routinely truncate. Returns the upload session with detected columns and mapping SUGGESTIONS — nothing is ingested yet. Next: review the suggested column mapping with your user, then call confirm_column_mapping.","before":"Stage a Trial Balance spreadsheet (xlsx or csv, max 4 MB) for an entity by INLINING its bytes as base64. This path is ONLY for programmatic callers (a script, Claude Code, an automation) that already have the raw file on disk. If a HUMAN has the file — e.g. they attached it to this chat — do NOT use this tool and do NOT base64-encode the file: call create_upload_link instead and give them the link to upload it in their browser. File size does not change this: even a small attached file goes through create_upload_link — inlining a human-supplied file is unreliable and its bytes routinely truncate. Even for a file you hold on disk, prefer create_upload_link once the file is larger than about 10 KB: base64 through a model context mutates a token often enough that the damage lands as a PLAUSIBLE trial balance, not as an obvious error. VERIFY THE HASH BEFORE YOU CONFIRM ANYTHING: this tool returns received_file_hash, the sha256 of the bytes the server actually received. Compute the sha256 of the file on your disk and compare the two. If they differ, the bytes changed in transit — do NOT call confirm_column_mapping on this session; re-send the file with create_upload_link instead. A mismatched file can still parse cleanly and still show sensible columns, so the hash is the only reliable check. Returns the upload session with detected columns and mapping SUGGESTIONS — nothing is ingested yet. Next: verify received_file_hash, then review the suggested column mapping with your user, then call confirm_column_mapping.","detail":"Description of `upload_trial_balance` changed (35% word delta).","severity":"risky","descriptionDelta":0.34507042253521125}],"published_at":"2026-08-20T14:05:43.545Z"}]