KAIDAN troubleshooting

Start with the symptom. Preserve identifiers and receipts, but never send credentials or sensitive content to support.

Briard access problems

What you see	Likely cause	What to do
KAIDAN is missing from the sidebar	Old application version or browser cache	Reload once, confirm the production domain, then contact support with the page URL and time
Free window closed	The fixed KAIDAN launch-year window is not active	Confirm the displayed UTC dates; no charge is created automatically, so review any future offer separately
Checkbox disabled	Your role is not owner or administrator	Ask an authorized owner or administrator to accept
Agreement changed	The version or digest changed after the page loaded	Reload, read the current agreement, and accept only after review
Acceptance failed	Session, MFA, database, or network error	Keep the request ID if shown, sign in again, and retry once
Setup required after acceptance	Customer deployment or identity bridge is not available	Continue with the deployment guide; acceptance alone is working as designed

Setup problems

The launcher does not open

• Confirm you obtained the signed launcher from the approved channel.
• Verify its checksum and signature.
• Confirm local security software did not quarantine it.
• Check whether another process is using the localhost port.
• Do not expose the port to the network.
• Record the launcher version and error, then contact the platform operator.

Preflight fails

Read the failed check. Common causes include:

• placeholder endpoint or image value;
• missing secret reference;
• untrusted artifact signature;
• identity issuer or audience mismatch;
• unsupported Kubernetes version;
• target access failure;
• NetworkPolicy or server-side dry-run denial;
• missing rollback revision; or
• plan digest changed after approval.

Correct the input. If the plan changes, render a new plan and collect approvals again. Never convert a failed preflight to “passed” by writing a note.

Apply fails

1. Preserve the apply receipt and request identifier.
2. Do not repeatedly rerun the command.
3. Check whether the operation was atomic and whether Helm rolled back.
4. Confirm current workload and database state.
5. Follow the plan’s exact rollback or recovery recipe.
6. Record the actual outcome, including partial success.
7. Escalate with metadata-only logs and receipt digests.

Rollback rehearsal fails

Treat the environment as not deployment-complete. Preserve both rollback and restoration receipts. Verify the approved revision exists, the target pseudonym matches, and the current release can be reapplied. Do not leave the environment on an old revision without an explicit incident decision.

Source problems

No events arrive

Check, in order:

1. source status is enabled;
2. credential is present in the secret manager;
3. the workload can read the secret reference;
4. authentication succeeds;
5. network policy permits only the expected destination;
6. the time window is correct;
7. checkpoint is advancing;
8. schema matches the signed package;
9. records were not privacy-rejected; and
10. dead-letter status is visible.

Do not broaden permissions until the source owner reviews the failed permission.

Duplicate events appear

Check checkpoint restart and source-native event identifiers. KAIDAN should make replay idempotent. Preserve examples and do not delete custody records manually.

Schema drift

The source should fail closed or dead-letter the record. Do not map new fields into production without reviewing data type, privacy boundary, semantics, capability ceiling, and signed package version.

Source says healthy but evidence is missing

“Healthy” may only prove transport. Compare the source’s expected event inventory, capability ceiling, checkpoint time, and the provider’s own receipt. Record the visibility gap in the case.

Investigation problems

Timeline times do not align

Compare source time, receipt time, time zone, and clock-skew indicators. Preserve original time values. Do not manually edit the source event to force alignment.

An answer has no citation

Do not use it as a finding. Narrow the question, inspect available evidence, and record “unknown” if no source supports the answer.

Two sources disagree

Preserve both, classify each statement, document the contradiction, and assign a reviewer. Source rank alone does not erase contradictory evidence.

Package verification fails

• Stop distribution.
• Preserve the original package and verifier output.
• Confirm the trusted verifier version and signature.
• Re-run against the unchanged file.
• Check transfer corruption.
• Escalate as a custody issue if the failure repeats.

What to send support

Send:

• organization name and pseudonymous organization identifier;
• environment name;
• page or setup stage;
• UTC time;
• request, plan, case, receipt, or package identifier;
• software and package versions;
• digest values;
• expected behavior;
• actual status and bounded error class; and
• steps already attempted.

Do not send tokens, passwords, keys, kubeconfig files, raw commands containing secrets, prompts, model responses, vectors, customer documents, or unredacted incident content.

Contact support@briard-ai.app. For suspected compromise, contact security@briard-ai.app.