The problem is ordinary work with an unusually strict boundary
Industrial teams handle approval notes, engineering calculations, scanned inspection reports and internal tools. These tasks are often repetitive enough to benefit from AI, but the source material may not be appropriate for a public cloud assistant. Faraday explores a third workflow: use local open-weight models on the operator’s own machine, with network access treated as a decision the system must expose.
The Smart India Hackathon prototype was built for the MRPL problem statement SIH26117. It is a workbench and integration project, not a claim that a local model can replace every specialist or every existing process.
The egress seal turns a policy into observable behavior
A privacy setting is hard to trust if it only changes a label in the interface. Faraday’s egress seal sits in the outbound-call refusal path. The implementation includes a canary request that can be allowed deliberately so the system can demonstrate the difference between a denied request and a real request that reaches the network. The opened state is an explicit calibration, not the default privacy guarantee.
The workbench records the decision and the operator-facing interface shows the network state. This makes the boundary testable: a reviewer can ask what happens when an outbound call is attempted, observe the refusal, and inspect the record rather than relying on a static “private” badge.
Models, tools and deliverables are separate parts of the design
The repository extends DeepSeek Harness through a pluggable model plane. Providers can include local, injected and replay implementations. A task router selects a lane, dispatch connects that selection to inference, and tools can produce artifacts such as signed Word documents and audit trails. This separation makes it possible to change the model provider without rewriting the whole workbench.
The project also carries deployment notes for running local models with llama.cpp and llama-swap, plus smoke checks, evaluation notes, licensing decisions and a component-level license audit. Those files are part of the engineering story because an offline AI application still has operational, hardware and dependency constraints.
- The documented local target is Windows 10 or 11 with a supported NVIDIA GPU and roughly 4 GB of VRAM.
- The repository describes a prototype. Teams should validate model quality, hardware compatibility, permissions and network behavior in their own environment before relying on it.
Why the project is interesting
The useful engineering question is not whether an AI system can generate a plausible answer. It is whether an operator can see which model handled a task, which tools ran, what left the machine and what evidence supports the resulting document. Faraday makes those questions part of the product surface.
That approach does not eliminate risk. Local inference still requires secure host configuration, model provenance, access controls and human review. It does, however, turn a vague privacy promise into specific system behavior that can be inspected and tested.
INSPECT THE IMPLEMENTATION
Read the code and project notes
The details above describe the public repository and project status as reviewed for this portfolio. Follow the source to inspect the implementation, setup instructions and current limitations.
Faraday source and implementation notes


