# Word list

Preferred spelling, capitalization, and usage for terms in Supabase docs including Supabase
product names. Use your best judgement when applying these rules. They are not intended
to be strict, one-size-fits-all solutions and can evolve with your input. Feel free
to contribute to this list as you write your documentation.

This list is part of the [style guide](./README.md). It is the source of truth for all
documentation consistency.

## Use with an AI agent

To apply this word list with an agent, you can use one of our skills. For more information, see [Write the docs skills](../CONTRIBUTING.md#write-the-docs-skills).

**For agents:** Work in two passes rather than reading this file end to end.

1. Mechanical pass. Read [Phrase groups](#phrase-groups). It collects every literal
   term list in one place, so you can match it against the page in a single read.
2. Judgment pass. Run `grep '^### ' WORD_LIST.md` for the term index, then read only
   the entries that match words on the page. Most entries carry a condition, so read
   the entry before you change a word.

After you draft, run the mechanical pass again in a fresh context to prevent drift.

## Numbers and symbols

### `+`

Don't use `+` to mean _or later_.

- **Recommended**: Postgres 15 or later
- **Not recommended**: Postgres 15+

### `&`

Use _and_ instead of `&` in prose, headings, navigation, and tables of contents.
Keep `&` when it is part of a UI label, code, or a space-constrained table or
diagram label.

## A

### abbreviations

Spell out an unfamiliar abbreviation on first use. Don't expand familiar technical
abbreviations such as API, CPU, HTML, HTTP, or SQL unless the audience needs it.

Use `for example` instead of `e.g.` when practical. If space is constrained, write
`e.g.` with both periods. Use `that is` instead of `i.e.`.

### abort

Use _stop_, _exit_, _cancel_, or _end_ in general prose. Use `abort` when it is the
name of a command, signal, API, or operation.

### above

Don't use _above_ to refer to a location in a document or UI. Link to or name the
section or control. For versions, use _later_.

### access

When possible, use a more specific verb such as _view_, _find_, _edit_, _open_, or
_use_. Keep _access_ when it accurately describes authorization or connectivity.

### admin

Use _administrator_ in prose. Use _admin_ when it is part of a product name, API,
role, command, or UI label.

### agent

Use _agent_ for a system that uses a model and tools to take actions, such as
following a procedure or drafting a page. Lowercase _agent_ unless it is a product
name.

Use _AI agent_ the first time _agent_ could mean a person or an HTTP user agent.
After that, use _agent_.

Use _LLM_ for the model itself. See [LLM](#llm).

### AI

You can use _AI_ without spelling out _artificial intelligence_ when the audience
is familiar with the term. For the model, see [LLM](#llm). For a system that uses
a model and tools to act, see [agent](#agent).

### allowlist and denylist

Use _allowlist_ and _denylist_ as nouns. Prefer a precise verb that describes the
action instead of using either term as a verb.

- **Recommended**: Allow requests from the IP address.
- **Recommended**: Add the IP address to the allowlist.
- **Not recommended**: Allowlist the IP address.

Don't use _blacklist_ or _whitelist_.
When a literal code item contains one of them, format the item as code and explain
what it does.

### allows you to

Use _lets you_, or make the reader the subject of the sentence.

- **Recommended**: You can query the table.
- **Recommended**: The API lets you query the table.
- **Not recommended**: The API allows you to query the table.

### alpha and beta

Use lowercase when describing a release stage. Preserve capitalization when it is
part of an official product name.

### among and between

Use _between_ for distinct items, even when there are more than two. Use _among_
for members of a group or items that aren't distinct.

### and/or

Rewrite to use _and_, _or_, or explicitly state that either or both apply.

### API

Use _API_ for a web API or a language-specific API. Don't use _API_ to mean an
individual method, function, class, or endpoint.

### app and application

Use _app_ for web and mobile software intended for end users. Use _application_
when it is part of an established term, such as _application programming
interface_, or when the distinction is technically useful.

### as and since

Use _because_ when you mean causation. _As_ and _since_ can be mistaken for
references to time.

### authentication and authorization

Authentication verifies an identity. Authorization determines what an
authenticated identity can access or do. Don't use the terms interchangeably.

Avoid _authN_ and _authZ_ in prose. Use _authentication_ and _authorization_.

### auto-

Follow the spelling established by the relevant technology. Common closed forms
include _autoscaling_, _autofill_, and _autogenerate_. Don't invent a hyphenated
variation when an established form exists.

## B

### backend

Write _backend_, not _back-end_ or _back end_.

### base64

Use _base64_ in general prose. Use the capitalization required by a formal name or
literal code item.

### below

Don't use _below_ to refer to a location in a document or UI. Link to or name the
section or control. For versions, use _earlier_.

### black-box, gray-box, and white-box

Prefer a description of what the monitoring or testing method can observe. If the
established term is necessary, define it on first use.

### boolean

Use the spelling and capitalization of the programming-language type when
referring to code. Use lowercase _boolean_ for the abstract data type and uppercase
_Boolean_ for Boolean logic.

### button

Use _button_ only for an element that is actually a button. In desktop
instructions, users _click_ a button. Preserve the exact button label and format
it in bold.

## C

### can, may, might, must, and should

- Use _can_ for ability, permission, or an optional action.
- Use _might_ for possibility or an uncertain outcome.
- Reserve _may_ for policy or legal guidance when possible.
- Use _must_ or _need to_ for a requirement.
- Avoid ambiguous _should_. State whether an action is required, recommended, or
  optional.

### checkboxes

Users _select_ and _clear_ checkboxes. Don't use _check_, _uncheck_, or _deselect_
for these actions.

### click

Use _click_ for buttons, links, and other controls in a desktop interface. Don't
write _click on_. Use _tap_ when the environment is specifically a touch
interface.

### click here

Don't use _click here_ or _here_ as link text. Describe the destination or action.

### client

In API documentation, a _client_ is usually an app that sends requests. Don't use
_client_ as an abbreviation for _client library_ when that could be ambiguous.

Use _concurrent connections_, not _concurrent clients_, when discussing database
connections.

### codebase

Write _codebase_, not _code base_.

### command-line interface

Name the specific interface, such as _Supabase CLI_. Use _CLI_ after the name is
clear.

### config

Use _configuration_ in general prose. Keep _config_ when referring to a literal
file, command, property, or established technical name.

### console and dashboard

Use the product's official name. Don't use _console_ and _dashboard_
interchangeably, and don't call a UI a dashboard unless it presents a dashboard.
Use _Supabase Dashboard_ for the Supabase product.

### currently

Avoid _currently_ when the sentence describes the product's present behavior.
State the behavior directly. See
[Write timeless documentation](./03-page-structure.md#write-timeless-documentation).

## D

### data

Treat _data_ as a singular mass noun: _the data is_ and _less data_.

### data center

Write _data center_, not _datacenter_.

### data source

Use _data source_ in prose. Preserve `datasource` when it is a code item or
official product term.

### data type

Write _data type_, not _datatype_.

### deprecate

Use _deprecated_ when use is discouraged, usually because support will end. Don't
use it to mean _removed_, _deleted_, or _unavailable_.

### dialog

Use _dialog_ for a UI element that presents information or asks for input. Don't
use _dialogue_ or _popup_.

### directory and folder

Use _directory_ in command-line contexts and _folder_ in graphical interfaces.
Match the product UI when it uses a specific term.

### disable

Use _disable_ or _turn off_ for an available feature or option. Don't use
_disabled_ to mean that something is broken or unavailable.

### display

_Display_ is a transitive verb and requires an object.

- **Recommended**: The Dashboard displays the query results.
- **Recommended**: The query results appear.
- **Not recommended**: The query results display.

### docs

Use _documentation_ in prose. Use _docs_ in informal contributor instructions,
repository paths, URLs, or established product names.

### dropdown

Prefer the specific control name, such as _list_ or _menu_. Use _dropdown_ only
when the distinction matters, and don't use _drop-down_.

### dummy

Don't use _dummy_ for placeholders or sample values. Use _placeholder_, _sample_,
or a name that describes the value's role. For the statistical concept commonly
called a dummy variable, use _indicator variable_ or another established,
context-appropriate term.

## E

### easy, quick, and simple

Avoid claiming that a task is _easy_, _quick_, or _simple_. These words can be
subjective and usually add no information. Don't use _easy_, _easily_, _quickly_,
_simple_, or _simply_.

### email

Write _email_, not _e-mail_. Don't use _email_ as a verb; use _send email_.

### enable

Use _enable_ or _turn on_ consistently for activating a feature. When describing
capability, prefer _lets you_ over _enables you_.

### endpoint

Write _endpoint_, not _end point_. Don't use _endpoint_ when the more specific
term is _function_, _method_, or _route_.

### enter

Use _enter_ for adding text to a field. Use _type_ only when the physical act of
typing matters.

### etc.

Avoid _etc._, _and so on_, and _and more_. Introduce a non-exhaustive list with
_including_, _such as_, or _for example_.

### execute

Use _run_ when it has the same meaning. Keep _execute_ when it is the precise
technical term, such as an execute permission or query execution plan.

### extract

Use _extract_ instead of _unarchive_, _uncompress_, _untar_, or _unzip_ in prose.
Preserve literal command names.

## F

### fail over and failover

Use _fail over_ as a verb. Use _failover_ as a noun or adjective.

### filename

Write _filename_, not _file name_.

### file system

Write _file system_, not _filesystem_, unless the latter is part of a code item or
official name.

### fill in and fill out

Users _fill in_ individual fields and _fill out_ an entire form.

### first person

Address the reader as _you_. Don't use singular first person (_I_, _me_, _my_, or
_mine_).

Use _we_ only when it clearly refers to Supabase, not when it means the writer and
reader together.

### foo, bar, and baz

Use meaningful placeholder names that help explain the example. Keep conventional
placeholder names only when the convention itself is relevant.

### frontend

Write _frontend_, not _front-end_ or _front end_.

## H

### hardcode and hardcoded

Write _hardcode_ and _hardcoded_ without a hyphen.

### health and healthy

When possible, state the observable condition, such as _responding_, _available_,
or _passing its health check_. Don't use _healthy_ when it could be ambiguous or
anthropomorphic.

### higher and lower

For version ranges, use _later_ and _earlier_, not _higher_ and _lower_.

### hover

Use _hold the pointer over_ when the reader must wait for the interface to react.
Use _point to_ when no waiting is required.

### HTTPS

Write _HTTPS_, not _HTTPs_.

## I

### ID

Write _ID_, not _Id_ or _id_, except when matching code. Use _identifier_ when it
is clearer.

### impact

Use _impact_ as a noun. Prefer _affect_ as the verb.

- **Recommended**: The change affects performance.
- **Not recommended**: The change impacts performance.

### index

Use _indexes_ as the plural in database documentation. Use _indices_ only in
domains where it is the established term.

### ingest

Use _import_, _load_, or _copy_ for simple data movement. Use _ingest_ when the
operation also performs substantial processing.

### in order to

Use _to_ unless _in order to_ is necessary to prevent ambiguity.

### inline

Write _inline_, not _in-line_.

### internet

Use lowercase _internet_ except at the beginning of a sentence.

## J

### just

Remove _just_ when it is filler. If it means _only_ or _previously_, use the more
specific word.

## K

### key

Don't use _key_ to mean _important_. When referring to a technical key, identify
the kind of key on first use.

### key-value pair

Write _key-value pair_, not _key/value pair_ or _key value pair_.

### kill

Use _stop_, _exit_, _cancel_, or _end_ in general prose. Preserve _kill_ for
literal commands, signals, and established technical operations.

## L

### later and earlier

Use _later_ and _earlier_ for version ranges.

- **Recommended**: Version 2.2 or later
- **Not recommended**: Version 2.2 or higher

### latest, new, and soon

Avoid time-relative descriptions that become stale. Provide a version, date, or
specific product state instead. See
[Write timeless documentation](./03-page-structure.md#write-timeless-documentation)
for the full list of words that fix a page to a moment.

### leverage

Use _use_ or a more specific verb instead of _leverage_.

### lifecycle

Write _lifecycle_, not _life cycle_ or _life-cycle_.

### LLM

Use _LLM_ for the model that reads or generates text. When a page introduces the
term, spell it out once as _large language model (LLM)_, then use _LLM_.

Use _agent_ for a system that takes actions with tools. See [agent](#agent).

### login and log in

Don't use _login_ or _log in_ in prose. Use _sign in_. See
[sign in and sign-in](#sign-in-and-sign-in).

## M

### marketing language

Describe measurable behavior instead of making promotional claims. Don't use:

- _best in class_ and _best-in-class_
- _cutting edge_ and _cutting-edge_
- _effortlessly_
- _game changer_ and _game-changer_
- _hassle free_ and _hassle-free_
- _powerful_
- _seamlessly_

### master and slave

Don't use _master_ and _slave_ together. Prefer terms that describe the
relationship accurately, such as _primary and replica_, _controller and worker_,
or _publisher and subscriber_.

When a literal code item uses either term, format it as code, explain it, and use
the preferred term afterward.

### media type

Use _media type_ rather than _MIME type_. Use _content type_ when referring to the
`Content-Type` HTTP header or when it prevents ambiguity.

### microservices

Write _microservices_, not _micro-services_.

### might

Use _might_ for possibility or an uncertain outcome.

### must

Use _must_ or _need to_ for a requirement. Don't use _must_ for a recommendation.

## N

### native

Use a more precise term when possible, such as _built-in_,
_platform-specific_, or _compiled_. Don't use _native_ to describe people.

### numbers

Spell out zero through nine. Use numerals for 10 and greater. Use numerals
regardless for versions, technical quantities, step and page numbers, prices, and
percentages, and throughout a sentence that mixes a number under 10 with a larger
one.

- **Recommended**: four options, 24 hours, version 3, 128 bits, step 2, 40%
- **Not recommended**: 4 options, twenty-four hours

Spell out ordinals. Group digits in large numbers with commas, counting left from
the decimal point. Write fractions as decimals where practical. Use a hyphen with
no spaces for a range.

- **Recommended**: first, forty-third, 1,532,784 bytes, 0.75, 2012-2016
- **Not recommended**: 1st, 1532784 bytes, three-quarters, 2012 - 2016

Omit a count of steps or items unless the count helps the reader plan. Name the
action or link the heading rather than citing a step or section number.

- **Recommended**: To connect to your database:
- **Recommended**: After you create the project, copy the project URL.

### numbers in product versions

Write an explicit comparison, such as _version 3.0 or later_. Don't use _newer_,
_older_, _higher_, _lower_, or a trailing `+`.

## O

### OAuth 2.0

Write _OAuth 2.0_, not _OAuth2_, _OAuth 2_, or _Oauth_.

### obviously and of course

Remove these phrases. They can sound dismissive and don't help the reader.

### once

Use _after_ if that is what you mean. Use _once_ only to mean one time.

### on-premises

Write _on-premises_, not _on-premise_, _on premise_, or _on prem_.

## P

### performant

Use a measurable or specific description, such as _lower latency_, _uses less
memory_, or _handles more concurrent connections_.

### persist

Avoid using _persist_ as a transitive verb.

- **Recommended**: Store the session.
- **Recommended**: Make the session persistent.
- **Not recommended**: Persist the session.

### plain text and plaintext

Use _plain text_ in general contexts. Use _plaintext_ in cryptography.

### please

Don't use _please_ in normal instructions. Use it only when asking permission,
apologizing for an inconvenience, or requesting an action that primarily benefits
Supabase.

### plugin

Use _plugin_ as a noun and _plug in_ as a verb.

### popup

Use the specific UI element, such as _dialog_, _menu_, or _window_. Don't use
_popup_ or _pop-up_ as a generic noun.

### Postgres

Use _Postgres_, not _PostgreSQL_, outside code and literal third-party names.

### powered by

Don't use _powered by_. Prefer _with_, _by_, or _through_, depending on the
relationship.

### prior to and subsequent to

Use _before_ and _after_.

## R

### read-only

Always hyphenate _read-only_.

### Realtime

Capitalize _Realtime_ when referring to the Supabase product. Use lowercase
_real-time_ as an adjective with its ordinary meaning.

### repository

Prefer _repository_ in documentation prose. _Repo_ is acceptable in informal
contributor instructions and when space is constrained.

### retry

Use _retry_ as a verb or noun. Write around _retriable_, _retryable_, _triable_,
and _tryable_ when practical.

### run time and runtime

Use _runtime_ for an execution environment. Use _run time_ for the time when a
program runs or the duration of a run.

## S

### sanity check

Use _preliminary check_, _confidence check_, or a description of what the check
validates.

### screenshot

Use _screenshot_ as a noun. Use _take a screenshot_, not _screenshot_ as a verb.
Redact secrets and personal information from screenshots.

### select

Use _select_ for choosing an item, selecting text, or marking a checkbox. Preserve
the exact UI label in bold.

### sensitive and confidential

_Sensitive data_ is data whose disclosure might cause harm. _Confidential data_ is
protected against unauthorized access. Use the term that describes the relevant
risk or control.

### setup and set up

Use _setup_ as a noun or adjective and _set up_ as a verb.

- **Recommended**: Complete the setup to set up authentication.
- **Not recommended**: Setup authentication.

### sign in and sign-in

Use _sign in_, _sign out_, and _sign up_ as verbs. Use the hyphenated forms
_sign-in_, _sign-out_, and _sign-up_ as nouns or adjectives. Match the product UI
labels **Sign in**, **Sign out**, and **Sign up**.

Keep _login_, _log in_, _logout_, _log out_, and `logOut` when quoting
third-party UI or when they are part of code, routes, URL slugs, CLI commands, or
established feature names such as _social login_.

### singular they

Use _they_, _them_, and _their_ as gender-neutral singular pronouns. Don't use
_s/he_, _he/she_, _(s)he_, or _him/her_.

### slang abbreviations

Don't use internet slang in documentation, such as _tl;dr_, _ymmv_, _rtfm_, _imo_,
or _fwiw_.

### spin up

Use _create_ or _start_ unless you are literally describing a spinning disk.

### SQL

Write _a SQL query_, not _an SQL query_. Use lowercase SQL keywords in code
examples unless uppercase is required by the surrounding convention.

### SSH

Don't use _SSH_ or `ssh` as a verb.

- **Recommended**: Connect to the server by using SSH.
- **Recommended**: Use the `ssh` command.
- **Not recommended**: SSH into the server.

### startup and start up

Use _startup_ as a noun or adjective and _start up_ as a verb.

### Supabase

Capitalize _Supabase_ outside code. Use _Supabase Platform_ with both words
capitalized. Match literal package names, commands, URLs, and code.

## T

### table name

Write _table name_ as two words. Format a specific table name as code.

### target

Avoid using _target_ as a verb for people. Use _intended for_, _designed for_, or
another description of the audience.

### terminate

Use _stop_, _exit_, _cancel_, or _end_ unless _terminate_ has a specific technical
meaning in the documented context.

### third party and third-party

Use _third party_ as a noun and _third-party_ as an adjective. Don't abbreviate
either form with `3rd`.

### this and that

Add a noun after _this_ or _that_ when the reference could be unclear.

- **Recommended**: This setting controls connection pooling.
- **Not recommended**: This controls connection pooling.

### timeout and time out

Use _timeout_ as a noun or adjective and _time out_ as a verb.

### timestamp

Write _timestamp_, not _time stamp_.

### time zone and time-zone

Use _time zone_ as a noun and _time-zone_ as an adjective.

### toggles

Users _enable_ and _disable_ features with toggles. Match and bold the visible
label. Don't instruct the reader to _click the toggle_ when the intended state can
be stated directly.

## U

### UI

Use the specific interface or page name when possible. Use _UI_ only when
discussing a user interface as a general concept.

Match visible UI labels exactly and format them in bold. Describe the element with
the correct noun when it improves clarity, such as _the **Connect** button_ or
_the **Database password** field_.

### URL

Use _URL_, not _web address_, when writing for developers. Use descriptive link
text rather than exposing a URL unless the URL itself is the subject.

### user

Address the reader as _you_. Use _user_ for a person who uses the software that
the reader is building or administering.

### utilize

Use _use_, not _utilize_ or _utilise_. Use _utilization_ only when referring to the
measured proportion of a resource in use.

## V

### vague verbs

Describe the concrete action:

- _view and resolve errors_ instead of _handle errors_
- _create, edit, or delete tables_ instead of _manage tables_
- _query and update data_ instead of _work with data_

Choose a different precise verb if the suggested replacement doesn't match the
actual operation.

### vCPU

Use _vCPU_ (plural _vCPUs_) for the CPU resources of Supabase compute sizes.
Don't describe Supabase compute in _cores_.

_Core_ remains correct for hardware the reader owns or manages, such as
self-hosting requirements or a migration VM, and in general CPU discussion.

- Recommended: The 16XL compute size has 64 vCPUs.
- Recommended: Run the migration from a VM with 8 CPU cores.
- Not recommended: The 16XL compute size has 64 cores.

### versus

Write _versus_ in prose, not _vs._ Use `vs` only when it is part of a literal name
or when space is constrained.

## W

### web

Use lowercase _web_. Use the capitalization established by formal names such as
_WebAssembly_.

### we

Don't use _we_ to mean the writer and reader together. Use _you_ for the reader.
_We_ is acceptable when it unambiguously means Supabase.

### while

Use _while_ for events that occur at the same time. Use _although_ or _whereas_
for contrast. Use _while_, not _whilst_.

### will and would

Use present tense for current product behavior. Use _will_ for an actual future
event, not a predictable result. Replace _would_ with _can_ when describing
capability.

### workload

Use a more specific term, such as _app_, _service_, _database_, or _job_, when the
meaning is known. If _workload_ is the established technical term, define its
scope on first use.

## Y

### you

Address the reader as _you_. Use _user_ only for a person who uses the software
that the reader is developing or administering.

## Phrase groups

The alphabetical entries explain the intent behind each rule. This section collects
the full term lists in one place, grouped by the problem they cause.

Every heading here is prefixed with `Group:`, so `### Group:` selects the whole set.
Where a group entry and its alphabetical entry differ, the alphabetical entry governs.

### Group: Filler

Don't use _actually_, _easily_, _easy_, _just_, _let's_, _obviously_,
_of course_, _please_, _quickly_, _simple_, _simply_, or _that's it_. Remove the term or state the intended meaning directly.
_please_ is the exception: keep it when asking permission, apologizing for an
inconvenience, or requesting an action that primarily benefits Supabase.

### Group: Marketing language

Don't use _best in class_, _best-in-class_, _cutting edge_,
_cutting-edge_, _effortlessly_, _game changer_, _game-changer_, _hassle free_,
_hassle-free_, _powerful_, or _seamlessly_. Describe specific behavior or
measurable results instead.

### Group: Vague verbs

Use _view and resolve errors_ for _handle errors_, _create, edit, or delete tables_
for _manage tables_, and _query and update data_ for _work with data_. Use a
different precise replacement when none of these match the operation.

### Group: Apologies

Don't use _oops_ or _sorry_. State what happened directly. Apologize
only when an apology is genuinely useful to the reader.

### Group: First person

Don't use _I_, _I'm_, _me_, _my_, or _mine_. Address the
reader as _you_ and use an explicit noun for other actors. Use _we_ only when it
clearly refers to Supabase. See [first person](#first-person) for the full rule.

### Group: Gender-neutral pronouns

Don't use _s/he_, _he/she_, _(s)he_, or _him/her_. Use the
singular _they_ or rewrite the sentence.

### Group: Inclusive language

Don't use these terms:

- _mankind_: use _humankind_ or _people_
- _manmade_: use _manufactured_, _artificial_, or _synthetic_
- _middleman_: use _intermediary_
- _blacklist_: use _denylist_ or a more precise term
- _whitelist_: use _allowlist_ or a more precise term

### Group: Abbreviations

Write _e.g._ with both periods, not _eg._ or _eg_. Replace _i.e._, _ie._, and
_ie_ with _that is_. Prefer _for example_ and _that is_ in prose when space
allows. See [abbreviations](#abbreviations) for when to spell one out on first use.

### Group: Powered by

Don't use _powered by_. Use _with_, _by_, or _through_, depending on the
relationship.

### Group: Preferred usage

Use:

- _Postgres_ for _PostgreSQL_
- _concurrent connections_ for _concurrent clients_
- _use_ for _utilize_ and _utilise_
- _uses_ for _utilizes_ and _utilises_
- _using_ for _utilizing_ and _utilising_

### Group: Direct, concise language

Don't use these phrases:

- _aforementioned_: name the item
- _amongst_: use _among_
- _endeavor_ or _endeavour_: use _try_
- _facilitate_: use _help_ or describe the action
- _for the purpose of_: use _to_
- _in order to_: use _to_
- _leverage_: use _use_ or a more precise verb
- _prior to_: use _before_
- _subsequent to_: use _after_
- _whilst_: use _while_

### Group: Internet slang

Don't use _tl;dr_, _ymmv_, _rtfm_, _imo_, or _fwiw_. Write out the
meaning or remove the aside.

## Attribution

Portions of this word list are modifications based on work created and shared by
Google and used according to the terms of the
[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/).
See the
[Google developer documentation style guide word list](https://developers.google.com/style/word-list)
for the original work. Supabase-specific guidance and adaptations are maintained
in this repository.