Connector Plugin Special Terms and Data Integration Risk Acknowledgment

Version: 1.1 Effective date: 9 August 2026

1. Agreement, parties, and precedence

1.1. These Connector Plugin Special Terms and Data Integration Risk 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 Connector 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 Connector plugin (the "Connector").

1.3. If these Special Terms conflict with the General Terms on a matter specific to the Connector's source access, data movement, mapping, normalization, synchronization, credentials, downstream delivery, or operational safeguards, these Special Terms control. Capitalized terms not defined here have the meanings in the General Terms.

2. Definitions

2.1. "Datasource Capability" means the Railbase core-owned, policy-mediated host capability through which the Connector may test, describe, and read a configured database. It is part of the Customer's Railbase deployment, not a Connector executable, subprocess, service, agent, or separate product.

2.2. "Canonical Data" means Source Data after the Connector maps, selects, converts, validates, labels, normalizes, enriches, or restructures it into the Connector's documented canonical record model.

2.3. "Consumer Module" means another module installed in the same Customer Railbase environment that is registered or configured to receive Canonical Data through Railbase's tenant-scoped event bus or another documented core-mediated capability.

2.4. "Credentials" means passwords, tokens, API keys, refresh tokens, certificates, connection strings, machine tokens, secret files, and other authentication or authorization material used to access Customer Systems or the Customer's Railbase deployment.

2.5. "Customer Systems" means the Customer's Railbase deployment, Vault, infrastructure, networks, files, databases, applications, accounts, devices, and third-party products or services that the Connector accesses or with which it exchanges data.

2.6. "Source Data" means records, fields, files, metadata, identifiers, configurations, transactions, and other information supplied by or on behalf of the Customer or obtained from Customer Systems under the Customer's authority.

2.7. "Supported Configuration" means a source-system product, edition, version, localization, API, schema, driver, mapping, field set, authentication method, network pattern, deployment pattern, Railbase core version, and Connector version identified as supported in then-current Documentation, subject to the assumptions and limits stated there.

2.8. "Serious Incident" means an unauthorized source access, credential compromise, tenant-boundary failure, material unintended disclosure, destructive synchronization, materially incorrect mapping at scale, or other Connector event reasonably likely to cause significant security, privacy, financial, legal, operational, or reputational harm.

2.9. "Documentation" means the then-current technical, source-system, mapping, security, datasource, configuration, use, release, and limitation documentation supplied by the Vendor for the Connector.

3. Nature and intended purpose

3.1. The Connector is a self-hosted data-integration and normalization tool. 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. It receives data selected by the Customer from configured Customer Systems, maps and normalizes that data into Canonical Data, stores Canonical Data in the Customer's Railbase deployment, and may deliver Canonical Data to Consumer Modules through Railbase's core-mediated event bus and replay mechanisms.

3.2. The intended purpose of the Connector is to help the Customer move selected business data into Railbase and provide a consistent input contract for authorized Consumer Modules. It is not a system of record, backup service, archival service, data-governance program, security control, audit procedure, or substitute for the Customer's reconciliation and professional judgment.

3.3. The Connector does not independently establish that Source Data is true, complete, current, lawfully obtained, or authoritative. Canonical Data remains derived from Source Data, Customer configuration, mapping logic, jurisdiction rules, source-system behavior, and the Connector version in use.

3.4. A checksum, format validation, normalization result, identity label, relationship, reference, or other derived field does not establish identity, authenticity, ownership, legal status, account ownership, beneficial ownership, authority, or the absence of fraud. Unless the Documentation expressly states otherwise, the Connector does not determine that two records represent the same person or entity.

3.5. The technical ability to connect, read, map, store, display, publish, replay, or export data is not a representation that the Customer's intended access, processing, combination, retention, transfer, or downstream use is lawful, authorized, or appropriate.

4. Customer authority and lawful source access

4.1. The Customer may use the Connector only for lawful internal business purposes and in accordance with the Documentation, the General Terms, these Special Terms, third-party terms applicable to Customer Systems, and applicable law.

4.2. The Customer represents and warrants that it owns or has all rights, permissions, contractual authority, API rights, licenses, consents, notices, and lawful bases required to access Customer Systems and to select, extract, copy, combine, normalize, store, publish, replay, export, retain, and otherwise process Source Data for the Customer's intended purposes.

4.3. The Customer must not use the Connector to bypass source-system authorization, licensing restrictions, technical access controls, rate limits, confidentiality duties, tenant boundaries, or restrictions on scraping or automated access.

4.4. The Customer must not knowingly configure access to data outside its authority or use the Connector for unlawful surveillance, indiscriminate collection, credential theft, data exfiltration, infringement of third-party rights, or another unlawful purpose.

4.5. The Customer is responsible for identifying data owners, affected business processes, categories of data and persons, permitted purposes, required notices or consultations, applicable retention periods, and authorized recipients before operational use.

5. Data scope, mapping, normalization, and quality

5.1. The Customer is responsible for selecting source objects, tables, queries, files, endpoints, fields, filters, mappings, canonical types, stable record references, synchronization frequency, and downstream Consumer Modules according to purpose-limitation, data-minimization, least-privilege, and need-to-know principles.

5.2. Auto-detection, templates, default mappings, aliases, type inference, jurisdiction packs, and normalization rules are starting points that require Customer validation. A field name or value may have a different meaning across products, editions, localizations, customizations, companies, periods, or business processes.

5.3. The Connector may produce incomplete, duplicated, stale, incorrectly typed, incorrectly joined, misclassified, truncated, rejected, or omitted Canonical Data. It may also fail to detect a deletion, change, relationship, invalid identifier, unsupported value, schema change, or reuse of a source reference.

5.4. The Customer must provide a stable, source-native record reference where required by the Documentation. A display name, personal identifier, bank number, tax number, or another value subject to collision or reassignment must not be used as a stable record reference unless the Documentation expressly identifies that use as safe for the Supported Configuration.

5.5. The Customer must validate field meaning, mappings, reference stability, identity handling, country and jurisdiction settings, date and number formats, currency, time zone, completeness, rejected rows, duplicate behavior, tombstones, and downstream interpretation before operational reliance and after material changes.

5.6. Canonical Data must be checked against authoritative source records and reconciled at a frequency proportionate to its purpose, volume, sensitivity, rate of change, downstream reach, and potential consequences. A successful connection test, completed run, green health indicator, accepted chunk, or absence of an error does not prove completeness or correctness.

5.7. The Customer must not present Canonical Data as independently verified by the Vendor or by a third-party source-system provider. A Customer or Consumer Module using Canonical Data for a material decision remains responsible for verifying the relevant source records and applying all safeguards required for that decision.

6. Downstream delivery, Consumer Modules, and replay

6.1. The Customer understands that the Connector is an integration hub. Canonical Data may be published to authorized Consumer Modules installed in the Customer's Railbase environment, and those Consumer Modules may create and retain their own derived records, indexes, alerts, cases, documents, logs, or other copies.

6.2. The Customer is responsible for reviewing which Consumer Modules are installed, which declared entity types they consume, their permissions and purposes, and whether delivery to each Consumer Module is lawful, necessary, proportionate, and compatible with the purpose for which the Source Data was obtained.

6.3. Replay, resend, retry, and durable-load features may deliver previously stored Canonical Data again, including to a Consumer Module installed or registered after the original ingestion. The Customer must restrict access to those features and assess the effect of replay before using them.

6.4. Disabling or deleting a source, mapping, schedule, Connector record, or Connector license does not necessarily delete copies already created by Consumer Modules, exports, backups, logs, or third-party systems. The Customer must operate a coordinated retention, correction, restriction, and deletion process covering all relevant copies.

6.5. Consumer Modules may apply their own business logic and produce their own output. Their operation, limitations, and special terms are separate from these Special Terms. The Connector's successful delivery does not establish that a Consumer Module processed the record correctly or that the Customer's downstream use is lawful.

7. Credentials, network access, and security configuration

7.1. The Customer is responsible for provisioning dedicated Credentials and source-system accounts with the minimum permissions, fields, companies, tenants, time range, and network reach necessary for the documented integration. Read-only access must be used unless a documented Connector feature genuinely requires write access.

7.2. The Customer must use the documented secret mechanism, must not place Credentials in non-secret configuration, source names, mappings, queries, logs, screenshots, support requests, command-line arguments, or other locations where they may be exposed, and must promptly rotate Credentials after suspected disclosure or when personnel or system access changes.

7.3. The Customer must use appropriately protected transport, including TLS where data crosses an untrusted network, validate destination identity, restrict firewall rules, protect DNS and proxy configuration, and avoid exposing source systems or the Railbase deployment directly to the public internet except where the Customer has assessed and accepted the risk.

7.4. Private-egress and host allowlists widen the destinations reachable from the Customer's Railbase deployment. In particular, allowing loopback, link-local, private-network, or broad CIDR destinations may expose internal services, including services on the Railbase host, to Connector requests. The Customer must approve the narrowest practical destination and periodically review and remove obsolete entries.

7.5. Machine tokens used by automation must be tenant-bound where supported, limited to the documented Connector permissions, given a proportionate lifetime, stored outside source control, monitored, and revoked when no longer required.

7.6. The Customer must periodically review source-system accounts, Credentials, machine tokens, egress rules, datasource configurations, Connector roles, Consumer Modules, and privileged operations, and investigate suspected unauthorized access or unexpected data movement.

8. Core-mediated database access

8.1. Database access is performed by the Datasource Capability inside the Customer's Railbase core. The Connector supplies only allowlisted non-secret configuration and secret references; the core resolves Credential values within the Customer's tenant and plugin scope and does not expose those values to the Connector's JavaScript runtime. The Customer remains responsible for securing the Railbase host, Vault, filesystem, network, backups, logs, and administrative access.

8.2. The Datasource Capability accepts read-only queries and bounded reads subject to the documented driver and policy limitations. The Customer must still use a dedicated read-only source account, review every query and selected object, and ensure that database-side permissions independently prevent writes and access outside the approved scope.

8.3. SQLite sources are restricted to documented read-only files under the Railbase datasource directory, currently <DataDir>/datasources, after path resolution. Network database targets are subject to Railbase's egress policy; loopback, link-local, private-network, and other restricted destinations require an explicit narrow Customer-controlled allowlist. These controls reduce but do not eliminate filesystem, network, DNS, driver, query, or Credential risk.

8.4. A structure or schema scan is intended to return metadata rather than sampled source values. A normal extraction necessarily returns the selected records to the Connector and stores or processes them inside the Customer's Railbase deployment. The Customer chooses that deployment's location and network and is responsible for any resulting network, geographic, organizational, or cross-border transfer.

8.5. The Customer must test connection settings, queries, mappings, incremental cursors, limits, timeouts, retries, and snapshot or deletion behavior before scheduling unattended operation. Loss, rollback, reuse, or corruption of cursor state, source references, mappings, or clocks may cause duplicates, omissions, replay, delayed updates, or unintended retirement of downstream records. The Customer must monitor runs and reconcile results after restore, migration, failover, Credential rotation, or material configuration change.

9. Third-party systems and dependencies

9.1. References to 1C, QuickBooks, Xero, NetSuite, SAP, Oracle, PostgreSQL, MySQL, MongoDB, SQLite, or another third-party product describe integration patterns only and do not imply certification, sponsorship, endorsement, partnership, or a guarantee by the third-party provider.

9.2. The Customer is responsible for obtaining and maintaining all third-party accounts, subscriptions, licenses, drivers, API rights, consents, Credentials, network access, export permissions, and source-system support required for its use.

9.3. The Vendor does not control and is not responsible for a third party's availability, security, data quality, schema, API, localization, authentication, rate limits, pricing, licensing terms, deprecation, product changes, or decision to restrict integration access.

9.4. A third-party or Customer change may interrupt synchronization, alter field meaning, invalidate Credentials, reduce available data, require remapping, duplicate or omit records, or change Canonical Data. The Customer must monitor connector health, review release and source-system notices, and validate affected data before reliance following such a change.

9.5. The Vendor may update, restrict, or discontinue a source adapter, driver, Datasource Capability behavior, or Supported Configuration when a third-party change, legal restriction, security risk, or unreasonable maintenance burden makes continued support impracticable, subject to the General Terms.

10. Pre-deployment testing and change control

10.1. Before operational use, the Customer must document the intended purpose, source owner, source scope, categories of Source Data, lawful authority, mappings, Consumer Modules, retention requirements, responsible operator, reconciliation method, incident path, and applicable legal or contractual requirements.

10.2. The Customer must perform controlled acceptance testing using representative and appropriately protected data. Testing must cover successful and failed authentication, source permissions, mapping accuracy, unsupported fields, duplicates, missing values, stable references, incremental updates, retries, replay, deletion or tombstone behavior, tenant isolation, Consumer Module delivery, error visibility, and recovery from interruption.

10.3. The Customer must record known limitations, rejected or unmapped fields, accepted source coverage, remediation, residual risks, and an authorized go/no-go decision before unattended or production use.

10.4. The Customer must repeat proportionate testing and reconciliation after a material change to the Connector, Datasource Capability, Railbase core, Customer Systems, source schema, source query, Credentials, mapping, jurisdiction pack, network path, Consumer Modules, data purpose, or legal environment.

10.5. The Customer must promptly suspend an affected source, schedule, replay, or Consumer Module where monitoring indicates unauthorized access, material misrouting, destructive behavior, a tenant-boundary failure, or materially unreliable data until the risk is understood and appropriately remediated.

11. Data protection, retention, deletion, and records

11.1. The Customer is the controller, business, employer, records owner, or other responsible party for personal data and business data processed in its self-hosted deployment, except to the limited extent mandatory law or an applicable Data Processing Addendum expressly assigns a different role.

11.2. The Customer must determine and document a lawful basis and permitted purpose; provide required privacy, employee, customer, vendor, or other notices; obtain consent where required; and apply purpose limitation, data minimization, accuracy, access control, retention, deletion, localization, and cross-border-transfer requirements.

11.3. The Customer is responsible for deciding whether identifiers, bank details, contact information, addresses, employment records, relationships, transactions, payment descriptions, contracts, health information, protected characteristics, allegations, or other sensitive or regulated data may lawfully be selected, combined, normalized, delivered, displayed, exported, and retained.

11.4. The Customer must maintain a process to correct inaccurate Source Data and Canonical Data, propagate material corrections where required, respond to applicable access, correction, deletion, objection, restriction, and portability requests, and document when technical or legal limits prevent propagation to a downstream copy.

11.5. The Customer remains responsible for the availability, integrity, confidentiality, backup, retention, restoration, reconciliation, export, restriction, and lawful deletion of its data. The Connector is not a backup or disaster-recovery system.

12. Self-hosting, Vendor access, and support

12.1. The Connector runs in the Customer's self-hosted Railbase deployment and stores Connector business data in the Customer's Vault. The Connector does not automatically transmit Source Data, Canonical Data, Credentials, or other Connector business data to the Vendor.

12.2. The Connector necessarily exchanges information with source systems and endpoints configured by the Customer. 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 Connector business data.

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

12.4. If the Customer asks the Vendor to inspect logs, mappings, screenshots, database extracts, support bundles, source samples, or temporary access, the Customer must minimize and redact the material, obtain required authority, use a secure transfer method approved by the Vendor, time-limit access, and revoke temporary Credentials when the support engagement ends.

12.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 or configured third-party systems.

13. Incidents and notification

13.1. The Customer must maintain procedures to identify, contain, investigate, remediate, document, and make legally required notifications concerning suspected unauthorized source access, credential compromise, Railbase host or runtime compromise, unintended data delivery, material mapping failure, tenant-boundary failure, destructive synchronization, or another Serious Incident.

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

13.3. The Customer remains responsible for notices to data subjects, employees, customers, counterparties, source-system providers, regulators, insurers, or other persons, except to the extent mandatory law expressly places a duty on the Vendor.

13.4. When the Vendor confirms a material Connector defect or vulnerability requiring Customer action, the Vendor will use commercially reasonable efforts to notify known affected Customers through Documentation, release notes, security notice, in-product notice, marketplace notice, or another appropriate channel, subject to lawful security-disclosure practices.

14. Material changes and revalidation

14.1. A "Material Change" includes a new or materially changed source adapter, driver, Datasource Capability behavior, mapping or auto-detection rule, jurisdiction rule, identity behavior, data category, Consumer Module delivery contract, replay behavior, external data transfer, credential flow, egress capability, security characteristic, or limitation that can reasonably affect Customer obligations or risk.

14.2. The Vendor will identify material Connector 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.

14.3. Before relying on an affected feature after a Material Change, the Customer must review the change, update its assessments and Documentation, repeat proportionate acceptance testing and reconciliation, update training and procedures, and obtain a new internal go/no-go approval where appropriate.

14.4. A material revision to these Special Terms, the stated intended purpose, data-transfer behavior, or 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.

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

15. No warranty of synchronization, data quality, or source-system fitness

15.1. THE CONNECTOR, DATASOURCE CAPABILITY, CANONICAL DATA, MAPPINGS, ADAPTERS, DRIVERS, AND RELATED OUTPUT 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, CONTINUITY, NON-INFRINGEMENT, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ERROR-FREE OPERATION, RESULTS, DATA RECOVERY, LEGAL COMPLIANCE, AND FITNESS FOR A PARTICULAR SOURCE SYSTEM, SCHEMA, WORKFLOW, DECISION, OR REGULATED USE.

15.2. The Customer has had the opportunity to evaluate the Connector, trial availability, Documentation, Supported Configurations, mappings, and limitations before purchase. Purchase does not create a warranty that the Connector fits Customer Systems, data-governance program, network, jurisdiction, retention model, Consumer Modules, or business-continuity requirements.

15.3. No statement about a Supported Configuration guarantees uninterrupted compatibility, complete object or field coverage, detection of every change or deletion, a particular throughput or latency, equivalence between versions, or continued support after changes by the Customer or a third party.

15.4. A lack of an error does not establish a complete synchronization, and an error does not establish that no data was stored, delivered, retried, or replayed before the error occurred. The Customer must use source-to-destination reconciliation appropriate to the risk.

16. Allocation of responsibility and claims

16.1. To the maximum extent permitted by law, the Customer assumes the risks arising from Customer Systems, Source Data, Credentials, source authority, queries, mappings, references, datasource configuration, infrastructure, network paths, Consumer Modules, legal basis, retention, downstream use, and reliance on Canonical Data.

16.2. No claim may be based solely on an error mode, source-system difference, third-party change, synchronization limitation, or mapping limitation disclosed in these Special Terms or the Documentation.

16.3. The indemnity and limitation-of-liability provisions in the General Terms apply to the Connector 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 unlawful or unauthorized source access, insecure Customer environment, exposed Credentials, unsupported or incorrect configuration, failure to provide required notices or rights, prohibited use, or violation of law or third-party rights.

16.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.

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

17. Acceptance, authority, and evidence

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

17.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.

17.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 the Connector can access, normalize, store, publish, and replay selected Customer data; understand the source-access, validation, security, and downstream-data obligations; have authority to bind the Customer; and intend the electronic act to constitute the Customer's signature and agreement.

17.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.

18. Term, cessation, and survival

18.1. These Special Terms apply during evaluation, trial, purchase, installation, activation, configuration, renewal, and use of the Connector and continue for as long as the Customer retains Source Data, Canonical Data, downstream copies, or records produced through the Connector.

18.2. On expiration, revocation, or termination of the applicable license, the Customer must stop using the Connector as required by the General Terms. The Customer remains responsible for disabling sources and schedules, revoking Credentials and machine tokens, removing unnecessary egress rules, and lawfully retaining, exporting, restricting, correcting, or deleting its data and downstream copies.

18.3. Sections concerning definitions, status of Canonical Data, source authority, data quality, downstream delivery, data protection, incidents, confidentiality, warranties, responsibility, evidence, and governing law survive to the extent necessary to give them effect.

19. Governing law and severability

19.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.

19.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.

20. Contact

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