AI Tools Field Guide

Open edition · no CAC needed

Intermediate — How it works, just enough

The method, in six steps

  1. Name the recurring product
  2. List the data it needs and where it lives
  3. Move the data to its home
  4. Build the project
  5. Design the check in
  6. Run it once with a human beside it

Six steps that work for any staff code. Most of the effort is in steps two and three.

Name the recurring product. Not "use AI for manpower". Pick the monthly manning report, the quarterly metrics slide or the annual instruction review: something with a due date and a signature.

List the data it needs and where it lives. Write the list by hand. Most products turn out to need four or five sources, and at least one of them lives on somebody's desktop.

Move the data to its home. One home per data type, named so a stranger can find it. This is the step people skip, and it is the step that decides whether any of the rest works. Data first is the whole lesson on it.

Build the project. Files once, standing instructions once. Projects covers the mechanics; build a GPT and a project builds one screen by screen.

Design the check in. Decide before you start how a wrong number would show itself. Checking output has the six methods.

Run it once with a human beside it. The person who owns the product sits with the first run and marks every place the draft was wrong. That list becomes the standing instruction for the second run.

N1: instructions, leave, memos, routing

Paperwork routing with a human approving. Incoming correspondence gets classified by type, matched to the office that owns it, and put in a proposed route. Nobody signs anything the model routed; the yeoman reads the proposal and approves or corrects it. That correction is training for the standing instruction, not for the model.

Manpower policy for all of this sits in OPNAVINST 1000.16L, Navy Total Force Manpower Policies and Procedures. Put the instruction in the project so the draft quotes it instead of paraphrasing it from memory.

N3: watchbills, product metrics, manpower studies

Watchbill proposals checked by a rule tool. Put the constraints in a file: qualifications, leave, temporary duty, maximum consecutive watches, the rest interval. The model proposes a bill. A short script or a spreadsheet then checks every rule and prints the ones it broke. The model gives you a fast first draft and will propose as many more as you want. The rule checker is the part you trust.

Product metrics from monthly logs. A year of production logs becomes a trend by product line: on time, late, missed, turnaround. Ask for the table first and the narrative second, so the numbers exist before the sentences about them do.

Manpower studies with the arithmetic in Python. Workload by watch and by product, set against billets, with every calculation done as a tool call and the code shown. A manpower narrative that cannot show its arithmetic will not survive the first question from above.

Watch organization and bills are prescribed in OPNAVINST 3120.32D, the Standard Organization and Regulations of the U.S. Navy. Attach the chapter, not your memory of it.

N4: equipment, work orders, contracts, inventory

Inventory reconciliation between two spreadsheets. The property record and the physical count rarely match. Ask for the rows that appear in one and not the other, the rows where the quantity differs, and the rows where the same item is recorded twice under different names. Then have it write the script that does the comparison, so next quarter takes a minute.

N6: the trouble tickets are a goldmine

Your ticket queue is the best unread dataset in the command: a year of evidence about what wastes people's time, written by the people whose time it wasted.

  1. Export the closed tickets
  2. Group by root cause and count
  3. Take the top ten with examples
  4. Propose a one-page fix for each
  5. Pick the three with the best return

A trouble-ticket mining run. The output is a short list of fixes.

The result looks like this: "printer mapping on the second deck, forty-one tickets last quarter, fix is a one-page cheat sheet and a login script change." That is a decision a department head can make in a minute.

Two more N6 patterns earn their keep. A knowledge base from closed tickets: every resolved ticket already contains a procedure; ask for the ten most repeated ones written as short articles, then have the technician who closed them read each article before it is published. Compliance evidence gathering: the artifacts an inspector asks for are scattered across mailboxes and folders; a project that holds the checklist can tell you which items have evidence, which have stale evidence, and which have none.

N8: requirements, issue papers, the roll-up

N8 is where every other department's data ends up, usually late and in a different shape each time. These patterns attack that directly.

An issue paper assembler. A project holding last year's papers, the guidance from higher headquarters, and this year's data extracts. It drafts the narrative with a quote and a location beside every claim. Anything it cannot source comes back marked, and that mark is the work list.

A requirements ledger agent. Each department drops its monthly data. The agent reads what arrived and reports what is missing, what is older than it should be, and what changed shape since last month. That report goes to the department head before the season, not during it.

What changed since last year. Two versions of the same document, one prompt: list every substantive difference, ignore formatting, and say which differences change a number. This is the fastest win on this page.

Manpower narrative with the math in a tool. Workload data and watch logs in; a table computed by code, then the narrative written from the table. Shore manpower requirements get scrutinized upward precisely because commands help determine their own, so auditable arithmetic is the argument.

A rehearsal where the model plays the questioner. Give it the paper and the role: "You are the resource sponsor reviewing this. Ask me the eight hardest questions, in the order you would ask them." Then answer them out loud. Ten minutes of this is worth an hour of rereading.

Subordinate roll-up. Detachments and subordinate units submit in their own shapes. One project, one submission format, and a monthly pass that normalizes every submission into one table with the outliers flagged.

Sailors and the chain of command: evals and awards

This is the work people most want help with, and it is the work with the tightest rules.

For the writer. A project with the performance instruction, the command's standards and the approved format. A skill that turns a page of accomplishments into blocks in the right shape, with a rule that numbers are copied exactly and never rounded, adjusted or invented. Have a tool check every number in the draft against the source page and report any that do not match.

For the reviewer. The same packages read against one rubric, scored on the same criteria, returned as a ranked table with the supporting sentence quoted beside each score. The value is that every package got the same reading, and that you can see which sentence earned each mark.

For a rack and stack, or a Sailor of the Quarter board. The ranked table is where the board starts. The board still reads the packages, and the model's ordering is an input with no vote.

Evaluations run under BUPERSINST 1610.10F, the Navy Performance Evaluation System. Awards policy is SECNAVINST 1650.1J, and the manual that implements it is SECNAV M-1650.1. They are two documents; attach the one that governs the question you are asking.

Vendor facts checked ; re-verify before relying on them.