Industrial sales inquiries mix technical requirements with customer names, project references, pricing and internal correspondence. A language model might help organise that information or prepare a brief, but first there is a decision to make: which details does the task actually need, and which are appropriate to share with the service processing it?

Removing everything recognisable can discard useful context. A buyer’s name may be unnecessary, while their role matters. A product reference may be needed to understand the request, while an internal project code is not. Those choices depend on the workflow.

Prompt Interlok is an experimental tool for exploring those decisions. It replaces detected sensitive details with descriptive placeholders and provides a record of the changes for review. The aim is to reduce exposure while preserving useful information. This does not guarantee that the remaining text is anonymous.

Why I built Prompt Interlok

I built Prompt Interlok to explore how the information-handling rules of industrial sales could become part of a working tool. Which details should be replaced? Which technical references should remain? How could someone inspect those decisions before using the result?

The project is an experiment informed by situations from my work, rather than a deployed company system. Its name comes from industrial safety interlocks: the idea of checking a condition before allowing the next step. Here, that is a design analogy, not a claim of equivalent safety assurance.

The intended setup keeps the original message and replacement record within an environment approved for that information. Any model or service involved must be assessed according to what it actually receives.

How the tool works

Prompt Interlok prepares the text, checks it with a language model, and presents the results for review.

First, rules, wordlists and pattern matching identify details to replace or preserve. Optional model-based entity recognition can support this step. Detected sensitive details become descriptive placeholders such as [CLIENT_COMPANY], [EMAIL] or [DETECTED_CODE].

An illustrative result might read:

The procurement manager at [CLIENT_COMPANY] asks for a quote on ACM-EX-110 before Friday.

The company name has been replaced, while the buyer’s role, product reference and deadline remain. Whether those details should be retained depends on the workflow. [DETECTED_CODE] serves a different purpose: it records that a code-like identifier was found without pretending to know its business meaning.

The model stage performs two tasks: looking for potentially sensitive information that remains and classifying the inquiry by type and urgency. It can also produce a short scope summary. The configured model can run locally or through a hosted service.

The adapters request JSON output, which the application parses and checks. A structured response can still contain mistakes.

The review interface brings together the prepared text, model findings and replacement record. The operator can inspect what changed, which rules were applied, and what needs further attention.

What this could support

The current tool prepares individual inquiries for review. It can produce sanitised text, classification results and a structured triage record. Those outputs provide a starting point for further automation.

One possible extension is a preparation brief for a sales engineer, combining the inquiry with relevant product guidance or internal procedures. Connecting it to customer history in a CRM or ERP would require additional integration and rules about which information each processing step may receive.

Another possibility is analysing correspondence across many inquiries: recurring technical questions, missing specification details or common complaint themes. That would require its own evaluation. Replacing identifiers alone does not make an archive ready for analysis, and tracking patterns for the same customer would require a controlled way to link records.

The current tool stops at preparation and review. The engine provides a foundation for further business workflows, but CRM integration, document retrieval and scheduled reporting are possible extensions rather than features of the present demo.

Choosing how much AI to use

The preparation stage can run without a generative model. It produces replacement records and structured signals that ordinary software can use.

A local or hosted model can add checks for remaining sensitive information and classify the inquiry. The choice depends on the task, available resources and information-handling requirements.

A separate model could then use the reviewed output for a further task, such as drafting a brief. That is an optional extension. Each added step needs a clear purpose and an assessment of what information it receives.

Adapting it to the work

What counts as sensitive or useful depends on the task. A product reference might be necessary for a quotation brief, while an internal project code adds nothing. Even familiar technical vocabulary may reveal too much when combined with other details.

Prompt Interlok separates several configuration choices: recognition rules and wordlists, terms to preserve, verification and classification prompts, and model connection settings. These provide a starting point for adapting the tool. They still need testing against representative examples from the intended workflow.

I would start with one concrete task. What result would help someone? What information is necessary to produce it? What should be replaced, and what would count as a mistake?

Domain experience matters here. It helps identify the exceptions, ambiguous references and missing details that a general rule can overlook.

From prepared information to useful work

Prompt Interlok already adds some business interpretation, including inquiry type, urgency and routing hints. A workflow built around it would decide how to use those signals: prepare a brief, suggest a next step or pass a case for technical review.

Those actions need their own checks. A classification result is a suggestion to assess, not proof that a particular action is appropriate.

For me, the value of this project is in working through those decisions explicitly. Which information does the task need? What should the software handle? What needs human judgment? The rules, examples and evaluation criteria developed along the way can remain useful even when the model or implementation changes.

The engine and the website demo

The project includes a standalone Python engine with command-line tools, an API, configurable rules and local or hosted model connections. The website demo exposes a guided workflow using that engine. It is not the full development environment, but it is more than a static example or a rules-only demonstration.

In the hosted path, the website sends the original inquiry to a configured Python service for preparation. The next request sends the prepared text and review metadata to that service for model verification and classification. Local model profiles are also available in the Python project. Running a model locally does not make the website’s hosted path local.

The demo should be used with synthetic examples. Its processing services receive information that may have been removed from the model-facing text, so the replacement record needs protection too. Exact model selection and service availability depend on deployment configuration.

Sanitising the main text is not enough on its own. Metadata and other fields can carry sensitive information into later processing stages, so every model-facing input needs an explicit boundary. These controls reduce exposure; they do not establish anonymity or guarantee that all sensitive information will be detected.