AI Policy
LateralTranslucence LLC — Last updated August 2026
Transparency, by design
We design, build, and write every application ourselves. AI tools are part of our process — the way a linter or a design system is — not a replacement for hands-on work or human judgment. This page explains where AI fits in.
There are two separate questions here, and we answer them separately below: how we use AI to build our software, and where AI appears inside the software itself. They have different rules, because they carry different risks.
The only AI tool we use, in either capacity, is Claude, built by Anthropic. We chose it specifically for Anthropic's focus on AI safety and responsible development, and we don't run client work through other AI platforms.
Where AI assists in our process
| Area | How AI is used |
|---|---|
| Bug diagnosis & fixes | Helps trace issues faster and test possible fixes |
| Security | Flags common vulnerabilities and reinforces best practices during code review |
| Accessibility | Assists with audits (WCAG) and remediation suggestions |
| SEO | Supports on-page structure, metadata, and technical SEO checks |
| Copy | Helps draft and refine website and app copy, which we edit before it ships |
What stays human
Every line of code, every design decision, and every piece of copy that reaches production has been reviewed and finalized by a human. AI output is a starting point, not a deliverable — nothing ships without review.
Where AI appears inside Spryly™
One feature uses AI at the moment you use it, rather than while we build: upgrade briefings.
When you ask Spryly™ whether you should take an upgrade, we send the package's published release notes — the same notes anyone can read on GitHub or the package's changelog — to Claude, and ask it to sort what they say into breaking changes, deprecations, and other notable changes. You get structured facts with a link back to the release they came from.
This output is generated at the time you request it and is not reviewed by a human first. That is a real difference from everything in the section above, and we'd rather say so plainly than let the sentence about human review quietly cover something it doesn't. Three things constrain it instead:
- It only reports, never infers. The model is instructed to extract only what the notes explicitly state, and never to speculate or draw on outside knowledge of the package. Where the notes say nothing about a breaking change, the briefing says nothing.
- Every claim is traceable. Each item links to the release whose notes produced it, so you can check any statement against the source in one click. If we can't point at where a claim came from, we don't show it.
- Silence is reported as silence. When a release published no notes, or we couldn't reach them, the briefing says which — it does not fill the gap with plausible-sounding text.
A briefing is a reading aid, not a substitute for reading the notes or testing the upgrade. Treat it the way you would treat a colleague's summary: useful, quick, and worth verifying before you rely on it.
Everything else Spryly™ tells you — whether a newer version exists, whether your dependencies allow you to take it, which packages block an upgrade and what would unblock them — is computed directly from your lockfiles and registry metadata. No AI is involved in any of it, and none of those answers can be affected by a model.
What we send, and what we never send
For upgrade briefings we send only publicly published release notes and changelog text, plus the package name and version they belong to.
We do not send your source code, your lockfiles, your dependency graph, your repository contents, your repository or project names, your account details, or anything else that identifies you. The model is never told who asked. Because the notes are public and the request is anonymous, the resulting summaries are shared across all users and reused rather than regenerated per person.
One clarification worth making plainly, because "never sent" and "never read" are different promises. On Pro accounts, a briefing for a repository-backed project does read your source files — that is how it can tell you which of a release's changes name something your code actually uses. That search runs on our servers against your own repository, and what it finds is a list of file paths and line numbers. The code itself is discarded when the request finishes, is never stored, and is never part of anything we send to Claude.
Data handling
We don't share confidential client data, credentials, or proprietary source code with third-party AI tools beyond what's required for the task at hand, and always in line with the confidentiality terms of our engagement. See the Privacy Policy for how client data is handled more broadly.
Questions
If you have questions about how we use AI, reach out any time at hi@spryly.io.