01
Open files and code selections
Selected modules · attached files
The working set may include more code than the developer pasted into the composer.
For healthtech engineering teams
Inspect AI coding context before sensitive data leaves the workflow.
Context Lens makes the assembled payload visible so developers can remove unnecessary context before send. Explicit provider choice, BYOK, and local model paths support the same review workflow.
Operational controls for engineering teams — not a compliance certification.
Pre-send review
Assembled context · 5 blocks
Developer prompt
Review the retry behavior in the API client.
src/api/client.ts3.1kKeep
.knotic/brain.loom1.6kReview
tests/fixtures/request.json0.8kRemove
.env.example0.2kReview
retrieved symbol references1.4kKeep
Route after review
Configured provider · selected model
Review complete
Illustrative workflow only. Labels indicate review decisions, not automatic sensitive-data detection.
The prompt is not the whole payload
The visible message can be the smallest part.
Data minimization is difficult to operationalize when developers cannot inspect the complete payload before send.
02
Repository memory and instructions
.loom · .knot · workspace skills
Project knowledge, session history, and reusable instructions can shape the request.
03
Logs and test fixtures
Stack traces · fixture payloads
Debugging artifacts can carry customer-like values or operational details when added to context.
04
Configuration and environment details
Config files · environment examples
Opened, attached, or retrieved configuration may expose more than the immediate task needs.
05
Automatically retrieved context
Symbol references · search results
Tool activity and repository search can add relevant material beyond the typed prompt.
These are review categories, not automatic detection labels. Knotic does not claim to identify every type of sensitive or regulated information.
Data minimization inside the developer workflow
Put review at the point where context becomes a request.
- 01
Inspect
Preview the context blocks and estimated token budget prepared for the model call.
- 02
Remove or hide
Remove stale entries or hide context that is not necessary for the task.
- 03
Select provider
Choose the configured cloud or local runtime appropriate for the workflow.
- 04
Send
Submit only after the developer has reviewed the assembled context.
- 05
Observe
Review the runtime activity and usage signals currently available through HQ Monitoring.
Context Lens
Inspect what Knotic knows before the model does.
Context Lens brings project knowledge, session context, token budget, and prepared context blocks into one review surface. Developers can hide or remove entries before returning to the session.
Read the Context Lens guide
Supporting capabilities
Context control works best with explicit runtime choices.
These capabilities are documented in the current product guides. They support technical evaluation; they do not replace your organization’s provider review or policy enforcement.
BYOK
Use your own credentials for documented cloud providers instead of relying only on managed inference.
Review BYOK options →Explicit provider choice
Keep the selected provider visible in the workflow. Pair configured providers with your internal approval process.
See provider support →Local model path
Point Knotic to a local OpenAI-compatible endpoint when a local runtime fits the team’s technical requirements.
Read the privacy-first guide →Repo-native knowledge
Project knowledge, session context, and reusable skills are stored under the repository’s .knotic directory.
See how sessions work →Operational telemetry
HQ Monitoring provides activity and usage signals for reviewing how the runtime is being used.
Explore HQ Monitoring →AI Coding Data-Minimization Checklist
Turn a broad principle into a repeatable review.
Use this checklist to structure a technical workshop with Engineering, Platform, Security, and Privacy stakeholders.
Request the checklistThe request opens a pre-filled contact form. No download is implied.
01
Repository context inventory
- Map files, memory, instructions, and tool outputs that can enter a request.
- Assign owners for shared project knowledge.
02
Logs and test data
- Review fixtures, stack traces, and copied debugging output.
- Prefer purpose-built, non-sensitive evaluation data.
03
Secrets and configuration
- Keep credentials out of prompts, attachments, and repository memory.
- Check configuration context before sending.
04
Provider selection
- Document which providers are appropriate for each workflow.
- Verify credentials, endpoint, and model before the request.
05
Pre-send review
- Inspect the complete assembled context, not only the composer text.
- Remove or hide material that is unnecessary for the task.
06
Retention and access questions
- Ask providers how requests, outputs, and logs are retained.
- Confirm access, deletion, and incident-handling responsibilities.
Good fit / Not yet a fit
Start where the technical evaluation can be honest and controlled.
Good fit
- Engineering teams building for healthcare providers or health systems
- Existing AI coding use with incomplete visibility into assembled context
- Security and Privacy stakeholders involved in engineering decisions
- A need to test BYOK, explicit provider choice, or a local runtime
- A willingness to start with non-sensitive repositories and evaluation data
Not yet a fit
- Teams looking for a regulatory certification or legal opinion
- Organizations expecting automatic discovery of every sensitive data type
- Workflows that require a validated clinical or healthcare decision system
- Teams unable to test outside production or without real patient data
Evaluation questions
Technical answers without compliance shortcuts.
Does Knotic guarantee regulatory compliance?
No. Knotic provides operational controls for engineering workflows. It does not certify compliance, provide legal or healthcare advice, or replace your organization’s formal risk assessment.
Can teams use local providers?
Yes. Knotic documents a local provider mode for OpenAI-compatible endpoints. Whether a specific local deployment satisfies your security, privacy, performance, or regulatory requirements requires your own technical review.
Can developers remove context before sending?
Yes. Context Lens lets developers inspect project and session context, preview prepared context blocks, and hide or remove entries before returning to the working session.
Does shared knowledge remain in the repository?
Core project memory and reusable skills are stored in the workspace under .knotic, so they can remain with the repository and follow its review and access practices. Provider-bound requests still follow the selected runtime path.
How can we test this without using sensitive data?
Start with a non-production repository, generic configuration placeholders, and purpose-built fixtures that contain no personal or health information. Test inspection, removal, provider selection, and monitoring before expanding the evaluation scope.
Start without sensitive data
Test the review workflow before expanding the data boundary.
Begin with a sanitized repository and purpose-built fixtures. Map what enters the payload, who selects the provider, and what evidence the team can review afterward.
Read the technical Context Lens documentation →