Persistent Module Configuration Assistant: A Claude Project That Remembers Every Config Decision

What This Builds

One Claude Project, kept alive for the life of the engagement, holds a single module's full history: workshop notes, approved gaps, configuration decisions, and open issues. Six months in, when a client stakeholder asks why drop-ship handling works the way it does, you ask the Project instead of searching through old email threads and meeting notes.

Prerequisites

• You have used a Claude Project before, or are willing to create one following Claude's own setup steps.
• You already track configuration decisions somewhere (workshop notes, an approved gap list, a decision log), even if it is currently scattered across several documents.
• You have a Pro subscription with enough project storage to hold months of accumulated documents.
• Total ongoing cost: $20/month per month for Pro. No other subscription is required for this build.

The Concept

Think of the Project as a filing cabinet that can also answer questions about what's inside it. A regular filing cabinet holds every document you ever put in it, but finding the one page that explains a decision from four months ago still means opening folder after folder. This Project holds the same documents and also answers the question directly, as long as you fed it the decision in the first place.

Build It Step by Step

Part 1: Create One Project Per Major Module

1. In Claude, start a new Project named for the client and the module, for example "Meridian Retail, Order Management." Create a separate Project for each major module rather than one Project for the whole engagement, so a question about Finance never pulls in an unrelated Supply Chain decision.
2. Upload whatever configuration history already exists: approved gap list entries, functional design documents, and workshop notes for that module. Remove real customer names, vendor names, and specific dollar figures first. Describe master data structurally (field names and types) rather than uploading an actual data export.

Part 2: Set the Project's Instructions and Start the Feed Habit

1. Paste custom instructions close to this into the Project:

You hold the configuration history for the [MODULE NAME] module on this engagement. When asked why something was configured a certain way, search the uploaded notes and answer with the date and source document of the decision you're citing. If you don't have a note covering the question, say so directly rather than guessing at a plausible-sounding answer.

1. After every workshop, decision, or configuration change, add a short dated entry to the Project. A consistent format works better than a long one:

[DATE] Module: [name]. Decision: [what was decided]. Reason: [why]. Alternatives considered: [if any]. Approved by: [role, not name].

1. Tie this five-minute habit to something you already do at the end of every workshop or change request, rather than relying on remembering to do it separately. A habit that depends on memory is the most common way this Project goes stale.

Part 3: Test It and Verify Before You Repeat Its Answer

1. Ask the Project a real question you'd otherwise dig for: "Why did we configure the discount as a manual override instead of an automatic three-way match exception?" Confirm it cites the actual entry and date rather than inventing a plausible reason.
2. Before repeating an old configuration rationale to a client stakeholder or a steering committee, confirm it against the vendor's own documentation (SAP Best Practice content, NetSuite's help center, Microsoft Learn) or the live system itself. Configuration can change after your last note was added, and the Project has no way to know that on its own.

Real Example: NetSuite Order Management, Six Months Post-Go-Live

Setup: A Project named "Northgate Distributors, Order Management" holds every gap entry, FDD, and dated decision note from discovery through go-live.

Input: A new client stakeholder, filling in after turnover on the client side, asks why drop-ship orders route through a manual approval step instead of auto-approving.

Output: The Project surfaces a February 12 decision entry: the client's original AP team flagged drop-ship vendor invoices as a fraud risk during discovery, so auto-approval was rejected in favor of a manual check, referenced against Change Request 14.

Time saved: A question that would otherwise mean searching six months of email and meeting notes gets answered in the time it takes to ask.

What to Do When It Breaks

• The Project answers confidently, but no note actually backs it up → This usually means the decision was made verbally and never logged. Treat any answer without a cited date and source as unverified, and go check with whoever made the call.
• Answers get vague or start mixing unrelated decisions together → The Project's knowledge has grown past what it can hold clearly. Split the module into two more narrowly scoped Projects, for example separating configuration decisions from open issues.
• You stop feeding it and it goes stale → Re-anchor the habit to a recurring event you already attend (the end of each workshop or the weekly status meeting) instead of trying to remember on your own.
• The Project cites a decision that no longer matches the live system → The configuration changed after the note was added and nobody updated the Project. Always confirm against the live system before repeating an old answer as current fact.

Variations

• Simpler version: Keep a single running decision log document instead of a Project. You lose the ability to ask it questions directly, but the discipline of logging decisions still pays off on its own.
• Extended version: Run one Project per workstream instead of per module, and cross-reference it against the RAID log so risk entries and configuration decisions for the same area sit side by side.

What to Do Next

• This week: Create one Project for your current highest-turnover module and backfill it with whatever decision history you can find.
• This month: Build the after-workshop logging habit until it feels automatic, and test the Project weekly with a real question.
• Advanced: Add a handoff step at the end of the engagement where you and the engagement manager decide whether the Project's content gets archived or purged under your firm's retention policy.

Advanced guide for ERP Implementation Consultant professionals. These techniques use more sophisticated AI features that may require paid subscriptions.