1
00:00:01,306 --> 00:00:01,913
Welcome!

2
00:00:02,268 --> 00:00:07,295
Let's see how KAIDAN helps you turn an AI
security alert into a clear next step.

3
00:00:07,637 --> 00:00:11,622
We'll start exactly where a Briard customer
starts: Home.

4
00:00:11,964 --> 00:00:16,508
The AI incident alerts panel brings
KAIDAN's alert summary into your everyday

5
00:00:16,528 --> 00:00:17,518
workspace.

6
00:00:17,861 --> 00:00:22,241
You can see what needs attention without
opening a technical console first.

7
00:00:22,609 --> 00:00:24,642
P1 needs the fastest review.

8
00:00:24,984 --> 00:00:27,781
The other priorities help you organize the
queue.

9
00:00:28,136 --> 00:00:32,359
An alert is a reason to investigate, not
proof that harm occurred.

10
00:00:32,701 --> 00:00:37,509
This walkthrough uses fictional examples,
including an isolated copy of the

11
00:00:37,529 --> 00:00:39,337
released KAIDAN application.

12
00:00:39,679 --> 00:00:43,254
No customer information or live systems are
involved.

13
00:00:43,597 --> 00:00:48,062
We'll follow the connection from Briard to
KAIDAN, work an alert, and bring the

14
00:00:48,082 --> 00:00:50,180
lesson back to a policy review.

15
00:00:53,745 --> 00:00:58,217
Let's choose Review beside the alert about
a tool crossing an approved boundary.

16
00:00:58,559 --> 00:01:03,797
Briard opens the matching KAIDAN alert,
keeping its title and alert ID together.

17
00:01:04,139 --> 00:01:08,018
You can also see the affected tool,
priority, and status.

18
00:01:08,374 --> 00:01:12,859
That continuity matters: your team starts
with the item you selected.

19
00:01:13,215 --> 00:01:16,157
Back to Briard alerts returns us to the
overview.

20
00:01:16,513 --> 00:01:20,115
Open all KAIDAN alerts takes us to the
work-account sign-in.

21
00:01:20,457 --> 00:01:25,199
Access and any required identity
verification still apply before protected

22
00:01:25,219 --> 00:01:27,594
evidence or responder actions open.

23
00:01:27,949 --> 00:01:31,776
This public preview shows the handoff using
made-up records.

24
00:01:32,118 --> 00:01:36,999
Next, we'll use a separate fictional
refund-agent alert in KAIDAN's full
console,

25
00:01:37,236 --> 00:01:40,205
so you can see the actual review controls
in action.

26
00:01:43,823 --> 00:01:45,842
Here is KAIDAN's Alerts page.

27
00:01:46,198 --> 00:01:49,866
It keeps the queue on the left and the
selected alert on the right.

28
00:01:50,221 --> 00:01:54,580
These alerts were generated by sending
fictional activity records through this

29
00:01:54,600 --> 00:01:57,239
isolated application's normal intake.

30
00:01:57,595 --> 00:02:01,632
The priority buttons and category filter
help you narrow the list.

31
00:02:01,974 --> 00:02:06,703
Open alerts shows the items still in play,
while All saved alerts preserves the

32
00:02:06,723 --> 00:02:07,779
broader history.

33
00:02:08,121 --> 00:02:11,578
Let's search for Refund, then select the
matching alert.

34
00:02:11,934 --> 00:02:16,063
The concern is simple: a tool action lacks
recorded approval.

35
00:02:16,405 --> 00:02:21,398
This teaching record is P3, so we follow
the priority shown rather than assuming

36
00:02:21,418 --> 00:02:22,975
every warning is urgent.

37
00:02:23,318 --> 00:02:28,534
A clear queue, a familiar search box, and
one selected item give a new reviewer a

38
00:02:28,554 --> 00:02:30,297
manageable place to begin.

39
00:02:33,875 --> 00:02:36,501
Start with the plain-language explanation.

40
00:02:36,843 --> 00:02:41,988
KAIDAN shows what happened, what was
affected, what it saw, what remains
unknown,

41
00:02:42,080 --> 00:02:43,387
and what to do next.

42
00:02:43,755 --> 00:02:46,025
Here, the approval record is the issue.

43
00:02:46,380 --> 00:02:50,338
We should check it before deciding that the
action was allowed or harmful.

44
00:02:50,694 --> 00:02:54,362
Notice that the saved business rules are
missing in this example.

45
00:02:54,704 --> 00:02:57,792
KAIDAN says so; it doesn't invent
permission.

46
00:02:58,134 --> 00:03:02,435
Review details opens the supporting facts
and the activity timeline.

47
00:03:02,790 --> 00:03:06,973
The visibility boundary explains the limits
of the collected records.

48
00:03:07,315 --> 00:03:12,637
Routine collection uses metadata:
information about an event, rather than the

49
00:03:12,657 --> 00:03:16,549
contents of messages, documents, or model
replies.

50
00:03:16,905 --> 00:03:21,238
That gives a compliance manager a useful
starting point while keeping deeper

51
00:03:21,258 --> 00:03:24,332
evidence access a separate, governed
decision.

52
00:03:27,918 --> 00:03:29,753
Now let's acknowledge the alert.

53
00:03:30,108 --> 00:03:34,541
That records that someone has seen it; it
does not mean the issue is fixed.

54
00:03:34,897 --> 00:03:39,317
The Resolve button opens a short review
question: What did you find?

55
00:03:39,672 --> 00:03:44,870
The choices are Needs action, Allowed use,
False alarm, or Not enough proof.

56
00:03:45,225 --> 00:03:49,474
These are everyday decisions, supported by
the evidence you've reviewed.

57
00:03:49,816 --> 00:03:52,495
For this example, we'll choose Needs
action.

58
00:03:52,863 --> 00:03:56,426
Watch the save button: it now says Save and
keep open.

59
00:03:56,768 --> 00:04:00,211
After saving, the last review appears on
the alert.

60
00:04:00,567 --> 00:04:04,024
The concern stays visible because follow-up
is still needed.

61
00:04:04,379 --> 00:04:08,778
This helps the next person understand what
you concluded, without treating an

62
00:04:08,798 --> 00:04:13,600
acknowledgment or a closed screen as proof
that the underlying problem went away.

63
00:04:17,162 --> 00:04:20,197
A useful alert should lead to a useful next
step.

64
00:04:20,539 --> 00:04:25,518
In Review details, we can assign the work
to ourselves and save a short suggestion

65
00:04:25,538 --> 00:04:26,647
for the tool owner.

66
00:04:27,003 --> 00:04:31,428
We'll ask the owner to check the refund
tool's approval requirement before another

67
00:04:31,448 --> 00:04:32,662
privileged action.

68
00:04:33,005 --> 00:04:36,620
Save suggestion keeps that recommendation
with the alert.

69
00:04:36,975 --> 00:04:40,722
The confirmation is explicit: no action was
run.

70
00:04:41,078 --> 00:04:43,980
When the issue needs a case, choose
Investigate.

71
00:04:44,323 --> 00:04:49,183
KAIDAN creates an investigation and
preserves the contributing alert records as

72
00:04:49,203 --> 00:04:49,969
evidence.

73
00:04:50,311 --> 00:04:52,608
Choose Investigate again to open it.

74
00:04:52,963 --> 00:04:54,903
The alert and case are now linked.

75
00:04:55,245 --> 00:04:59,446
Your security team can take the
investigation further, while you retain the

76
00:04:59,466 --> 00:05:03,992
original concern, the review result, and
the proposed next step.

77
00:05:07,553 --> 00:05:10,628
The case is the working record of the
investigation.

78
00:05:10,970 --> 00:05:15,588
Simple view brings the summary, supported
answers, and next steps together.

79
00:05:15,943 --> 00:05:20,851
Open a linked record to see where the
information came from, when it was
reported,

80
00:05:21,087 --> 00:05:22,948
and which action it describes.

81
00:05:23,304 --> 00:05:26,061
You don't need to read code to follow that
connection.

82
00:05:26,403 --> 00:05:29,135
Before sharing, use the record-chain check.

83
00:05:29,490 --> 00:05:34,021
It tests the integrity of the retained
evidence, not whether every statement in

84
00:05:34,041 --> 00:05:35,216
the source is true.

85
00:05:35,571 --> 00:05:41,105
Our local demonstration has no independent
outside timestamp, and that limitation

86
00:05:41,125 --> 00:05:42,273
remains visible.

87
00:05:42,615 --> 00:05:45,690
Download case proof saves the evidence
package.

88
00:05:46,058 --> 00:05:50,774
The practical benefit is a record your team
can review together, with its sources

89
00:05:50,794 --> 00:05:55,188
and limits attached, rather than a
conclusion copied into an email.

90
00:05:58,779 --> 00:06:03,700
For a larger example, let's open the
preloaded cross-tenant disclosure case.

91
00:06:04,056 --> 00:06:08,832
That means information may have crossed a
boundary between customer environments.

92
00:06:09,174 --> 00:06:13,567
KAIDAN has selected relevant records into
four evidence-backed answers.

93
00:06:13,936 --> 00:06:19,174
The risk check helps prioritize review, and
its missing coverage remains visible.

94
00:06:19,503 --> 00:06:21,548
Scroll to What we can answer now.

95
00:06:21,903 --> 00:06:26,508
The questions are written for people: Was a
data safety rule weak or missing?

96
00:06:26,850 --> 00:06:28,553
Did a safety tool warn us?

97
00:06:28,895 --> 00:06:30,888
Could a tool act without approval?

98
00:06:31,243 --> 00:06:35,043
Open the proof and limits beside an answer
to see its basis.

99
00:06:35,398 --> 00:06:38,393
The timeline then walks through the
supported sequence.

100
00:06:38,736 --> 00:06:44,005
This is how KAIDAN makes a complex incident
easier to examine: it organizes the

101
00:06:44,025 --> 00:06:48,485
records, shows the reasoning labels, and
keeps the source links close.

102
00:06:52,040 --> 00:06:56,368
Let's connect that investigation work to
Briard's public practice story.

103
00:06:56,723 --> 00:07:01,763
This is another clearly labeled fictional
example you can try without an account.

104
00:07:02,118 --> 00:07:06,676
The saved rule lets a proposal assistant
search approved information, but not

105
00:07:06,696 --> 00:07:07,936
change its settings.

106
00:07:08,279 --> 00:07:11,208
The alert reports an attempted settings
change.

107
00:07:11,550 --> 00:07:16,569
The evidence separates the source report,
KAIDAN's interpretation, and a person's

108
00:07:16,589 --> 00:07:17,368
decision.

109
00:07:17,710 --> 00:07:19,663
Now open the response result.

110
00:07:20,019 --> 00:07:24,096
One person proposed a limited change and
another approved it.

111
00:07:24,451 --> 00:07:28,718
The provider accepted the request, but a
follow-up check still found the unsafe

112
00:07:28,738 --> 00:07:29,926
action possible.

113
00:07:30,268 --> 00:07:32,696
KAIDAN keeps that failed result visible.

114
00:07:33,052 --> 00:07:38,414
For a manager, the question is
straightforward: did the unsafe action
stop, and

115
00:07:38,434 --> 00:07:40,136
does allowed work still work?

116
00:07:40,478 --> 00:07:43,157
A success message alone is not the answer.

117
00:07:46,723 --> 00:07:50,760
The response details also show the handoff
to the security team.

118
00:07:51,102 --> 00:07:55,483
A failed delivery and a later accepted
delivery are separate records.

119
00:07:55,838 --> 00:08:00,601
Even a delivered message does not turn a
failed response into a successful one.

120
00:08:00,943 --> 00:08:05,587
Send a copy lets us preview a destination,
such as a ticketing workflow.

121
00:08:05,943 --> 00:08:07,605
This sample sends nothing.

122
00:08:07,948 --> 00:08:10,059
Next, choose Review what we learned.

123
00:08:10,401 --> 00:08:15,367
This is the connection back to Briard: the
incident can inform a policy owner's

124
00:08:15,387 --> 00:08:16,021
review.

125
00:08:16,377 --> 00:08:21,040
The original rule, the missing evidence,
and the failed response remain part of

126
00:08:21,060 --> 00:08:21,826
the story.

127
00:08:22,181 --> 00:08:25,506
The owner can decide whether clearer
instructions are needed.

128
00:08:25,861 --> 00:08:29,878
That closes the learning loop without
losing the history of what happened or

129
00:08:29,898 --> 00:08:31,548
skipping the follow-up work.

130
00:08:35,145 --> 00:08:40,079
Here is the proposed policy improvement:
keep only the access the tool needs,

131
00:08:40,276 --> 00:08:45,137
check both unsafe and allowed actions after
a change, and ask the owner to review

132
00:08:45,157 --> 00:08:47,136
the next plan if a check fails.

133
00:08:47,492 --> 00:08:50,936
The policy owner can accept, revise, or
decline.

134
00:08:51,291 --> 00:08:55,236
We'll accept these sample words into a
draft and record the decision.

135
00:08:55,591 --> 00:08:57,531
This does not publish a policy.

136
00:08:57,886 --> 00:09:02,570
Download and verify checks the sample file
before saving it, keeping the rule,

137
00:09:02,807 --> 00:09:05,908
alert, evidence, response, and review
together.

138
00:09:06,276 --> 00:09:11,105
Back in Briard, My AI policy has separate
steps for drafting, approval,

139
00:09:11,342 --> 00:09:13,704
publishing, and tracking acknowledgments.

140
00:09:14,046 --> 00:09:18,893
KAIDAN supplies the incident evidence;
Briard gives your organization a place to

141
00:09:18,913 --> 00:09:21,223
review what the rules should say next.

142
00:09:24,805 --> 00:09:27,458
You now have a practical route through the
platform.

143
00:09:27,800 --> 00:09:29,740
See a KAIDAN alert in Briard.

144
00:09:30,095 --> 00:09:31,494
Open the matching item.

145
00:09:31,836 --> 00:09:34,172
Read the explanation and evidence.

146
00:09:34,514 --> 00:09:38,670
Record your review, involve the right
owner, and check the response.

147
00:09:39,012 --> 00:09:42,482
Then carry the lesson into a policy review
when needed.

148
00:09:42,838 --> 00:09:45,688
Start with one alert and one clear next
step.

149
00:09:46,030 --> 00:09:51,313
To begin using Briard or discuss KAIDAN for
your organization, visit briard dot A

150
00:09:51,333 --> 00:09:51,835
I.

151
00:09:52,190 --> 00:09:56,399
You can also contact the team at support at
briard dash A I dot app.

152
00:09:56,768 --> 00:10:00,027
We'll help you choose a sensible starting
point for your team.