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,759 --> 00:00:58,232
Let's choose Review beside the alert about
a tool crossing an approved boundary.

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

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

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

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

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

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

22
00:01:25,234 --> 00:01:27,609
evidence or responder actions open.

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

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

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

26
00:01:43,825 --> 00:01:47,520
Before trusting a quiet alert queue, check
the sources.

27
00:01:47,849 --> 00:01:50,105
Open Sources, then Check a tool link.

28
00:01:50,447 --> 00:01:54,788
This is a fictional local tool, with no
customer provider connected.

29
00:01:55,117 --> 00:01:58,785
The provider catalog is unavailable in this
isolated demo.

30
00:01:59,127 --> 00:02:02,083
That gap stays separate from the tool test
receipt.

31
00:02:02,412 --> 00:02:06,621
The tool is linked, but that alone does not
prove its actions reached KAIDAN.

32
00:02:06,963 --> 00:02:09,496
Health checks and action records are
different.

33
00:02:09,799 --> 00:02:11,080
Start a link test.

34
00:02:11,421 --> 00:02:16,018
Now a fictional, harmless Read observation
enters this isolated application

35
00:02:16,038 --> 00:02:18,466
through its normal metadata-only intake.

36
00:02:18,808 --> 00:02:20,313
Choose See test record.

37
00:02:20,655 --> 00:02:25,424
A fresh receipt confirms the exact event
types listed for this source, version,

38
00:02:25,444 --> 00:02:26,381
and settings.

39
00:02:26,723 --> 00:02:30,286
Open Review details to see the last action
and test proof.

40
00:02:30,628 --> 00:02:34,916
This source has no heartbeat, so its
ongoing health remains unknown.

41
00:02:35,258 --> 00:02:38,609
If a source loses contact, its gap must
stay visible.

42
00:02:38,938 --> 00:02:42,422
Restoring a link does not recover earlier
missing records.

43
00:02:42,777 --> 00:02:47,645
Discovery, connection, a verified test, and
continuous coverage are separate steps.

44
00:02:47,987 --> 00:02:50,917
Start with one approved source and one
clear test.

45
00:02:54,452 --> 00:02:56,471
Here is KAIDAN's Alerts page.

46
00:02:56,826 --> 00:03:00,494
It keeps the queue on the left and the
selected alert on the right.

47
00:03:00,849 --> 00:03:05,209
These alerts were generated by sending
fictional activity records through this

48
00:03:05,229 --> 00:03:07,868
isolated application's normal intake.

49
00:03:08,223 --> 00:03:12,261
The priority buttons and category filter
help you narrow the list.

50
00:03:12,603 --> 00:03:17,332
Open alerts shows the items still in play,
while All saved alerts preserves the

51
00:03:17,352 --> 00:03:18,408
broader history.

52
00:03:18,750 --> 00:03:22,207
Let's search for Refund, then select the
matching alert.

53
00:03:22,562 --> 00:03:26,692
The concern is simple: a tool action lacks
recorded approval.

54
00:03:27,034 --> 00:03:32,027
This teaching record is P3, so we follow
the priority shown rather than assuming

55
00:03:32,047 --> 00:03:33,604
every warning is urgent.

56
00:03:33,946 --> 00:03:39,163
A clear queue, a familiar search box, and
one selected item give a new reviewer a

57
00:03:39,183 --> 00:03:40,925
manageable place to begin.

58
00:03:44,503 --> 00:03:47,129
Start with the plain-language explanation.

59
00:03:47,471 --> 00:03:52,617
KAIDAN shows what happened, what was
affected, what it saw, what remains
unknown,

60
00:03:52,708 --> 00:03:54,015
and what to do next.

61
00:03:54,384 --> 00:03:56,653
Here, the approval record is the issue.

62
00:03:57,009 --> 00:04:00,967
We should check it before deciding that the
action was allowed or harmful.

63
00:04:01,322 --> 00:04:04,990
Notice that the saved business rules are
missing in this example.

64
00:04:05,332 --> 00:04:08,420
KAIDAN says so; it doesn't invent
permission.

65
00:04:08,762 --> 00:04:13,063
Review details opens the supporting facts
and the activity timeline.

66
00:04:13,418 --> 00:04:17,601
The visibility boundary explains the limits
of the collected records.

67
00:04:17,943 --> 00:04:23,266
Routine collection uses metadata:
information about an event, rather than the

68
00:04:23,286 --> 00:04:27,178
contents of messages, documents, or model
replies.

69
00:04:27,533 --> 00:04:31,866
That gives a compliance manager a useful
starting point while keeping deeper

70
00:04:31,886 --> 00:04:34,961
evidence access a separate, governed
decision.

71
00:04:38,546 --> 00:04:40,381
Now let's acknowledge the alert.

72
00:04:40,736 --> 00:04:45,169
That records that someone has seen it; it
does not mean the issue is fixed.

73
00:04:45,525 --> 00:04:49,944
The Resolve button opens a short review
question: What did you find?

74
00:04:50,300 --> 00:04:55,498
The choices are Needs action, Allowed use,
False alarm, or Not enough proof.

75
00:04:55,853 --> 00:05:00,102
These are everyday decisions, supported by
the evidence you've reviewed.

76
00:05:00,444 --> 00:05:03,122
For this example, we'll choose Needs
action.

77
00:05:03,491 --> 00:05:07,053
Watch the save button: it now says Save and
keep open.

78
00:05:07,396 --> 00:05:10,839
After saving, the last review appears on
the alert.

79
00:05:11,195 --> 00:05:14,652
The concern stays visible because follow-up
is still needed.

80
00:05:15,007 --> 00:05:19,406
This helps the next person understand what
you concluded, without treating an

81
00:05:19,426 --> 00:05:24,228
acknowledgment or a closed screen as proof
that the underlying problem went away.

82
00:05:27,789 --> 00:05:30,824
A useful alert should lead to a useful next
step.

83
00:05:31,166 --> 00:05:36,146
In Review details, we can assign the work
to ourselves and save a short suggestion

84
00:05:36,166 --> 00:05:37,275
for the tool owner.

85
00:05:37,630 --> 00:05:42,055
We'll ask the owner to check the refund
tool's approval requirement before another

86
00:05:42,075 --> 00:05:43,290
privileged action.

87
00:05:43,632 --> 00:05:47,247
Save suggestion keeps that recommendation
with the alert.

88
00:05:47,603 --> 00:05:51,350
The confirmation is explicit: no action was
run.

89
00:05:51,705 --> 00:05:54,608
When the issue needs a case, choose
Investigate.

90
00:05:54,950 --> 00:05:59,811
KAIDAN creates an investigation and
preserves the contributing alert records as

91
00:05:59,831 --> 00:06:00,597
evidence.

92
00:06:00,939 --> 00:06:03,235
Choose Investigate again to open it.

93
00:06:03,590 --> 00:06:05,530
The alert and case are now linked.

94
00:06:05,872 --> 00:06:10,074
Your security team can take the
investigation further, while you retain the

95
00:06:10,094 --> 00:06:14,619
original concern, the review result, and
the proposed next step.

96
00:06:18,189 --> 00:06:22,055
Now we are in a fictional KAIDAN case,
using a local demo.

97
00:06:22,397 --> 00:06:27,641
Before opening any technical details, the
access card separates routine monitoring

98
00:06:27,661 --> 00:06:29,812
from this case's extra access.

99
00:06:30,154 --> 00:06:35,199
Routine monitoring records facts about
events, not the contents of messages or

100
00:06:35,219 --> 00:06:35,972
files.

101
00:06:36,314 --> 00:06:39,586
No extra content has been collected for
this case.

102
00:06:39,942 --> 00:06:43,636
One action shows two choices, and neither
is preselected.

103
00:06:43,978 --> 00:06:48,556
Analyze and keep findings can examine
approved content inside your environment,

104
00:06:48,978 --> 00:06:53,556
then keep findings and receipts as case
evidence, not the original content.

105
00:06:53,898 --> 00:06:58,508
Collect selected evidence can keep approved
original items in protected customer

106
00:06:58,528 --> 00:07:03,581
quarantine; exact files need a separate
vault decision and controls.

107
00:07:03,936 --> 00:07:07,459
We'll use the narrower findings check for
this fictional alert.

108
00:07:07,802 --> 00:07:12,939
On the second screen, we confirm the linked
case, a named fictional source, why we

109
00:07:12,959 --> 00:07:15,440
need it, and small time and item limits.

110
00:07:15,782 --> 00:07:20,004
This is a browser simulation, not a
connected customer provider.

111
00:07:20,360 --> 00:07:25,603
The final screen shows the exact proposed
scope, retention boundary, expiry, and

112
00:07:25,623 --> 00:07:27,391
the two-person approval rule.

113
00:07:27,733 --> 00:07:30,122
Send for approval saves the request.

114
00:07:30,477 --> 00:07:32,246
It does not start collection.

115
00:07:32,627 --> 00:07:35,359
Here is the request history at zero of two.

116
00:07:35,701 --> 00:07:40,575
One simulated reviewer approves, then a
different simulated reviewer approves the

117
00:07:40,595 --> 00:07:41,994
same saved scope.

118
00:07:42,336 --> 00:07:45,661
KAIDAN now says approved, but collection
has not started.

119
00:07:46,016 --> 00:07:51,175
These are fictional simulated approvals,
not real people or provider operation.

120
00:07:51,530 --> 00:07:55,898
If a source later runs, a receipt or
failure must be shown separately.

121
00:07:56,240 --> 00:07:59,644
The routine metadata-only alert path is
unchanged.

122
00:08:03,176 --> 00:08:08,242
The case follows an evidence path: Source,
Event, Decision, and Signed package.

123
00:08:08,585 --> 00:08:13,123
Start with where the records came from,
then follow the supported timeline.

124
00:08:13,465 --> 00:08:18,584
Each link keeps source reports, human
decisions, and custody results distinct.

125
00:08:18,913 --> 00:08:23,650
Review technical details opens the existing
investigation tools when needed.

126
00:08:23,979 --> 00:08:26,499
Before sharing, choose Check the record
chain.

127
00:08:26,841 --> 00:08:31,135
This checks the integrity of saved records;
it does not prove that a source

128
00:08:31,155 --> 00:08:34,005
statement is true or that a response
worked.

129
00:08:34,347 --> 00:08:39,195
This local demonstration has no independent
outside timestamp, and that limit

130
00:08:39,215 --> 00:08:40,284
stays visible.

131
00:08:40,613 --> 00:08:44,848
Choose Download case proof, then use Save
ZIP to keep the package.

132
00:08:45,190 --> 00:08:48,621
Your team can review the retained sources
and limits together.

133
00:08:52,223 --> 00:08:55,548
Let us open the fictional cross-tenant
disclosure case.

134
00:08:55,891 --> 00:08:59,928
Information may have crossed a boundary
between customer environments.

135
00:09:00,270 --> 00:09:04,373
The same evidence path keeps this larger
investigation manageable.

136
00:09:04,715 --> 00:09:08,806
Where the records came from shows the
selected records and missing sources.

137
00:09:09,148 --> 00:09:13,211
How it happened, step by step follows the
sequence the evidence supports.

138
00:09:13,554 --> 00:09:18,322
What we can say so far brings the risk
check, evidence-backed answers, and

139
00:09:18,342 --> 00:09:20,044
remaining unknowns together.

140
00:09:20,387 --> 00:09:24,002
Open the proof and limits beside an answer
before using it.

141
00:09:24,344 --> 00:09:29,872
Review technical details expands the
existing investigation tools without losing
the case.

142
00:09:30,214 --> 00:09:33,499
A shared timeline alone does not prove
cause or intent.

143
00:09:33,855 --> 00:09:37,523
Keep the evidence labels and gaps attached
to any conclusion.

144
00:09:41,123 --> 00:09:45,451
Let's connect that investigation work to
Briard's public practice story.

145
00:09:45,806 --> 00:09:50,846
This is another clearly labeled fictional
example you can try without an account.

146
00:09:51,201 --> 00:09:55,759
The saved rule lets a proposal assistant
search approved information, but not

147
00:09:55,779 --> 00:09:57,020
change its settings.

148
00:09:57,362 --> 00:10:00,291
The alert reports an attempted settings
change.

149
00:10:00,633 --> 00:10:05,652
The evidence separates the source report,
KAIDAN's interpretation, and a person's

150
00:10:05,672 --> 00:10:06,451
decision.

151
00:10:06,793 --> 00:10:08,747
Now open the response result.

152
00:10:09,102 --> 00:10:13,179
One person proposed a limited change and
another approved it.

153
00:10:13,534 --> 00:10:17,801
The provider accepted the request, but a
follow-up check still found the unsafe

154
00:10:17,821 --> 00:10:19,009
action possible.

155
00:10:19,352 --> 00:10:21,780
KAIDAN keeps that failed result visible.

156
00:10:22,135 --> 00:10:27,497
For a manager, the question is
straightforward: did the unsafe action
stop, and

157
00:10:27,517 --> 00:10:29,219
does allowed work still work?

158
00:10:29,561 --> 00:10:32,240
A success message alone is not the answer.

159
00:10:35,806 --> 00:10:39,843
The response details also show the handoff
to the security team.

160
00:10:40,185 --> 00:10:44,565
A failed delivery and a later accepted
delivery are separate records.

161
00:10:44,921 --> 00:10:49,684
Even a delivered message does not turn a
failed response into a successful one.

162
00:10:50,026 --> 00:10:54,670
Send a copy lets us preview a destination,
such as a ticketing workflow.

163
00:10:55,025 --> 00:10:56,688
This sample sends nothing.

164
00:10:57,030 --> 00:10:59,142
Next, choose Review what we learned.

165
00:10:59,484 --> 00:11:04,450
This is the connection back to Briard: the
incident can inform a policy owner's

166
00:11:04,470 --> 00:11:05,104
review.

167
00:11:05,459 --> 00:11:10,122
The original rule, the missing evidence,
and the failed response remain part of

168
00:11:10,142 --> 00:11:10,908
the story.

169
00:11:11,264 --> 00:11:14,589
The owner can decide whether clearer
instructions are needed.

170
00:11:14,944 --> 00:11:18,960
That closes the learning loop without
losing the history of what happened or

171
00:11:18,980 --> 00:11:20,630
skipping the follow-up work.

172
00:11:24,219 --> 00:11:29,153
Here is the proposed policy improvement:
keep only the access the tool needs,

173
00:11:29,350 --> 00:11:34,211
check both unsafe and allowed actions after
a change, and ask the owner to review

174
00:11:34,231 --> 00:11:36,210
the next plan if a check fails.

175
00:11:36,566 --> 00:11:40,009
The policy owner can accept, revise, or
decline.

176
00:11:40,365 --> 00:11:44,310
We'll accept these sample words into a
draft and record the decision.

177
00:11:44,665 --> 00:11:46,605
This does not publish a policy.

178
00:11:46,960 --> 00:11:51,644
Download and verify checks the sample file
before saving it, keeping the rule,

179
00:11:51,881 --> 00:11:54,981
alert, evidence, response, and review
together.

180
00:11:55,350 --> 00:12:00,179
Back in Briard, My AI policy has separate
steps for drafting, approval,

181
00:12:00,415 --> 00:12:02,778
publishing, and tracking acknowledgments.

182
00:12:03,120 --> 00:12:07,967
KAIDAN supplies the incident evidence;
Briard gives your organization a place to

183
00:12:07,987 --> 00:12:10,297
review what the rules should say next.

184
00:12:13,892 --> 00:12:16,545
You now have a practical route through the
platform.

185
00:12:16,887 --> 00:12:18,827
See a KAIDAN alert in Briard.

186
00:12:19,182 --> 00:12:20,581
Open the matching item.

187
00:12:20,923 --> 00:12:23,259
Read the explanation and evidence.

188
00:12:23,601 --> 00:12:27,757
Record your review, involve the right
owner, and check the response.

189
00:12:28,099 --> 00:12:31,569
Then carry the lesson into a policy review
when needed.

190
00:12:31,925 --> 00:12:34,775
Start with one alert and one clear next
step.

191
00:12:35,117 --> 00:12:40,400
To begin using Briard or discuss KAIDAN for
your organization, visit briard dot A

192
00:12:40,420 --> 00:12:40,922
I.

193
00:12:41,277 --> 00:12:45,486
You can also contact the team at support at
briard dash A I dot app.

194
00:12:45,855 --> 00:12:49,114
We'll help you choose a sensible starting
point for your team.