QuietNode
Docs

Documentation that survives security review.

How QuietLens and Pumpkin deploy, connect, and stay governed inside your boundary — deployment paths, the shipping connector surface, the governed run lifecycle, and where our 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.

QuietNode BI Analyst · QuietLens

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

QuietNode Data Engineer · Pumpkin

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 we 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 we 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 our 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; Pumpkin executes behind human gates. Neither list is aspirational — this is the shipping surface.

QuietNode BI Analyst · QuietLens

Read-only diagnosis

Every probe runs through a SELECT-only, single-statement SQL gate on one least-privilege read-only identity. The single write in the product is filing a Jira ticket.

  • 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

    Escalation tickets — the one write

  • Slack

    Where answers meet the team

QuietNode Data Engineer · Pumpkin

Governed execution

Work starts from a ticket and ends in a pull request. Every action is checked against deny-by-default policy, and the sensitive surfaces below only open under a human-approved, 60-minute scoped session.

  • Jira Cloud

    Ticket intake, plan + access-request comments

  • GitHub

    Branch, commit, PR — merge not implemented

  • AWS Glue + S3

    DEV-only script repair with pre-change snapshot

  • 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 Pumpkin exist as typed stubs awaiting demand, with Airflow and dbt execution planned. We list what ships — if a connector you need is missing, that’s exactly the conversation to have with us.

The governed run

Three gates in every run.

This is the exact lifecycle of a Pumpkin run — including the three points where it must stop and wait for a human. It never auto-advances past access approval, QA sign-off, or the pull request.

  1. 01

    Ticket received

    A Jira ticket assigned to Pumpkin's alias enters the durable 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 exact minimum scope, persisted as structured JSON.

  4. 04

    Scoped session

    Approval mints a short-lived STS session — 60 minutes, auto-expiring, never renewed silently.

  5. 05

    DEV fix + validation

    The repair runs in DEV with a pre-change snapshot; row-count, null, and key checks must pass — fail-closed.

  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, PR with validation evidence and a rollback recipe. Merge is not implemented in the connector.

Deny-by-default policy-as-code

Every plan and every connector action is evaluated against a customer-owned policy file before execution. If an action isn’t positively permitted, it’s blocked — and Pumpkin stops and explains on the ticket instead of improvising.

Kill switch that freezes, not crashes

One per-workspace flag halts new runs and parks in-flight runs at their next human gate. Queued tickets are held, never lost; every engage and disengage is audited with actor and reason.

Audit on every transition

Each state change and connector action becomes an append-only structured event — exportable to your SIEM. QuietLens does the same per 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 our numbers come from.

Every accuracy and safety figure on this site is produced by an eval harness that gates CI — not by a demo that went well once. Here is exactly what each number means.

QuietLens golden eval

121 cases · 121/121 passing · 0 grounding violations

A frozen set of 121 golden cases — including questions it must refuse outright and ambiguous ones where it must ask instead of guessing; the set only grows, and the count ships in each release scorecard. The harness runs the real investigation engine on deterministic fixtures with no network and no LLM, so the score measures the product, not the prompt.

  • A grounding violation — any number not traceable to evidence — hard-fails CI
  • 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 →

Pumpkin safety evals

100% red-team refusals · every golden case passing

A frozen suite of deterministic golden cases replays through the real orchestrator, access, and policy engines on every commit — plan quality, access minimality, gate ordering, prompt injection, kill switch. Every red-team case (prod writes, unapproved reads, injection probes) must score DENIED; exact counts ship with each release scorecard.

  • 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
  • An adversarial security review across 10 attack lenses found no critical path through the safety invariants

What we don’t claim yet, on purpose: Pumpkin’s live-AWS sandbox run is the one remaining exit-gate item before we call the Glue path production-proven — it’s proven against fixtures and golden cases today, and we 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 compliance control matrix mapped to SOC 2 and ISO 27001, a data-handling policy, and a ready-to-review DPA.

Start an evaluationSecurity overview