Terms of Service

GISweaver Master Terms of Service & Subscription Agreement

Last Updated & Effective Date: 14 October 2026
Document Version: 2026-10-14
Operating Entity: Alons Advanced Technologies Private Limited ("Alonstech", "Company", "we", "us", or "our")
Product: GISweaver Platform (gisweaver.com, app.in.gisweaver.com, admin.gisweaver.com)
Applicable Cell / Region: India Data Plane (in-mumbai-1, AWS Mumbai), the one cell GISweaver operates

1. Introduction, Legal Capacity & Formation of Agreement

1.1. Contractual Relationship. This Master Terms of Service and Subscription Agreement ("Terms", "Agreement") constitutes a legally binding contract between Alons Advanced Technologies Private Limited (a private limited company incorporated under the Companies Act, 2013, with its registered office in Kerala, India, hereinafter referred to as "Alonstech") and the entity, organisation, sole proprietorship, partnership, or professional individual accessing or using the GISweaver platform ("Customer", "Organisation", "You", or "Your").

1.2. Product Description. GISweaver is a proprietary, sovereign, high-performance geospatial workspace, delivery and spatial analysis Software-as-a-Service (SaaS) platform (collectively, the "Service" or "Platform"). It is built for organisations and independent professionals who create, coordinate, measure, analyse, verify or deliver location-aware and technical work — including, by way of non-exhaustive example, cadastral and land surveyors, drone and aerial mapping firms, civil and structural engineering consultants, infrastructure and utility contractors, architectural and planning practices, mining and quarrying operations, environmental and agricultural assessors, and the project offices that commission and receive such work.

1.3. Authority to Bind. If you are accepting these Terms on behalf of a company, corporate enterprise, partnership, government body, or other legal entity, you represent, warrant, and covenant that you possess full legal power and statutory authority to bind such entity to these Terms. If you do not possess such authority, or if you do not agree with each provision set forth herein, you must immediately refrain from creating an account, uploading spatial data, or accessing the Service.

1.4. Electronic Contract Formation. In accordance with the Information Technology Act, 2000 (as amended) and the Indian Contract Act, 1872, this Agreement is an electronic record generated by a computer system and does not require physical or digital signatures. By clicking "I Agree", checking a registration consent box, signing in via verified credentials, provisioning an organisation workspace, or submitting any spatial dataset into the quarantine upload gateway, you signify your unreserved assent to these Terms.

1.5. Age & Professional Requirement. The Platform is strictly a business-to-business (B2B) and professional commercial workspace. You affirm that all individual users operating under your organisation are at least eighteen (18) years of age and legally competent to enter into a valid contract under Indian law.

1.6. The Platform Is in Beta. GISweaver is offered as a beta service, and the Platform says so beside its name in its own header. These Terms describe what the Platform does on their effective date. The beta affects them in the following respects, and in no other:

• Features may change or be withdrawn. Alonstech makes capabilities available as they are built, and may change any capability described in these Terms, restrict it to particular plans, or withdraw it. A change or withdrawal never deletes or degrades Customer Data: what an Organisation made with a capability stays stored, readable and exportable under Section 5. A change to these Terms themselves is governed by the paragraph "These Terms may be changed during the beta" below and by Section 17.1.

• No service level is offered. During the beta Alonstech gives no availability commitment, no support response time and no service credit for any interruption. Section 10 states what Alonstech aims for and how the Platform is run; it is not a service level agreement.

• Support is what the Platform provides. Any Organisation may write to support@gisweaver.com. An Organisation whose plan includes support tickets may also open a ticket in the Platform's Help section, and Alonstech replies in the ticket and by email. A plan that includes priority support has its tickets placed ahead of others in Alonstech's queue; that is not a response time either.

• These Terms may be changed during the beta. While the Platform is in beta, Alonstech may change these Terms at any time; the version published on this page, with its date, is the one in force, and the notice period of Section 17.1 applies from the day Alonstech declares GISweaver generally available. Such a change does not loosen the commitments in the paragraph "Data handling is not relaxed" below or the data-location rules of Sections 1.7 and 6.3, and an amount already paid is governed by the Terms in force when it was paid.

• Data handling is not relaxed. Tenant isolation (Section 2.4), the immutability of published releases (Section 3.3), the non-destruction commitment (Section 5), the India data plane (Section 6.3) and the Privacy Policy apply in full during the beta, and so does Section 3.1's statement that uploads are not scanned for malware.

• Payments may run in test mode. During the beta the Platform's checkout may run in the payment provider's test mode, and when it does the checkout says so beside the amount ("Test — no real money moves"). In test mode no real payment is taken and nothing is charged to anyone. Completing a test checkout nevertheless starts the chosen plan as a paid purchase would, and the Platform issues a specimen for it instead of a tax invoice: a document headed and stamped as a specimen of a test payment, numbered in a series of its own (prefixed TS, and TSCN for a credit note against one) apart from the series of Section 4.3, which says in its own words that it is not a tax invoice, and which it sends by email, as it sends an invoice for a real payment. Once Alonstech switches the checkout to live payments, a paid plan is charged, invoiced, renewed and cancelled as Section 4 states.

1.7. Data Residency. GISweaver operates one cell today, the India Data Plane (in-mumbai-1, AWS Mumbai). All customer survey data, compute workloads, and database operations reside strictly within sovereign Indian territory in AWS Mumbai (ap-south-1); backups of the database and of stored files are copied to AWS Hyderabad (ap-south-2), also within India, and no copy leaves India. All processing adheres to Indian law — including the Digital Personal Data Protection Act, 2023, the Information Technology Act, 2000, and the National Geospatial Guidelines — and disputes are subject to exclusive resolution in Ernakulam / Kochi, Kerala (Section 16). If Alonstech later operates a data plane in another region, workspaces created there will be governed by a schedule for that region, and these Terms will be amended before that happens.

2. Platform Architecture, Identity & Multi-Tenant Hierarchy

2.1. Tenancy Hierarchy & Scoping. GISweaver enforces a strict hierarchical tenancy model structured as follows:

• Organisation: The overarching legal entity and billing tenant.

• Branches: Regional or divisional operating units within the Organisation (e.g., Headquarters, regional branch offices).

• Projects: Discrete survey assignments, tender jobs, or geographic work packages bound to a specific Branch.

• Releases & Artifacts: Versioned, immutable survey deliverables, raw spatial files, 2D/3D tile sets, CAD vector layers, elevation models, and project documentation.

2.2. Role-Based Access Control (RBAC) & Delegated Grants. Access within the Customer workspace is governed by explicit roles granted at one of three scopes. Every role GISweaver provides is named below. An Organisation may also define its own roles from them, as "The Organisation's own roles" below states; those are described in words, not named here.

Organisation scope:

• owner: Ultimate administrative and commercial authority over the Organisation, including billing, plan modifications, branch creation, and account ownership transfer. Exactly one Owner is maintained per Organisation, enforced by the database.

• admin: Every capability of the Owner except those the Owner alone holds: transferring ownership, closing the Organisation's account, requesting its erasure (Section 5.3), exporting the Organisation's records as a whole, retiring the files of a delivered release (Section 3.5), and reading and correcting its data custody record.

• billing: Buys and upgrades the plan at checkout, applies promotional codes, and keeps the billing identity the invoices carry — the GSTIN, the billing address and the billing email. Reads the Organisation's invoices, payments, members, branches and client directory. Reads, downloads and exports every project, its survey data included, and changes none of it; takes part in every project's conversations. Cancelling a paid subscription is for the Owner or an Administrator (Section 4.5).

• auditor: Reads everything in the Organisation — every project, the audit trail and every project's conversations — and changes nothing: it writes in no conversation.

• member: The base membership row. On its own it lets a person see the Organisation itself — its name and contact card, its plan, the settings every member works under, its connected Organisations and contact persons, and its referral code — and open a support ticket in its name where the plan includes support tickets. It opens no project: membership of the company does not by itself let a person see its work.

Branch scope: manager, member, viewer.

Project scope: lead, contributor, viewer.

• Conversations. Whoever may open a project may also take part in its conversations where the plan includes "Notes and comments": write and answer in them, whether or not they may change the project's data, and be named in them where the plan also includes "Mentions". That is the owner, admin and billing roles across the Organisation, and every branch and project role, the viewer included. The auditor reads every conversation and writes in none, unless the same person also holds another role that writes in them.

• A plan without "Roles and permissions". If your plan no longer includes roles and permissions, the roles and limits you set keep applying; you can still review and remove access, but not create new roles. A plan never gives anyone more access than their roles do. Where, before 9 October 2026, an Organisation's plan made every member act as an administrator, each member, billing person and auditor was given on that day a role recorded as coming from the former plan that allows exactly what the plan allowed them (for an auditor, without taking part in project conversations), without changing their own role or the roles they may give to others, so that nothing changed for them; the Owner was notified, and each such role can be ended like any other.

• Access administration. Two further roles administer access, and a person is named to them rather than holding them as their membership: access_administrator, held across the Organisation (an Access administrator) or over one branch (a Branch access administrator), and emergency_access. The Owner holds every authority they carry, is never named to one, and is the only person who may name an Access administrator or a holder of emergency_access; the Owner or an Access administrator may name a Branch access administrator. An Access administrator may give the branch roles of every branch, up to manager, and approve changes others asked for; a Branch access administrator may give the roles of their branch, up to manager; neither may give anyone a role across the Organisation. Nobody names themselves. Naming an administrator is a sensitive change. Changes to access that your organisation marks as sensitive need a second access administrator's approval. Where the Organisation has two or more access administrators, the Owner included, such a change waits until another access administrator approves it, and nobody approves or rejects a change they asked for or one that names them; where it has one, the change needs emergency access and is recorded as an emergency override, never as an approval. Emergency access needs a fresh sign-in, a reason and an expiry, and everyone who administers access is told. It may be used by the Owner and by members the Owner names, lasts four hours unless a shorter or longer period of at most twenty-four hours is chosen, can be ended early, and never reaches what the Owner alone holds. Ending an administration role takes effect at once. Every request, decision, naming, ending and use of emergency access is written to the Organisation's audit trail, and the people concerned are notified.

• The Organisation's own roles. Where the Platform makes it available to an Organisation (during the beta, to the Organisations taking part in testing it), the Organisation may define its own roles from the roles we provide, by choosing groups of permissions we describe, leaving out any permission it chooses with a stated reason, and saying where each role may be held: across the Organisation, over a branch or on a project. A person may hold more than one role and may do what any of them allows; a role held over a branch or on a project allows there only what acts there. A role an Organisation defines never carries what the Owner alone holds, transferring ownership included, nor administering access (giving roles, naming access administrators, approving changes, using emergency access, or editing roles, permission groups and policies), nor anything reserved to Alonstech's staff. Roles and permission groups are edited by the Owner and Access administrators. Such a role is given by the Owner or an Access administrator, or by a Branch access administrator over their branch where it carries nothing beyond a branch manager there; nobody gives themselves one, and the Owner is never given one. It may be given until a date, and ends on it. Giving a role that carries a sensitive permission across the Organisation, or changing a role so that it allows more to the person changing it or gives someone who holds it across the Organisation a sensitive permission, is a sensitive change; narrowing or ending one applies at once. Every definition, change, giving and ending is written to the Organisation's audit trail with its reason.

• Organisation policies. Where the Platform makes them available to an Organisation, as for its own roles, the Organisation may set policies that only ever take access away, never give it: no new share of a project with another Organisation and no new client review invitation, across the Organisation or for projects it names, what was already shared working until it is ended and ending it never being refused (deliveries are not affected); a confidential project, which only the people given a role on the project, and where the Organisation chooses also those given one over its branch, can open, roles held across the Organisation, the Owner's included, reaching it only while their holder has emergency access switched on; downloads of a project's originals and exports limited to the roles the Organisation names, or refused to people whose access to the project comes only from a role on the project, the Owner never being refused; and a fresh sign-in, with two-step and the password where the account has one, before sensitive work (such as inviting people, managing members, managing billing, reading the audit trail, lending a role, giving roles, approving access changes, and editing roles, permission groups and policies), which lasts eight hours for the session it was made in. Policies are set by the Owner and Access administrators, and every change is written to the Organisation's audit trail with its reason.

• Delegated grants. Where the plan includes "Delegated access", a person who may lend a role — the Owner, an Administrator and the billing role across the Organisation, a branch manager over their branch, and a project lead over their project — may lend another member of the Organisation who is not suspended a role at or below their own at that scope, never the Owner's, and only one whose every capability they hold, by their own roles or, for a role lent out of a borrowed one, by that loan, with a stated reason, until a date no more than ninety (90) days ahead. Across the Organisation the role lent is the billing or auditor role (the administrator's role is not lent across the Organisation; one lent before 10 October 2026 runs until it ends), so the billing role lends the billing role and not the auditor's; over a branch or a project it is any role of that scope. A role lent out of a borrowed one ends no later than the loan it came from. A borrowed role does to other people's roles what the lent role does, lowering, suspending or removing them included, but it cannot give anyone a lasting role above the one its holder has without the loan. A loan ends on its date; when its lender, or anyone who may lend at that scope, withdraws it; when its lender no longer holds by their own roles everything they lent; when its lender or its holder is no longer a member of the Organisation, and it does not return if either rejoins or regains a role; and when the plan stops including "Delegated access". While its lender or its holder is suspended a loan grants nothing, and it applies again on their reactivation if its date has not passed. A loan that ends ends every loan made out of it; withdrawing a loan needs no plan feature. A role the Organisation defined may be lent in the same way, for at most ninety (90) days, at a scope where it may be held, by a person who holds everything it carries; a loan of it never carries more than the role carried when it was lent, nor more than it carries now. Making and withdrawing a loan, and every other way a loan ends, are written to the Organisation's audit trail.

• Alonstech staff access. Where an Alonstech operator assumes an Organisation for support or administration, which requires a stated reason, that operator receives the admin capability set less eighteen withheld capabilities: transfer of ownership, upload creation, work-layer writing, taking part in conversations, billing management, client management, invitation, delegation, archiving a branch, archiving a project, sharing a release with another Organisation, making a delivery, receiving a delivery, issuing, changing or withdrawing a client's access, taking part in a direct conversation, managing a private group (Section 3.7), managing checklist templates, and ticking a checklist step; roles an Organisation defines never widen it, and the Organisation's policies do not restrict it: an operator may open a confidential project to give the support asked for. Every such assumption is written to a separate staff audit trail, and to the Organisation's own audit trail as well. Alonstech's staff reach the staff console only through Cloudflare's access gate (Section 6.3), and then sign in with their own password or a sign-in link sent to their email address, and a code from their second factor; an operator who has not yet set up a second factor can do nothing in the staff console but set one up, change their password or sign out.

2.3. Session & Credential Security.

• Every sign-in is identified by a random, opaque token held in a browser cookie that page scripts cannot read and that the browser does not send on requests made from other sites. Alonstech keeps only a one-way hash of each token, so a copy of our records does not yield a usable session. Every change made through the browser is additionally protected against cross-site request forgery. The cookies GISweaver sets, and their attributes, are listed in full in Section 14 of the Privacy Policy.

• Password credentials are salted and hashed — never encrypted, and never recoverable — using the memory-hard Argon2id key derivation function with a cryptographically random per-password salt. Multi-Factor Authentication (MFA / TOTP) with replay guards is available and strongly recommended for all administrative accounts.

• The Customer is solely responsible for maintaining the confidentiality of user login credentials and for all activities that occur under its authorised accounts. Customer must immediately notify Alonstech upon discovering any unauthorised access, credential compromise, or security incident.

2.4. Tenant Isolation in the Database. Customer acknowledges that all spatial records, metadata, project hierarchies and memberships are isolated per Organisation inside the database itself, by rules the database engine applies to every query regardless of which part of the application issued it. No account the running Platform uses is able to switch those rules off. A request for a record that belongs to another Organisation is answered exactly as a request for a record that does not exist, so that neither the record nor its existence is disclosed.

3. Scope of Services & Workspace Operations

3.1. Spatial Intake, Validation & the Pilot Scanning Posture.

• Accepted formats, and where a file goes. A project accepts uncompressed LiDAR point clouds (.las), GeoJSON, ASCII DXF, TIFF rasters (.tif, .tiff) including GeoTIFF, PDF, ZIP archives, photographs in PNG, JPEG, WebP, and HEIC or HEIF, and video in MP4 and MOV (as a phone or camera records it). Files are identified by their content — their leading bytes — and never by their filename or extension; a file whose content is not one of the accepted formats is refused at intake. A point cloud, GeoJSON, DXF, TIFF, PDF or ZIP archive added to a project's files joins the project's open draft, and a photograph or a video added there is kept with the project's files instead. The files kept with a project accept PDF, ZIP archives, GeoJSON, ASCII DXF, photographs and video, and keep them with the project outside any release. A file sent to a project without naming either is filed by its content: a point cloud, GeoJSON, DXF or TIFF joins the open draft, or, while the project has no open draft, is kept and joins the next draft when someone starts one; and a PDF, an archive, a photograph or a video is kept with the project, up to 1 GiB. No upload becomes a release by itself: a release is made only by publishing a draft.

• Links kept with a project. A project may also keep links: a web address beginning http:// or https://, without a user name or password in it, and a name the Customer gives it, listed with the project's files. A link is not an upload. The Platform stores the address and its name and nothing else; it does not fetch, open, scan or copy what the address points to, does not count a link against any plan limit, and never draws a link on the map or includes it in a release. Every member who can read the project sees the address and may open it in their own browser, where what it points to is governed by whoever operates that address and not by this Agreement. A link is discussed, renamed, deleted and restored as a file kept with the project is; a permanent deletion removes the address and the link's threads, and the audit record keeps its name and website but not the address.

• Formats not accepted today. LASzip-compressed point clouds (.laz) are not accepted: a compressed file's internal structure cannot be validated, and the uncompressed LAS must be supplied instead. ESRI Shapefiles other than as entries within an accepted archive, and OGC 3D Tiles, are likewise not accepted intake formats at present. Alonstech makes no commitment as to when, or whether, any further format will be accepted.

• What is verified. Every upload is verified against the SHA-256 checksum declared by the Customer's browser before transfer, and a mismatch is refused. LAS, ZIP, GeoJSON, DXF and TIFF then undergo structural validation appropriate to the format; archives are metered against entry-count and total-expansion limits, path traversal is refused, and an archive that contains another ZIP archive is refused outright. PDF, PNG, JPEG, WebP, HEIC, MP4 and MOV are identified by format only and receive no structural validation. A photograph kept with the project is then prepared before it is recorded, according to the Organisation's photo setting (Console → Settings → Organisation → Photos): it is turned the right way up; a HEIC, HEIF or WebP is converted to a JPEG; and, unless the Organisation keeps photographs at full quality, a photograph larger than 2,560 pixels on its longest side is reduced to that size as a JPEG at quality 85. A PNG or JPEG kept at its own size keeps its pixels and has its embedded metadata removed; a converted photograph is a new image made from its pixels. Either way only the prepared copy is served, and the file as uploaded is kept with the Organisation's other uploads and is not served. Two facts are read from the embedded metadata before it is removed — the position at which the photograph was taken and the time of capture, where the camera recorded them — and are kept with the file and shown to the Organisation's members beside it. A photograph that cannot be opened is refused. A video is kept exactly as uploaded: it is not converted, reduced or stripped of its embedded metadata, so any position or time the camera recorded in it stays in the file and is served as uploaded to those who can open the project; it is played with the viewing browser's own player.

• Malware scanning is presently suspended, and we state so rather than imply otherwise. No antivirus scanner is installed on any GISweaver host, and malware scanning of archives and PDFs is suspended for the pilot. The original basis of that decision was containment: no path existed by which a source file uploaded into an Organisation could reach anyone outside that Organisation's membership chain. That is no longer absolute, and the condition below has consequently been triggered. An Organisation sharing a release under Section 3.4 may now permit the recipient Organisation to download the release archive, which contains the files the sharing Organisation uploaded. Scanning is therefore owed on the earlier of (a) the day any capability ships by which a source artifact can reach a recipient outside the uploading Organisation — which the release download of Section 3.4 is, and which shipped with it — and (b) 30 November 2026.

• What stands in the place of scanning until it is in force, stated plainly rather than implied. Scanning is not yet in force and this Agreement does not represent that it is. Until it is, and no later than the backstop above, the following are what the Platform actually does about the exposure that download creates, each of them enforced by the Platform rather than promised:

  • The download is off unless the Organisation that uploaded the files switches it on, per grant, and that Organisation alone decides it. The control that sets it carries the unscanned-content notice below whichever way it is set, so the choice is never made without it; and the uploading Organisation may switch it off for that grant after making it, with immediate effect.

  • It is bounded and reversible on the same terms as every other grant: named recipient, named layers, stated expiry, withdrawable at any time with immediate effect.

  • Each download is recorded in the sharing Organisation's own audit trail, naming the recipient Organisation and the grant, and appears in that Organisation's chain-of-custody record.

  • Before the archive is downloaded, the recipient is shown a notice that the files were uploaded by another Organisation and are not scanned for malware.

  • A PDF, an uploaded ZIP archive, and an original whose type the Platform does not recognise or whose name does not match its content are not handed to another Organisation by any route — a share, a delivery, a client review, a grant of access, or a copy into the other Organisation's project — even where the download is allowed: the other Organisation is told that the file cannot be transferred and is referred to the Organisation that sent it, and a download of an archive that would contain such a file is refused in the same way. This is containment, not a malware scan, and no other file is represented to be free of malware.

• Notice before choosing a file. The following notice is shown on a project's page, under a "What is checked" disclosure beside the one-line statement that files are checked for type and integrity and not for malware, directly under the upload control through which every file is added to the project (the strip at the top of its Files list), before a file is chosen rather than after one is refused. It is not yet shown beside the upload control on the map:

  During the pilot, files are checked for type and upload integrity. ZIP archives are also checked for structure; a PDF receives file-type identification and checksum checks only. Files are not scanned for malware. They can be downloaded by members of your organisation, by another organisation you deliver a release to, and by another organisation you share a release with or invite to review where you allow the download. Please do not upload a file you received from someone else and have not checked yourself.

• Quarantine. On GISweaver "quarantine" is a recorded verdict rather than a separate storage system. A file that fails checksum verification, format identification or structural validation is marked quarantined and is not promoted into an authoritative release. Where the file was added through the project's upload control, the uploader, while still a member, and the Organisation's Owner and Administrators are told by email, and Alonstech's operations receive a notice naming only identifiers; a file that replaces another file of the draft, or that a client reviewer adds, is marked quarantined without either. Validation is performed by the Platform itself, inside the India cell, and by no outside service.

3.2. 2D & 3D Spatial Computing & Analysis. The Platform provides browser-based spatial computing, including:

• 2D and 3D map viewports powered by OpenLayers and self-hosted CesiumJS, with the camera position shared between them.

• Coordinate reference systems. Each project records one native coordinate reference system. A delivered vector layer is stored in that system and in WGS 84 for display; a point cloud is tiled in Earth-centred coordinates (EPSG:4978); an elevation grid is resampled onto a WGS 84 lattice. A DXF file names no coordinate system and is read in the project's, and is refused where it falls outside that system's area of use. A GeoJSON file that names no coordinate system is read as WGS 84. A LAS file whose declared horizontal coordinate system differs from the project's is kept as a source artifact and no point-cloud tiles are made from it, with the reason recorded; a LAS file that declares none is read in the project's. A TIFF that declares a system other than the project's is kept as a source artifact and no elevation grid is made from it.

• A dedicated Work Layer, in which measurements, elevation profiles, volume results, annotations, markers and design objects drawn over a delivery are stored separately from, and never alter, the survey record beneath them. Work-layer objects are revisioned.

• Exact measurements. A point, distance, area or profile in the Work Layer may be stated as typed coordinates in a named coordinate reference system, with each vertex's height and its source recorded. Each save of such a measurement is kept as an immutable version; a version's figures (grid distance, grid-plan area, geodesic distance, slope length) are computed by the Platform from the recorded vertices, never taken from the Customer's browser, and the version records the calculation used and any qualification of it. Where a figure cannot be computed the version says so and states why; no figure is ever an assumed value. A height a browser reads from a delivered elevation grid is recorded as the browser's reading and is marked as such. The Platform's arithmetic is exact on the recorded vertices and says nothing about how accurately the survey itself was captured. At present exact measurements are qualified for EPSG:32643 and WGS 84 only.

• Corridor review. An alignment — a polyline of straight segments entered in EPSG:32643 — may be kept in the Work Layer, and each save of it is kept as an immutable version; reversing an alignment is a new version. Chainage is grid-plan distance along the alignment, an offset is signed positive to the right of the direction of travel, and stations are placed by the interval and endpoint rule the version records. A curved segment is refused rather than flattened. A cross-section at a station is a resampled-grid section computed by the Platform from the elevation grid of a published release: it is not a point-cloud section, a sample any of whose neighbouring grid heights is missing is shown as a gap and never filled, and vertical exaggeration changes only how the section is drawn. Creating, changing and reversing alignments is available to every Organisation during the current period; a future plan may leave it out, and alignments already made remain readable either way.

• Survey file exports. Exact measurements, chosen from the Work Layer or as pinned by a published survey release, may be exported as DXF, GeoJSON or a profile CSV. The files are written by the Platform from the versions' recorded coordinates, and a DXF or CSV is refused for a measurement that has no projected coordinates rather than projected by the exporter. An issued export is stored with the SHA-256 checksum of each file and never changes: asking again for the same export returns the stored files. Issued exports are kept with the Work Layer they were made from, and are removed only when the Organisation is erased in full under Section 5.3. Each Organisation may issue exports at up to twelve (12) a minute, with a burst of six (6), on each server that answers it, and may hold at most 2,000 issued exports and 2 GiB of export files. That is a fixed platform ceiling, the same for every Organisation and every plan; it is not a plan feature, it is not raised for any one Organisation, and it does not limit the release export, sign-in, read or download rights of Section 5. An Organisation at the ceiling can still download every export it holds. Issuing an export is a change to the workspace and is not available while the workspace is suspended, frozen or closed; downloading an export the Organisation holds is a read and remains available. Where a review grant allows downloading, the receiving Organisation may export a published release it was sent, unless a measurement in that release refers to a record it was not sent, in which case the export is refused whole. While the sending Organisation is suspended or closed, the receiving Organisation can neither make a new export under the grant nor download the files of one already made. Each such export, and each file of it the receiving Organisation downloads, is written to the sending Organisation's audit trail, naming the receiving Organisation and the grant and no individual. A receiving Organisation may download export files at up to sixty (60) a minute, with a burst of twenty (20), by an ordinary download request only, on each server that answers it; beyond that the Platform asks it to wait.

• Dynamic elevation colour ramps, cross-section elevation profiling, and cut-and-fill volume calculation. These analyses are computed in the Customer's browser from the data present in a delivery, and are consequently available only where that delivery contains the surface data they require. The elevation profile, cut-and-fill and profile comparison tools are shown only to an Organisation whose plan includes elevation-based analysis, which is off by default; where it is not included, the tools are not shown. Volume and profile results are planning-grade numerical integrations constrained by the resolution, no-data extent and declared vertical reference of the supplied model; they are not a certified quantity survey.

• Contour lines delivered within a CAD or vector layer are rendered and may be drawn in three dimensions. The Platform does not generate contours from a surface.

• Which derived products are generated, and which are not. An ASCII DXF delivery is converted into per-layer vector data; a GeoJSON delivery is stored as a vector layer; an uncompressed LAS delivery in the project's coordinate system is converted into OGC 3D Tiles, with a vector layer outlining the survey's coverage; and a TIFF delivery whose samples are elevations is resampled into an elevation grid that is stored with the release, recording the source raster and the version of the recipe that produced it. A TIFF whose samples are not elevations — an orthophoto, or a single-band raster whose meaning cannot be established from the file — is published as a source artifact with that stated, and so is an archive or a PDF that joined the project's draft. What a release holds. A release holds the files of the draft it is published from: its map files, and those files kept with the project (Section 3.1) — a PDF, a photograph or an archive — that a person who may publish chose to include, one by one, while the project was in Draft or Review. A kept file nobody included stays with the project and is not published; a PDF is left out unless it is included. An included kept file is published as a source artifact, copied into the release with its preview where it has one, and is then delivered with the release like any other file of it. The publish confirmation names each included kept file and counts those left with the project. Publishing does not end the choice: the file stays kept with the project, and remains included in the next draft until someone takes it out. Including a kept file in a draft does not count it towards the Organisation's storage a second time; its copy in a published release is counted as every release file is. Each inclusion and each removal is recorded in the Organisation's audit trail with the file's name. Nothing is derived from the contents of an archive. A TIFF whose samples are not elevations, and a PDF that joined the draft, is also given a preview: compressed pictures of up to its first 200 pages, or of the image, made once when the file is processed so that it can be read on a screen without downloading it. A preview is kept with the file and removed with it, is not counted towards the Organisation's storage, and is not a derived product of the survey; a file the Platform cannot preview, such as a PDF that needs a password to open, is kept without one and with the reason recorded, and the original is kept unchanged either way. A PDF kept with a project rather than published in a release is given the same preview, made when it is added rather than at publication, stored beside the kept file and removed with it, and not counted towards the Organisation's storage; a kept PDF the Platform cannot preview is kept without one, with the reason recorded, exactly as an unpreviewable release file is. A photograph kept with a project is likewise given a preview when it is added. A file of a kind this Section previews, delivered or kept before the processing that makes its preview existed, is covered by a background pass that makes it a preview in the same way and to the same limits, without altering the original file; where that pass cannot preview such a file, it is recorded without one, with the reason, and is not attempted again. Whether the analyses in this Section that read an elevation grid are offered to a given Organisation is a matter of its subscription rather than of its delivery. Nothing in this Agreement commits Alonstech to generating any further derived product.

3.3. Immutable Survey Releases.

• When a project reaches a delivery milestone, the Customer issues a Survey Release.

• Published survey releases are sealed with a SHA-256 checksum and become strictly append-only and immutable. Immutability is enforced inside the database itself, on every path by which a record could be altered — including the most privileged ones — and not by the application alone.

• Corrections, supplementary survey runs, or revised cadastral layouts require issuing a new release, which marks the previous release as superseded. A published release may make exactly one transition — to superseded — and only where its identity, checksum and dates are unchanged. Historical releases cannot be edited or overwritten, preserving the chain of custody for legal, regulatory, and engineering auditability.

• Records and underlying data are distinct. The release record — its dates, state, and SHA-256 checksum — is immutable and survives as a tombstone even where the underlying survey data it describes is later erased, whether on the Customer's own verified erasure request under Section 5.3 or under Section 4.7. A SHA-256 checksum of geometry identifies no person. Immutability of the record is therefore not, and must not be read as, a refusal to erase data.

3.4. Review, Acceptance & Sharing With Another Organisation.

• Review, comment and acceptance of a survey release take place within the Organisation's own membership chain, save for a client reviewer as described in the next paragraph. A person who is not a member of the Organisation, holding a grant at the relevant scope, cannot open a project, a release, or a source artifact, save under an organisation-to-organisation share or a review invitation as described below. There is no public link, no expiring guest link, and no domain or IP constrained link.

• A client reviewer. While a project is in Review, the Organisation may invite one named, signed-in person of a client Organisation it has linked to review a fixed copy of the project's files. That person reads the copy, and may comment on a file or a feature of it, or on the review as a whole, and answer in the conversations they started. They may also read, and answer in, a conversation of the Organisation's that the Organisation has marked visible to the client, when it is about a file, a feature or a drawn object of that copy (never one about the project as a whole); a member of the Organisation may name them in such a conversation, or address everyone in it with @All, and they are then notified. They cannot read the Organisation's other conversations, and a conversation stops being readable to them, and any notice of it is withdrawn, as soon as the Organisation removes the mark. A withdrawn message keeps its place rather than disappearing: it is shown as a placeholder naming who withdrew it and when, without its words, and any reply already made to it stays. Where the Organisation switches it on for that invitation (off unless it does), the reviewer may also add files to the project, and where it switches that on (also off unless it does), the reviewer may download the original files of the copy, save those Section 3.1 keeps from another Organisation. The reviewer's comments and files are held in the inviting Organisation's account as its own records: they are counted against the inviting Organisation's plan allowances, including its uploads and storage, and are erased with that Organisation's data. A reviewer cannot change, remove, publish or share anything, and cannot act on any other project. A file a reviewer adds is not scanned for malware (Section 3.1). The invitation ends on the date it states or when the Organisation withdraws it, and from then the reviewer can do none of this. Each comment and each file is written to the inviting Organisation's audit trail with the invitation it was made under; the trail names no individual of the client Organisation.

• Connecting a client Organisation. An Organisation's record of a client is linked to that client's own Organisation in one of two ways: a person of the client Organisation accepts an emailed invitation the Organisation sent, or the Organisation enters the client Organisation's organisation code and the client Organisation accepts the resulting connection request on its Connections settings. Where the address the emailed invitation is sent to is already a verified GISweaver account, the invitation is also shown in that person's notifications, in each Organisation they belong to, and may be accepted from there with the same effect; the email is sent in every case, and the inviting Organisation is not told whether the address holds an account. Entering a code only makes a request, because an organisation code is also given out for other purposes: nothing is linked until the client Organisation accepts, and until then the requesting Organisation learns only the client Organisation's legal name and whether the request was accepted. The client Organisation is notified of each request and is shown the requesting Organisation's legal name and when it asked; it may accept or decline, and it may switch off incoming requests, in which case a request is refused and the requesting Organisation is told that the client Organisation is not accepting them. Either Organisation may end a link at any time; ending it ends every review invitation made through that link with immediate effect, and the other Organisation is notified. When a project of the Organisation names a linked client, the client Organisation's owners, administrators and contact persons marked for review (below) are notified once for that project, with the Organisation's legal name and its label for the project, and the notice is written to the Organisation's audit trail. Requests, answers and the ending of a link are written to the audit trails of both Organisations, and no entry names an individual of the other Organisation. An Organisation may send no more than twenty client invitations and connection requests together in any twenty-four hours.

• What a connected client Organisation shares. A client Organisation chooses on its Connections settings whether an Organisation connected to it may copy its contact card (its contact person, email and telephone), its GSTIN and its billing address, each separately; none of them is shared unless it chooses. When it accepts a connection request, what it shares is copied into the requesting Organisation's record of it wherever that record is empty, and never over a value already there; the requesting Organisation may copy it again at any time, into the empty fields or, where it confirms that it wants to, over the values it holds. What is copied becomes part of the requesting Organisation's own record of its client, which that Organisation may edit and may quote on its invoices: it is a copy, not a live mirror. It is never updated by itself, and a later change to what is shared, or to the client Organisation's own details, does not change it. The client Organisation is shown, for each connected Organisation, what it may copy and when it last did, and not what its record holds. Each copy is written to the requesting Organisation's audit trail, naming the fields copied, and each change to what is shared to the client Organisation's.

• Contact persons for connected Organisations. An Organisation may name, on its Connections settings, members of its own as contact persons for the Organisations connected to it, each marked for review, for deliveries, or both. Each person named is notified, and may remove themselves at any time; a member who leaves the Organisation leaves the list. While a link stands, a connected Organisation is shown the name, email address and marks of each contact person, and nothing else about them, so that it may invite a person marked for review as a client reviewer (above). When an Organisation delivers to it, the contact persons marked for deliveries are notified as well as its owners and administrators; a delivery is still made to the Organisation, and naming a person gives them no access they do not already hold as a member. A person taken off the list, and every contact person once a link ends, is no longer shown to the connected Organisation. Each addition, change and removal is written to the Organisation's own audit trail, naming the person.

• Where a release is published by the Organisation from its own delivery, the Platform records and displays that fact plainly: the release carries a self-declared validation notice stating that survey acceptance by a validation partner is not represented. Alonstech does not represent that any release has been assessed, accepted or certified by anyone other than the Organisation that published it.

• Sharing with another Organisation. An Organisation may grant another Organisation that has its own GISweaver account read access to one published survey release of one project. The terms of that grant are set entirely by the Organisation that makes it:

  • Sign-in is required. The recipient's people read the release inside their own Organisation's signed-in session: those of them who hold an organisation-wide role that reads projects — its Owner, Administrators, billing role and auditors. No token, link or address grants access to anyone; access is the session together with the grant record. Nobody from the recipient Organisation becomes a member of, or appears in the roster, notes or comments of, the Organisation that shared.

  • The sharing Organisation chooses what is visible. A grant names the layers of that release which may be read, and no other layer is served. What the recipient reads is the survey content of those layers, rendered on a map they cannot write to. A grant also names which tools that map offers; measurements and analyses are computed in the recipient's own browser from data already sent, so a tool list is a statement of what the Platform offers them and not a technical restraint, and the control that sets it says so.

  • The release archive, where the sharing Organisation allows it. A grant may permit the recipient to download the release as one archive — every file the release records, including the files the sharing Organisation uploaded, with a manifest stating what each should hash to. It is off unless the sharing Organisation switches it on, per grant; where it is off, the Platform refuses the download. Under a share, individual source artifacts are not otherwise served to a recipient. The one other route by which a recipient receives a file is a delivery under Section 3.5, where each file is served on its own as well as in the archive, and every download is recorded.

  • Every grant ends. A grant states the day it expires, which is set when it is made and may be no more than 365 days ahead. It may be withdrawn at any time by the Organisation that made it, with immediate effect.

  • It is recorded. Making, changing and withdrawing a grant are written to the sharing Organisation's audit trail; the recipient Organisation is notified when a grant is made. A download by the recipient is written to the sharing Organisation's trail, naming the recipient Organisation and the grant, and appears in that Organisation's chain-of-custody record. The trail names no individual of the recipient. Once a share has been taken into the Platform's access record, the sharing Organisation's record of looks at the release (at most one for each person in any fifteen minutes) and of each file taken tells the recipient's people apart by an alias the Platform assigns, not by name, unless the recipient Organisation switches on "Show our people's names to senders", in which case their names are shown there.

  • Sharing outbound is a Platform capability stated against a plan under Section 4.1, and it is off by default: it is available only to an Organisation whose plan version, or an individual grant, includes it. Receiving is not a plan capability: an Organisation on any plan may read what it has been sent.

  • Section 3.1's malware-scanning condition IS triggered, and this is what follows. That condition is written against "any capability ships by which a source artifact can reach a recipient outside the uploading Organisation". The release download described above is exactly such a capability: an archive containing the files the sharing Organisation uploaded, served to a company that is not it. Section 3.1 therefore now owes scanning; scanning is not yet in force, that Section says so rather than implying otherwise, and it states what the Platform does instead in the meantime — the download is the uploading Organisation's own choice, made in a control that carries the unscanned-content notice and switchable off at any time, it is bounded and withdrawable, each download is recorded, and the recipient is told before downloading that the files are not scanned for malware. The 30 November 2026 backstop stands.

• Future capability. Alonstech intends to develop identity-verified acceptance of a shared release by the recipient Organisation. That capability is not built, is not enabled for any Customer, and nothing in this Section is a commitment to build it, a representation that it exists, or a term of this Agreement.

3.5. Deliveries.

• A delivery is an Organisation's offer of one published survey release to another Organisation on GISweaver for a stated period, which the delivering Organisation sets when it makes the delivery, may be no more than 730 days when the delivery is made, and which the delivering Organisation may extend at no charge, each extension setting a new end no more than 365 days ahead. During that period the receiving Organisation's people, signed in to their own Organisation and holding a role that reads a share under Section 3.4, may read the release and download its files — each file on its own, or every file as one archive with a manifest stating what each should hash to. No token, link or address grants access to anyone. The receiving Organisation needs a GISweaver account of its own on any plan, including a free one; delivering outbound is a Platform capability stated against a plan under Section 4.1.

• The receipt. When the receiving Organisation has downloaded every file, the Platform records a receipt stating which Organisation handed what to which, when, by which route, and the SHA-256 checksum of each file, signed with the Platform's receipt key, and gives a copy to both Organisations. The receipt carries the key that checks its signature, so either Organisation may show it to a third party; Alonstech publishes that key nowhere else. Alonstech keeps the receipt for as long as it operates the Platform, in a form that names the two Organisations and no person; once an account the receipt names is erased under Section 5.3, the receipt names the Organisation alone.

• Holding, withdrawing and ending. The delivering Organisation may hold a delivery for a cooling period after making it, during which the receiving Organisation sees what is offered but cannot download it and the delivering Organisation may withdraw it alone; the Platform states the length of that period in the control that sets it. Once the cooling period has passed, or where the delivering Organisation chose not to hold, the delivery cannot be withdrawn by the delivering Organisation; it may still delete a delivered file, or the project it came from, permanently under Section 5.4, and the receiving Organisation is then told, in place of that file's download, that the file was deleted permanently and on which day. The receiving Organisation may decline a delivery. A delivery whose files have not all been downloaded when its period ends is closed; the Platform reminds the receiving Organisation thirty (30), fourteen (14) and one (1) days before that day, each only where the period is long enough to include it, and none while the delivery is paused.

• The files remain the delivering Organisation's. The delivered files are stored under the delivering Organisation's plan and count against its storage until it retires them. The delivering Organisation may retire a release's files only once every delivery of that release has ended — by receipt, by decline, by the period ending, or by withdrawal — and only where every receiving Organisation whose period ended without a download has been sent the notice that its period has ended; retiring the files does not touch the release record, the receipt, or any share of a different release. Alonstech keeps no copy of a delivered file for the receiving Organisation.

• The delivering Organisation's account. Suspension of the delivering Organisation under Section 12.2 pauses downloads on its open deliveries and extends each period by the length of the pause; it does not end a delivery. Where the delivering Organisation's account is erased under Section 5.3 or Section 4.7 while a delivery is open, the receiving Organisation is told and given not less than thirty days, or the remainder of the period if shorter, to download the files; after that the files are destroyed with the rest of that Organisation's survey data, and the receipt for a delivery that was completed is kept.

• Service interruptions. Where Alonstech declares that the Platform was unavailable, every open delivery whose period overlapped the interruption is extended by its length and a further day, and both Organisations are told.

• It is recorded. Making (with any hold), extending, withdrawing and retiring are written to the delivering Organisation's audit trail; accepting, declining and each download are written to the receiving Organisation's — naming the person for each file downloaded on its own, and once for an archive. Each file downloaded on its own is also written to the delivering Organisation's audit trail, naming the receiving Organisation and no individual of it, and the delivery is written there as taken when its receipt is made; an archive download is written to the receiving Organisation's trail only, and is not written to the delivering Organisation's trail or to its access record. Where a share of the same release to the receiving Organisation is in the access record, a file downloaded on its own is also recorded there for the delivering Organisation, against the person's alias as Section 3.4 states. Adding a delivery's files to one of the receiving Organisation's own projects (Section 7.5) is written to the receiving Organisation's audit trail alone. The receiving Organisation is told, beside the download, that the files were uploaded by another Organisation and are not scanned for malware, and Section 3.1's malware-scanning condition, already triggered by Section 3.4, applies to a delivery exactly as it applies to a share download; the 30 November 2026 backstop stands.

3.6. Public Provider Profiles. An Organisation may, if it chooses, publish one public profile: a page about the Organisation at an address of the form gisweaver.com/p/{name} that anyone can read without an account, and that is listed in the Platform's public provider directory at gisweaver.com/providers. The same page requested at the Platform's other addresses, including an address shared before 26 September 2026, is permanently forwarded to that address. Nothing is public until the Organisation publishes it.

• Who edits it. Only the Organisation's owner and administrators can edit, publish or unpublish the profile. What they save is public straight away while the profile is published. The page's address is made from the Organisation's name and may be changed once; for ninety days after a change the old address forwards to the new one if the profile had been published.

• The confirmation. Before a profile is first made public, and each time it is published again, the person publishing it must confirm this statement, and the Platform records the confirmation in the Organisation's audit trail: "I confirm that I am authorised to publish this profile for my organisation, that what it says is accurate and lawful, and that GISweaver does not check or verify it."

• The Organisation is responsible for what it says. The profile's contents are Customer content published by the Organisation. Alonstech does not check or verify them, and every public profile page and the directory say so: "GISweaver has not verified this profile. The organisation that published it is responsible for what it says." Section 8 applies to the profile as it does to everything else an Organisation puts on the Platform.

• Reports. Every public profile page has a "Report this page" link. A visitor's report goes to Alonstech's staff and is never shown to the reported Organisation, nor is the reporter's identity or email address disclosed to it. The address a report was sent from is stored only as a keyed hash, never as the address itself.

• Automatic hide. When reports about one profile arrive from 3 different visitors within twenty-four hours, the profile stops being shown at once and stays hidden until Alonstech's staff have reviewed the reports. If staff find nothing to act on, it is shown again.

• Staff action. After a report, Alonstech's staff may hide a profile, or turn off publishing for the Organisation, which unpublishes the profile and stops it being published again until staff restore it. Each such act is recorded in the Organisation's own audit trail. An Organisation that disagrees may contact support as Section 1.6 describes.

• Suspended, closed and frozen Organisations. While an Organisation is suspended under Section 12.2 or closed, its profile is not shown, is not listed and cannot be reported, and its owner and administrators can still unpublish it. A profile is still shown while the Organisation's workspace is frozen for non-payment under Section 4.6.

• Removal with the Organisation. An Organisation's public profile, its forwarding addresses and the reports about it are deleted when the Organisation is erased under Section 5.3.

3.7. Direct Messages and Private Groups.

• What they are. Any member of an Organisation whose membership is not suspended may write privately to one other such member of the same Organisation, whatever the role of either. The Organisation's Owner or an Administrator may also start a private group of two to one hundred (100) such members, including themselves, with a name of up to eighty (80) characters. A message in a direct conversation or a private group is text, with links, of at most 4,000 characters; nothing can be attached to it. Any message may be replied to in a thread, one level deep: a reply cannot itself be replied to. A person outside the Organisation, including a client reviewer, cannot take part in a direct conversation or a private group. Members of an Organisation can see each other's names and pictures in order to write to each other.

• Who reads them. A direct conversation is read by its two participants, and a private group by its current members, and in each case by nobody else: not the Organisation's Owner or Administrators unless they are members of that group, not its auditor unless a member of that group, and not Alonstech's staff, including while an operator has assumed the Organisation (Section 2.2). A member added to a group can read everything written in it, including earlier messages and threads. The Organisation's audit trail records that a direct conversation was started, by whom and with whom; and that a private group was created, who was added to it or removed from it or left it, and that it was renamed, archived or reopened; and never what is written in a conversation, a group's name, how much is written, or when. The export of the Organisation's records (Section 5) does not include direct messages or private groups. A colleague named in a direct conversation is not told of it; a member named in a private group is notified of that mention, every member of a group is notified when a member who manages it addresses the whole group ("@All") in a new message, and a member of a group is notified of a reply in a thread they follow.

• How they are kept, and when Alonstech produces one. Direct messages and private groups are stored in the Platform's database like every other record, encrypted at rest and in transit; they are not end-to-end encrypted. Alonstech produces a direct conversation or a private group only where an order of a court, or a direction of a government authority that the law empowers to require it, so requires, and then only as a manual act authorised by a director of Alonstech and recorded, without the words, in Alonstech's staff audit trail. The Platform has no feature by which anyone other than the participants can read one.

• Correcting and withdrawing. A participant may withdraw their own message, and may correct it while direct messages and private groups are available to the Organisation under its plan (see Plans below) and, in a group, while the group is not archived. Neither can be done while the Organisation's workspace is suspended, closed or frozen for non-payment, except that a participant may withdraw their own message in a group that is archived. A withdrawn message keeps its place, without its words, and any replies to it remain.

• When a participant leaves. A participant in a direct conversation who is removed from or suspended by the Organisation, or whose account is closed, can no longer read it; the other participant keeps it and can no longer write in it; a person who rejoins the Organisation finds the same conversation. A member of a private group who is removed from the group by one of its managers, who leaves it, or who leaves or is removed from the Organisation can no longer read it, and the group carries on without them; their earlier messages remain, under their name. A person who rejoins the Organisation does not regain a seat in a private group: a member who manages the group must add them again. A member who manages a private group is one of its members who is the Organisation's Owner or an Administrator; if none is left in the group, nobody can add or remove people or rename it, and its members may still write in it and leave it. A manager may archive a group, which makes it read-only for everyone until a manager reopens it. A private group cannot be deleted; it is erased with the Organisation's whole account.

• Plans. Direct messages and private groups are included in every paid plan. On Sketch they may be used for sixty (60) days from the Organisation's first direct or group message; after that, conversations are read-only: existing conversations and groups remain readable, a participant can still withdraw their own messages and a member can still leave a group, and starting a conversation or a group, writing in one, correcting a message, adding people to a group or renaming it needs a paid plan.

• Erasure. Direct messages and private groups are erased with the rest of the Organisation's data when the Organisation's whole account is erased (Section 5). The erasure of survey data alone, and the removal of an unconverted trial's data (Section 4.7), leave them in place.

4. Subscriptions, Pricing, Invoicing & Commercial Terms

4.1. Subscription Plans & Resource Quotas. GISweaver's subscription plans are Sketch, Plot, Parcel and Estate. Sketch is the free plan, and where these Terms say "the Free plan" they mean Sketch. Further plans may be added above Estate. Each is published as a plan version stating its name, its price, its quotas and the capabilities of the Platform it includes, and which plans are offered for purchase at any time, and on what terms, is shown on the Platform. The quotas govern members besides the Owner, branches, new projects in each calendar month, storage capacity (in megabytes or gigabytes), the largest single file (in megabytes), and uploads begun in each calendar month; a plan is shown everywhere on the Platform by its name with its storage capacity and its number of people, with the largest single file stated beneath. A plan withdrawn from the public list remains in force for every Organisation subscribed to it, which may renew it on the terms of its plan version. A plan may be published with a monthly price and a yearly price, and which of the two billing periods can be bought at any time is shown on the Platform: during the beta Alonstech may withhold the yearly billing period, in which case only the monthly period can be bought, and withholding it does not change the term of an Organisation already paying for a yearly period, which may renew it. Alonstech may additionally offer plans that are not publicly listed, on terms agreed in writing with the Organisation concerned.

• Capabilities a plan does not mention. Each capability of the Platform has a default. A plan version that does not mention a capability includes it or not according to that default; a plan version may switch any capability off; and Alonstech may switch a capability on for one Organisation by an individual grant. Corridor review (Section 3.2) is on by default for every Organisation.

• Published Plan Immutability: Plan versions are immutable once published. Alonstech shall not unilaterally alter the price or quota terms of an active subscription version during an ongoing billing period. Pricing or quota adjustments take effect via newly published plan versions upon subsequent renewal or explicit plan change.

• Quota Enforcement Scope: Quotas govern additions only. If an organisation exceeds a plan quota following a voluntary downgrade or expired promotion, the Organisation retains all existing projects, branches, and stored data, but is prevented from adding new resources until upgraded or brought within limits.

4.2. Starting Plan, Trials & Promotional Access.

• A new Organisation starts on the Free plan, unless it receives a specific trial offer or promotional entitlement. There is no automatic Professional trial. The available plans, any trial offer and any invitation requirement are shown on the Platform before registration; an invitation code may grant the entitlement stated in its offer.

• A trial, where expressly offered, runs on the plan and for the duration stated in that offer. One trial is available per Organisation in its lifetime. A promotional plan grant is a separate entitlement and lasts for its stated period.

• Promotional codes at checkout. Alonstech may issue a promotional code that takes a stated whole percentage off the price of a paid plan, and may limit it to one Organisation, to one plan, to a number of uses and to a period in which it can be used. The code is entered when the plan is bought and reduces the fee, GST included, for the billing period that payment is for, monthly or yearly; GST is charged on the reduced fee, and the tax invoice shows the plan at its price before GST and the reduction as a separate line naming the code. A code can be used once by an Organisation, and is used when its payment is confirmed. It does not reduce any later payment: a renewal, and a plan bought afterwards, are charged at the price then published unless a code is entered for that payment. A code cannot be exchanged for money or credited against anything else.

• Referral programme. Every Organisation has a referral code shown on its Billing page. Where Alonstech runs a referral programme, the Platform states, before an Organisation signs up with a code and again at checkout, what the programme gives: a stated percentage or amount off the price of the plans it covers for the Organisation that signed up with the code (the "referred Organisation"), on its first paid plan unless the programme states that it applies to every payment, and a stated percentage or amount, computed on the amount the referred Organisation paid before GST (or, where the programme so states, including GST), earned by the Organisation whose code was used (the "referring Organisation"). The reduction is applied last, after the yearly price and after any promotional code the two allow to be used together, to the price then remaining, and before any credit for an upgrade under Section 4.5; GST is charged on the reduced fee; and the tax invoice shows each reduction as a separate line. An Organisation is attributed to one referring Organisation, fixed when it signs up, and the attribution cannot be added or changed afterwards. No earning arises, and no reduction is given, where the two Organisations share an Owner, a billing e-mail address, a GSTIN or a verified e-mail domain, or where Alonstech finds the referral was not genuine. An earning becomes payable after a holding period stated in the programme (ninety days unless stated otherwise), is paid by bank transfer on a day of Alonstech's choosing in the month after it becomes payable, and is withdrawn — or, if already paid, recovered from later earnings — where the payment it arose from is refunded or reversed within the programme's stated period. Earnings are not credits against fees and cannot be applied to an invoice. Alonstech may set a monthly ceiling on what one Organisation earns, may agree different terms with an Organisation in writing, and may end or change the programme for future sign-ups and future payments at any time; the terms shown at checkout govern that payment. The referring Organisation is responsible for the tax consequences of what it receives, and Alonstech deducts tax at source where the Income-tax Act requires it and issues the certificate for it. A promotional code and a referral reduction apply together unless the code, or the programme, states that it cannot be combined with the other; where either so states, only one of them applies to the payment — the referral reduction where the programme refuses codes, and otherwise the code — the checkout says, before payment, which one applies and why, the Organisation may remove the code and pay with the referral reduction instead, and the tax invoice states that the other was not applied.

• Previously accepted Terms. An Organisation that accepted the earlier wording promising a thirty (30) day Professional trial retains that entitlement, including where it has not yet used it. It may contact support@gisweaver.com to arrange fulfilment. Existing trials, subscriptions and promotional grants retain their agreed terms. This publication correction is not a notice of withdrawal or reduction of those rights; any material modification remains subject to Section 17.1.

• Upon expiration of the free trial, upon non-renewal of a paid subscription, or at the end of the period of a cancelled subscription (Section 4.5), the Organisation transitions to the Free plan. Under no circumstances does trial expiration itself result in account lockout, asset deletion, or access revocation; data uploaded during a trial that is never converted and never returned to is retained under Section 4.7.

4.3. Fees, Indian GST & Statutory Tax Invoicing.

• All fees are denominated and billed in Indian Rupees (INR, ₹).

• Prices are calculated inclusive of Goods and Services Tax (GST) in accordance with the Central Goods and Services Tax Act, 2017 (CGST), State Goods and Services Tax Act, 2017 (SGST), and Integrated Goods and Services Tax Act, 2017 (IGST).

• Each tax invoice states the Services Accounting Code (SAC) under which its supply is classified. A subscription and a reinstatement charge under Section 4.6 are different supplies and are classified separately, each under the code recorded in Alonstech's GST registration details.

• Tax treatment is determined automatically from the Place of Supply (POS): the billing state the Customer gives, or where it gives none, the state within its Goods and Services Tax Identification Number (GSTIN), or where it gives neither, Alonstech's own state. The Platform checks that a GSTIN is well formed and that its check digit is correct; it does not verify the registration with the GST authorities.

  • Intra-state Supply (Seller and Buyer in same State): 50% CGST + 50% SGST.

  • Inter-state Supply (Seller and Buyer in different States): 100% IGST.

  • Unregistered Buyer: IGST or CGST/SGST applied as per billing address state code.

• Where a plan is bought for a yearly billing period at a yearly price below twelve of its monthly payments, the tax invoice shows the plan at twelve monthly payments before GST and the difference to the yearly price as a separate line, above any promotional code or referral reduction under Section 4.2.

• Tax invoices bear a consecutive serial number, unique for the financial year, in accordance with Rule 46(b) of the Central Goods and Services Tax Rules, 2017 (e.g. GW/2627/000001), and are immutably archived for accounting and audit compliance. As an internal control exceeding what the Rule requires, serials are issued so that the series contains no gaps: a number is never consumed by an invoice that was not in fact issued.

4.4. Payment, Renewal & Grace Period.

• Payments are processed through an RBI-authorised payment aggregator, presently Razorpay, using the payment methods Razorpay offers at its checkout. Alonstech does not receive or store card numbers or banking credentials. Where Alonstech agrees to accept a payment directly — by bank transfer, UPI transfer, cheque or cash — it records that payment against the checkout it pays for.

• There is no automatic renewal and no stored payment mandate. GISweaver holds no standing instruction, e-mandate, card token or recurring authorisation against any Customer, and never charges an Organisation without that Organisation initiating the payment. A subscription therefore does not renew of its own accord: at the end of a paid period, the Organisation renews by completing a checkout it starts itself. A renewal of the same plan and billing period may be paid in the last seven (7) days of a paid period; the renewed period then begins when the current one ends, so no paid day is lost.

• Where a period ends without a renewal payment, the subscription enters a seven (7) day grace period (a cancelled subscription excepted, under Section 4.5) during which the plan and its full workspace functionality continue uninterrupted, and during which the Organisation may complete the renewal it began. A subscription that is past due or in its grace period remains fully entitled to its plan; cutting a Customer off the moment a payment does not arrive punishes a bank, not a customer.

• If the period is not renewed by the end of the grace period, the subscription expires and the Organisation reverts to the Free plan, subject to Section 4.1's rule that quotas govern additions only. Non-payment never triggers data deletion or the hiding of survey work.

4.5. Refunds, Cancellation & Plan Changes.

• Cancellation. An Organisation's Owner or Administrator may cancel a paid subscription from the Organisation Billing console at any time while its paid period is running (a subscription in its grace period under Section 4.4 has no running period left to cancel). The plan stays in force, with every quota and capability it carries, until the end of the period already paid for. On that date the Organisation moves to the Free plan; the seven (7) day grace period in Section 4.4 does not apply to a cancelled subscription. Until that date the Owner or an Administrator may withdraw the cancellation from the same console, and the subscription then continues as though it had not been cancelled. Cancelling issues no invoice and no credit note.

• No refund. Cancelling refunds nothing for the unused part of the period. Because GISweaver provides immediate compute allocation, high-performance spatial ingestion, and sovereign storage provisioning upon subscription, fees paid are non-refundable, except where required by applicable Indian consumer protection law or in the event of proven double-billing resulting from technical gateway errors.

• A refund in full ends the plan. Where Alonstech refunds a payment in full, it decides at the same time whether the plan that payment bought also ends. A refund is in full when it returns the whole balance still unrefunded on the payment, whether that is left to the Platform or stated as the exact figure. By default the plan ends when the refund is made, the Organisation moves to the Free plan with no grace period, and the choice and its reason are written to the Organisation's audit trail. Alonstech may instead keep the plan running to the end of the period paid for, as a gesture of goodwill. A refund of part of a payment does not end the plan. Only the period that payment bought is ended, and only while it is the period running. Where that period replaced another that still had paid days, which is so for a payment that bought an upgrade, a billing period switch or an early renewal that had not yet begun, the earlier period runs again and the Organisation keeps that plan for the days it had paid for, but only while the payment that bought that earlier period still stands: it is captured, none of it has been refunded or is being refunded (a refund in process counts), no chargeback against it has been lost or is still open, and no credit note has reduced it. Otherwise the plan ends. The same applies where Alonstech ends a plan because the bank decided a chargeback against it. The plan ends when the refund is accepted, not when the money reaches the Customer: a refund that fails afterwards leaves the plan ended, and Alonstech then settles the failed refund with the Organisation.

• Upgrade. An Organisation may move from a running paid period to a higher plan (a plan whose published monthly price is higher than that of its current plan or, where either plan has no monthly price, whose published yearly price is higher) at any time. The new plan takes effect when its payment is confirmed, and its billing period starts on that day. The unused part of the current period is credited against the new plan's price, as follows:

  • Basis. The basis is the taxable value of the plan on the invoice that paid for the current period — for a period that was itself bought by an upgrade, the plan's taxable value before the credit that invoice carried, and for a period bought with a promotional code or with a referral reduction under Section 4.2, the taxable value after the reduction, which is what was paid — less the taxable value of any credit note issued against that invoice. Where that invoice has been voided or credited in full, no credit is given. Where that invoice is in a different currency from the new plan, the upgrade is not available.

  • Days. The days in the period are its length in 24-hour steps, rounded to the nearest whole day. The days remaining are counted in 24-hour steps back from the end of the period, a step already begun counting as remaining, and are never more than the days in the period. They are counted when the Platform quotes the price at checkout.

  • Credit. The credit is the basis multiplied by the days remaining and divided by the days in the period, rounded down to the paisa.

  • Early renewal. Where the Organisation renewed its current plan early, so that the renewed period has not yet begun, the renewed period is credited in full and the days remaining in the period it follows are credited as well, on the invoice that paid for that period and by the same rule.

  • Amount. The amount charged is the new plan's published price before GST — reduced first, where a promotional code under Section 4.2 is entered for the upgrade, by that code, and then by any referral reduction under Section 4.2 — less the credit, with GST charged on that net amount and rounded to the nearest paisa, half a paisa rounded up. Where the credit would equal or exceed the new plan's price before GST, that upgrade is not available on that billing period. Nor is any purchase available where the amount to be paid, GST included, after every promotional code, referral reduction and credit under this Section 4.5 and Section 4.2, would be less than ₹1 (one rupee), which is the least the payment provider accepts: the Platform refuses it before a payment is started, and nothing is charged. Alonstech may instead put the plan on the Organisation's account by agreement.

  • Invoice. The invoice shows the new plan at its price before GST and the credit as a separate line.

  • Before payment. The Platform shows the credit and the amount before the payment is started.

  • Late payment. A payment that arrives after the credited period has ended or has been replaced is recorded but is not applied to the plan, and Alonstech settles it with the Organisation.

• A late payment for an older plan. A payment that arrives for a checkout opened before a different plan, which is still running, was paid for is recorded but is not applied: the later plan stays, and the late payment is not given a period of its own. Alonstech settles it with the Organisation, ordinarily by refunding it. An Organisation that wants the older plan after all buys it again at the price then published.

• No downgrade mid-period. A plan that is not higher than the current plan cannot be bought while a paid period is running. An Organisation that wants a lower plan cancels its current plan and buys the lower plan when the current period ends.

• Billing period change. Moving the same plan from monthly to yearly billing, or from yearly to monthly, takes effect when the paid period running ends. The new period is paid for when its payment is confirmed and begins on the day the current one ends, so nothing already paid for is lost and nothing is credited, prorated or refunded. The Platform shows the day the new period begins before the payment is started and on the billing page afterwards.

4.6. Dormant Accounts & Reinstatement.

• Where a subscription has lapsed or been cancelled and no payment has been made, the Organisation's workspace may, after a notice period stated to the Organisation in advance, be placed in a frozen state in which the Organisation's people can add or change nothing in its workspace, a new survey file export under Section 3.2 included, other than paying for a plan, writing to support, requesting the closure or erasure of its account, clearing a mark on its data custody record, taking down its public profile, withdrawing access it has given another Organisation or a role it has lent, and removing themselves as a contact person; an invitation it sent before the freeze can still be accepted. Freezing is automatic once Alonstech has set the notice and freezing periods, and the Organisation is told the date before it arrives; Alonstech may extend that date for an Organisation. Freezing never affects existing data: throughout dormancy the Organisation retains sign-in access, complete read access, the download of every file, release and export it holds, and its Owner's export of its records as a whole, as guaranteed by Section 5, and no dormant period of any length results in the deletion, archiving, or degradation of Customer data.

• The Organisation may reinstate its subscription at any time. Buying any paid plan, or starting a trial, ends a freeze and withdraws any reinstatement charge offered under this paragraph. Alonstech may instead offer reinstatement on a one-time reinstatement charge, reflecting a fair recovery of the costs of holding the Organisation's data during the dormant period, determined case by case, and never exceeding the subscription fees that would have been payable for that period. The charge and the basis on which it was calculated will be stated to the Organisation before any payment is taken, and invoiced as a single tax invoice with GST applied as required by law.

• Paying that charge, or its waiver, ends the freeze. Alonstech may waive the reinstatement charge in whole or in part at its discretion. Whether or not reinstatement ever occurs, the Organisation's data remains stored, readable and downloadable throughout dormancy, and its Owner can export its records as a whole.

• This Section applies only to dormant periods beginning after its publication date, and creates no charge in respect of any lapse that began before it.

4.7. Unconverted Trial Data Retention.

• This Section applies only to an Organisation that (a) has never held a paid subscription or made any payment to Alonstech, (b) whose free trial ended at least six (6) months ago, and (c) in which, for at least six (6) continuous months, no user has signed in, no act has been recorded against the Organisation by an authenticated user, and no payment has been made ("Trial Silence"). An export of the Organisation's data or of a release under Section 5 is recorded against the Organisation as such an act, and so ends the silence. An Organisation that has ever paid Alonstech anything is permanently outside this Section, whatever its later state.

• Where Trial Silence is established, Alonstech may permanently delete the survey data uploaded during that trial — the stored files themselves and the spatial features derived from them — subject to every condition below. Nothing else goes. The Organisation's account, its people, their sign-in, its branches and projects, its release records with their dates and SHA-256 checksums, its statutory records and both audit trails all remain. The Organisation may return, be told plainly what was removed and when, and begin again.

• An Organisation holding less than a minimum quantity of trial data, configured by Alonstech and presently one gigabyte, is not considered under this Section at all.

• Notice. Before any deletion, Alonstech shall send the Organisation not fewer than four (4) notices: the first not fewer than thirty (30) days before the deletion date, thereafter approximately weekly, and the final notice not fewer than seven (7) days before. Each of those four conditions is re-verified at the moment of deletion itself, and the deletion is refused if any of them is not met. Each notice shall state what is held, the date after which it may be deleted, and the means of retrieving it. The export remains complete, unrestricted and free throughout, as guaranteed by Section 5.

• Any of three acts stops it. A sign-in by any user of the Organisation, any act recorded against it by an authenticated user, or any payment immediately ends the pending deletion and voids its notices; an export of its data is such an act. Deletion may only be considered again after a fresh six-month period of Trial Silence, beginning after that act, with all notices given afresh. Deletion is a consequence of sustained silence, never of non-payment.

• Alonstech may, at its discretion, retain trial data indefinitely rather than delete it, and in practice prioritises deletion by the storage burden the data imposes.

• Non-retroactive. This Section applies only to trials commencing on or after 27 August 2026, the date on which it was first published. Trial data uploaded before that date is retained under the terms in force when it was uploaded.

• Statutory records — tax invoices, payment records and the audit trail — are retained under Section 5.3 and are unaffected by this Section.

5. The Sacred Data Guarantee: Additions vs. Retention

5.1. Core Architectural Principle. Alonstech recognizes that survey deliverables represent vital cadastral, engineering, and legal records of work for which our Customers have been professionally compensated and which may be required to defend property boundaries, infrastructure alignments, or civil claims decades later.

5.2. Absolute Non-Destruction Commitment.

• Payment state governs additions; it never governs retention.

• No automated sweep, dunning workflow, payment lapse, downgrade, or commercial dispute shall ever trigger the deletion, archiving, watermarking, obfuscation, or degradation of Customer survey releases, uploaded raw artifacts, CAD geometries, or audit records. The sole exceptions are Section 4.7, which applies only to trials that were never paid for, is conditioned on six months of complete silence rather than on payment state, and is ended immediately by any sign-in, export, or payment; and the end of the restoration period of a project the Organisation itself deleted under Section 5.4, which follows only from the Organisation's own act.

• Even on the Free tier or following subscription cancellation, Customers retain permanent sign-in access, complete read privileges, and unrestricted release export capabilities for all historically published data.

• The commitment binds Alonstech's commercial conduct; it is not a promise to defy the law or to operate for ever. Customer data may be removed, withheld or made unavailable only in the following circumstances, each of which is narrow and none of which arises from payment state:

  • the Organisation's own deletion of a file or a project under Section 5.4;

  • a verified erasure or account-closure request under Section 5.3, or a verified request by a Data Principal exercising a statutory right;

  • compulsion by a court of competent jurisdiction, a law enforcement agency, or a statutory authority acting within its powers;

  • containment of an active security incident, for the period and to the extent stated in Section 12.2;

  • discontinuation of the Service or of a cell, in which case Alonstech shall give the Organisation not fewer than one hundred and eighty (180) days' written notice and shall maintain complete, unrestricted and free export throughout that period;

  • a Force Majeure event, to the extent and for so long as it prevents performance.

Outside these circumstances, no lapse of payment, no dormancy of any length, and no commercial disagreement causes Customer data to be deleted, degraded or withheld.

5.3. Customer-Initiated Erasure & Account Closure. An Organisation's survey data shall be permanently purged from the active data plane only upon an explicit, verified, multi-step erasure request initiated by the authenticated Organisation Owner, or under Section 4.7. Alonstech has deliberately built erasure so that no request the Platform can receive — from a browser, from an API client, or through a defect — destroys survey data, other than the Organisation's own permanent deletion of a file or a project under Section 5.4, which removes the stored copy of what it deletes and nothing else: the Owner records and confirms an intent, and the destruction itself is carried out by an Alonstech operator using an authority the running Platform does not hold.

• Confirmation requires the Owner to restate the mode of erasure, to acknowledge by name each category of record that will survive it, and to re-authenticate. Where the Owner has no second factor or password configured, confirmation is refused outright, erring in the only direction erasure may err: retaining. An erasure request may be withdrawn up to the moment an operator acts on it.

• Two modes are offered: erasure of the survey data while the record of the work is kept, and erasure of everything, in which the Organisation's identity is reduced to an unnamed tombstone. In both modes the following survive, and the Owner is told so before confirming: tax invoices, payment and subscription records, retained under Section 9.2 of the Privacy Policy; both audit trails, which are append-only and become pseudonymous once the accounts they name are gone; existing backups, which age out on their own schedule and which nothing here reaches; and, where the survey data alone is erased, the release records with their dates and SHA-256 checksums. Deliveries the Organisation made to other Organisations under Section 3.5 survive both modes as receipts that name the two Organisations and no person — they are those Organisations' records of work they paid for — and the delivered files of any delivery still open are kept for the receiving Organisation's last chance stated in that Section before they are destroyed; where the survey data alone is erased, deliveries the Organisation received are kept.

• Where a person of an erased Organisation is still named by another Organisation's records — a conversation they opened or a remark they made, a work object they drew, a file they uploaded, a delivery or share they made, an invitation they sent or accepted, while they worked there — that Organisation's record is not the erased Organisation's to take and is kept intact: the person's account is reduced to a placeholder that reads "Deleted user", with every identifying detail, credential, session and preference removed, so that it can never sign in, be invited or be named again, and the record keeps only that placeholder. A person no other Organisation's record names is deleted outright.

5.4. Deleting Files and Projects. An Organisation manages its own files and projects; the Platform records what it does rather than refusing it.

• Deleting a file from a project. Anyone who may upload to a project may delete any file of it that is not still being sent, checked or processed, with an optional comment. This includes a file kept with the project rather than processed into a release, such as a PDF, a photograph or an archive attached to it: it is deleted, recorded and freed in the same way as any other file. The file leaves the project's files and every release made afterwards. A release it was already published in is not edited: it keeps the file, and every delivery, share and review of that release goes on serving it for as long as that delivery lasts.

• Deleting a file permanently. The Organisation's Owner or an Administrator may delete a file permanently, and is warned before doing so that it is then removed from the deliveries it was published in and that the receiving Organisation will no longer be able to download it. From that moment no part of the Platform serves the file to anyone — not its download, its map, its preview or its place in an archive. The release record keeps the file's name, size and SHA-256 checksum and says that it was removed and on which day, and a receiving Organisation is told the same in place of the download. The file's stored copy is then removed from storage — the file as uploaded and everything the Platform made from it, including its copies in published releases and their previews — ordinarily within the hour, and from then it no longer counts towards the Organisation's storage; the removal is recorded in the Organisation's audit trail with the file's name, size and SHA-256 checksum. A copy another Organisation has already downloaded, or copied into its own project, is that Organisation's and is not reached. Publishing a corrected delivery afterwards is the deleting Organisation's to do.

• Deleting a project. The Owner or an Administrator may delete a project, with an optional comment. It leaves every list at once and may be restored for the period the Platform states when it is deleted — thirty (30) days, unless Alonstech sets another period of at least one (1) and at most three hundred and sixty-five (365) days — a period fixed when the project is deleted, so that a later change reaches only projects deleted afterwards; its deliveries continue to be served during that time. At the end of that period, or earlier when the Owner or an Administrator confirms a permanent deletion by typing the project's number, it is deleted permanently, with the effect of a permanent file deletion on every file in it, including the removal of their stored copies, and it can no longer be restored.

• What deletion keeps. Deleting a file from a project, or deleting a project that can still be restored, destroys no stored file: the stored copy is kept under Section 5.2, and counts towards the Organisation's storage. A permanent deletion removes the stored copy as set out above and keeps every record: the release records, the file's name, size and checksum, and the audit trail. Neither is an erasure under Section 5.3, which is how an Organisation asks for everything else to be destroyed. An Alonstech operator acting inside an Organisation cannot delete its files or projects (Section 2.2).

• It is recorded. Every deletion and every restoration is written to the Organisation's audit trail with who did it, when, the file's name, size and checksum or the project's number and name, whether the deletion was permanent, and the comment. A permanent deletion at the end of the restoration period, and the removal of each stored copy, is recorded as the Platform's own act. The Organisation reads its own audit trail from its Console.

6. Indian Geospatial Regulatory Compliance & Surveyor Responsibilities

6.1. Compliance with National Geospatial Policy 2022 & 2021 DST Guidelines.
The acquisition, processing, handling, and distribution of geospatial data in India is governed by the Guidelines for Acquiring and Producing Geospatial Data and Geospatial Data Services Including Maps (Department of Science and Technology, Government of India, 15 February 2021) and the National Geospatial Policy, 2022.

6.2. Threshold Value of Spatial Accuracy (Coarser vs. Finer).

• The DST Guidelines set threshold values of spatial accuracy, of which the two relevant to terrestrial survey work are one (1) metre horizontal and three (3) metres vertical, expressed at one RMSE in accordance with the Department's Office Memorandum of 28 November 2022. Further threshold values apply to gravity and to bathymetric data.

• Coarser than the threshold: geospatial data of accuracy coarser than those values.

• Finer than the threshold: geospatial data of accuracy finer than those values — for example millimetre-accurate Total Station surveys, DGPS coordinates, high-density drone LiDAR, and terrestrial laser scans.

• The Customer acknowledges that certain categories — including terrestrial mobile mapping, street-view surveys, and surveying within Indian territorial waters — are reserved to Indian entities by the Guidelines irrespective of accuracy, and that these Terms do not relieve the Customer of that restriction.

6.3. Sovereign Data Localization & Edge Boundary.

• In strict adherence to DST Guidelines, all Fine geospatial data pertaining to Indian territory processed on GISweaver is hosted, stored, and computed exclusively within sovereign Indian data centers (India Data Plane in-mumbai-1 in AWS Mumbai).

• Hard Technical Boundary: Fine Indian survey coordinates, point cloud geometry, and vector cadastral parcels never transit foreign edge proxies, international CDN workers, overseas key-value stores, or international log aggregators. The customer workspace at app.in.gisweaver.com, through which every survey file and feature travels, resolves directly to the India cell and is not proxied by anyone.

• What Cloudflare does. Cloudflare provides the authoritative DNS for GISweaver's domain, the challenge that protects sign-in and similar forms, the dispatch of the Platform's email, the hosting of the public documentation, and the access gate and proxy in front of the staff console at admin.gisweaver.com. The staff console carries account, billing, membership and support records and no survey geometry; text a Customer writes into a support ticket is read there, so survey coordinates should not be written into a ticket.

6.4. Negative List of Sensitive Attributes.

• The DST Guidelines provide for a negative list of sensitive attributes, being attributes that may not be shown or labelled on a map. Explanation 1 to paragraph 8(iii) of the Guidelines states expressly that there will not be any negative list of prohibited areas. The restriction is accordingly one on the labelling and depiction of specified attributes, and not a prohibition on collecting data within any area.

• The Customer is solely responsible for verifying that its survey projects do not attribute, label or depict any entry on the negative list of sensitive attributes as notified by the Department of Science and Technology, and for complying with any separate restriction imposed by the Ministry of Defence, the Survey of India, or any other competent authority in respect of particular installations or activities.

• Customer warrants that all drone mapping, aerial LiDAR, and terrestrial surveys uploaded to the Platform have obtained necessary statutory permissions (including DGCA / DigitalSky flight permissions, local administration clearances, and landholder authorizations where required by law).

6.5. Professional Disclaimer & Boundary Dispute Limitation.

• GISweaver is exclusively a software infrastructure, spatial computing, visualization, and delivery platform. Alonstech is not a licensed land surveyor, is not a cadastral authority, does not issue government revenue records, does not adjudicate boundary or encroachment disputes, and does not warrant, determine, or guarantee legal land ownership titles, property boundaries, or easements.

• All spatial coordinates, boundary lines, contour levels, cross-sections, alignment stations, and cut-and-fill volumetric estimates calculated or rendered by the Platform represent mathematical and computational models derived from Customer-supplied source inputs.

• The Customer (as a qualified surveying professional or engineering enterprise) remains solely and exclusively responsible for the technical accuracy, ground-truthing, native SRID datum verification, quality assurance, regulatory compliance, and legal certification of survey deliverables supplied to downstream clients, tender authorities, arbitral tribunals, courts, or government revenue departments.

• No Legal Evidence on Alonstech's Part: No measurement, calculation, visualization, export, or map rendered by GISweaver constitutes certified legal survey evidence, cadastral proof, or boundary determination on Alonstech's part. In the event of any boundary, title, or property dispute between Customer and any third party, Alonstech shall have no liability, and Customer shall defend and indemnify Alonstech under Section 14.3.

7. Intellectual Property & Customer Data Ownership

7.1. Customer Ownership of Survey Data. As between Customer and Alonstech, Customer retains full, exclusive, and unencumbered ownership of all intellectual property rights, copyright, and title in and to all raw survey files, CAD drawings, point clouds, raster orthophotos, vector boundaries, attribute tables, project notes, and documentation uploaded to or created within the workspace ("Customer Data").

7.2. Limited Operational License to Alonstech. Customer grants Alonstech a non-exclusive, worldwide, royalty-free, limited license to access, store, parse, transform, tile, render, and display Customer Data solely and strictly to the extent necessary to provide, maintain, optimize, and support the Service for Customer and its designated collaborators. Alonstech shall not sell, commercialise, aggregate for third-party resale, publicly disclose, or claim ownership of any Customer Data.

7.3. Alonstech Proprietary Rights. Alonstech retains all rights, title, interest, and intellectual property in and to the GISweaver platform, including its software code (Go backend, React frontend, Cesium/OpenLayers integrations, Python ingestion engines), UI/UX designs, design tokens, algorithms, database architectures, APIs, documentation, and the "GISweaver" and "Alonstech" names, logos, and trademarks. Customer shall not reverse engineer, decompile, disassemble, copy, or create derivative works of the Platform.

7.4. Privacy-Preserving Media Processing. Any corporate logo or user avatar uploaded to the Platform is immediately stripped of all embedded metadata (including camera GPS coordinates and timestamps): the image is decoded to its pixels alone, bounded, scaled, and re-encoded afresh, and only that re-encoded image is kept. The file as uploaded is never stored. The process is described in Section 4.1 of the Privacy Policy.

7.5. Adding a Delivery's Files to Your Own Project. Adding a received delivery's files to a project is a plan capability that is off by default. Where an Organisation whose plan includes it adds the files of a delivery it has received (Section 3.5) to one of its own projects, the project must be in Draft or Review; the Platform copies each delivered file into that Organisation's own storage as a file of that project and checks and files it as it checks and files an upload under Section 3.1 — a point cloud, GeoJSON, DXF or TIFF joins the draft and a PDF, archive or photograph is kept with the project — and records beside each file which Organisation delivered it, from which release, under which name and when. A layer, tiles or an elevation grid the delivering Organisation's release derived from a file is not copied; the draft derives its own from the file. The copies count towards that Organisation's storage from the moment they are added. They are Customer Data of that Organisation for the purposes of Section 7.1, and are stored, billed, renamed, deleted, published and erased as that Organisation's own data; the delivering Organisation retains its ownership under Section 7.1 of the underlying survey data, and adding the files grants the receiving Organisation only such rights in that data as the two Organisations have agreed between themselves. Alonstech is not a party to, and takes no position on, that agreement. The copies are unaffected by the delivering Organisation later retiring the files, closing the delivery, or erasing its account, and nothing the receiving Organisation does with them changes the delivering Organisation's release, delivery or receipt. Files cannot be added from a delivery whose period has ended, or which was withdrawn, revoked, retired, held or paused. Adding the files is written to the receiving Organisation's audit trail; the delivering Organisation is not told.

8. Acceptable Use Policy (AUP) & Platform Restrictions

8.1. Prohibited Activities. You agree that you and your authorised users shall not:

• Upload any survey or spatial dataset violating the sovereignty, integrity, or national security of India or in violation of the National Geospatial Policy 2022.

• Upload, store, or transmit any material containing computer viruses, trojans, worms, ransomware, corrupted files, or malicious code designed to disrupt or compromise the Platform or other users.

• Attempt to probe, scan, test the vulnerability of, or breach any security, authentication, or tenant-isolation controls of GISweaver.

• Use any automated scraper, crawler, spider, or robotic extraction tool to harvest data from the Platform without prior written authorization.

• Resell, sublicense, lease, or operate a commercial timeshare service bureau using GISweaver without an explicit Enterprise partner contract with Alonstech.

• Impersonate any person, entity, or surveying authority, or falsely state or misrepresent an affiliation with any governmental revenue or survey department.

8.2. Quarantine & Enforcement. Alonstech quarantines, rejects or blocks any uploaded file that fails checksum verification, format identification or the structural validation described in Section 3.1, and reserves the right to do so in respect of any file that fails a malware check where such checking is in force. Where an egregious violation of national security or statutory law occurs, Alonstech may suspend the offending workspace in accordance with Section 12.

9. Operational Telemetry

9.1. Collection and Use. By using the Platform you accept that operational telemetry — system metrics, error reports and performance measurements about the Platform itself — is collected and used to keep the Service reliable, to diagnose and fix faults, and to improve performance.

9.2. What It Does Not Contain. This telemetry is designed so that it carries no survey data and nothing that names a person: the attribute names under which a name, an email address, a coordinate, a file name, a token or a tax identifier would be recorded are refused before it leaves the Platform. Free text it carries, such as an error message or the path of a page in the browser, is not screened word by word. It does carry the random identifiers the Platform assigns to accounts, to staff accounts and to Organisations, so that a fault can be traced to the request that caused it; these are pseudonymous identifiers, which Alonstech can link to a person through its own records, so they are personal data. If we ever find telemetry carrying survey data or information that names a person, we treat it as an incident, remove it and close the cause.

10. Availability & Maintenance

10.1. Availability. Alonstech aims for the core API, the authenticated workspace and release viewing to be available for 99.9% of each calendar month, excluding planned maintenance and Force Majeure events. That is an aim and not a commitment: during the beta (Section 1.6) no availability is guaranteed and no service credit is payable. The Platform's database presently runs in a single availability zone, so a failure of that zone interrupts the Service until it is restored. Where Alonstech declares that the Platform was unavailable, open deliveries are extended under Section 3.5.

10.2. Maintenance. The database's automatic maintenance window is 01:00 to 02:00 IST on Mondays. New releases of the Platform, including database migrations and security fixes, are deployed when they are ready and at any hour, and a deployment or a maintenance action may interrupt the Service briefly. The Platform has no mechanism for announcing maintenance in advance; where Alonstech plans downtime that it expects to be significant, it will tell Organisation Owners by email beforehand.

10.3. Platform Portability & Cloud Exit. To safeguard Customer continuity against vendor lock-in or single-cloud failure, Alonstech builds on open, portable technologies — Go, PostgreSQL and PostGIS, OCI containers, and S3-compatible object storage — and confines its dependence on any one cloud provider, so that complete workspace databases and stored files can be exported and restored to independent sovereign infrastructure without proprietary dependencies.

• Alonstech commits to conducting a documented restore-and-exit drill at least once in every twelve (12) month period, and to recording its date and outcome. As at the effective date of these Terms no such drill has yet been performed, and Alonstech makes no representation that a restore or exit has been rehearsed. Portability is a property of how the Platform is built; it is not, until a drill has been run, a demonstrated operational capability, and these Terms do not pretend otherwise.

11. Intermediary Status & Safe Harbor under Indian Law

11.1. Intermediary Status under the IT Act. With respect to spatial data, cadastral drawings, orthophoto rasters, comments and deliverables uploaded by Customers, Alonstech receives, stores and transmits records on behalf of another person and accordingly considers itself an "intermediary" within the meaning of Section 2(1)(w) of the Information Technology Act, 2000. Whether Alonstech is an intermediary in respect of any particular record, and whether the exemption from liability under Section 79 is available, are matters for determination by a competent authority on the facts. Alonstech does not, by this Section, declare itself to hold that status.

11.2. Conditions of the Exemption. The exemption under Section 79 is expressly conditional: it applies only where the conditions in Section 79(2) are met, and does not apply in the circumstances set out in Section 79(3). Alonstech conducts itself so as to qualify. It does not initiate transmissions, does not select the receivers of transmissions, and does not select or modify the spatial data or deliverables created by Customers; and it observes the due diligence prescribed by the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 (as amended, most recently by G.S.R. 120(E) dated 10 February 2026), including the grievance mechanism at Section 15 below.

12. Term, Suspension & Termination

12.1. Term. This Agreement commences on the date you first register an account or access the Platform and continues until terminated by either party in accordance with these Terms.

12.2. Suspension for Cause. Alonstech may temporarily suspend an Organisation's workspace if:

• required to do so by a competent court of law, law enforcement agency, or statutory government directive;

• the Customer is in material breach of the Acceptable Use Policy (Section 8) or of Indian geospatial regulation;

• the Customer's workspace activities pose an imminent threat to platform security, system integrity, or other tenants.

• Scope of suspension — the default. Suspension for commercial cause, for breach of the Acceptable Use Policy, or under Section 4.6 disables write mutations, new uploads, and invitations, other than the changes Section 4.6 keeps open for a frozen workspace, but retains sign-in, read access and billing management for the Customer's existing data. The suspension check governs changes alone: a request to read or download is not refused because the Organisation is suspended or frozen. A suspension or a freeze does not grant unlimited storage or downloads; what an Organisation may store and download is governed by its plan and Section 4, not by its standing. Withdrawing access the Organisation has given another Organisation remains available whatever its standing: withdrawing a share or a grant of access, switching off its download, and ending a link with a client Organisation are open while it is suspended, frozen or closed, and withdrawing a review invitation or a held delivery while it is suspended or frozen; so is a contact person removing themselves. While an Organisation is suspended, the Organisations it has shared releases with under Section 3.4 cannot read those shares; freezing does not have that effect.

• Scope of suspension — security containment. Where an active security incident is under way, or where a judicial or statutory order so requires, Alonstech may suspend access to an Organisation's workspace in full, including read and export, for as long as containment or the order requires and no longer. The Platform's own suspension never blocks reading, so a suspension of this kind is an operational measure Alonstech takes outside it. Alonstech shall notify the Organisation of such a suspension and of its basis as soon as it is lawful and safe to do so, shall restore read and export access at the earliest point at which doing so is consistent with containment, and shall not use this paragraph for a commercial purpose. Nothing in this paragraph permits deletion or degradation of Customer data.

12.3. Termination by Customer. Customer may terminate this Agreement at any time by closing its account and cancelling all active subscriptions. Prior to account closure, Customer is strongly encouraged to export all survey releases, vector layers, and invoice records.

12.4. Survival. Sections 1, 4.3, 5, 6, 7, 11, 13, 14, 15, 16, and 17 shall survive any termination or expiration of this Agreement.

13. Warranties & Disclaimers

13.1. Mutual Warranties. Each party warrants that it has the valid legal power and authority to enter into this Agreement.

13.2. As-Is Platform Disclaimer. EXCEPT AS EXPRESSLY PROVIDED HEREIN, THE SERVICE IS PROVIDED ON AN "AS IS" AND "AS AVAILABLE" BASIS. TO THE MAXIMUM EXTENT PERMITTED UNDER APPLICABLE INDIAN LAW, ALONSTECH AND ITS DIRECTORS, EMPLOYEES, AND AFFILIATES EXPRESSLY DISCLAIM ALL WARRANTIES OF ANY KIND, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON-INFRINGEMENT.

13.3. No Guarantee of Uninterrupted Spatial Rendering. Alonstech does not warrant that spatial rendering, 3D tiles streaming, or point cloud visualization will be completely error-free or uninterrupted across all hardware configurations, unsupported web browsers, or degraded client internet connections.

14. Limitation of Liability & Indemnification

14.1. Exclusion of Consequential Damages. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL ALONSTECH, ITS AFFILIATES, OFFICERS, DIRECTORS, OR AGENTS BE LIABLE TO CUSTOMER OR ANY THIRD PARTY FOR ANY INDIRECT, PUNITIVE, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR EXEMPLARY DAMAGES, INCLUDING BUT NOT LIMITED TO DAMAGES FOR LOSS OF PROFITS, GOODWILL, WORK STOPPAGE, TENDER DISQUALIFICATION, CADASTRAL PROPERTY DISPUTES, COMPUTER FAILURE, OR LOSS OF BUSINESS REVENUE, ARISING OUT OF OR IN CONNECTION WITH THE USE OR INABILITY TO USE THE SERVICE.

14.2. Aggregate Liability Cap. IN NO EVENT SHALL ALONSTECH'S TOTAL AGGREGATE LIABILITY ARISING OUT OF OR RELATED TO THIS AGREEMENT, WHETHER IN CONTRACT, TORT (INCLUDING NEGLIGENCE), STATUTE, OR OTHERWISE, EXCEED THE TOTAL AMOUNT ACTUALLY PAID BY CUSTOMER TO ALONSTECH UNDER THIS AGREEMENT IN THE TWELVE (12) MONTHS IMMEDIATELY PRECEDING THE EVENT GIVING RISE TO THE CLAIM, OR INDIAN RUPEES FIVE THOUSAND (INR ₹5,000), WHICHEVER IS GREATER. NOTHING IN THIS AGREEMENT SHALL EXCLUDE OR LIMIT LIABILITY THAT CANNOT BE EXCLUDED OR LIMITED UNDER APPLICABLE LAW, INCLUDING LIABILITY FOR FRAUD, FRAUDULENT MISREPRESENTATION, GROSS NEGLIGENCE, OR WILLFUL MISCONDUCT.

14.3. Customer Indemnification. Customer agrees to defend, indemnify, and hold harmless Alonstech, its parent, subsidiaries, officers, directors, and employees from and against any claims, liabilities, damages, judgments, awards, losses, costs, and expenses (including reasonable attorneys' fees) arising out of or relating to:

• Customer's violation of these Terms or the Acceptable Use Policy.

• Customer's infringement of third-party intellectual property, privacy, or land rights.

• Customer's non-compliance with the National Geospatial Policy 2022, 2021 DST Guidelines, or DGCA drone surveying regulations.

• Any boundary, title, easement, encroachment, landholder, tender authority, or engineering dispute arising between Customer and its downstream clients, tender authorities, adjoining landholders, or statutory bodies.

• Any spatial dataset, photograph, Cadastral drawing, or deliverable uploaded, processed, shared, or delivered by the Customer or its authorised users.

15. Grievance Redressal Mechanism

15.1. Designation of Grievance Officer. In compliance with Rule 3(2) of the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 (as amended), Alonstech has designated a Grievance Officer and publishes that officer's name and contact details, together with this mechanism, in this section, accessible through the Terms and Privacy links on the GISweaver website and in the application.

15.2. Grievance Contact Details:

• Grievance Officer: [name published on the website and in the application footer]

• Entity: Alons Advanced Technologies Private Limited

• Registered Address: Alons Advanced Technologies Private Limited, Kerala, India

• Official Grievance Email: grievance@alonstech.com

• Support Email: support@gisweaver.com

15.3. Who May Complain. The mechanism is open to any user of the Platform and to any victim, whether or not that person is a user of the Platform or a Customer of Alonstech.

15.4. Response Timelines under the IT Rules.

• Acknowledgement: The Grievance Officer shall acknowledge receipt of a complaint within twenty-four (24) hours of its receipt.

• Disposal: The complaint shall be resolved within a period of seven (7) days from the date of its receipt. (This timeline was shortened from fifteen days by G.S.R. 120(E) dated 10 February 2026, in force from 20 February 2026.)

• Certain categories of removal request carry shorter statutory periods — thirty-six (36) hours for specified requests under Rule 3(1)(b), and two (2) hours for content of the kind described in Rule 3(2)(b). Alonstech observes the shortest period applicable to the complaint before it.

15.5. Data Protection Grievances. The Digital Personal Data Protection Act, 2023 has been brought into force in stages by notification G.S.R. 843(E) dated 13 November 2025. Sections 5 to 17 of that Act — which include the obligations of a Data Fiduciary, the rights of a Data Principal, and the right of grievance redressal at Section 13 — are not yet in force, and are expected to commence approximately eighteen months from the publication of that notification. Pending commencement, Alonstech voluntarily receives, acknowledges and disposes of data protection grievances through the same officer and on the same timelines set out above, and will comply with the statutory scheme when it commences. Details are set out in Section 15 of the Privacy Policy.

16. Governing Law, Dispute Resolution & Jurisdiction

16.1. Governing Law. This Agreement, its construction, validity, and performance, and all disputes arising out of or related to this Agreement, shall be governed by and construed in accordance with the substantive laws of the Republic of India, without giving effect to any choice of law or conflict of law rules.

16.2. Amicable Negotiation. In the event of any dispute, claim, or controversy arising out of or relating to this Agreement, the parties shall first endeavor in good faith to resolve the dispute through friendly consultation and mutual negotiation between authorised executive officers within thirty (30) calendar days of written notice.

16.3. Arbitration. If the dispute cannot be settled through negotiation within thirty (30) days, it shall be referred to and finally resolved by binding arbitration under the Arbitration and Conciliation Act, 1996 (as amended).

• The arbitration shall be conducted by a sole arbitrator appointed by mutual consent of both parties (or, failing agreement within 15 days, appointed by the High Court of Kerala under the Act).

• The seat and legal venue of arbitration shall be Ernakulam / Kochi, Kerala, India.

• The language of the arbitration proceedings shall be English.

• The arbitral award shall be final, binding, and enforceable in any court of competent jurisdiction.

16.4. Exclusive Judicial Jurisdiction. Subject to the arbitration agreement above, the courts of competent jurisdiction situated at Ernakulam / Kochi, Kerala, India, shall have exclusive jurisdiction over all court proceedings, applications for interim or injunctive relief (including under Section 9 of the Arbitration and Conciliation Act, 1996), or enforcement actions arising under or in connection with this Agreement.

17. Miscellaneous Provisions

17.1. Modifications to Terms. Alonstech reserves the right to modify or update these Terms periodically to reflect changes in platform architecture, statutory regulations, or business practices. Notice of material modifications will be provided at least thirty (30) days prior to their effective date via email to Organisation Owners or prominent in-app notifications. Continued use of the Service following the effective date constitutes acceptance of the modified Terms. While the Platform is in beta, these Terms change as Section 1.6 states: at any time, the version published on this page with its date being the one in force, the notice period in this Section applying from the day Alonstech declares GISweaver generally available, and the limits Section 1.6 sets on such a change applying.

17.2. Severability. If any provision of this Agreement is held to be invalid, illegal, or unenforceable by an arbitral tribunal or court of competent jurisdiction, such provision shall be enforced to the maximum extent permissible, and the remaining provisions shall continue in full force and effect.

17.3. No Waiver. No waiver of any breach or default under this Agreement shall constitute a waiver of any prior, concurrent, or subsequent breach or default.

17.4. Entire Agreement & Incorporation by Reference. These Terms, together with the Privacy Policy, Part B (Trust Commitments) of the Vision, Mission & Governance statement, and any applicable written enterprise addenda, constitute the entire understanding between the parties with respect to the subject matter hereof and supersede all prior discussions, representations, or agreements.

• Part A (Mission & Vision) and Part C (Governance Framework) of that statement are published as statements of intent and of internal practice. They are expressly not incorporated into this Agreement, create no contractual obligation, and are not representations on which the Customer is entitled to rely. Part B alone is contractual, and where Part B and these Terms differ, these Terms prevail.

17.5. Versioning. Each published version of these Terms carries a version identifier, being the date of that version, shown with the document. Acceptance is recorded, with the version in force, when a person creates an account and an Organisation at sign-up and when a person accepts the ownership of an Organisation. A person who joins an Organisation by invitation is not asked to accept these Terms when joining, and uses the Platform under the Terms its Owner accepted. Where these Terms are subsequently modified in accordance with Section 17.1, the modified version takes effect for all Customers on its stated effective date; Alonstech does not require existing Customers to re-accept a modified version except where it states that it does.