User agreement (public offer)

This is an English translation for convenience. The Russian version is the legally binding one.

This document is a public offer (clause 2 of Article 437 of the Civil Code of the Russian Federation): a proposal to conclude a contract on the terms set out below. The contract is deemed concluded from the moment of registration (and for organisations created later and for users who join — in the manner of clauses 3.4 and 3.5), at which the user confirms acceptance of this agreement (acceptance of the offer, Article 438 of the Civil Code of the Russian Federation). The date of acceptance of the agreement is the date of the user’s registration, and for an invitee — the date of their first sign-in.

The Contractor is the person whose details are given on the Contacts page. The email address for legally significant notices is there too.

1. Terms

• Service — the Buff Development software system, available through the Contractor’s website and the web application, as well as the connector and Buff Code.
• Client — a legal entity, sole proprietor or individual who has concluded the contract by registering.
• User — an individual who has signed in to the service under their own account. A user acts on behalf of the client whose organisation they belong to. If the client is an individual, that individual is the user who owns their organisation; users they invite act on their behalf (clauses 3.5, 3.6).
• Organisation — the client’s space in the service, bringing together users, repositories, tasks and the balance. An organisation has one or more owners and members.
• Development project — the organisation’s workspace in the service, which holds repository mirrors, development tools and tasks.
• Separate environment — an instance of the service deployed by the Contractor for a single client (on the website — “Custom setup”).
• Repository — the client’s code storage on its platform (GitHub, GitLab, Bitbucket, Gitea or a server in the client’s network) connected to the service.
• Mirror — a copy of a connected repository that the service keeps on its side in order to do the work.
• Work — the service’s services under the client’s assignment: answers to questions about code (in the web application — “Ask”), research, project analysis (in the web application — “Audit”), preparing and clarifying the specification, preparing development tools (the project’s build and tests), developing tasks with checking (in the web application — “Review”) and sending changes to the client’s repository (clause 4.4, without separate payment). The word “work” denotes a type of service, not work under a contract for work (podryad).
• Result — code changes prepared by the service in the task branch and delivered to the client as a pull request (a request to merge), texts of answers, research and analyses, as well as development tools (build and test settings) prepared by the service in the client’s development project.
• Part of the work — a separate step of the work (preparing the specification, splitting the specification, developing each part of the specification, checking, an answer, research, an analysis) for which the service makes one or more charges shown in the billing history.
• Balance — the amount in roubles on the organisation’s personal account in the service, from which the cost of work is charged: the prepayment made by the client (including by a third party on its behalf, clause 3.3) and the starting balance credited by the Contractor.
• Plan — a set of conditions determining on which computing resources the work is done and how its cost is calculated. The current plans are published on the Pricing page.
• Dedicated capacity — a separate machine rented by the Contractor for the client’s organisation, as well as plans on which work is done on such a machine.
• Connector — an agent program that the client installs in its network to connect its repositories and other systems to the service without passing access tokens to the Contractor.
• Integration — an additional software component for the connector, developed and signed by the Contractor and published in the integration catalogue. An integration lets the connector work with a specific client system (a task tracker, a knowledge base, a repository platform).
• Integration catalogue — the list of integrations available for installation in the connector; for each integration it declares its version, the addresses it contacts, the type of credentials required and the list of its tools.
• Connection — a link, configured by the client, between the connector and a specific client system through a chosen integration: the system’s address, credentials and the list of projects, repositories or spaces in which the connection works (the scope).
• Client system — a task tracker, knowledge base or other client system connected to the service through the connector.
• Buff Code — a development program that the user installs on their computer to work with code on models and with the organisation’s connections; it reaches the service only through the developer gateway in the client’s connector.
• Development session — a record, kept by the service, of the user’s work in Buff Code: every request to the model and the response to it.

2. Subject of the contract

2.1. The Contractor provides services to the client: it provides access to the service and uses it to do work on the client’s assignments (Chapter 39 of the Civil Code of the Russian Federation), and the client pays for the work under the current plan.

2.2. The service is provided remotely over the internet. The Contractor does not install the service on the client’s equipment, except for the connector, which the client installs itself (section 10). A separate environment and dedicated capacity in the Russian jurisdiction are provided on request on terms (hourly price, shutdown period) agreed with the client by email and assigned to the organisation in the web application, or under a separate contract; the provisions of this agreement apply to them unless the agreed terms or a separate contract provide otherwise.

2.3. The work is done using artificial intelligence models. The client understands that the result of such work requires checking by a human and takes on that checking (section 6).

3. Registration, account and organisation

3.1. To use the service, the user registers an account, giving an email address, login, password and, optionally, an organisation identifier (the name of the workspace). Sign-in is confirmed by a code that the service sends to the given email address.

3.2. When registering to use the service in the interests of a legal entity or sole proprietor, the user undertakes to provide the information under clause 3.3; until the information is provided, the party to the contract is determined by clause 3.3. A client who is an individual concludes the contract in their own name and confirms that they are at least 18 years old.

3.3. A client that is a legal entity or sole proprietor provides the Contractor with its name, TIN (INN), OGRN (OGRNIP), address and email address for legally significant notices. The information is sent by email to the address given on the Contacts page, in the manner described in sub-clause (a) below — at any time on the client’s initiative, upon the first top-up of the balance by bank transfer, or at the Contractor’s request. The legal entity or sole proprietor becomes a party to the contract (the client) from the earlier of the dates: (a) receipt by the Contractor of the information under this clause from an email address in that entity’s domain, or from the organisation owner’s address with a power of attorney or a letter signed by an authorised person attached; (b) receipt of the first payment from that entity’s bank account stating the organisation identifier — provided that the information under this clause is provided no later than 5 business days after the payment. If the information is not provided within this period, the payment is credited to the organisation’s balance as performance of the client’s obligation by a third party (Article 313 of the Civil Code of the Russian Federation), the party to the contract is determined by sub-clause (a), and the acts under clause 5.2 for periods before the information was provided are sent after it is provided. Until that date, the client is the individual who registered the organisation. Charges are paid off from the funds paid in, in the order in which they were received. From the date of transfer to the legal entity (sole proprietor), the rights and obligations under the contract pass to it, including the organisation’s balance and the rights to results obtained earlier, and the user who registered the organisation is recognised as its authorised representative. Funds paid by bank card before the information was provided remain on the organisation’s balance; on a refund under clause 5.7, their unspent part is returned to the same card.

3.4. On registration, an organisation is created, and the registering user becomes its owner. The owner invites members by login or email address, assigns roles, grants and revokes access to repositories, changes the plan and manages the balance. An organisation created by a user in the web application later is subject to the same rules: until the information under clause 3.3 is provided, the client for it is the user who created it, and the contract in respect of it is deemed concluded from the moment of its creation. The client’s rights and obligations are accounted for separately for each organisation.

3.5. If there is no account with the given address yet, the service creates one and sends an invitation; the address is used only to send the invitation, and if the invitation is not accepted within 30 days, the account and the address are deleted. The invitee gets access after signing in and accepting this agreement. By accepting the agreement as an invitee, the user does not conclude a separate contract but joins the contract of the client whose organisation they were invited to. The client warrants that it is entitled to pass the invitee’s email address to the Contractor.

3.6. The client is responsible for the actions of all users of its organisation as for its own, including the tasks set, the repositories connected and the charges to the balance.

3.7. The user must keep the password and access tokens secret and immediately inform the Contractor of any suspected unauthorised access. Changing the password ends the user’s other sessions.

3.8. One user may be a member of several organisations. The service executes the user’s commands within the roles assigned in the particular organisation.

4. How the work is done

4.1. The client connects a repository: either it gives the service an access token for the repository (to send the result under clause 4.4 — with write access to that repository; for other work, read access is enough), or it installs the connector in its network. A token passed to the service is stored in encrypted form, is not shown in the interface and can be deleted by the user in the settings. The service creates and updates the repository mirror on the client’s command. Synchronisation is one-way: by itself it writes nothing to the client’s repository.

4.2. The client sets tasks, asks questions and starts research and project analysis in the web application. For a task, the service clarifies the details, shows the specification and starts development only after the user has approved the specification; questions, research and project analysis start without approval. Clarifying and preparing the specification, as well as preparing development tools, are work and are paid for under the plan regardless of whether the user approved the specification. The time needed to complete work depends on the specification and the service’s load; the estimated time and progress are shown in the web application. For clients who are individuals using the service for personal needs, the deadline for completing work is no more than 30 days from its start (for task development — from the moment the specification is approved); this deadline does not include time during which the work is waiting for the user’s answer or decision, or is stopped by the client or under clause 5.1, and rework on the user’s findings (clause 4.3) is done within a new deadline of the same length from its start. If the deadline is exceeded, the client may stop the work, and the cost of the unfinished part is returned to the balance. The client may stop work at any time using the web application, and where it has no such means — by a letter to the address on the Contacts page; in that case the cost of the work done by the moment of stopping is charged (for clients who are individuals using the service for personal needs — the expenses actually incurred by the Contractor within that cost; the difference between the amount charged and such expenses is returned to the balance as an adjustment within 5 business days of the date of stopping, and the operation is visible in the billing history). A stopped task can be resumed: parts of the task completed by the moment of stopping are not done or paid for again; a part interrupted midway is done again and paid for under the plan. If a task is stopped before the specification is approved or while the approved specification is being split into parts, preparation of the specification is done again and paid for under the plan.

4.3. Development is done in a separate branch on the service’s side. On completion, the changes are checked in the service, and the user decides: approve them or return them for rework. A change with open findings cannot be approved. Rework on the user’s findings is done as new development on the same task and is paid for under the plan; a deviation of the result from the specification that the service reported in the check findings is not a defect of the service. A defect of the service is a deviation of the result from the approved specification that the service did not report in the check findings and that the user stated in a finding before approving the change; in this case the Contractor returns to the balance the cost of the parts of the work for developing the part of the specification in which the deviation occurred, including its checking; the cost of the other parts of the specification is not returned, and rework on this finding is done as described above; other claims arising from the defect are limited by section 11. For clients who are individuals using the service for personal needs, clause 11.5 applies.

4.4. After approval, the service sends the task branch to the client’s repository and opens a pull request into the target branch the user chose on approval. Sending is done using the token of the user who approved the change, or through the connector; in the client’s repository, the branch and the pull request appear on behalf of the token’s owner. Sending is done for all of the task’s repositories together. The service writes nothing else to the client’s repository. The service does not change the client’s existing branches, including the main one; when the same task is published again, only the task branch the service created earlier is updated, provided the client has not changed it themselves; otherwise sending is not done, and the service reports this. If sending is impossible (no token, no write access, the client’s platform is unavailable), the service reports this; the result is kept in the service, and once the cause is removed, sending can be repeated. Charges for task development are not refunded if the cause lies on the client’s side.

4.5. The Contractor’s obligation to deliver code changes is deemed fulfilled at the moment the pull request appears in the client’s repository; answers, research and analyses are deemed delivered at the moment they are displayed in the web application. The user’s approval of a change in the web application constitutes acceptance of the result. Development tools are kept in the development project in the service, are used for subsequent tasks and are delivered to the client at the organisation owner’s request as a copy of the project repository (build and test settings) within 10 business days of the date of the request, including after termination — until the end of the retention period under clause 12.5; they are deleted together with the working materials (clauses 8.7, 12.5). The client merges the pull request into the target branch; the client is responsible for the decision to merge and its consequences for the client’s product.

4.6. The Contractor does not choose the architecture of the client’s product and is not responsible for the result’s compliance with requirements the client did not set out in the specification.

4.7. Work can be started not only in the web application but also from a client system connected through the connector (section 10) — by directly addressing the bot account in a comment on a ticket, task, page or pull request discussion (by a mention or a command), and also, if the client has turned this on in the connection settings, by assigning a task to the bot. A request with a question or asking for research is equivalent to starting the corresponding work and is paid for under the plan from the organisation’s balance; prices are published on the Pricing page and in the web application, and by connecting its system and defining the connection’s scope, the client agrees to pay for work started by requests from it under the rules of clause 5.3. A request asking to file a task is not work: the service creates a task draft in the web application and sends a link to it, and clarifying the specification and development are done in the manner of clause 4.2 after the user’s decision. Work is started only by a direct request and only within the connection’s scope; changing labels, statuses and fields of a ticket does not start work. A request can be written by any person who has access to the projects, repositories or spaces of the client system marked in the scope; the client determines who these persons are and is responsible for the work they start. The service writes to the client system only the answer and service messages about the progress of the work — as a comment in the same discussion, and for research it additionally attaches a document if the client system accepts attachments. The service does not change statuses, labels, assignees, ticket fields, knowledge base pages or repository content in the process.

5. Payment

5.1. Work is paid for from the organisation’s balance in roubles. The cost of each piece of work is determined by the plan in effect at the time it is done and is charged as it is done. New work is not started when the balance is negative or zero. The cost of work already started that exceeds the balance is recorded as a negative balance and paid off from the next top-up; the Contractor is not entitled to collect it separately. As soon as the balance becomes negative (on dedicated capacity — in the manner of clause 5.4), the Contractor stops task development together with its checking (clause 4.3), and it is resumed in the manner of clause 4.2; answers to questions, research, project analysis, preparation of the specification (including splitting into parts) and preparation of development tools started earlier are run to completion and paid for in full, and on dedicated capacity the machine time is also charged until it is shut down (clause 5.4).

5.2. The balance is topped up by bank card in the web application or by bank transfer to the Contractor’s details given on the Contacts page, stating the organisation identifier in the payment reference; the balance is topped up once the funds arrive. For a bank card payment, and for any payment by a client who is an individual, a cash receipt is sent to the payer’s email address (for a bank transfer — to the organisation owner’s address). Prices are in roubles; the services are not subject to VAT: the Contractor applies the simplified taxation system and is exempt from VAT under Article 145 of the Tax Code of the Russian Federation. If the Contractor loses the right to the VAT exemption, from the date of loss the published prices include VAT at the applicable rate; the Contractor notifies the organisation owner of the loss by email no later than 5 business days later and from that date issues VAT invoices as part of the UPD. No later than 5 business days after the end of a calendar month, the Contractor sends legal entities and sole proprietors an act of services rendered (a universal transfer document, UPD) for the amount charged during the month minus adjustments to the balance relating to work of the same month — in electronic form to the email address provided under clause 3.3, or through an electronic document exchange operator. The act is deemed accepted, and the services for the month deemed duly rendered, if within 5 business days of the date it was sent the client has not sent reasoned objections to the address given on the Contacts page. An adjustment relating to work included in the act for the previous month is issued as a corrective act (UKD) to that act within the same periods. If the client uses electronic document exchange, or at the Contractor’s request, the client returns a signed copy within 5 business days through the electronic document exchange operator or as a scanned copy by email.

5.3. The prices and contents of the plans are published on the Pricing page and form part of the contract. On any plan, work is priced at the price in effect at the start of each part of the work; the number of tokens is determined from the model provider’s data, and on dedicated capacity and in a separate environment — from the model data recorded by the service, and is shown in the web application; a price changed after the work was started applies to parts started after the change. On a plan where the client chooses the model, the model’s price may change following the model provider’s price; the current price is always shown in the web application at the time of choosing. The model’s price is shown for the compute supplier that serves it by default; if a request was served by another supplier from the provider’s catalogue (when the first was unavailable or failed), the cost is determined by that supplier’s price given in the catalogue; at the organisation owner’s request, the Contractor reports which supplier served the request. On all plans, the model’s reasoning tokens are priced at the output price, and tokens read from the cache at a price no higher than the input price. If the chosen model is unavailable, the request is run on the default model indicated in the web application (the “Billing” → “Models” section); the cost of such a request does not exceed the cost calculated at the price of the model chosen by the client (the difference, if any, is returned to the balance as an adjustment within 5 business days after the work is completed), and at the organisation owner’s request the Contractor reports which requests were run on the default model. For clients who are individuals using the service for personal needs, the price shown in the web application (the “Billing” section) at the time the work was started applies to the work; if a part of the work was charged at a higher price, the difference is returned to the balance as an adjustment within 5 business days after the work is completed.

5.4. On dedicated capacity, in addition to the cost of the work, the cost of the machine’s running time is charged at the hourly price published for the model class chosen by the client (the list of classes and the hourly price are on the Pricing page) or agreed under clause 2.2. Time is counted from the moment the machine is ready until it is shut down — manually or automatically: in dynamic mode — after idling for more than 20 minutes or because of the balance, in permanent mode — only because of the balance; in permanent mode the machine time is charged continuously, including idling, until the client shuts it down; time spent preparing the machine and time it is unavailable because of a failure is not charged. The machine shuts down automatically in advance — when the balance is enough for less than one hour of work at the current spend rate; from that same moment task development stops, even if the balance is still positive; the forecast is shown in the web application. When the balance is insufficient, task execution stops; after the balance is topped up, the task can be resumed in the manner of clause 4.2. Dedicated capacity in the Russian jurisdiction and a separate environment are shut down by the Contractor at the organisation owner’s request within the period set by a separate contract, and in the absence of one — within 3 business days; machine time is not charged from the moment the request is received, and for the purposes of clauses 5.5, 5.7 and 9.2 they are deemed shut down from the same date.

5.5. The plan applies to the whole organisation. The organisation owner can change the plan in the web application when no work is running in the organisation and dedicated capacity is shut down; while capacity is switched on, changing is unavailable. The new plan applies from the moment of the change; amounts already charged are not recalculated.

5.6. When a user registers, the Contractor may credit their first organisation with a starting balance to get acquainted with the service. The starting balance is not the client’s money, is not refundable and is not transferred to another organisation or another client. Charges are paid off first from the starting balance, then from the funds paid in by the client; the amount refundable under clause 5.7 is the balance minus the unspent part of the starting balance.

5.7. The client may at any time request a refund of the unspent balance paid in by itself or by a third party on its behalf (clause 3.3); a balance paid in by a third party is refunded to the bank account from which the payment came. The Contractor refunds the balance by the same method by which it was paid in, or by another method agreed with the client, within 10 business days (for clients who are individuals — 10 calendar days, including adjustments under clauses 4.2 and 5.3) of the date as of which the balance amount is determined: the later of the date the application is received at the email address given on the Contacts page, or the date the client stopped work and shut down dedicated capacity; if no work is running and capacity is shut down on the date the application is received — from the date the application is received. The application is sent from the organisation owner’s email address.

5.8. Work interrupted through no fault of the client (a failure of the service, the Contractor’s infrastructure, the model provider or the model, including one chosen by the client under clause 5.3) is resumed in the manner of clause 4.2: the amount charged for the completed part is not refunded; the amount charged for re-running the interrupted part and for preparing the specification again (if that was needed) is returned to the balance by the Contractor without an application from the client within 5 business days after the resumed work is completed, and the operation is visible in the billing history; parts first started after resumption are paid for under the plan. If such work cannot be resumed or the Contractor discontinues it, the amount charged for it is returned to the balance. If the client does not resume the interrupted work within 30 days of the date of interruption, or terminates the contract before it is resumed, the amount charged for the part interrupted midway is returned to the balance on the client’s application in the manner of clause 5.7. Inability to complete a task because of its content (contradictory or beyond the capabilities of the models), inability to build the project or reproduce its tests for reasons related to the client’s repository (including when development tools under clause 4.2 could not be prepared), or unavailability of the client’s platforms is not the Contractor’s fault; the cost of the completed part is not refunded in these cases.

6. Checking the result and responsibility for the code

6.1. The result is created using artificial intelligence models and may contain errors, suboptimal solutions or deviations from the specification. The service checks the result with the means available in the repository (build and tests, if there are any) and with a separate reviewing model; this check does not replace checking by the client.

6.2. The client undertakes to check the result before merging and using it. The Contractor is not liable for the consequences of merging and using a result that the client has approved.

6.3. The result may include third-party libraries and code fragments under their own licences. The client checks their licence compatibility with its product.

6.4. The Contractor does not guarantee that the service will complete any task set. If a task cannot be completed, the service reports this. The cost of the work done up to that point is charged under the plan; a refund is made in the case provided for in clause 5.8.

7. Rights to the code and the result

7.1. The exclusive rights to the client’s code belong to the client. The client warrants that it is entitled to pass the connected repositories and materials to the service and that their processing does not infringe the rights of third parties.

7.2. For the term of the contract, and as regards storage and deletion — until the materials are deleted within the periods set by clauses 8.7 and 12.5, the client grants the Contractor a simple (non-exclusive) royalty-free licence to use the code, tasks and materials solely to do the work under the contract: to create and keep the mirror, to analyse, develop, check and prepare the result.

7.3. All rights to the result that may belong to the Contractor pass to the client from the moment the result is created, regardless of whether it has been sent to the client’s repository. The remuneration for the transfer of rights to the result is included in the cost of the work and is not paid separately. The Contractor makes no claim to rights to the result and does not use the result outside the contract.

7.4. The exclusive rights to the service (including the connector and integrations), its code, interface and documentation belong to the Contractor. The client receives the right to use the service to the extent necessary to receive the work, without the right to copy, modify or transfer the service to third parties; the connector is used on the terms of section 10.

8. Confidentiality and data

8.1. The client’s code, tasks, questions, research and analyses are the client’s confidential information. The Contractor does not disclose it to third parties except in cases provided for by the contract and the law. The obligation to maintain confidentiality applies for the term of the contract and indefinitely after its termination.

8.2. Account data, repository mirrors, tasks, answers, research, analyses, development tools and information about charges are permanently stored on servers used by the Contractor and located in the Russian Federation; data is transferred outside it only in the cases of clauses 8.3 and 8.4.

8.3. On plans where work is done through a model provider (named on the Security page), the content of repository files, including the change history, texts of tasks and questions, attachments and other materials involved in the work are passed to the model provider and through it to third-party compute suppliers on whose capacity the model is hosted; their list for each model is available in the provider’s catalogue and is provided by the Contractor at the organisation owner’s request. The model provider and such suppliers are located outside the Russian Federation; cross-border transfer is carried out by the Contractor in compliance with Article 12 of Federal Law No. 152-FZ. The model provider and compute suppliers may temporarily store the requests and responses passed to them in accordance with their policies; the Contractor provides the current storage terms at the organisation owner’s request. The Contractor selects providers and models that do not use the data passed to them for training, and does not itself use client data to train models on any plan.

8.4. On dedicated capacity outside the Russian Federation, the model runs on a machine rented by the Contractor from a third-party hosting provider outside the Russian Federation; the content of repository files and texts of tasks and questions are passed to it as part of requests to the model for the duration of the work, and the mirror is not placed on it; after shutdown the machine is released, and the Contractor keeps no data on it; the hosting provider has physical access to the machine. These materials are not passed to the model provider. On dedicated capacity in the Russian jurisdiction and in a separate environment, the client’s materials do not leave the Russian Federation and are not passed to the model provider.

8.5. The Contractor’s staff do not view the client’s code and materials without a request from the client. On request, access is granted narrowly to resolve the matter and revoked once it is closed. Exceptions: technical operations on storage without viewing the content (backup, recovery after a failure); investigating an incident (clause 8.8) and checking a breach of clause 9.1 — in both cases with notice to the organisation owner of the fact of and grounds for access no later than 3 business days later; cases provided for by law.

8.6. The client undertakes not to include personal data in the code, tasks, questions and other materials passed to the service, except for the names and work email addresses of change authors in the repository history and the display names of request authors passed under clause 8.10, and not to pass secrets (passwords, keys, tokens) through the service, except for the repository access token passed in the manner of clause 4.1; the client is responsible for secrets contained in the repository history. The client warrants that it has a lawful basis for the Contractor’s processing of the names and work email addresses of change authors from the repository history, including their transfer outside the Russian Federation and processing by the model on the plan chosen by the client (clauses 8.3, 8.4), and that it has notified these persons. The client is responsible for what the materials passed contain; the Contractor does not check their content and processes them as the client’s code and working materials.

8.7. At the written request of the organisation owner, the Contractor deletes, in full or for individual repositories, the organisation’s mirrors, tasks, analyses, research and other working materials within 30 days of the date of the request, and from backups — within 90 days. Information about payments and charges, closing documents and data whose retention is required by law are kept for the periods established by law. The request is sent to the address given on the Contacts page from the organisation owner’s email address.

8.8. The Contractor notifies the organisation owner by email of an incident that led to unauthorised access to the organisation’s materials no later than 72 hours from the moment it learned of it, describing the data affected and the measures taken.

8.9. Users’ personal data (email address, login, information about actions in the service) is processed by the Contractor on the basis of Article 6(1)(5) of Federal Law No. 152-FZ — to conclude and perform this contract, including the contract the user joined (clause 3.5) — in accordance with the Personal Data Processing Policy, which forms part of this agreement. The Contractor processes the names and work email addresses of change authors contained in the history of connected repositories as part of the client’s code to perform the contract with the client on the basis of Article 6(1)(7) of Federal Law No. 152-FZ, to the extent and for the purposes of clause 7.2. For purposes that require consent, it is requested separately.

8.10. When working through integrations (section 10), only what is needed to carry out a request is passed to the service from the client system: the text of the request to the bot, the title, address and identifier of the ticket (task, page), the display name of the request’s author, and for a request in a pull request discussion — the repository and branch name. The rest of the content of tickets, pages and discussions is not passed to the service in advance and is not indexed: the connector reads it in the client’s network on request, to the extent needed for the specific work, and what has been read is processed as part of the client’s materials (clauses 8.2, 8.3, 8.4). Credentials for client systems are not passed to the Contractor. The display name of the request’s author is included in the text of the task draft created from the request and is then processed as part of the client’s materials (clauses 8.3, 8.4). The connector status report shown in the web application (the list of connections, their integrations and versions, status, the list of tools and allowed addresses, information about tool calls) does not contain credential values. The client warrants that it has a lawful basis for the Contractor’s processing of the display names of request authors, including their transfer outside the Russian Federation and processing by the model on the plan chosen by the client (clauses 8.3, 8.4), and that it has notified these persons.

8.11. When a user works in Buff Code, the Contractor keeps in full every request to the model and the response to it — the development session: the text of the request, including the materials and tool results passed in it, the model’s response, as well as the user’s login, their device name, the organisation, the project, the model, the time, the amount of model work and the amount charged. Development sessions are the client’s working materials: they are passed and stored under clauses 8.2–8.4 and deleted under clause 8.7. A user sees their own development sessions, and the organisation owner sees the sessions of all users of the organisation; every viewing of another user’s session and every export is recorded in the organisation’s audit log. The client informs users working in Buff Code of this recording.

9. Restrictions on use

9.1. The client is prohibited from:

• connecting repositories and passing materials that the client has no right to pass;
• using the service to create malicious code, means of unauthorised access or for other unlawful activity;
• attempting to circumvent the service’s restrictions or to gain access to the data of other organisations or to the Contractor’s infrastructure;
• reselling access to the service or providing it to third parties outside its organisation;
• creating load aimed at disrupting the service.

9.2. In case of a breach of clause 9.1, the Contractor may suspend the organisation’s access until the breach is remedied, notifying the organisation owner by email; dedicated capacity is shut down for the period of suspension. The unspent balance is refunded on the client’s application under the rules of clause 5.7. The Contractor may withhold from the balance the amount of documented losses caused by the breach, sending the organisation owner a calculation; a dispute about the withholding is resolved in the manner of section 13. Withholding does not apply to clients who are individuals using the service for personal needs; losses are recovered in the manner established by law.

10. Connector

10.1. The Contractor grants the client a simple (non-exclusive) royalty-free licence to use the connector and the integrations installed in it throughout the world for the term of the contract for the sole purpose of connecting the client’s repositories and other systems to the service.

10.2. The client may not modify, decompile or distribute the connector and integrations outside its network, except in cases expressly permitted by law, nor use them to connect to other services.

10.3. The connector is installed and maintained by the client in its network and runs on the client’s equipment. Repository access tokens and connection credentials remain in the connector and are not passed to the Contractor. The client is responsible for keeping the connector’s credentials and configuration safe.

10.4. The client can verify the authenticity of the downloaded connector using the checksum and signature published with it, and can revoke the connector in the web application at any time.

10.5. The connector installs integrations from the Contractor’s catalogue on the client’s instruction: without installing an integration no connection is created, and the connector by itself does not install integrations or replace their versions. Before installation, the catalogue declares the information on which the client makes its decision: the rule defining the addresses, methods and paths the integration will be able to contact; the type and purpose of the credentials required; whether the integration accepts webhooks; the list of its tools, indicating which of them only read. Each version of an integration is signed by the Contractor, and the connector verifies the signature before installation. Moving a connection to a new version of an integration is done at the client’s decision.

10.6. An integration runs on the client’s equipment as a separate process under a separate operating system user, and does not receive the connector’s key, credential values or the data of other connections; outgoing requests to the client system are made by the connector, which inserts the credentials and checks the address against the declared rule. For this separation, the connector needs the corresponding rights in the client’s operating system; if it does not have them, integrations do not start, while repository connections keep working. The client provides the conditions for the connector to work on its equipment and is responsible for the environment in which it runs, including network restrictions the client considers necessary in addition to those described in this clause.

10.7. For each connection, the client determines the credentials, the rights of the account under which the integration works in its system, and the scope. The client is responsible for the extent of these rights and for what materials become available to the service within the scope, as well as for notifying the persons whose requests are passed in the manner of clause 8.10.

10.8. The Contractor may mark a version of an integration as revoked, including when an error or vulnerability is found in it. Installing a revoked version becomes unavailable; a connection already running on such a version is not switched off by the Contractor — the connector marks it as running on a revoked version in its interface and in the web application, and the client decides whether to move to another version or to stop the connection. The Contractor is not liable for the consequences of a connection continuing to run on a revoked version after the revocation has become available to the client.

10.9. For Buff Code to work, the client may turn on the developer gateway in the connector. The client issues and installs the certificate for the secure connection to the gateway itself; the Contractor does not issue certificates for users’ computers and adds nothing to the certificate stores of their operating systems. Buff Code gets access to the service only through the client’s connector gateway and only after the user has confirmed the sign-in in the web application; the user can revoke a confirmed device at any time.

10.10. In Buff Code, the model has access to the tools of all of the connector’s connections, including tools that change data in client systems; a call is made on behalf of the user and recorded in the connector’s call log. The client determines which connections exist and the rights of their accounts (clause 10.7).

11. Liability

11.1. The parties are liable in accordance with the legislation of the Russian Federation, subject to the limitations of this section.

11.2. The Contractor’s aggregate liability under the contract is limited to the amount charged to the client organisation’s balance over the three months preceding the event giving rise to the claim, but no less than the amount the client paid into the balance over the same period. Lost profits are not compensated.

11.3. The Contractor is not liable for losses caused by the actions of the client and its users, by merging and using the result (section 6), by unavailability of the client’s platforms and systems, including those connected through the connector (section 10), of the model provider and of the hosting provider (clauses 8.3, 8.4), or by force majeure.

11.4. The Contractor strives to keep the service available around the clock but does not guarantee the absence of interruptions. The Contractor gives notice of planned maintenance at least 24 hours in advance in the web application or by email. Support requests are accepted at the email address given on the Contacts page and are handled on business days.

11.5. The limitations and exclusions of liability provided for by the agreement (including clauses 4.3, 4.4, 4.5, 4.6, 5.8, 6.2, 6.4, 9.2, 11.2, 11.3 and the rule of clause 4.2 on charging when work is stopped) do not apply to liability that cannot be limited by law, including towards clients who are individuals using the service for personal needs, or to liability for an intentional breach.

12. Term, amendment and termination

12.1. The contract is concluded for an indefinite term.

12.2. The Contractor may amend this agreement and the plans. A new edition of the agreement or the plans is published at the address of the current edition, stating the date it takes effect, no less than 10 days before that date. Publication of a new edition constitutes notice to the client of the changes. Work done before the changes take effect is paid for on the previous terms. Using the service after the new edition takes effect means the client accepts it; for clients who are individuals using the service for personal needs, the new edition of the text of the agreement applies after it is accepted in the web application; until it is accepted, the client uses the service on the previous terms or terminates the contract (clause 12.3). Prices apply to each piece of work under clause 5.3: before the work is started, the current price is shown in the web application (the “Billing” section), and starting the work means agreement with the price applied under clause 5.3. The 10-day period does not apply to the prices of individual models on a plan where the client chooses the model (clause 5.3).

12.3. A client that does not agree with the changes may terminate the contract before they take effect. The unspent balance is refunded under the rules of clause 5.7.

12.4. The client may terminate the contract in respect of an organisation at any time by sending a request from the email address of that organisation’s owner. The Contractor may terminate the contract in case of a material breach of the agreement by the client, notifying the organisation owner 10 days in advance, and also without giving a reason, notifying at least 30 days in advance and refunding the unspent balance under the rules of clause 5.7. The right to terminate the contract without giving a reason does not apply to clients who are individuals using the service for personal needs; the Contractor may terminate the contract with such clients only in case of a material breach of the agreement or in cases provided for by law.

12.5. On termination, the Contractor refunds the unspent balance under the rules of clause 5.7 and deletes the organisation’s working materials at the client’s request (clause 8.7). Before deletion, the client may export answers, research and analyses using the web application. Materials the client has not asked to delete are deleted by the Contractor 90 days after the date of termination, and from backups — within the following 90 days; data with a retention period established by law is kept for that period.

13. Dispute resolution

13.1. Before going to court, a party sends the other party a claim by email. The period for replying to a claim is 15 days from the date of receipt. For clients who are individuals using the service for personal needs, the claim procedure is optional.

13.2. Disputes with clients that are legal entities and sole proprietors are heard by the commercial (arbitrazh) court at the Contractor’s location (if the Contractor is a sole proprietor — at their place of residence) under the law of the Russian Federation.

13.3. Disputes with clients who are individuals using the service for personal needs are heard in the manner established by consumer protection legislation.

13.4. Other disputes with clients who are individuals are heard by a court of general jurisdiction at the Contractor’s location or, if the Contractor is a sole proprietor, at their place of residence (Article 32 of the Civil Procedure Code of the Russian Federation).

14. Other terms

14.1. The contract is governed by the law of the Russian Federation.

14.2. The parties recognise the legal force of messages sent from the organisation owner’s email address, the address provided under clause 3.3 and the address given on the Contacts page, as well as actions performed in the web application after a sign-in confirmed by a code. A client that is a legal entity or sole proprietor may also send applications under clauses 5.7, 8.7 and 12.4 from the address given when providing the information under clause 3.3, signed by an authorised person; in this case the Contractor may ask for confirmation of authority. From the same address, signed by an authorised person, the client may request that the organisation owner role be transferred to another user, including when the owner has lost access; the Contractor carries out the request within 3 business days after authority is confirmed.

14.3. If any provision of the agreement is held invalid, the remaining provisions remain in force.

14.4. For clients with whom the Contractor has concluded a separate contract, the terms of that contract take precedence over this agreement.

14.5. Periods in hours and days are calculated in Moscow time; periods in days are calendar days unless “business” is specified; business days are determined by the production calendar of the Russian Federation. The current edition of the agreement and, in the period before it takes effect, the new edition are available at the address of this page; the date of the edition is shown in its heading.