KAIDAN setup and deployment

This guide starts after a Briard-AI owner or administrator has accepted the KAIDAN agreement. It explains the business decisions in ordinary language and tells the technical operator what evidence must come back.

IMPORTANT

Agreement accepted is not the same as deployment complete. Do not report KAIDAN as deployed until the setup report contains current-digest evidence for discovery, source connection, render, preflight, apply, validation, and rollback.

Step 1: name the people

Before downloading or running anything, write down:

• business owner;
• security/incident-response owner;
• platform or Kubernetes operator;
• identity owner;
• data/privacy owner;
• one owner for every source you may connect; and
• a reviewer who did not perform the deployment.

KAIDAN separates permissions:

Permission	What it allows	Typical holder
setup:read	View plans, reports, catalog, and signed files	Reviewer or auditor
setup:manage	Answer inventory, render artifacts, run preflight	Setup planner
setup:apply	Test sources and apply deployment	Technical operator
setup:approve	Record one of five plan acceptances	Named approval owner

No default role must both apply and approve. An approved plan performs no external action until an authorized operator applies it.

Step 2: choose where KAIDAN runs

Standard Kubernetes

Choose this when the organization has a supported Kubernetes environment and can reach approved identity, source, and trust services.

The setup bundle contains a signed Helm chart, customer values, schema, NetworkPolicy, checksums, and provenance. The operator must supply real customer values, immutable image digests, external secret references, exact network destinations, and a specific rollback revision.

Air-gapped Kubernetes

Choose this when the environment cannot reach public networks. The same signed profile is used, with offline=true. Software, trust material, and evidence packages must be transferred and verified inside the approved boundary.

Evaluation environment

Use an isolated non-production environment for learning and the fictional golden path. Do not connect production sources or claim production readiness from an evaluation.

Managed cloud Kubernetes

AWS EKS, Azure AKS, and Google GKE can host the standard Kubernetes profile. The cloud name does not remove the need for customer topology review, workload identity, secret management, network policy, backups, monitoring, and rollback proof.

If your organization has no Kubernetes capability, stop and contact Briard-AI support for an approved deployment option. Do not improvise a public server.

Step 3: prepare the operator workstation

The technical operator needs:

• the signed KAIDAN release and setup bundle supplied through the approved channel;
• a supported Windows, Linux, or macOS workstation;
• access to the target Kubernetes context;
• absolute paths to approved helm, kubectl, and kaidan-verify executables;
• a protected file for the tenant pseudonymization key;
• a secret manager for source credentials;
• approved HTTPS identity and trust endpoints; and
• a protected folder outside source control for plans and receipts.

Verify the release checksums and signatures before opening any executable. Do not continue after a signature or checksum failure.

Step 4: start the guided plan

The local kaidan-setup launcher opens a temporary localhost browser session and creates or resumes the same server-held plan used by the KAIDAN console.

The launcher:

• binds only to localhost;
• keeps its bootstrap token in the process;
• opens the browser to the local session;
• does not place the token in the URL; and
• does not install into Kubernetes.

Close the launcher when finished. Do not publish the localhost port or copy its token.

Step 5: build the inventory

Answer what exists and what was inspected. For every possible discovery area, record one of:

• inspected and found;
• inspected and not found;
• excluded with an owner and reason; or
• unknown and requiring follow-up.

Discovery may use privacy-safe host executable names, approved repository dependency/deployment manifests, strict Kubernetes or cloud inventory metadata, OpenTelemetry metadata, and owner questionnaires.

Discovery does not persist command lines, environment values, window titles, browser URLs, prompts, responses, credentials, raw cloud account IDs, raw Kubernetes object IDs, or repository file contents. It records bounded product-family matches and pseudonymous identifiers.

Step 6: decide every source

For each proposed source, record:

• source owner;
• business purpose;
• exact metadata fields;
• maximum visibility level;
• least-privilege permission;
• secret-manager reference;
• network destination;
• test recipe;
• failure and rollback recipe;
• retention;
• explicit exclusions; and
• final disposition: approve, reject, or defer.

Continue with Connect sources for the source-by-source workflow.

Step 7: render the deployment artifacts

The setup planner renders the immutable plan into deterministic deployment artifacts. Review:

• image digests;
• namespaces and service accounts;
• identity issuer and audience;
• database and object-storage references;
• secret references, never secret values;
• ingress and egress destinations;
• default-deny NetworkPolicy;
• storage class and backup responsibility;
• retention and region;
• source packages and visibility ceilings; and
• approved rollback revision.

Any change creates a new plan digest. Prior approvals do not carry to a changed digest.

Step 8: pass blocking preflight

Preflight must fail closed when a required fact is missing. It verifies artifact signatures and plan binding, target access, Helm lint/template, Kubernetes server-side dry run, policies, identities, secret references, endpoints, and rollback facts.

Do not override a failed check with a screenshot or a written statement. Correct the input, render a new plan if needed, and run preflight again.

Step 9: collect five approvals

The current plan digest needs five separate approval domains:

1. security;
2. platform/deployment;
3. identity;
4. data/privacy; and
5. source ownership.

Each approval is recorded by an authenticated setup:approve user assigned to that domain. An exception must be explicit, bounded, owned, and tied to the same digest. A proposer cannot approve their own plan where separation rules forbid it.

Step 10: apply once

The setup:apply operator uses the approved runner bundle. The runner receives absolute tool paths, verifies the plan and artifacts, checks target access, performs dry runs, executes one fixed atomic Helm apply, applies NetworkPolicy, and waits for readiness.

The retained receipt contains operation names, exit codes, output digests, timestamps, pseudonymous target and runner identities, and observations. It does not contain raw command output, arguments, kubeconfig data, cluster identifiers, or credentials.

NOTE

A v1 runner receipt is an authenticated operator-submitted execution record, not independent proof that a particular host or binary performed the action. Keep that provenance limit with the evidence.

Step 11: validate

Validation requires:

• a synthetic metadata-only evidence package;
• a separately exported offline evidence package;
• the trusted kaidan-verify executable; and
• a receipt bound to the plan, artifacts, target pseudonym, and package digests.

Both packages must verify. Then confirm:

• authentication denies an unauthenticated request;
• tenant A cannot retrieve tenant B evidence;
• source and connector health are visible;
• an event keeps its source attribution;
• unknowns and contradictions remain visible;
• a case export verifies offline; and
• no prohibited content appears in normal intake.

Step 12: rehearse rollback

Rollback accepts only the positive Helm revision approved in the plan. The runner verifies the revision, performs an atomic rollback, waits for readiness, then reapplies and validates the current approved release so the rehearsal does not leave the customer on an older version.

Keep both rollback and restoration receipts.

Completion checklist

Do not mark deployment complete until all boxes are true:

• [ ] Current Briard KAIDAN agreement accepted by an owner or administrator
• [ ] Named roles and owners recorded
• [ ] Deployment path and environment approved
• [ ] Inventory complete, including exclusions and unknowns
• [ ] Every source approved, rejected, or deferred
• [ ] Current plan and artifact signatures verified
• [ ] Blocking preflight passed
• [ ] Five digest-bound approvals recorded
• [ ] Apply receipt accepted
• [ ] Synthetic package verified
• [ ] Offline package independently verified
• [ ] Tenant isolation test passed
• [ ] Source health and evidence gaps visible
• [ ] Rollback and restoration rehearsal passed
• [ ] Setup report exported and retained

What to give a nontechnical owner

The technical operator returns:

1. the setup report;
2. plan identifier and digest;
3. approval summary;
4. deployment and validation receipts;
5. source list with permissions and gaps;
6. rollback receipt;
7. offline verification result; and
8. the next credential-rotation, access-review, and restore-test dates.

The owner should not be asked to approve raw terminal output.