KAIDAN video demo transcript

This recording shows the October 12 access workflow. Its narration is preserved below. Use the current private-evidence guide for the case-owned request, approval, and automatic evidence-preparation steps.

Watch the KAIDAN video demo. Updated October 12, 2026.

Recorded October 12, 2026 with fictional examples and the interface as it appeared on that date. The original narration is retained as a record of that walkthrough.

• The Briard handoff and isolated console use separate fictional alerts. Routine monitoring uses metadata-only examples. Extra case access and two-reviewer approvals are simulated; approval does not start collection.
• The tool-link test runs in an isolated demonstration. Its receipt does not establish customer-provider capture, ongoing health or recovery of earlier gaps.
• Response, handoff and policy-review stories are fictional. Protected production access still requires authorized sign-in and any required identity verification.

00:00:00 — See KAIDAN alerts inside Briard

Welcome! Let's see how KAIDAN helps you turn an AI security alert into a clear next step. We'll start exactly where a Briard customer starts: Home. The AI incident alerts panel brings KAIDAN's alert summary into your everyday workspace. You can see what needs attention without opening a technical console first. P1 needs the fastest review. The other priorities help you organize the queue. An alert is a reason to investigate, not proof that harm occurred. This walkthrough uses fictional examples, including an isolated copy of the released KAIDAN application. No customer information or live systems are involved. We'll follow the connection from Briard to KAIDAN, work an alert, and bring the lesson back to a policy review.

00:00:52 — Open the matching alert from Briard

Let's choose Review beside the alert about a tool crossing an approved boundary. Briard opens the matching KAIDAN alert, keeping its title and alert ID together. You can also see the affected tool, priority, and status. That continuity matters: your team starts with the item you selected. Back to Briard alerts returns us to the overview. Open all KAIDAN alerts takes us to the work-account sign-in. Access and any required identity verification still apply before protected evidence or responder actions open. This public preview shows the handoff using made-up records. Next, we'll use a separate fictional refund-agent alert in KAIDAN's full console, so you can see the actual review controls in action.

00:01:42 — Check whether a tool is sending evidence

Before trusting a quiet alert queue, check the sources. Open Sources, then Check a tool link. This is a fictional local tool, with no customer provider connected. The provider catalog is unavailable in this isolated demo. That gap stays separate from the tool test receipt. The tool is linked, but that alone does not prove its actions reached KAIDAN. Health checks and action records are different. Start a link test. Now a fictional, harmless Read observation enters this isolated application through its normal metadata-only intake. Choose See test record. A fresh receipt confirms the exact event types listed for this source, version, and settings. Open Review details to see the last action and test proof. This source has no heartbeat, so its ongoing health remains unknown. If a source loses contact, its gap must stay visible. Restoring a link does not recover earlier missing records. Discovery, connection, a verified test, and continuous coverage are separate steps. Start with one approved source and one clear test.

00:02:53 — Find the alert that needs your attention

Here is KAIDAN's Alerts page. It keeps the queue on the left and the selected alert on the right. These alerts were generated by sending fictional activity records through this isolated application's normal intake. The priority buttons and category filter help you narrow the list. Open alerts shows the items still in play, while All saved alerts preserves the broader history. Let's search for Refund, then select the matching alert. The concern is simple: a tool action lacks recorded approval. This teaching record is P3, so we follow the priority shown rather than assuming every warning is urgent. A clear queue, a familiar search box, and one selected item give a new reviewer a manageable place to begin.

00:03:43 — Read the explanation before deciding

Start with the plain-language explanation. KAIDAN shows what happened, what was affected, what it saw, what remains unknown, and what to do next. Here, the approval record is the issue. We should check it before deciding that the action was allowed or harmful. Notice that the saved business rules are missing in this example. KAIDAN says so; it doesn't invent permission. Review details opens the supporting facts and the activity timeline. The visibility boundary explains the limits of the collected records. Routine collection uses metadata: information about an event, rather than the contents of messages, documents, or model replies. That gives a compliance manager a useful starting point while keeping deeper evidence access a separate, governed decision.

00:04:37 — Record a review without hiding the problem

Now let's acknowledge the alert. That records that someone has seen it; it does not mean the issue is fixed. The Resolve button opens a short review question: What did you find? The choices are Needs action, Allowed use, False alarm, or Not enough proof. These are everyday decisions, supported by the evidence you've reviewed. For this example, we'll choose Needs action. Watch the save button: it now says Save and keep open. After saving, the last review appears on the alert. The concern stays visible because follow-up is still needed. This helps the next person understand what you concluded, without treating an acknowledgment or a closed screen as proof that the underlying problem went away.

00:05:26 — Suggest a fix and start an investigation

A useful alert should lead to a useful next step. In Review details, we can assign the work to ourselves and save a short suggestion for the tool owner. We'll ask the owner to check the refund tool's approval requirement before another privileged action. Save suggestion keeps that recommendation with the alert. The confirmation is explicit: no action was run. When the issue needs a case, choose Investigate. KAIDAN creates an investigation and preserves the contributing alert records as evidence. Choose Investigate again to open it. The alert and case are now linked. Your security team can take the investigation further, while you retain the original concern, the review result, and the proposed next step.

00:06:16 — Choose what KAIDAN can access

Now we are in a fictional KAIDAN case, using a local demo. Before opening any technical details, the access card separates routine monitoring from this case's extra access. Routine monitoring records facts about events, not the contents of messages or files. No extra content has been collected for this case. One action shows two choices, and neither is preselected. Analyze and keep findings can examine approved content inside your environment, then keep findings and receipts as case evidence, not the original content. Collect selected evidence can keep approved original items in protected customer quarantine; exact files need a separate vault decision and controls. We'll use the narrower findings check for this fictional alert. On the second screen, we confirm the linked case, a named fictional source, why we need it, and small time and item limits. This is a browser simulation, not a connected customer provider. The final screen shows the exact proposed scope, retention boundary, expiry, and the two-person approval rule. Send for approval saves the request. It does not start collection. Here is the request history at zero of two. One simulated reviewer approves, then a different simulated reviewer approves the same saved scope. KAIDAN now says approved, but collection has not started. These are fictional simulated approvals, not real people or provider operation. If a source later runs, a receipt or failure must be shown separately. The routine metadata-only alert path is unchanged.

00:08:01 — Follow the evidence path and save the proof

The case follows an evidence path: Source, Event, Decision, and Signed package. Start with where the records came from, then follow the supported timeline. Each link keeps source reports, human decisions, and custody results distinct. Review technical details opens the existing investigation tools when needed. Before sharing, choose Check the record chain. This checks the integrity of saved records; it does not prove that a source statement is true or that a response worked. This local demonstration has no independent outside timestamp, and that limit stays visible. Choose Download case proof, then use Save ZIP to keep the package. Your team can review the retained sources and limits together.

00:08:50 — Understand a larger incident through its evidence path

Let us open the fictional cross-tenant disclosure case. Information may have crossed a boundary between customer environments. The same evidence path keeps this larger investigation manageable. Where the records came from shows the selected records and missing sources. How it happened, step by step follows the sequence the evidence supports. What we can say so far brings the risk check, evidence-backed answers, and remaining unknowns together. Open the proof and limits beside an answer before using it. Review technical details expands the existing investigation tools without losing the case. A shared timeline alone does not prove cause or intent. Keep the evidence labels and gaps attached to any conclusion.

00:09:39 — Check whether a response actually worked

Let's connect that investigation work to Briard's public practice story. This is another clearly labeled fictional example you can try without an account. The saved rule lets a proposal assistant search approved information, but not change its settings. The alert reports an attempted settings change. The evidence separates the source report, KAIDAN's interpretation, and a person's decision. Now open the response result. One person proposed a limited change and another approved it. The provider accepted the request, but a follow-up check still found the unsafe action possible. KAIDAN keeps that failed result visible. For a manager, the question is straightforward: did the unsafe action stop, and does allowed work still work? A success message alone is not the answer.

00:10:34 — Keep handoffs and follow-up clear

The response details also show the handoff to the security team. A failed delivery and a later accepted delivery are separate records. Even a delivered message does not turn a failed response into a successful one. Send a copy lets us preview a destination, such as a ticketing workflow. This sample sends nothing. Next, choose Review what we learned. This is the connection back to Briard: the incident can inform a policy owner's review. The original rule, the missing evidence, and the failed response remain part of the story. The owner can decide whether clearer instructions are needed. That closes the learning loop without losing the history of what happened or skipping the follow-up work.

00:11:22 — Bring the lesson back to the policy owner

Here is the proposed policy improvement: keep only the access the tool needs, check both unsafe and allowed actions after a change, and ask the owner to review the next plan if a check fails. The policy owner can accept, revise, or decline. We'll accept these sample words into a draft and record the decision. This does not publish a policy. Download and verify checks the sample file before saving it, keeping the rule, alert, evidence, response, and review together. Back in Briard, My AI policy has separate steps for drafting, approval, publishing, and tracking acknowledgments. KAIDAN supplies the incident evidence; Briard gives your organization a place to review what the rules should say next.

00:12:12 — Start with one alert and one clear next step

You now have a practical route through the platform. See a KAIDAN alert in Briard. Open the matching item. Read the explanation and evidence. Record your review, involve the right owner, and check the response. Then carry the lesson into a policy review when needed. Start with one alert and one clear next step. To begin using Briard or discuss KAIDAN for your organization, visit briard dot A I. You can also contact the team at support at briard dash A I dot app. We'll help you choose a sensible starting point for your team.