# Before AI builds your internal tool, define the rules

Plan an AI-built internal tool around a real business job. Define records, permissions, exceptions and shared identifiers before adding more modules.

By Daltn editorial team. Published 2026-11-01.
Canonical: https://daltn.tech/feeds/ai-generated-internal-tools-business-rules/

## What should you define before AI builds an internal tool?

AI can help build an internal tool, while useful software still needs clear records, permissions, rules and tests. Begin with one job, define a completed result and inspect the generated interface against realistic examples. Connect later modules through shared identifiers, and review consequential actions before the tool changes important business records.

## Keep these in mind

- Define the workflow before refining the interface.
- Test who may see and change each kind of record.
- A working demo needs an owner for updates, recovery and data export.

## Begin with a job, not an empty prompt

“Build our operations system” leaves the most important decisions unstated. “Help the workshop track repair jobs from intake to collection” is a better beginning. It names the people, records and transitions the tool must handle.

For a fictional repair shop, a job needs a job number, customer, item, reported issue and current stage. The owner may later add photographs, a parts estimate and a collection date. Introducing these deliberately is safer than creating a new field every time a differently worded note arrives.

## Write the rules in ordinary sentences

Try: “Technicians can update diagnosis and work status. Only a manager can approve a price change. A job cannot be marked collected without a collection confirmation.”

These sentences are understandable to the team and can become acceptance tests for the application. The generated screen should make those rules visible. A disabled action can explain what is missing.

A price change can show the previous and proposed amounts. A neat collection button that bypasses the business rule is not a finished feature.

## Use a compact specification

The following specification describes a fictional repair queue. Use it as a starting point for deciding which records, permissions and exceptions your own application must handle.

Part | Decision | Example test
--- | --- | ---
Records | One job has one stable identifier | Two jobs for Rahul remain separate
Stages | Intake, diagnosis, approval, repair, collection | An unapproved estimate stays blocked
Access | Technicians see assigned jobs | A restricted user cannot export all customers
Corrections | Reopen with reason and manager review | A mistaken collection is traceable
Exit | Export jobs and attachments | Another tool can read the exported sample

## Generated software still needs secure development

[NIST’s Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final) describes security practices across the development lifecycle. The buyer’s implication is straightforward: code created quickly still needs review, testing and a way to address vulnerabilities. The method used to write it does not replace those responsibilities.

[GitHub’s security-feature documentation](https://docs.github.com/en/code-security/getting-started/github-security-features) describes tools for dependencies, secrets and code security. Scanning can support a review, but a clean scan does not prove the business permissions are correct. Test that a customer cannot see another customer’s repair and that a technician cannot approve their own restricted price change.

## Try a complete journey with difficult examples

Run a fictional job from intake through collection. Then try a customer with the same name, a cancelled repair, an unavailable part and an estimate changed after approval.

Ask someone who did not write the prompt to use the application. Their confusion often reveals a missing state or unclear label.

Check operations too. Who receives an error? Can the owner recover an accidentally removed record?

Does the app still work on the actual phone used in the workshop? An internal tool becomes valuable through these ordinary details, not merely through the speed of its first generated screen.

## Keep modularity understandable

Each module should add a clear capability, such as repair intake or parts requests. Use shared identifiers for customers and jobs. Separate versions of Rahul and separate job numbers fragment the business picture.

Share the underlying identifiers across modules. Agree on the core records before expanding.

1. Choose one workflow and define its beginning and end.
1. Specify records, permissions and allowed transitions.
1. Build a small version with fictional data.
1. Test normal work, mistakes and restricted access.
1. Assign maintenance and export responsibilities before release.

## Add modules around shared business records

Choose the next module from an observed need once the first tool works. Customer intake or parts requests might follow. Reuse the existing customer and job identifiers rather than making another disconnected list.

Define which module owns each fact and how a correction reaches the other screens. Test the handoff with a changed order before expanding to more of the business.

## Common questions

### How can an owner explain an internal tool without writing code?

Describe its users, required records and permitted decisions. Add completed-job examples and important exceptions. Those concrete cases help an implementation team evaluate whether the tool follows the intended rules.

### When should a new module reuse an existing record?

Reuse the same customer, order or job identity when modules refer to the same real-world work. Define which module owns each fact and how corrections travel. Separate duplicate lists make a polished application harder to operate and report on.

## Sources

- [NIST Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final): Provides secure development lifecycle practices.
- [GitHub security features](https://docs.github.com/en/code-security/getting-started/github-security-features): Describes dependency, secret and code-security tooling.