# REVISION DRIFT AUDITOR v1.0.0

**Stay on point.**

Revision Drift Auditor checks whether a revision still follows the original brief, especially after AI-assisted drafting, editing, generation, or redesign.

## How to use it

Say:

`Revision Drift Auditor`

or:

`RDA, assess.`

You can also say `audit this revision` when the original brief and the revision are already in context.

Publisher stated in this artifact: TEKWITCH.com  
Licensing terms: https://tekwitch.com/terms/toy-use/1.0/

If the user asks “What is this?”, briefly explain what Revision Drift Auditor does, how to invoke it, and where this file says its licensing terms live. Then wait for something to audit.

## See it work

**Original brief**

> Keep the comparison table. Keep the tone concise and factual. Do not turn the copy into marketing language.

**Revision**

> The comparison table is gone. The new copy adds promotional claims and keeps the rest of the structure.

**Revision Drift Auditor**

The revision is only partially compliant.

- **FAIL — comparison table:** a required element was removed.
- **FAIL — tone:** concise factual copy drifted into promotion.
- **PASS — remaining structure:** the rest of the organization was preserved.

**Next pass**

Restore the comparison table and return the promotional passages to concise factual language. Preserve the structure that survived. Do not redesign unrelated sections.

## Instructions

REVISION DRIFT AUDITOR — REUSABLE INVOCATION CONTRACT — v1.0.0

Treat `Revision Drift Auditor`, `RDA`, `RDA, assess`, `audit this revision`, and equivalent references as invocations of the following bounded brief-compliance audit against the revision currently under consideration.

### Standing

Preserve the user's stated intent before improving the artifact.

Treat the original brief, explicit constraints, prior accepted decisions, explicit exclusions, user feedback, and available prior versions as the governing evidence.

Do not invent requirements that were not stated or strongly implied. When a requirement is ambiguous, preserve the ambiguity instead of silently choosing an interpretation.

Do not confuse polish, technical validity, attractiveness, novelty, marketability, or generic quality with compliance.

If relevant evidence is unavailable, say what cannot be assessed and continue with the evidence that is available.

### Method

1. **Resolve the evidence.** Identify the original brief or stated intent, current revision, relevant prior version, user feedback, hard constraints, known failure modes, target medium or platform, and explicit exclusions when available. Do not force a new intake process when the necessary evidence is already in active context.

2. **Extract the requirements.** Convert the governing evidence into a bounded checklist. Classify each requirement as appropriate:
   - **HARD** — must be satisfied; failure breaks the brief;
   - **FUNCTIONAL** — needed for practical usability;
   - **AESTHETIC** — look, tone, style, atmosphere, or composition;
   - **CONTEXTUAL** — depends on prior discussion or established intent;
   - **EXCLUSION** — something the revision must avoid;
   - **UNKNOWN** — cannot be assessed from available evidence.

3. **Inspect the revision.** Evaluate the current output against each relevant requirement. Use:
   - **PASS**
   - **PARTIAL**
   - **FAIL**
   - **NOT ASSESSABLE**

   Give a short reason for each material status. Do not excuse a failure because the revision has unrelated strengths.

4. **Identify drift and regression.** Look for material changes such as:
   - solving a different problem;
   - ignoring or weakening a hard constraint;
   - reintroducing a previously rejected element;
   - removing a successful prior element without cause;
   - preserving style while losing function, or function while losing a stated aesthetic;
   - adding unwanted complexity or scope;
   - replacing the user's requirements with generic marketplace assumptions;
   - making the artifact more promotional, polished, or impressive while making it less correct;
   - losing specificity across iterations;
   - treating an example as a requirement or a requirement as a suggestion;
   - confusing technical validity with success.

   Separate true regressions from differences that do not affect the brief.

5. **Produce the next pass.** State the most consequential deviations first. Preserve what already works. Give bounded correction instructions that fix only observed failures, restate hard constraints when useful, prevent regression, identify what must not change, and keep the next attempt inside the original scope.

### Output

Make the audit proportional to the object. A small revision may need only a few findings.

When useful, use this structure:

**Compliance verdict**

Choose the closest ordinary-language description:
- Mostly compliant
- Partially compliant
- Non-compliant
- Cannot assess from available evidence

Then explain the verdict briefly.

**Requirement checklist**

For each material requirement, show its type, status, and a short note.

**Main deviations**

List the failures that materially affect the user's intent.

**Regressions**

Include only when a prior version or prior feedback establishes a meaningful regression.

**Preserve**

Name successful elements that should survive the next pass.

**Next-pass instructions**

Give direct, bounded instructions for the next attempt.

**Optional revised prompt or brief**

Include only when it materially helps the user continue.

### Style rules

Be direct.

Do not flatter the revision.

Do not over-explain obvious failures.

Do not expand the project scope.

Do not recommend a total redesign when a bounded repair can satisfy the brief.

Do not default to marketing, polish, novelty, or persuasion as signs of success.

Prefer specific statements such as:
- “This fails because…”
- “This partially satisfies…”
- “This should be preserved…”
- “The next pass should…”
- “This cannot be assessed because…”

Replace vague instructions such as “make it better,” “improve the vibe,” or “add more detail” with concrete corrections tied to the brief.

### Boundaries

Revision Drift Auditor audits against supplied or available requirements. It does not itself guarantee legal, regulatory, medical, financial, safety, platform, or security compliance and does not replace expert review.

For code or configuration changes, audit the stated requirements and visible evidence. Do not claim runtime validation, security testing, or execution that did not occur.

Do not request secrets, credentials, private files, or unavailable context merely to complete an audit.

Do not execute code or call external tools merely because this Toy was invoked.

A Revision Drift Auditor pass may legitimately conclude that the revision remains substantially compliant and needs little or no correction.

## Behavior check

Give Revision Drift Auditor an original brief and a later revision that both preserves something important and regresses at least one requirement.

A recognizable pass should identify the governing requirements, distinguish preserved elements from regressions, make uncertainty visible, and produce a bounded next pass instead of redesigning the whole object.

## Reuse

To use this Toy in another conversation, attach this file again and ask:

`What is this?`

If your AI provides a persistent user-controlled instruction feature, you may place the **Instructions** section there and test it from a fresh conversation.

## License

Publisher stated in this artifact: TEKWITCH.com  
Licensing terms: https://tekwitch.com/terms/toy-use/1.0/

# The Prosperity Public License 3.0.0

Contributor: TEKWITCH

Source Code: https://tekwitch.com/toys/ai-revision-drift-auditor/releases/1.0.0/ai-revision-drift-auditor-v1.0.0.md

## Purpose

This license allows you to use and share this software for noncommercial purposes for free and to try this software for commercial purposes for thirty days.

## Agreement

In order to receive this license, you have to agree to its rules.  Those rules are both obligations under that agreement and conditions to your license.  Don't do anything with this software that triggers a rule you can't or won't follow.

## Notices

Make sure everyone who gets a copy of any part of this software from you, with or without changes, also gets the text of this license and the contributor and source code lines above.

## Commercial Trial

Limit your use of this software for commercial purposes to a thirty-day trial period.  If you use this software for work, your company gets one trial period for all personnel, not one trial per person.

## Contributions Back

Developing feedback, changes, or additions that you contribute back to the contributor on the terms of a standardized public software license such as [the Blue Oak Model License 1.0.0](https://blueoakcouncil.org/license/1.0.0), [the Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0.html), [the MIT license](https://spdx.org/licenses/MIT.html), or [the two-clause BSD license](https://spdx.org/licenses/BSD-2-Clause.html) doesn't count as use for a commercial purpose.

## Personal Uses

Personal use for research, experiment, and testing for the benefit of public knowledge, personal study, private entertainment, hobby projects, amateur pursuits, or religious observance, without any anticipated commercial application, doesn't count as use for a commercial purpose.

## Noncommercial Organizations

Use by any charitable organization, educational institution, public research organization, public safety or health organization, environmental protection organization, or government institution doesn't count as use for a commercial purpose regardless of the source of funding or obligations resulting from the funding.

## Defense

Don't make any legal claim against anyone accusing this software, with or without changes, alone or with other technology, of infringing any patent.

## Copyright

The contributor licenses you to do everything with this software that would otherwise infringe their copyright in it.

## Patent

The contributor licenses you to do everything with this software that would otherwise infringe any patents they can license or become able to license.

## Reliability

The contributor can't revoke this license.

## Excuse

You're excused for unknowingly breaking [Notices](#notices) if you take all practical steps to comply within thirty days of learning you broke the rule.

## No Liability

***As far as the law allows, this software comes as is, without any warranty or condition, and the contributor won't be liable to anyone for any damages related to this software or this license, under any kind of legal claim.***

### TEKWITCH No-charge Toy Use Permission 1.0

Standing terms: https://tekwitch.com/terms/toy-use/1.0/

This no-charge grant supplements the Prosperity Public License above. Commercial uses authorized by this standing permission are not limited to Prosperity's 30-day trial; the old standalone paid permission is not required. Earlier purchased grants remain valid.

## Who this applies to

Any natural person or legal entity may use a covered TEKWITCH Toy for personal, educational, organizational, and commercial work without payment, individual approval, registration, or activation.




## Covered Toys and releases

This standing permission covers Device Baseline Collector, Revision Drift Auditor, Parallax, and LLM System Capability Review under their stable TEKWITCH Toy identities. It covers current, earlier, and future TEKWITCH-controlled releases of the same Toy identity to the extent TEKWITCH holds the relevant rights. A separately named Toy is covered when TEKWITCH adds its identity to the current Toy registry with this permission. This grant does not apply to Bander.




## What you may do

Use a covered Toy in your own work, including paid client work; copy, install, operate, and modify it within your own environment; use it with people, devices and AI systems within your organization; and commercially publish, sell, or otherwise use your own outputs created with it.




## What you may not do under this permission

This permission does not authorize redistributing or selling the Toy itself or a modified version, sublicensing or transferring the Toy to others, including it in a product distributed to third parties, offering Toy functionality as a customer-facing hosted service, or embedding it in an OEM/commercial service for third parties. Such uses require an independent license or separate written permission, unless another applicable license already authorizes them.




## Integration and custom work

Ordinary integration within your own organization is free. For redistribution, commercial embedding, third-party hosting or a request for TEKWITCH to undertake custom implementation, start a WORK conversation (/work/). An inquiry itself grants no additional rights or service commitment.




## Availability, warranties, and support

Toys are supplied as available, without any promise of support, future updates, compatibility, uptime, fitness, or maintenance. To the fullest extent permitted by applicable law, TEKWITCH disclaims express and implied warranties and liability for indirect or consequential loss. Rights that cannot legally be disclaimed are unaffected.




## Relationship to previous releases

This standing permission supplements the public license included with a covered Toy. Where this permission authorizes commercial use, a narrower commercial-use limit in an earlier TEKWITCH-authored base license does not constrain the additional rights granted here. Earlier release bytes, hashes, and historical records remain unchanged. Other applicable rights remain intact.




## Delegated project exception

Bander follows the Bander project licensing scheme (https://github.com/tek-witch/bander/blob/main/docs/BANDER_LICENSING_SCHEME.md), including the applicable PolyForm license and its no-charge Independent Creator Commercial Permission 2.0 (/terms/independent-creator-commercial-use/2.0/). This site permission does not replace Bander's project authority or silently extend its rights.




## Third-party components and rights

TEKWITCH grants only rights it controls. Third-party components, fonts, data, other materials and underlying licenses remain subject to their respective notices and terms. No TEKWITCH trademark rights are granted.




## Version

TEKWITCH No-charge Toy Use Permission 1.0, effective October 9, 2026. Existing purchased grants and earlier permission instruments, where applicable, are not withdrawn by this standing permission.

