Our approach to AI

AI is the first thing many people ask us about, and they deserve a straight answer: We don’t use generative AI in the novels we make, commission, co-produce, or publish.

For everything else, we decide case by case, based on a set of principles.

Our guiding principles

We ask two questions about any use of AI:

Does it lower the quality of the work?
Does it devalue or replace the skill of a person?

If the answer to either one is yes, we don’t allow it.

The first question protects the people who read novels. The second protects the people who create them.

Who we listen to

To answer these questions, we look to the professional communities closest to the work. Guilds and professional associations negotiate on behalf of their members, and they see firsthand how AI is being used against them.

They’ve written protections in response, and we rely on their experience to measure harm. Where they’ve drawn a line, we won’t cross it.

These organizations don’t speak for us or endorse Inkweaver. We follow their lead because they know the problems in their professions best.

Writers Guild of America

Most of our screenplays come from film and television writers, so we follow and exceed the principles of the Writers Guild of America (WGA). Under the WGA’s agreement with the studios:

AI isn’t a writer. AI-generated material can’t count as a writer’s literary material or source material, so it can’t be used to reduce their credit or pay.
A studio can’t require a writer to use AI.
A studio must tell writers when material it gives them was generated by AI.
A writer may choose to use AI if the studio agrees.
Studios must meet with the WGA to review how they use AI, and tell the guild when they license writers’ work to train AI.

SAG-AFTRA

Voice actors are represented by SAG-AFTRA. Its video game agreement requires a performer’s consent before their voice is used to make an AI replica, and requires the studio to disclose how the replica will be used.

We don’t use AI replicas of anyone’s voice at all.

Other professional organizations

Illustrators, concept artists, and composers don’t have a guild agreement that covers the work we commission. Their professional organizations, like the Authors Guild, the Graphic Artists Guild, and the Concept Art Association, have set out shared principles:

Consent before anyone’s work is used to train AI.
Credit and payment when it is.
Transparency about when AI was used.

Again, we go further, and hold artwork and music to the same standard as we do for writing.

Professional Software Engineering Foundations

Software engineering has no formal guild or standard agreement on AI, but large open-source projects have written their own rules for AI-assisted code. The Linux kernel’s guidelines are among the most widely followed:

A person must review all AI-assisted code, and takes full responsibility for it.
Only a person can sign off on a contribution. An AI can’t certify its own work.
AI-assisted changes name the tool that helped.

How we build Inkweaver covers the workflow we add on top of these.

No generative AI in our novels

For our novels, we go further than the guilds. The WGA lets each writer decide whether to use AI. For our titles, we’ve made that decision for everyone: no generative AI.

Every novel we make, commission, co-produce, or publish is made by people. No generative AI is used in its writing, artwork, music, or voice acting. This applies to our own team and to everyone we choose to work with. If you’re unsure whether a tool counts, the two questions above decide.

How we check the work

We don’t use AI detectors. They’re unreliable, and a false result would hurt the people this policy is meant to protect.

We look at the work itself, for the mistakes AI makes routinely:

Artwork: all those fingers, patterns that repeat unevenly, impossible architecture, geometric oddities.
Writing: continuity breaks, rigid cadence, lack of polyphony.
Voice acting: unnatural or missing breathing, mispronunciation, flat cadence.
Music: smeared or mushy attacks, structure that wanders without purpose.

When work shows these flaws, we name each one and ask for a rework. That isn’t an accusation of using AI. We can’t tell from the work alone whether AI caused the flaws, so we don’t guess. We ask for the fix either way.

Working files are the other half of the evidence. Drafts, layered artwork, and project files show how a piece was made, and our contracts ask for them.

If the rules are broken

For our employees, using generative AI for creative work in violation of this policy is a serious breach of their employment agreement. For contractors and partners, it is grounds for terminating the agreement.

Anyone working at a professional level can fix, or explain, the flaws we name in a rework. If flagged work can’t (or won’t) be fixed, the partnership ends, whether or not AI was the cause.

How we build Inkweaver

AI affects engineering differently, and there are good reasons to be wary of it. Many employers now require engineers to use AI, but a requirement doesn’t make it good for the work. Many engineers distrust what it produces, and the companies behind the largest models face serious criticism over how they were built.

But engineers also face a difficult job market, especially early in their careers. The vast majority of professional developers now use AI tools, and a new engineer who doesn’t know them is at a real disadvantage. Forbidding AI in our engineering would hold our engineers back, so they may use it at their discretion.

Every AI-assisted change meets the Linux kernel’s baseline: a person reviews it, takes full responsibility for it, and is the only one who can sign off on it.

We go further. Every change to our code, with or without AI, follows the same professional workflow:

Planned architecture. Significant features start with a written design that the team reviews before code is written.
Established design patterns. We build on patterns other engineers already know, so the code is easy to reason about and maintain.
Unit tests. Behavior is covered by tests that run before a change is accepted.
Peer code review. Every change is read and approved by another engineer before it’s merged.
Ownership. The engineer who submits a change understands every line of it, and is responsible for it.

AI only assists with tasks the engineer could do on their own. We don’t assign work to an engineer who isn’t qualified to do it.

How we check the work

The biggest risk with AI in engineering is vibe coding: accepting code an AI wrote without reading or understanding it. Vibe coding skips every step of the workflow above, and it leaves recognizable flaws:

Design: code that ignores the planned architecture, duplicates logic that already exists, or invents its own patterns.
Code: calls to functions or packages that don’t exist, dead code, comments that narrate the obvious.
Tests: tests that assert nothing meaningful, mirror the implementation, or were short-circuited so they pass.
Changes: sprawling diffs that touch unrelated files, workarounds stacked on workarounds, an author who can’t explain their own change.

When a change shows these flaws, we name each one in review and ask for a rework. As with creative work, this isn’t an accusation of using AI. We can’t tell from the code alone whether AI caused the flaws, so we ask for the fix either way.

If the rules are broken

We hold our engineers and development partners to the same standard as our creative partners. Anyone working at a professional level can fix, or explain, the flaws we name in review.

If flagged work can’t (or won’t) be fixed, the partnership ends, just as it does for creative work, whether or not AI was the cause.