KAIDAN user guide

This guide follows a safe first incident from opening a case through independent package verification.

Before an incident

Complete these checks before relying on KAIDAN:

• the current Briard agreement is accepted;
• deployment and rollback are validated;
• your user can sign in with the correct tenant and role;
• expected sources are healthy;
• source owners and emergency contacts are known;
• retention and legal-hold procedures are documented;
• the trusted offline verifier is available; and
• the team has practiced with fictional metadata.

If a source is degraded, write down the visibility gap before opening a conclusion.

Understand the four statement types

Every important statement must have one type:

Type	Meaning	Example
Observed fact	KAIDAN directly preserved an event or receipt	“The relay accepted event X at 09:41 UTC.”
Source assertion	An external source reported something	“The guardrail reported policy outcome Y.”
Detector inference	A rule or model inferred meaning	“The event sequence may indicate tool misuse.”
Reviewer conclusion	A named human evaluated the evidence	“The response lead classified this as a contained incident.”

Never rewrite an inference as a fact. Never treat a source’s label as KAIDAN’s independent observation.

Open a case

1. Sign in through the approved Briard-to-KAIDAN access path.
2. Confirm the tenant and environment.
3. Select Cases, then New case.
4. Use a factual title that does not assert an unproven cause.
5. Enter the detection time, reporting source, initial scope, and response owner.
6. Choose the permitted severity.
7. Link the originating alert or evidence receipt.
8. Record known missing sources.
9. Save.

A good title is “Unexpected assistant tool activity on 13 August.” A poor title is “Malicious employee stole data” when intent and data access are not yet established.

Build the timeline

1. Set the time window broad enough to include setup and follow-on activity.
2. Add relevant evidence from approved sources.
3. Normalize time zones to UTC while preserving source time.
4. Review clock-skew indicators.
5. Group by pseudonymous actor, request, trace, deployment, tool, or source receipt where supported.
6. Mark duplicate, replayed, late, and contradicted events.
7. Do not fill an empty period with assumptions.

For each event, open the citation and confirm:

• source package;
• source event time and KAIDAN receipt time;
• evidence classification;
• capability ceiling;
• integrity or custody status; and
• any redaction or pseudonymization note.

Ask investigation questions

Use narrow questions:

• Which approved sources observed this request?
• What model or deployment was requested, and what did the provider actually report as served?
• Which identity, agent, tool, vector store, or guardrail events share a trace or request identifier?
• What evidence supports the sequence?
• Which expected receipts are missing?
• Do any sources contradict one another?
• What was independently verified after the response action?

Avoid “Tell me what happened” without a time, system, and evidence scope.

Review gaps and contradictions

A gap is evidence you expected but do not have. A contradiction is two pieces of evidence that cannot both be accepted without explanation.

For each gap, record:

• expected source;
• expected receipt or field;
• time range;
• reason it may be missing;
• owner;
• next action; and
• effect on the conclusion.

For each contradiction, preserve both records. Do not delete the less convenient one.

Record a conclusion

A reviewer conclusion should include:

• reviewer identity and role;
• time recorded;
• question decided;
• cited evidence;
• contrary evidence;
• unresolved gaps;
• confidence and rationale;
• scope of the conclusion;
• response decision; and
• approval if required.

A conclusion is append-only. If it changes, add a superseding conclusion and explain why.

Record response actions

KAIDAN may record that an action was proposed, approved, attempted, reported by a source, or independently verified. These are different states.

For example:

1. “Revoke token” proposed.
2. Security owner approved.
3. Operator reported execution.
4. Identity provider supplied a revocation receipt.
5. A separate check confirmed the token no longer worked.

Do not mark step 5 complete using only step 3.

KAIDAN does not silently execute response actions as an inline control.

Collaborate safely

• Assign a named owner to each task.
• Use case comments for metadata and decisions, not raw sensitive content.
• Link approved evidence instead of pasting it.
• Mention uncertainty explicitly.
• Follow legal hold and privilege instructions from qualified personnel.
• Keep tenant and role checks visible before sharing.

Export the case

Before export:

• confirm the authorized audience;
• select the case scope and time window;
• review included and excluded evidence;
• label every claim type;
• include gaps and contradictions;
• verify retention and legal-hold restrictions;
• confirm the custody head and signing identity; and
• choose whether the recipient needs an online or offline package.

Create the export. Keep the generated package unchanged.

Verify the export independently

1. Transfer the package and trusted kaidan-verify executable through approved channels.
2. Verify the executable using the release checksums and signature.
3. Run the verifier in an isolated review location.
4. Confirm the package digest, signatures, custody chain, evidence inventory, and validation result.
5. Save the verification receipt separately.
6. If verification fails, preserve the package, stop distribution, and escalate.

Do not unzip, edit, and repackage an evidence export before verification.

Close the case

Close only when the response owner confirms:

• scope is documented;
• evidence and unknowns are preserved;
• conclusions have named reviewers;
• response actions have the correct evidence state;
• required notifications were handled outside KAIDAN;
• exports and verification receipts are retained;
• follow-up controls have owners and dates; and
• source gaps have remediation or accepted-risk decisions.

Closure does not mean every uncertainty disappeared.

Monthly operating routine

• Review users, roles, MFA, and service identities.
• Review connector health and credential age.
• Sample evidence citations and source classification.
• Check dead-letter and replay activity.
• Verify one fictional export offline.
• Review retention, holds, and storage capacity.
• Confirm backup and restore evidence.
• Review exceptions and expiring approvals.
• Schedule the next rollback rehearsal.