Audit Plugin Special Terms and Assurance Limitation Acknowledgment

Version: 1.1 Effective date: 12 August 2026

1. Agreement, parties, and precedence

1.1. These Audit Plugin Special Terms and Assurance Limitation Acknowledgment (the "Special Terms") are a binding agreement between Silkway Tech LLC, a Wyoming limited liability company with a mailing address at 5830 E 2nd St, Ste 7000 #30294, Casper, WY 82609, USA (the "Vendor"), and the company or other legal entity acquiring, trialing, installing, configuring, or using the Railbase Audit plugin (the "Customer"). The individual accepting these Special Terms represents that they have authority to bind the Customer.

1.2. These Special Terms supplement the Terms of Service, Railbase Core EULA, Plugin Subscription & Marketplace Agreement, and, where applicable, the Data Processing Addendum (together, the "General Terms"). They apply specifically to the Railbase Audit plugin (the "Plugin").

1.3. If these Special Terms conflict with the General Terms on a matter specific to the Plugin's analytical output, assurance limitations, completeness, materiality, findings, verification, or professional-judgment obligations, these Special Terms control. Capitalized terms not defined here have the meanings in the General Terms.

1.4. Where the Customer also uses the Railbase Connector plugin to supply ledger data to the Plugin, the Connector Plugin Special Terms apply to that data movement in addition to these Special Terms.

1.5. The Plugin exchanges data with other Railbase plugins installed in the same deployment through the platform event bus, both consuming their signals and publishing its own gaps, findings, recommendations, and entity flags (Section 16.6). These Special Terms continue to govern the status and permitted use of the Plugin's own output wherever that output travels, including after another plugin consumes it or attaches it to that plugin's records; another plugin's terms do not upgrade the status of the Plugin's output. Conversely, a signal the Plugin receives from a neighbouring plugin remains governed by that plugin's own agreement and is not adopted, reviewed, or warranted by the Vendor merely because the Plugin displays or acts on it.

2. Definitions

2.1. "Plugin Output" means any indication, score, ratio, metric, reconciliation result, difference, exception, gap, coverage figure, traceability statement, journal-entry test result, finding, recommendation, verification result, register, export, working file, dashboard, or other result produced or displayed by the Plugin.

2.2. "Analytical Indication" means Plugin Output in its only intended status: a machine-computed observation about ledger data that requires independent human examination of the underlying records before it may support any conclusion.

2.3. "Ledger Data" means the postings, journal lines, chart of accounts, balances, dimensions, counterparties, documents, periods, and related accounting records supplied to the Plugin by the Customer, whether through the Railbase Connector plugin, a file import, or another documented path. Where a specific procedure requires records beyond the general ledger — for example the payroll-versus-headcount reconciliation, or a re-performance procedure over stock counts, production, or receivables — Ledger Data also includes the personnel, employment, payroll, and count records the Customer supplies for that procedure, and every obligation in these Special Terms that attaches to Ledger Data attaches to them.

2.4. "Scope Disclosure" means the Plugin's own statement of what it did and did not see for a given result, including period coverage, role-mapping coverage, unmapped accounts, unavailable axes, refused layers, and named missing inputs.

2.5. "Refusal" means the Plugin's documented behavior of declining to produce a number, layer, reconciliation, or metric, and naming the reason or the missing input, instead of returning an approximated, defaulted, or zero value.

2.6. "Materiality Parameters" means the overall materiality, performance materiality, tolerances, thresholds, calendars, noise ceilings, and other configurable values the Customer declares and by which the Plugin distinguishes a recorded difference from a raised finding.

2.7. "Finding" means a record created in the Plugin stating an assertion, a condition observed, and the criteria the condition is said to depart from. "Recommendation" means a remediation record linked to a Finding. "Verification" means a re-run of the recorded procedure used to test whether the condition persists.

2.8. "Human Review" means examination and evaluation of Plugin Output, and of the underlying accounting records, by a competent person with authority to reach an independent conclusion, to reject Plugin Output, and to escalate.

2.9. "Material or Adverse Decision" means any decision that can materially affect a person or organization, including an accounting adjustment, restatement, provision, write-off, disclosure, filing, certification, management representation, payment hold, contract action, counterparty termination, allegation of error or misconduct, investigation, disciplinary or employment action, referral to a regulator or law-enforcement body, or any decision presented to an auditor, lender, investor, board, audit committee, or regulator.

2.10. "Affected Person" means an individual or organization whose data is processed by the Plugin or who may be affected by a Material or Adverse Decision informed by Plugin Output, including employees, officers, customers, vendors, counterparties, and their representatives.

2.11. "Source Systems" means the accounting, ERP, and other systems from which Ledger Data originates, including 1C, QuickBooks, NetSuite, SAP, and any database or file export.

2.12. "Serious Incident" means a Plugin event reasonably likely to cause significant financial, legal, regulatory, privacy, employment, reputational, or operational harm, including materially incorrect reconciliation or metric output relied upon for a Material or Adverse Decision, a tenant-boundary failure, unintended disclosure of ledger or personal data, or a failure of a Refusal to trigger where the Documentation states it should.

2.13. "Documentation" means the then-current technical, configuration, mapping, methodology, limitation, and release documentation supplied by the Vendor for the Plugin.

3. Nature, intended purpose, and status of Plugin Output

3.1. The Plugin is a self-hosted analytical tool for examining accounting data. It is installed as a protected data-resident plugin bundle and executes only inside the Customer's Railbase core; it has no standalone executable, service, database, port, subprocess, or supported run path outside Railbase.

3.2. The intended purpose of the Plugin is to help the Customer's own competent personnel organize, quantify, and prioritize their examination of Ledger Data — by testing whether the books reconcile, by measuring differences across business areas, by running configurable journal-entry tests, by computing declared financial-statement metrics, and by recording findings and their verification.

3.3. Plugin Output is an Analytical Indication and nothing more. It is not an audit opinion, review conclusion, attestation, assurance report, certification, compilation, agreed-upon-procedures report, expert report, forensic determination, valuation, credit assessment, going-concern conclusion, tax position, legal advice, accounting advice, or investment advice, and must not be labeled, exported, presented, or relied upon as any of those.

3.4. A Plugin run is not an audit. Operating the Plugin does not constitute, satisfy, evidence, or substitute for an audit, review, internal-audit engagement, or other engagement performed under ISA, ISSAI, GAAS, PCAOB standards, the IIA International Professional Practices Framework, or any other professional or statutory standard, and does not discharge any statutory audit, internal-control, certification, or reporting obligation of the Customer or its officers.

3.5. The Vendor is not the Customer's auditor, internal auditor, accountant, or professional adviser. Acquiring or using the Plugin creates no engagement, no auditor-client or practitioner-client relationship, no professional duty of care in respect of the Customer's financial statements or controls, and no independence, competence, licensing, or professional-standards representation about the Customer's personnel.

3.6. A computed result, a matched difference of zero, a completed run, a green indicator, an absent exception, or a fully covered chart of accounts does not establish that the Ledger Data is complete, accurate, authorized, properly cut off, correctly classified, free of error, or free of fraud.

3.7. Conversely, an exception, gap, difference, adverse ratio, journal-entry test hit, or Finding does not establish that an error, irregularity, misstatement, control failure, breach of policy or law, dishonesty, or fraud has occurred. Each is a candidate for examination, and many are explained entirely by ordinary business activity, timing, configuration, mapping, or data scope.

3.8. The technical ability to compute, display, rank, export, or publish a result is not a representation that the Customer's intended use of that result is appropriate, proportionate, sufficient, or lawful.

4. Completeness, scope, sampling, and the meaning of a Refusal

4.1. Completeness is the Customer's responsibility. The Plugin analyzes only the Ledger Data actually supplied to it. It does not and cannot determine that the supplied data is the complete population, that every company, period, ledger, journal, subsidiary, adjustment, or off-system record is present, or that the extraction itself was faithful.

4.2. The Plugin provides a Scope Disclosure describing what it observed. A Scope Disclosure is a description, not a certification. The Customer must independently reconcile the supplied population to authoritative source records before relying on any result, and must repeat that reconciliation after any change to the source, extraction, mapping, period, or entity structure.

4.3. Selection of the population, the periods, the entities, the sampling method, sample sizes, and the sufficiency and appropriateness of evidence are professional judgments reserved to the Customer. The Plugin does not make, validate, or warrant those judgments, and no Plugin feature constitutes a statistically valid sampling plan unless the Documentation expressly states otherwise for that feature.

4.4. A data set may reconcile perfectly against itself and still be incomplete. Where the Plugin can compare an assembled figure against an independently printed or exported figure it will report a completeness difference; where it cannot, no such comparison exists and the absence of a reported difference means only that none was measurable.

4.5. A Refusal is Plugin Output. Where the Plugin declines to compute a layer, reconciliation, or metric and names the reason or missing input, the Customer must treat that as the result. Substituting an estimate, a default, a prior-period value, a zero, or an externally computed figure in place of a Refusal, and then presenting the composite as Plugin Output, is the Customer's own work and risk.

4.6. Absence and zero are different. The Customer must not read a measured zero as an unreported value, or an unreported value as zero. Where the Documentation states that the Plugin distinguishes them, the Customer must preserve that distinction in every extract, report, or presentation derived from Plugin Output.

5. Read-only access to Source Systems

5.1. The Plugin is designed to be read-only with respect to Source Systems. It does not write, post, reverse, adjust, correct, delete, close, reopen, or approve anything in 1C, QuickBooks, NetSuite, SAP, or any other accounting system, and it must not be represented as a remediation, correction, posting, or close tool.

5.2. The Plugin's read-only design does not by itself make the Customer's access read-only. The Customer remains responsible for provisioning dedicated least-privilege, read-only source accounts and credentials, and for ensuring that source-side permissions independently prevent writes and access beyond the approved scope.

5.3. Where Ledger Data reaches the Plugin through the Railbase Connector plugin, the Customer's obligations regarding source authority, credentials, mapping validation, downstream delivery, and reconciliation are governed by the Connector Plugin Special Terms and are not reduced by these Special Terms.

5.4. The Plugin creates, stores, and retains its own analytical records — including aggregates, exceptions, findings, recommendations, verification results, and evidence snapshots — inside the Customer's Railbase deployment. The Customer is responsible for the access control, retention, correction, export, and lawful deletion of those records.

6. Chart of accounts, roles, and inference

6.1. The Plugin's analysis is organized around account roles assigned by chart-of-accounts packs. A pack proposes; the Customer confirms. The Customer is responsible for reviewing, correcting, and confirming role assignments before operational reliance, and after any change to the chart of accounts, source system, localization, or entity structure.

6.2. Where a role is inferred from an account name rather than read from a structural attribute such as a code or type, the Plugin records that provenance. The Customer must not treat an inferred role as an authoritative classification, and must not present inferred and system-derived classifications interchangeably in any record, export, or report intended as evidence.

6.3. An account left deliberately unmapped is disclosed rather than forced into a role. Unmapped accounts reduce coverage and may suppress or distort every result computed above them. The Customer must review named unmapped accounts before relying on any area, reconciliation, or metric affected by them.

6.4. An incorrect role assignment can move amounts between business areas while leaving every downstream number arithmetically plausible. The Customer must validate role assignments against its own chart of accounts and accounting policies, and must not rely on the internal consistency of Plugin Output as evidence that roles are correct.

7. Reconciliations, materiality, thresholds, and grain

7.1. Materiality Parameters are declared by the Customer and are professional judgments. The Vendor does not set, review, approve, or warrant them, and default or example values in the Documentation or product are illustrations, not recommendations.

7.2. The Customer understands that Materiality Parameters directly determine which differences are recorded, which are surfaced, and which become Findings. A difference below the declared performance materiality may be recorded and visible without being raised, and a difference below the declared tolerance may not be recorded at all.

7.3. The Plugin may restrict changes to Materiality Parameters after they are declared and may require an authority-gated action to override them. That restriction is a workflow control, not a warranty that the parameters are appropriate or that they were declared before the analysis began.

7.4. A reconciliation exists only where both sides can be measured at the same declared grain. Where they cannot, the Plugin refuses and names the unavailable axis; the Customer must not substitute a coarser comparison and present it as the refused one.

7.5. A reconciliation difference is a difference between two measured populations under the Customer's configuration. It is not, without examination, evidence of an error, an omitted transaction, a control failure, or misconduct, and it may be created or removed entirely by cut-off, timing, mapping, scope, or configuration.

7.6. Results computed on periods that do not balance, or on insufficient role coverage, are gated by the Plugin. The Customer must not bypass, disable, or work around such a gate and then rely on the result.

8. Journal-entry tests

8.1. Journal-entry tests are configurable heuristics operating on attributes such as document type, posting date, calendar, amount pattern, and value. Their results depend entirely on the Customer's calendars, holidays, thresholds, rounding grains, and source-system conventions.

8.2. A test hit is a candidate, not a finding. On many real ledgers a test will fire on a large share of ordinary postings. The Customer must evaluate the hit rate against the population before treating results as exceptions, and must tune configuration rather than treat routine activity as irregular.

8.3. The Plugin may label a test as noise rather than signal where its hit rate exceeds a configured ceiling. That label is an analytical aid; it neither excuses examination nor establishes that the underlying postings are proper.

8.4. Journal-entry tests are not a fraud-detection system and are not designed, validated, or represented as capable of detecting fraud, collusion, management override, or concealment. Absence of hits is not evidence of the absence of irregularity.

8.5. Records the Plugin cannot interpret — for example an unparseable date — are excluded from the affected test rather than reported as a hit. Excluded records are not tested records, and the Customer must review exclusions.

9. Financial-statement metrics and composite models

9.1. Metrics, ratios, and composite scores computed by the Plugin are arithmetic derived from the supplied Ledger Data under the Customer's configuration. They are not opinions, ratings, forecasts, valuations, credit assessments, going-concern conclusions, or investment advice, and must not be provided to a lender, investor, insurer, rating agency, counterparty, or regulator as though they were.

9.2. Published composite models — including those commonly associated with distress prediction, financial-strength scoring, and earnings-manipulation screening — are third-party academic constructs developed on specific populations, periods, jurisdictions, and accounting frameworks. They are screening heuristics with documented false-positive and false-negative behavior. A score does not identify an entity as distressed, sound, manipulative, or fraudulent, and must never be used to allege misconduct by any person or organization.

9.3. Where the Plugin substitutes an input that a published formula does not use, it discloses the substitution together with the number. The Customer must carry that disclosure wherever the number is carried and must not present a substituted composite as the published model's result.

9.4. Where a required input is unavailable, the Plugin refuses and names the missing input rather than estimating. The Customer must not supply an estimate in its place and present the result as Plugin Output.

9.5. Comparisons against history, budget, benchmarks, or peers depend on data the Customer supplies or selects. Their comparability, basis of preparation, and relevance are the Customer's responsibility.

10. Findings, recommendations, verification, and closure

10.1. A Finding requires an assertion, an observed condition, and the criteria it is said to depart from. Recording criteria does not establish that the criteria apply, are current, are correctly stated, or are the appropriate standard; that determination is the Customer's.

10.2. Verification consists of re-running the recorded procedure. A clean re-run establishes only that the recorded procedure no longer produces the recorded condition on the data then available. It does not establish that a control now operates effectively, that a root cause was addressed, that a remediation was implemented, or that the matter is resolved.

10.3. The Plugin may enforce workflow separations, such as preventing the party responsible for a remediation from certifying it. Those separations are configuration-dependent controls within the Plugin. They do not create, evidence, or substitute for organizational independence, segregation of duties, or the Customer's own governance.

10.4. The Plugin does not translate policy, regulatory, or contractual text into tests. Any mapping between a written requirement and a Plugin procedure is an explicit Customer decision, and the Customer is responsible for its correctness and for the risk that a procedure appears to enforce a requirement it does not in fact test.

10.5. Findings, recommendations, verification results, exports, and working files are the Customer's own work product. The Vendor does not review, approve, sign, endorse, or take responsibility for them, and they must not be presented as reviewed or approved by the Vendor.

11. Human Review and decision-making

11.1. The Customer is solely responsible for its use of the Plugin and for every conclusion, adjustment, disclosure, filing, representation, allegation, investigation, personnel action, counterparty action, report, and other decision made in reliance on Plugin Output. Using the Plugin does not transfer the Customer's duties, judgment, accountability, or legal responsibility to the Vendor.

11.2. Before relying on Plugin Output for a Material or Adverse Decision, the Customer must conduct and document Human Review by personnel with appropriate accounting or audit competence for the subject matter and the potential impact of the decision.

11.3. Human Review must, as applicable, inspect the underlying accounting records and supporting documents; confirm the population, period, and entity scope; check role mappings, Materiality Parameters, calendars, thresholds, and configuration; consider ordinary business explanations and contradictory evidence; obtain explanations from the persons responsible for the transactions; and follow the Customer's own investigation, escalation, due-process, and approval procedures.

11.4. Viewing Plugin Output, accepting a default, ranking by score, exporting a register, clicking an approval control, or confirming that required fields are populated does not constitute Human Review.

11.5. The reviewer must document the evidence considered, unresolved limitations and Refusals, any disagreement with Plugin Output, any override or escalation, the reviewer's conclusion, and the independent reasons for the Customer's final decision.

11.6. A decision made without the Human Review required by these Special Terms is the Customer's own choice and risk. To the maximum extent permitted by law, the Customer may not attribute that decision or its consequences to the Vendor merely because Plugin Output was considered.

11.7. Plugin Output does not change status by crossing to another plugin. Where the Plugin attaches an indication to another plugin's record — for example, where it corroborates a compliance alert by attaching the ledger exposure behind it, or automatically emits a signal such as a payment made inside a counterparty's ban window — that output remains an Analytical Indication. An automatically emitted cross-plugin signal is produced without the assertion, observed condition, and criteria of a Finding and without Human Review; it is not a Finding, a verified fact, an allegation, or corroboration by the Vendor, and its appearance in another plugin's case, dashboard, or score does not satisfy the Human Review, corroboration, and Affected-Person obligations of these Special Terms, which apply in full before any Material or Adverse Decision regardless of which plugin surfaces the output.

12. Allegations, personnel action, and Affected Persons

12.1. Plugin Output frequently concerns identifiable individuals — the person who entered a posting, approved a document, is named as a counterparty, or is an employee identified by a personnel reconciliation such as payroll-versus-headcount. It attributes activity recorded in the Ledger Data; it does not attribute intent, knowledge, responsibility, or wrongdoing.

12.2. The Customer must not use Plugin Output as the sole or primary basis for an accusation, disciplinary measure, dismissal, demotion, suspension, denial of payment, contract termination, blacklisting, referral to a regulator or law-enforcement body, or any public or internal statement adverse to a person or organization.

12.3. Before any such action the Customer must corroborate independently, apply the presumption that ordinary explanations exist, provide the process required by applicable employment, labor, works-council, contractual, data-protection, and due-process rules, and give the Affected Person a genuine opportunity to explain unless mandatory law provides otherwise.

12.4. The Customer is responsible for lawful bases, notices, transparency, works-council or employee-representative consultation, access, correction, objection, restriction, and retention obligations relating to personal data processed by or derived from the Plugin, and for any monitoring, profiling, or automated-decision restrictions that apply to its use.

12.5. The Customer must restrict access to Plugin Output to personnel with a need to know, and must apply appropriate confidentiality, privilege, whistleblower-protection, and insider-information controls to analytical results concerning financial reporting.

13. Pre-deployment assessment, commissioning, and testing

13.1. Before operational use the Customer must document the intended purpose and scope, the entities and periods, the data path and its owner, the personnel commissioning the use, the personnel performing Human Review, the escalation and stop-use path, the Materiality Parameters and who approved them, and the applicable legal, contractual, and professional requirements.

13.2. The Customer must perform controlled acceptance testing on representative and appropriately protected data, covering at least: reconciliation of the supplied population to authoritative records, role coverage and unmapped accounts, Refusal behavior, materiality and tolerance effects, journal-entry test hit rates, metric availability and substitutions, permission boundaries and cross-area visibility, and export contents.

13.3. The Customer must record known limitations, accepted coverage, residual risks, and an authorized go/no-go decision before relying on Plugin Output for any Material or Adverse Decision, and must repeat proportionate testing after a material change to the Plugin, the Railbase core, the Connector, a Source System, the chart of accounts, the entity structure, the Materiality Parameters, or the applicable requirements.

13.4. The Customer must promptly suspend reliance on an affected capability where monitoring indicates materially unreliable output, an incorrect Refusal, a permission-boundary failure, or an unexplained change in results, until the cause is understood and appropriately remediated.

14. Records, evidence, and retention

14.1. The Plugin records analytical results, findings, verification outcomes, and evidence snapshots inside the Customer's Railbase deployment. Unless the Documentation expressly states otherwise for a specific feature, those records are ordinary application data, not tamper-evident, sealed, notarized, timestamped, or legally privileged records.

14.2. The Plugin is not a records-management, archival, legal-hold, backup, or disaster-recovery system. The Customer is responsible for retention schedules, legal holds, backups, restoration, export, integrity, chain of custody, and lawful deletion of Plugin records and of anything derived from them.

14.3. Where Plugin Output may be produced to an auditor, regulator, court, or counterparty, the Customer is responsible for determining what constitutes adequate evidence in that context and for preserving the underlying source records, configuration, and version information necessary to reproduce the result.

14.4. A later Plugin version, configuration change, data reload, or correction may cause a previously produced result to be unreproducible. The Customer must capture and retain what it needs at the time it relies on a result.

15. Third-party systems, connectors, and dependencies

15.1. References to 1C, QuickBooks, NetSuite, SAP, Oracle, or another third-party product describe integration patterns only and do not imply certification, sponsorship, endorsement, partnership, or a guarantee by that provider. References to accounting, auditing, or professional standards describe subject matter only and do not imply approval, accreditation, or endorsement by any standard-setter or professional body.

15.2. The Plugin depends on data supplied through the Railbase Connector plugin or another documented path. Its output is limited by, and inherits every limitation of, that data path. Optional neighbouring modules may extend Plugin capabilities; where such a module is absent, unlicensed, or misconfigured, the related capability is unavailable rather than approximated.

15.3. The Vendor does not control and is not responsible for a third party's availability, security, data quality, schema, API, localization, versioning, licensing, deprecation, or decision to restrict integration access. A third-party or Customer change may alter field meaning, mappings, coverage, or results; the Customer must revalidate affected output before reliance.

15.4. The Vendor may update, restrict, or discontinue an adapter, pack, metric, procedure, or supported configuration where a third-party change, legal restriction, security risk, or unreasonable maintenance burden makes continued support impracticable, subject to the General Terms.

16. Self-hosting, confidentiality, Vendor access, and support

16.1. The Plugin runs in the Customer's self-hosted Railbase deployment and stores its business data in the Customer's Vault. The Plugin does not automatically transmit Ledger Data, Plugin Output, findings, or working files to the Vendor.

16.2. Railbase separately exchanges limited account, licensing, activation, version, tenant-registration, purchase, and security-related operational metadata with railbase.app as described in the General Terms and Privacy Policy; that operational metadata does not include the Customer's Plugin business data.

16.3. The Vendor has no routine or persistent access to Ledger Data or Plugin Output in the Customer's self-hosted deployment. Support does not require the Customer to grant remote access or to provide production data unless the parties separately agree and the Customer determines that doing so is necessary and lawful.

16.4. If the Customer asks the Vendor to inspect logs, exports, screenshots, extracts, or a support bundle, the Customer must minimize and redact the material, obtain required authority — including any approval required because the material concerns financial reporting, an investigation, or privileged matters — use a secure transfer method approved by the Vendor, time-limit access, and revoke temporary credentials when the engagement ends.

16.5. When the Vendor accepts Customer-provided support material it will apply the General Terms and, where applicable, the Data Processing Addendum. The DPA does not make the Vendor a processor of business data that remains solely inside the Customer's self-hosted deployment.

16.6. Within the Customer's self-hosted deployment, the Plugin exchanges data with other installed Railbase plugins over the platform event bus. It consumes signals published by neighbouring plugins — for example compliance alerts, party blacklists, and published policy clauses — and it publishes its own reconciliation gaps, findings, recommendations, and entity flags, which other installed plugins may consume, including by attaching an audit indication to a case those plugins maintain. This exchange occurs inside the Customer's deployment and does not transmit data to the Vendor; the statement in Section 16.1 that the Plugin does not automatically transmit Plugin Output or findings addresses transmission to the Vendor and does not describe this intra-deployment exchange. The Customer is responsible for which plugins are installed, for how this data is routed, consumed, and retained across them, and for applying the access, confidentiality, personal-data, and Human Review controls in these Special Terms to Plugin Output after it reaches another plugin. Where a neighbouring plugin is absent, unlicensed, or misconfigured, the related exchange does not occur rather than being approximated.

17. AI-assisted development and regulatory classification

17.1. The Vendor may use artificial-intelligence-assisted tools in designing, coding, testing, reviewing, documenting, or maintaining the Plugin. The Customer acknowledges the general limitations of AI-assisted development, including the possibility of defects, omissions, unexpected behavior, or incomplete reasoning.

17.2. Unless a specific Plugin feature and its Documentation expressly state otherwise, the Plugin does not send the Customer's Plugin business data to a third-party AI provider and does not delegate the Customer's conclusions or decisions to an external AI service.

17.3. The Vendor does not represent that any Plugin feature or Customer deployment is, or is not, an artificial-intelligence system, high-risk AI system, automated decision-making technology, profiling system, or other legally regulated system. Classification depends on applicable law, the feature, intended purpose, configuration, data, decision process, affected persons, jurisdiction, and the Customer's actual use.

17.4. Each party is responsible for determining and performing the mandatory legal obligations assigned to that party by applicable law. Contractual allocation of operational responsibility does not eliminate a non-waivable statutory duty of either party.

17.5. If a Plugin feature or use is regulated, the Customer is responsible for its obligations as deployer, user, employer, controller, or decision-maker, including required assessments, governance, Human Review, input-data controls, monitoring, logging, notices, explanations, correction, contest, appeal, worker consultation, registration, and regulatory cooperation.

17.6. The Vendor will provide the Documentation and technical information it is contractually or legally required to provide and may, on reasonable request, provide additional information then reasonably available to assist an applicable assessment. Such assistance is technical information, not legal, accounting, audit, or professional advice, and does not transfer the Customer's obligations.

18. Serious Incidents, complaints, and suspension

18.1. The Customer must maintain procedures to identify, contain, investigate, remediate, document, and make legally required notifications concerning a Serious Incident, including a material analytical error relied upon for a Material or Adverse Decision.

18.2. The Customer must notify the Vendor without undue delay where Vendor assistance, correction, or investigation is reasonably required, while minimizing personal data and protecting confidential, privileged, and regulated information.

18.3. The Customer must maintain a channel through which an Affected Person may raise a complaint, request an explanation, or contest a decision informed by Plugin Output, and must correct or withdraw a conclusion shown to be unfounded, including in any report already issued.

18.4. The Customer must suspend reliance on an affected capability where a Serious Incident, material defect, or materially unreliable output is suspected, until the cause is understood and appropriately remediated.

18.5. When the Vendor confirms a material Plugin defect requiring Customer action, the Vendor will use commercially reasonable efforts to notify known affected Customers through Documentation, release notes, in-product notice, marketplace notice, or another appropriate channel.

19. Material changes and revalidation

19.1. A "Material Change" includes a new or materially changed procedure, reconciliation, journal-entry test, metric, composite model, chart-of-accounts pack, role-assignment rule, materiality behavior, Refusal behavior, permission model, export format, data dependency, or stated limitation that can reasonably affect Customer obligations or risk.

19.2. The Vendor will identify material Plugin changes through release notes, Documentation, in-product notice, marketplace notice, or another commercially reasonable channel, except where immediate action is reasonably necessary for security, law, incident response, or protection of Customer systems.

19.3. Before relying on an affected capability after a Material Change, the Customer must review the change, update its assessments and documentation, repeat proportionate acceptance testing, and obtain a new internal go/no-go approval where appropriate. Results produced before a Material Change must not be compared with results produced after it without confirming comparability.

19.4. A material revision to these Special Terms, the stated intended purpose, or the allocation of risk may require separate re-acceptance for a later purchase, trial, renewal, activation, update, or continued use as specified in the applicable notice.

19.5. The Vendor may deploy an urgent correction or disable functionality without advance notice where reasonably necessary to address a vulnerability, Serious Incident, unlawful behavior, or material risk. The Vendor will provide notice when reasonably practicable.

20. No warranty of accuracy, completeness, or fitness for an audit

20.1. THE PLUGIN, PLUGIN OUTPUT, PROCEDURES, PACKS, METRICS, COMPOSITE MODELS, REFUSALS, REGISTERS, EXPORTS, AND DOCUMENTATION ARE PROVIDED "AS IS" AND "AS AVAILABLE." TO THE MAXIMUM EXTENT PERMITTED BY LAW, THE VENDOR DISCLAIMS ALL EXPRESS, IMPLIED, STATUTORY, AND OTHER WARRANTIES, INCLUDING ACCURACY, COMPLETENESS, CURRENCY, DETECTION OF ERROR OR FRAUD, NON-INFRINGEMENT, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ERROR-FREE OPERATION, RESULTS, AND FITNESS FOR AN AUDIT, REVIEW, ATTESTATION, CERTIFICATION, REGULATORY FILING, PROFESSIONAL ENGAGEMENT, OR OTHER REGULATED USE.

20.2. The Vendor does not warrant that Plugin Output will identify any particular error, omission, irregularity, control deficiency, misstatement, or fraud, that it will avoid false positives or false negatives, or that it is sufficient or appropriate evidence for any purpose.

20.3. The Customer has had the opportunity to evaluate the Plugin, trial availability, Documentation, methodology, and stated limitations before purchase. Purchase does not create a warranty that the Plugin fits the Customer's accounting framework, chart of accounts, entity structure, jurisdiction, audit methodology, or professional-standards obligations.

20.4. No description of a supported source system, pack, procedure, or metric guarantees complete coverage, comparability between versions, a particular result, or continued support after a change by the Customer or a third party.

21. Allocation of responsibility and claims

21.1. To the maximum extent permitted by law, the Customer assumes the risks arising from the Ledger Data supplied, the completeness and provenance of that data, chart-of-accounts and role configuration, Materiality Parameters, calendars and thresholds, sampling and scope judgments, interpretation of Plugin Output, personnel competence and independence, Human Review, and every decision, allegation, disclosure, filing, or action taken in reliance on Plugin Output.

21.2. No claim may be based solely on an error mode, limitation, Refusal, false positive, false negative, coverage gap, model limitation, or source-system difference disclosed in these Special Terms or the Documentation.

21.3. The indemnity and limitation-of-liability provisions in the General Terms apply to the Plugin and these Special Terms. In particular, the Customer will defend, indemnify, and hold the Vendor harmless, to the extent permitted by law, from third-party claims arising from the Customer's presentation of Plugin Output as an audit, opinion, attestation, or certification; from a Material or Adverse Decision taken without the required Human Review; from an allegation made against a person or organization on the basis of Plugin Output; from unlawful or unauthorized data access; or from the Customer's violation of law or third-party rights.

21.4. Nothing in these Special Terms excludes or limits liability to the extent it cannot lawfully be excluded or limited. No provision purports to excuse fraud or intentional or reckless misconduct.

21.5. Subject to mandatory law, the Vendor's aggregate liability remains limited as stated in the General Terms.

22. Acceptance, authority, and evidence

22.1. The Customer may not start a trial or purchase the Plugin unless an authorized representative separately and affirmatively accepts these Special Terms. Acceptance is not bundled with acceptance of the General Terms.

22.2. The Vendor records the accepting account, Customer tenant, context, time, network address, Special-Terms version, and cryptographic hash of the exact text accepted. The version accepted for a purchase or trial governs that acquisition unless a later version is validly accepted or mandatory law requires otherwise.

22.3. By selecting the separate acceptance checkbox and continuing, the representative confirms that they had the opportunity to open, read, retain, and print these Special Terms before proceeding; understand that Plugin Output is an Analytical Indication and is not an audit opinion, assurance, or certification; understand the completeness, Human Review, and decision-making obligations; have authority to bind the Customer; and intend the electronic act to constitute the Customer's signature and agreement.

22.4. The electronic acceptance record establishes the representative's affirmative act, representations, and opportunity to review the recorded version. It does not constitute a Vendor guarantee that the representative actually read or subjectively understood every provision.

23. Term, cessation, and survival

23.1. These Special Terms apply during evaluation, trial, purchase, installation, activation, configuration, renewal, and use of the Plugin, and continue for as long as the Customer retains Ledger Data, Plugin Output, findings, working files, exports, or downstream copies produced through the Plugin.

23.2. On expiration, revocation, or termination of the applicable license, the Customer must stop using the Plugin as required by the General Terms. The Customer remains responsible for closing or reassigning open findings and recommendations, and for lawfully retaining, exporting, restricting, correcting, or deleting its data and downstream copies.

23.3. Sections concerning definitions, the status of Plugin Output, completeness and scope, Human Review, allegations and Affected Persons, records and evidence, data protection, incidents, confidentiality, warranties, responsibility, evidence of acceptance, and governing law survive to the extent necessary to give them effect.

24. Governing law and severability

24.1. These Special Terms are governed by the laws of the State of Wyoming, USA, without regard to conflict-of-laws rules, and the venue provisions in the General Terms apply.

24.2. If a provision is unenforceable, it will be enforced to the maximum lawful extent and the remaining provisions will remain effective. A mandatory legal right or duty prevails only to the extent it cannot lawfully be varied by agreement.

25. Contact

25.1. Silkway Tech LLC — 5830 E 2nd St, Ste 7000 #30294, Casper, WY 82609, USA. Questions: via the support page.