architecture.dev Rider to the Gridlight Terms
Last updated 28 October 2026
Published as Section 15, Third-Party Products and Services, of the Gridlight Terms of Service. architecture.dev is sold by Gridlight as the Gridlight Software Factory.
15.1. Scope and precedence
15.1.1 This Rider governs the architecture.dev Components that Subscriber buys through a Gridlight Order Form. It is made between Subscriber and architecture.dev (“architecture.dev”), under Section 3.6 of the Gridlight Terms of Service (the “Gridlight Terms”).
15.1.2 Where this Rider is silent, the Gridlight Terms apply to the architecture.dev Components as if “Gridlight” read “architecture.dev.” This covers confidentiality, payment, governing law and venue.
15.1.3 For the architecture.dev Components, the following apply in this order: (a) the Order Form, (b) this Rider, (c) the Gridlight Terms. The Gridlight SLA does not apply to the architecture.dev Components. Sections 15.3 to 15.5 of this Rider replace it for them.
15.1.4 Gridlight is not responsible for architecture.dev’s obligations under this Rider, and architecture.dev is not responsible for Gridlight’s.
15.2. Definitions
Capitalized terms not defined here have the meanings given in the Gridlight Terms.
- architecture.dev Components: the Platform, the Hosted Environment, Support and any Professional Services listed on the Order Form.
- Platform: architecture.dev’s software and services as described in the Documentation, including updates.
- Hosted Environment: the production instance of the Platform that architecture.dev operates for Subscriber. It excludes staging, preview, sandbox and trial instances, and any Beta Features.
- Response: a first reply from a qualified architecture.dev person that acknowledges the Ticket, confirms its severity and states the next step. An automated reply is not a Response.
- Ticket: a support request submitted through an Authorized Channel (§15.3.4).
- Support Hours: the hours of In-Scope Support stated on the Order Form, or under §15.5.1 if the Order Form is silent.
- Customer Content: data, files, prompts and other material that Subscriber or its Authorized Users submit to the Platform.
- Output: material the Platform generates from Customer Content, including specifications, designs and code.
- Beta Features: features labelled beta, preview or early access.
15.3. Support response
15.3.1 architecture.dev will give a Response to each Ticket within the time below. The clock starts when architecture.dev receives the Ticket through an Authorized Channel.
| Severity | Definition | Response within | Status updates |
|---|---|---|---|
| 1 – Critical | The Hosted Environment is unavailable, or a core function is unusable for all users, with no workaround | 24 hours, counted on Business Days | Every Business Day until a workaround or fix |
| 2 – Major | A core function is materially impaired, or a workaround exists but is burdensome | 24 hours, counted on Business Days | Every 2 Business Days |
| 3 – Minor | A non-core function is impaired, or the issue is cosmetic | 2 Business Days | On change |
| 4 – Request | A question, how-to or feature request | 3 Business Days | On change |
15.3.2 Business Days are Monday to Friday, excluding US federal holidays. Response times count only the hours that fall on a Business Day. architecture.dev provides no support on weekends or US federal holidays. For example, a Severity 1 Ticket received at 5 p.m. US Eastern on a Friday requires a Response by 5 p.m. US Eastern on the following Monday.
15.3.3 Support Effort. architecture.dev will use commercially reasonable efforts to resolve or work around a Ticket. Resolution times are targets, not commitments.
15.3.4 Authorized Channels are support@architecture.dev and the in-product support form. A Ticket that reaches Gridlight first is received by architecture.dev when Gridlight hands it over through the channel agreed between Gridlight and architecture.dev. architecture.dev may reclassify a Ticket’s severity under the definitions above, and will tell Subscriber why.
15.3.5 Support Tickets. Each Ticket names the affected component, the steps to reproduce the problem, its impact and a contact. Tickets about the Gridlight Solution itself go to Gridlight under §14.
15.3.6 Missed Responses. If architecture.dev misses a Response time three or more times in a calendar quarter, Subscriber may require a written corrective plan within 10 Business Days. Six or more misses in two consecutive quarters is a material breach for the purposes of §15.10.3. Apart from that termination right, these are Subscriber’s only remedies for a missed Response time.
15.4. Availability
15.4.1 architecture.dev will make the Hosted Environment Available at least 99.5% of each calendar month (the “Availability Commitment”).
15.4.2 Available means that an authorized user can sign in to the Hosted Environment and load its primary workspace, as measured by architecture.dev’s external monitoring at 1-minute intervals. Availability % = (minutes in the month − Downtime minutes) ÷ minutes in the month × 100.
15.4.3 The following are excluded from Downtime:
- Scheduled maintenance announced at least 48 hours in advance, up to 8 hours a month, held where practical between 10 p.m. and 6 a.m. US Eastern
- Emergency maintenance to fix a security vulnerability, notified as soon as practical
- Failures of the Gridlight Solution, or of Subscriber’s devices, networks, identity provider or other third-party services Subscriber controls
- Outages of a third-party AI model provider, while the Platform’s core functions other than AI generation stay Available
- Suspension under this Rider or the Gridlight Terms, or Subscriber’s breach
- Beta Features and non-production instances
- Force majeure, including a regional outage of architecture.dev’s cloud provider that architecture.dev could not reasonably avoid
15.4.4 Service credits. If monthly Availability falls below the Availability Commitment, Subscriber earns a credit on that month’s fee for the Hosted Environment and Platform. The credit does not apply to fees for the Gridlight Solution or Support Hours.
| Monthly Availability | Credit |
|---|---|
| 99.0% to under 99.5% | 5% |
| 97.0% to under 99.0% | 10% |
| Under 97.0% | 25% |
15.4.5 To receive a credit, Subscriber must request it in writing within 30 days after the end of the month. Credits:
- apply to the next invoice;
- are capped at 25% of that month’s fee;
- are not paid in cash; and
- are forfeited when the subscription ends.
Gridlight applies credits on its invoice to Subscriber.
15.4.6 Chronic failure. If Availability is below 99.0% in any three months of a rolling six-month period, Subscriber may terminate the architecture.dev Components on 30 days’ notice. Subscriber then receives a pro-rata refund of prepaid fees for the unused term.
15.4.7 Credits under §15.4.4 and termination under §15.4.6 are Subscriber’s sole and exclusive remedies for any failure to meet the Availability Commitment.
15.4.8 architecture.dev will keep a status page at architecture.dev/status. Within 5 Business Days of any Severity 1 outage lasting more than one hour, it will post a summary of the root cause.
15.4.9 Backups and recovery. architecture.dev backs up Customer Content in the Hosted Environment at least daily and keeps backups for 30 days. The recovery point objective (“RPO”) is 24 hours, and the recovery time objective is 24 hours. Section 12.3.2, which requires Subscriber to keep its own backups, applies only to data on Registered Devices.
15.5. Support
15.5.1 The Quote/Order Form sets Subscriber’s Support Hours, the period they cover and the hourly rate, all of which may vary by Subscriber.
15.5.2 Scope. Support falls into three categories:
| In-Scope Support (draws on Support Hours) | No charge (never draws on Support Hours) | Out of scope (requires a Change Request) |
|---|---|---|
| How-to questions about Platform (AI or Software Factory) features and the Documentation | Diagnosing and fixing a confirmed defect in the Platform (AI or Software Factory) | Designing, specifying or building Subscriber’s own applications, beyond guidance on how to use the Platform (AI or Software Factory) to do so |
| Configuring Platform settings, users, roles and SSO | Restoring the Hosted Environment after an outage (§15.4) | Custom code, integrations, scripts or data migrations |
| Diagnosing a problem until it proves to be a Gridlight defect, at which point it moves to no charge | Security incidents caused by Gridlight Software | Problems in the Subscriber’s systems, networks, identity provider or other third-party services |
| Guidance on upgrading to a new Platform release | Responses to any Ticket(s) (§15.3) | Training beyond 2 sessions a year (or the number on the Order Form); training for end users |
| Reviewing Platform logs and usage at Subscriber’s request | Consulting, architecture review, or work on Output after it leaves the Platform | |
| On-site work, and work outside Business Days at Subscriber’s request |
15.5.3 Classification. At triage, architecture.dev decides whether a request is In-Scope Support, a no-charge defect or out of scope, and records the decision on the Ticket.
Before starting out-of-scope work, architecture.dev gives Subscriber a written Change Request. It contains a description of the work, an estimate of hours and the rate. Out-of-scope work starts only after Subscriber approves the Change Request in writing; email is sufficient. The work is performed under Section 7.2 and billed at the hourly rate under §15.5.1. Out-of-scope work that Subscriber has not approved is not billable.
15.5.4 Metering. Support Hours are recorded in 15-minute increments against a named Ticket. Subscriber may view the running balance at any time. architecture.dev sends a monthly statement of hours used per Ticket.
15.5.5 Disputes. Subscriber may dispute a classification or an entry within 15 days of receiving the monthly statement. The parties’ support leads will resolve the dispute in good faith within 10 Business Days. Undisputed entries are final.
15.5.6 Balance. architecture.dev notifies Subscriber when 75% and when 100% of Support Hours have been used. After Support Hours are used up, In-Scope Support continues at the hourly rate only if Subscriber approves. Otherwise, only Responses under §15.3 and no-charge work continue.
15.5.7 Expiry. Unless the Order Form provides a rollover, unused Support Hours expire at the end of the period they cover and are not refundable or creditable.
15.5.8 Subscriber may name up to three (3) Authorized Contacts, or the number stated on the Order Form. Only Authorized Contacts may open Tickets and approve Change Requests.
15.6. Customer Content and data protection
15.6.1 architecture.dev processes Customer Content only to provide the architecture.dev Components and as Subscriber instructs. It does not sell Customer Content and does not use it to train AI models.
15.6.2 architecture.dev hosts Customer Content in the United States. It maintains administrative, physical and technical safeguards no less protective than those described in its Security Overview. These include encryption in transit and at rest, and access limited to personnel who need it.
15.6.3 architecture.dev uses the subprocessors listed at architecture.dev/legal/subprocessors, including its cloud host, Amazon Web Services, and its AI model providers. It gives 30 days’ notice of any new subprocessor, during which Subscriber may object.
15.6.4 After confirming a security breach that affects Customer Content, architecture.dev notifies Subscriber without undue delay, and in any event within 72 hours.
15.6.5 If Customer Content includes personal data, the architecture.dev Data Processing Addendum applies and is incorporated by reference.
15.6.6 architecture.dev may use aggregated, de-identified usage data to operate and improve the Platform, in the same way Section 13.3 permits Gridlight.
15.7. AI features and Output
15.7.1 As between the parties, Subscriber owns Output. architecture.dev assigns to Subscriber any rights it has in Output. The assignment excludes rights in the Platform and in architecture.dev’s pre-existing templates, components and know-how that appear in Output. Subscriber receives a perpetual license to use those as part of the Output.
15.7.2 Output is generated by AI. It may be inaccurate or incomplete, and it may be similar to output generated for others. Subscriber is responsible for reviewing Output before relying on it or deploying it.
15.8. Intellectual property
architecture.dev keeps all rights in the Platform, the Documentation and any improvements to them, including improvements suggested by Subscriber. Subscriber keeps all rights in Customer Content.
15.9. Warranties, liability and indemnity
15.9.1 architecture.dev warrants that:
- the Platform will perform materially as described in the Documentation; and
- Support will be performed in a professional manner.
Subscriber’s remedy for breach of these warranties is re-performance or a fix. If architecture.dev cannot fix the breach within 30 days, Subscriber may terminate the affected component and receive a pro-rata refund. All other warranties are disclaimed, as in Section 8.4. Beta Features are provided as is.
15.9.2 Each party’s total liability under this Rider is capped at the fees paid or payable for the architecture.dev Components in the 12 months before the claim. The cap does not apply to the matters excluded in Section 9: payment obligations, breach of confidentiality and indemnification obligations. Section 9.1, which excludes indirect and consequential damages, applies.
15.9.3 architecture.dev will defend Subscriber against third-party claims that the Platform infringes intellectual property rights, on the terms of Section 10. Subscriber will defend architecture.dev against third-party claims arising from Customer Content on the same terms. architecture.dev has no obligation for claims arising from Customer Content, or from Output that Subscriber modifies, combines with other material or deploys.
15.10. Term, termination and changes
15.10.1 This Rider runs for the Subscription Term on the Order Form and renews with it.
15.10.2 If Subscriber’s Gridlight subscription ends, the architecture.dev Components end with it. If the commercial relationship between Gridlight and architecture.dev ends, architecture.dev will continue to provide the architecture.dev Components until the end of the paid term, either directly or through Gridlight.
15.10.3 Either party may terminate the architecture.dev Components for uncured material breach, on the terms of Section 12. The immediate cut-off in Section 12.3.1 does not apply to Customer Content in the Hosted Environment. For 30 days after termination, Subscriber may export that content in a zip format. architecture.dev then deletes it within a further 30 days, except where the law requires it to keep the data.
15.10.4 architecture.dev may update this Rider by publishing a new version. A new version applies to Subscriber only from Subscriber’s next renewal. No change may materially reduce the commitments in Sections 15.3 to 15.5 during a paid term.
15.10.5 Governing law and venue follow Section 13.1: Texas law, and the state or federal courts in Tarrant County, Texas. Notices to architecture.dev go to legal@architecture.dev.