QuietNode
Docs

Documentation that survives security review.

How QuietLens and QuietMend deploy, connect, and stay governed inside your boundary: deployment paths, the connector surface, the governed run lifecycle, and where the numbers come from.

Run it in ten minutesRun the eval yourself
Deployment

Everything runs inside your boundary.

The two products deploy separately, on purpose — they never share credentials or a network path. Each lands entirely in your environment.

QuietLens BI · AI data analyst

A self-contained container in your VPC

  • Two containers via docker compose — the app plus Postgres 17, which holds all state. There is no vendor-hosted backend and no telemetry; the only outbound connections are the ones an admin configures.
  • Published images are verifiable before you run them: keyless cosign-signed, with SLSA build provenance and a CycloneDX SBOM attached.
  • The LLM is optional. Without a key, a deterministic composer still answers from evidence; with one, you choose the endpoint — including a private in-VPC endpoint so inference never leaves your boundary.
  • Connector credentials never sit in the database — they flow through pointer-only references to your AWS Secrets Manager or Vault.
docker compose upcosign verifyBYO-LLM endpointsecrets stay in your vault

QuietMend · AI data engineer, in development

Designed to Terraform into your AWS account

  • Deploys with Terraform to ECS Fargate in private subnets with no public ingress — ticket intake is egress-only polling by default.
  • Outbound TLS is restricted to exactly three endpoint classes: the model provider, Jira, and Git. AWS calls go through VPC endpoints.
  • Encryption and secrets are customer-owned: your KMS keys, your Secrets Manager, and an append-only audit trail written to file, S3 (SSE-KMS), or CloudWatch — it never leaves your account.
  • The model sees schema, metadata, and ticket text only — never data rows, credentials, or secret values.
Terraform · ECS Fargateegress-only intakecustomer-managed KMSSIEM-ready audit
Quickstart · QuietNode BI Analyst — QuietLens

Ten minutes to a running QuietLens.

This is the real flow, quoted from the product's own bootstrap runbook — not a marketing abstraction. One step is a gate I won't hide: the image is private, and pull access is granted per evaluation. Everything after the grant is copy-paste.

  1. 01

    Get pull access — the honest gate

    The image is private today — ghcr.io/quietnode-studio/quietlens-bi cannot be pulled anonymously. Pull access is granted per evaluation under the written evaluation agreement: send the GitHub identity to grant (your org, a named user, or — recommended — a robot account that survives offboarding) to hello@quietnode.studio, and I add read-only pull — docker pull only, no source access. Then authenticate with a token scoped to nothing but package reads:

    shell · docker host
    docker login ghcr.io -u <granted-account># password: a fine-grained PAT scoped to read:packages only — no repo scopes
  2. 02

    Verify the signature before first run

    Every published image is keyless-signed by CI, with SLSA build provenance and a CycloneDX SBOM attached, and the signing identity is recorded in the public Rekor transparency log. The grant proves you may pull; the signature proves what you pulled was built by QuietNode’s CI:

    shell · docker host
    cosign verify \  --certificate-identity-regexp 'github.com/QuietNode-Studio/quietlens-bi' \  --certificate-oidc-issuer https://token.actions.githubusercontent.com \  ghcr.io/quietnode-studio/quietlens-bi:latest
  3. 03

    Boot the stack

    Two containers — the app plus Postgres 17, which holds all state. The session secret is required (compose refuses to start without it), migrations run automatically at boot, and the container runs non-root on a read-only root filesystem. The compose file and the full bootstrap runbook arrive with your evaluation onboarding pack:

    shell · docker host
    export QUIETLENS_SESSION_SECRET=$(node -e "console.log(require('crypto').randomBytes(32).toString('hex'))")docker compose up -d
  4. 04

    Seed the demo workspace and log in

    Seeding creates a demo workspace with connectors, reports, metrics, and a lineage graph, so the first question you ask gets a real evidence-backed answer — not an empty screen:

    shell · docker host
    # Seed the demo workspace (npm cache routed to /tmp — the root FS is read-only):docker compose exec -e npm_config_cache=/tmp/.npm app npm run db:seed# → http://localhost:3000   login: demo@quietlens.io / demo1234

About ten minutes from access grant to a serving login page.

No Anthropic key required for the demo — without one, a deterministic composer still answers from evidence.

Not aspirational: CI's compose-smoke job boots this exact flow — clean clone, compose up, read-only root filesystem — to a serving login page on every push.

Request evaluation accessThen run the eval yourself
Connector reference

What connects today — and how it’s allowed to touch.

Two products, two very different access models. QuietLens reads. QuietMend is designed to act only behind human gates. Neither list is aspirational: it is what the code connects to today. Neither product is released yet.

QuietLens BI · AI data analyst

Read-only diagnosis

Every probe runs through a SELECT-only, single-statement SQL gate on one least-privilege read-only identity. Its only outbound writes are an optional Jira ticket and an optional Slack summary.

  • Snowflake

    Warehouse probes · key-pair auth, no password

  • PostgreSQL

    Warehouse probes · read-only role

  • BigQuery

    Warehouse probes · scoped service account

  • Redshift

    Warehouse probes · read-only role

  • Power BI

    Dataset refresh history · service principal

  • dbt Cloud

    Run and model status

  • Airflow

    DAG and task status

  • Jira

    Optional ticket creation

  • Slack

    Optional answer summaries

  • GitHub

    Commit metadata only

QuietMend · AI data engineer

Designed execution, in development

By design, work starts from a ticket and ends in a pull request. Every action is checked against deny-by-default policy, and it is designed to ask for short-lived access scoped to the ticket. It has never run against live systems.

  • Jira Cloud

    Ticket intake, plan + access-request comments

  • GitHub

    Branch, commit, PR. It cannot merge

  • AWS Glue + S3

    Designed for DEV-only script repair

  • AWS discovery

    Metadata-only estate map across 12 service surfaces

  • PostgreSQL

    Read-only validation checks

  • Redshift

    Read-only validation checks

On the roadmap, stated as roadmap: Snowflake, MySQL, SQL Server, BigQuery, and Databricks execution surfaces for QuietMend exist as typed stubs, with Airflow and dbt execution planned and no dates. If a connector you need is missing, that is exactly the conversation to have with me.

The governed run

Three gates, by design.

This is the designed lifecycle of a QuietMend run, including the three points where it must stop and wait for a human: access approval, QA sign-off, and the pull request. QuietMend is in development and has never run against live systems.

  1. 01

    Ticket received

    A Jira ticket assigned to the employee's alias enters the intake queue.

  2. 02

    Plan posted

    The PLAN comment lands on the ticket, tagging the reporter — before anything runs.

  3. Access requestedHuman gate

    An ACCESS REQUEST comment states the scope it is designed to ask for.

  4. 04

    Approved access

    By design, approval grants short-lived access scoped to the ticket. That scope is not yet enforced in code.

  5. 05

    DEV fix + validation

    The change is designed to run in DEV only, with row-count, null, and key checks that must pass.

  6. QA sign-offHuman gate

    The ticket moves to Ready for QA; a human decides whether the fix is real.

  7. Pull requestHuman gate

    Branch, commit, and a pull request with the validation evidence. It cannot merge.

Deny-by-default policy-as-code

The design: every plan and connector action is checked against a customer-owned policy file first. If an action is not permitted, it is blocked, and QuietMend stops and explains on the ticket. Against fixtures it denied 50 of 50 attack cases.

Kill switch that freezes, not crashes

The design: one per-workspace flag halts new runs and parks in-flight runs at their next human gate. Queued tickets are held, and every engage and disengage is logged with actor and reason.

Audit on every transition

QuietMend is designed to log each state change and connector action as an append-only event. QuietLens logs every question, hash-chained so tampering is detectable.

The same discipline applies to QuietLens in the other direction: it can’t execute anything at all. Diagnosis is read-only by construction, and escalation means filing a ticket a human will route.

Eval methodology

Where the numbers come from.

Every accuracy and safety figure on this site comes from an eval harness, not a demo that went well once. Here is exactly what each number means.

QuietLens golden eval

149 of 149 passing · 0 grounding violations

The deterministic engine scores 149 of 149 on its own golden evaluation, published with each release. The harness runs on deterministic fixtures with no LLM, so the score measures the engine, not the prompt. It covers the diagnosis journey. The LLM-assisted path and the plain-English “ask” journey have no published eval yet.

  • An ungrounded number in an answer fails the release build
  • Every user thumbs-down becomes a new frozen case: fix the engine, never edit the case
  • The harness and scorecard ship with the product — run it yourself during evaluation
The full methodology, and how to reproduce the score →

QuietMend safety evals

90 of 90 passing · 50 of 50 attack cases denied

A frozen suite of deterministic cases replays through the orchestrator, access, and policy engines: plan quality, gate ordering, prompt injection, kill switch. Every attack case (prod writes, unapproved reads, injection probes) must score DENIED. All of it runs against fixtures; QuietMend has never run against live systems.

  • Any red-team case scoring anything but DENIED is an absolute build failure
  • Every new capability ships with its policy route, a denial test, and a red-team case in the same change
  • QuietMend is in development; these numbers describe its design under test, not live use

What I don’t claim yet, on purpose: QuietMend has never run against live systems. It is tested against fixtures only, and I won’t substitute a simulated transcript for the real thing.

Evaluation documentation

The full onboarding pack ships with your evaluation.

Everything above goes deeper in the engagement pack, matched to your stack: the step-by-step onboarding runbook, IAM and policy-as-code references, ticket comment-gate templates, a control mapping, a data-handling policy, and a DPA template on request.

Start an evaluationSecurity overview