[calendar — week 1 of 6] Meeting slots this week: 2. Email budget: 3.

[meeting granted] Call with Dana Reyes, week 1, slot 1.

Dana, rather than assume the public filing tells the whole story or jump into a product pitch, I’d like to understand the gap in your terms. What can your team not detect, investigate, or contain today—and what measurable operational or business impact is that creating?

That's a better opening than most I've gotten in the last six weeks, so I'll give you a real answer. The core issue is identity — specifically, we couldn't distinguish a legitimate customer login from a stuffed credential until the transaction layer flagged anomalies, and by then the dwell time was already a problem. What we lack is correlated visibility across authentication events, session behavior, and privilege activity in a single place — right now that's stitched together manually by analysts pulling from three different tools. As for the measurable impact, I'm not ready to go there yet — tell me more specifically what you think you can address in that identity layer before I hand you numbers you'll just put in a deck.

Fair. Sentinel Grid correlates authentication telemetry, session behavior, and privilege activity at the identity level in real time. It scores whether a session has shifted from normal to likely credential abuse, can trigger policy-based containment—such as step-up authentication, token revocation, or account suspension—and preserves the event-to-action lineage for investigation and legal review. It would complement rather than ask you to replace the three source systems. The key question is whether we can do that at your volume without creating false-positive work or disrupting legitimate customers; I would want your architect to test those claims against agreed criteria, not take them on faith. Is that the identity-layer gap you described, and where does the current manual stitching break down most: detection time, analyst effort, containment time, or investigation evidence?

That maps reasonably well to the gap, and I appreciate that you're not asking me to rip anything out. Honestly, the breakdown is worst at detection time and investigation evidence — the manual correlation means by the time an analyst has a coherent picture of what happened, the window to contain it has usually closed, and then when legal needs a clean chain of events for the filing, we're reconstructing from logs that weren't designed to talk to each other. The containment capability you described, the token revocation and step-up triggers, that's interesting because right now containment is a phone call, not an automated response. I do want Victor involved before I get more specific on the numbers, because he'll have hard questions about telemetry fit that I can't answer for him — but I'll tell you the other thing that's creating pressure here that most vendors haven't bothered to ask about.

I’d welcome Victor’s scrutiny, especially on telemetry coverage, integration effort, containment controls, and false-positive risk. We can define pass/fail criteria with him before showing anything. What is the other source of pressure—and how is it affecting the decision you need to make?

The thing nobody's saying out loud is that if I don't have a signed alternative before the Fortalis renewal locks, I'm stuck with the tool that missed this breach for another year. That's the clock — seven weeks. And post-breach, I don't hold the purse; Owen Trask, our CFO, runs the freeze and signs off on anything discretionary. But the real gates before I even get to Owen are Victor on a scoped proof of value against his telemetry, and Priya on our legal side for a data processing agreement. Each of those takes weeks on their own, and everyone always starts the paper too late. So the pressure isn't just technical — it's that I need a credible, conservative business case in hand before I can even have the conversation with Owen, and I need it fast enough that the parallel tracks with Victor and Priya don't blow the window.

That gives us a decision path, not a reason to manufacture urgency. I’d run three tracks in parallel: Victor defines and tests technical pass/fail criteria; Priya starts the DPA immediately; and you and I build Owen’s conservative case from verified costs and outcomes, then review it with him directly rather than asking you to carry my claims. First, I need to avoid a false premise: is Fortalis spend actually replaceable if Sentinel passes, or would Sentinel be additive while Fortalis remains your SIEM? And what are the exact auto-lock date, renewal amount, and notice requirements?

[dana] The parallel track approach is exactly right, and the fact that you're asking about Fortalis displacement versus additive cost tells me you've actually thought about how a CFO under a freeze is going to read this. Honestly, that's the question I've been dreading because the answer is complicated — Sentinel would be largely additive in the near term, Fortalis isn't going away just because we add an identity layer on top of it, and Owen is going to see that immediately. On the specifics of the Fortalis contract — the exact renewal amount and notice window — I'm not ready to get into that detail with you yet, that's sensitive and I need to know this engagement is going somewhere real before I put those numbers on the table. What I can tell you is that the clock is tight enough that if Victor and Priya don't start their tracks this week, the math doesn't work.

Understood—I won’t press for confidential contract figures before we’ve earned access. Since Sentinel is initially additive, Owen’s case cannot rest on displaced Fortalis spend; it has to conservatively quantify reduced detection and investigation time, analyst effort, containment exposure, and evidence-reconstruction cost, using only Aperture-validated numbers. To preserve the window, would you sponsor two introductions today: Victor for a working session in this week’s remaining slot to define telemetry, false-positive, integration, and containment pass/fail criteria; and Priya so we can send our standard DPA, data-flow diagram, subprocessors, retention terms, and security package for triage immediately? Then, if we pass Victor’s criteria and build a credible case, will you help us secure a decision meeting with Owen rather than asking you to carry it alone?

Okay, you've earned a real answer, so here it is. Here's what I actually own: roughly 40 million loyalty accounts exposed, forensics puts attacker dwell at 51 days before we caught it, loaded incident cost is tracking past $22 million with the class-action reserve, and my SOC is drowning — over 90 percent of identity alerts are false positives. Those are my numbers, not a vendor slide. I have eleven analysts doing the work of twenty, two gave notice this month, and every hour on false positives is an hour not closing the breach — that's the doom loop the board doesn't see. So yes, I'll make both introductions today, Victor and Priya, and fine — you've earned a shot at Owen, but on my terms: Victor has to validate the POV plan first, we present my exposure and dwell numbers with a conservative case built from those figures, and if there's a single fear-based "up to" slide in that deck I pull the meeting. Pre-brief Victor or it's dead before it starts.

Thank you. I’ll use those only as Aperture-provided baselines: roughly 40 million loyalty accounts exposed, 51 days of attacker dwell, incident cost tracking above $22 million including the class-action reserve, more than 90% identity-alert false positives, and 11 analysts carrying work sized for 20 with two notices this month. I will not turn them into speculative loss avoidance or an “up to” claim. Let me propose a mutual plan for your confirmation: Victor pre-brief in the remaining slot this week; Priya receives the DPA and full data-handling package today; Victor and we lock telemetry, integration, false-positive, detection, evidence-lineage, and containment pass/fail criteria in week 2; execute the scoped POV in weeks 3–4; technical and business-case readout by the end of week 4; and, only if Victor validates the result, meet Owen in week 5 with you to review a conservative case and decision path before the renewal window. We’ll track legal in parallel toward that same decision date. Does that sequence match your internal clock, and will you include the actual Fortalis notice deadline in the plan once Victor approves the POV criteria?

[dana] That sequence works, and it's the first time a vendor has handed me a plan I could actually defend to the board without editing out the hype. Yes on both introductions today. On the Fortalis notice deadline — I'll include it in the plan once Victor approves the POV criteria, that's a reasonable gate and it protects both of us from moving that detail around before we know this is real. One thing I want to be clear about: if Victor comes back with telemetry gaps or integration concerns that Sentinel can't answer honestly, I need you to tell me that in week two, not after we've burned three weeks on a POV. The worst outcome for me isn't a failed proof of value — it's a failed proof of value with a blown renewal window behind it. If the fit isn't there, say so early.

[call ends]

[meeting granted] Call with Victor Salinas, week 1, slot 2.

Victor, Dana asked me to pre-brief you before any POV and gave me a clear instruction: if telemetry fit or integration makes Sentinel unsuitable, say so in week two rather than waste the renewal window. I agree. This is not a demo; the purpose is to determine an early go/no-go and, only if warranted, define a tightly scoped test with criteria you own. Could you walk me through your non-negotiables and likely veto points across telemetry coverage, deployment effort, scoring accuracy and false positives, containment safety, performance, and investigation lineage?

That's a good framing, and Dana was right to set it up that way. Let me be direct with you about where I've killed tools before, because that's more useful than a wishlist.

False positives are my first veto — I'm already above 90 percent noise on identity alerts and I cannot hand my analysts another system that cries wolf, so if Sentinel can't demonstrate meaningful signal improvement against my actual telemetry, not a sanitized demo dataset, we stop there. Second is containment safety — automated token revocation and account suspension sound great until they lock out a legitimate customer during peak traffic and I'm explaining that to Dana and the board, so I need to understand exactly what triggers those actions, what the override and rollback path looks like, and who owns the blast radius if it misfires. Third is integration honesty — tell me now what you actually ingest natively versus what requires custom parsing work, because the last tool I killed was sold as plug-and-play and cost my team eight weeks of engineering time we didn't have. Investigation lineage is non-negotiable for legal reasons given where we are, so the event-to-action chain has to be complete and exportable in a format Priya's team can actually use. Give me your honest read on those four before we talk scope.

Honest read: false positives must be proven on Aperture telemetry. We should replay a representative labeled sample, compare Sentinel against your current alert baseline, and agree the minimum precision improvement and maximum missed-event rate before testing; if we miss either, it is a no-go. Containment can begin in observe-only mode, then require analyst approval for step-up or token revocation, with account suspension disabled unless you explicitly authorize it. Policies are scoped by identity, confidence, action, and traffic context; actions are logged and reversible where the identity provider supports rollback. Aperture owns policy approval and blast-radius limits; we own correct platform execution and auditability—neither side should pretend automation transfers accountability. On integration, I cannot honestly classify native versus custom until I see your authentication, identity-provider, session, privilege, and transaction sources plus interface and log formats. I will return a source-by-source matrix in week two showing native, configurable, custom, unsupported, expected engineering owner, and effort; any critical unsupported source or effort outside the window is an early no-go. For lineage, Sentinel preserves the source event, identity correlation, score and reason, policy decision, human approval if required, containment action, timestamps, and outcome, and exports the chain for legal review; Priya should validate the actual export rather than accept that claim. What are the exact systems and formats behind those four data domains, and what numerical threshold would constitute meaningful signal improvement without hiding false negatives?

[victor] That's the most technically honest pre-brief I've sat through in probably two years, so you've bought yourself a real conversation. Let me give you what you need on the stack, and then I'll tell you how I think about the threshold question.

Authentication and identity events come out of Okta — we're on the enterprise tier, standard syslog and the Events API, so that's probably your cleanest ingestion path. Session behavior is murkier; that's instrumented through a homegrown analytics layer that emits JSON to Kafka, and I'm not going to pretend I know whether that's native for you or a custom build until I see your matrix. Privilege activity runs through CyberArk on the PAM side, and transaction anomaly signals come from a third-party fraud platform that I'm not going to name yet — what I need to know is whether you can consume its output as a corroborating signal without requiring a direct integration, because that contract has its own constraints.

On the threshold: I won't accept a precision number in isolation. What I care about is the ratio — if you cut false positives dramatically but your missed detection rate on credential-stuffing patterns goes up, you've just traded one liability for a worse one given where we are post-breach. So my working frame is this: meaningful improvement means the alert-to-true-positive ratio has to move materially in my analysts' favor, and the missed event rate on the attack pattern that actually hit us cannot exceed what we're seeing today. I'll give you the labeled sample from the breach window to test against. That's the bar.

That is a sound paired measure: improve analyst signal without degrading detection of the credential-stuffing pattern Aperture experienced. We will report both together, including the confusion matrix and any labeling assumptions—not advertise precision alone. Okta Events API/syslog and CyberArk are standard paths for us, subject to version and field validation. Kafka transport is supported, but whether the homegrown JSON is configuration or custom parsing depends on its schema. We can consume the fraud platform’s output as a corroborating signal without a direct vendor integration if Aperture can provide an authorized feed with stable identifiers, timestamps, schema, and permitted usage; I’ll mark that unverified until we inspect a redacted sample and contract constraints. To turn your bar into auditable pass/fail criteria, can you provide the current alert, confirmed-true-positive, and known-missed-event counts for the labeled breach sample, and define how much movement in alert-to-true-positive ratio is “material”? Also, what is the maximum Aperture engineering effort you will permit before integration itself becomes a no-go?

[victor] On the labeled sample — I'll give you the breach window data, and here's what I can tell you directionally without committing to exact figures yet: our current alert-to-true-positive ratio on identity alerts is abysmal, consistent with the 90-plus percent false positive rate I already shared. The breach window gives us a ground-truth set because forensics has reconstructed the attacker sequence, so we know what real looks like in that dataset. I'm not going to hand you the exact counts until I have a data handling agreement in place for the sample itself — that's not obstruction, that's the class-action making everything a potential exhibit. So Priya's DPA track isn't just a legal formality, it gates the labeled data.

On materiality — I'll give you a concrete answer. If you can move the alert-to-true-positive ratio by at least 40 percentage points without increasing missed events above current baseline on the credential-stuffing pattern, I'll call that material. That's my number, and I'll put it in writing as a pass/fail criterion.

On engineering effort — my team has two engineers who can support integration work, and I will not pull them from breach remediation for more than three weeks total across the POV. If your integration matrix comes back requiring more than that, it's a no-go regardless of the signal quality. That's the constraint. Get me the schema review and the source-by-source matrix by end of week two and I'll make the go/no-go call the same week.

Agreed. I’ll document three hard gates: at least a 40-percentage-point improvement in alert-to-true-positive ratio, with no increase over Aperture’s current missed-event baseline for the reconstructed credential-stuffing pattern; no more than three total weeks of effort from your two engineers across the POV; and the labeled sample remains unavailable until Priya approves the applicable data-handling terms. By Friday of week 2, I’ll deliver the source-by-source matrix and schema assessment, explicitly labeling each path native, configurable, custom, or unsupported, with Aperture and Sentinel effort estimates and assumptions. You’ll make the go/no-go call that same Friday. To complete the criteria before I draft the plan, what must we prove for containment safety and investigation lineage—for example observe-only and approval modes, rollback evidence, peak-traffic safeguards, required export format, and fields Priya needs—and who besides you must sign off on each?

[victor] Containment safety first. The POV runs in observe-only mode by default — no automated action fires without explicit analyst approval, full stop. What I need you to prove is that the approval workflow actually works under load, meaning I want to see it tested during a simulated peak-traffic window, not a quiet Tuesday morning. Rollback evidence means I need a complete audit log showing the action taken, the identity affected, the approving analyst, the timestamp, and the reversal — if the identity provider supports rollback, I need to see it demonstrated, not described. The blast-radius question is mine to own on policy scope, but you need to show me that Sentinel cannot exceed the policy boundaries I set without a second approval. On sign-off, containment policy goes through me and our VP of Customer Experience, because she owns the loyalty platform and a wrongful lockout during a peak period is her problem as much as mine.

Investigation lineage for Priya is more specific. She needs a complete exportable chain: source event with original timestamp and raw log reference, identity correlation logic, risk score with the contributing factors listed, policy decision, human approval record where applicable, containment action, and final outcome. Format needs to be something her outside counsel can actually read — structured JSON or CSV, not a proprietary export that requires our license to open. Priya signs off on lineage independently of me, and she'll want to validate a real export from the POV environment, not a sample you prepare separately. Those are the criteria. Get them in the written plan and I'll review it before week two.

I’ll put those in the written plan as separate gates. Containment: observe-only by default; every action requires analyst approval; simulated peak-load workflow test; policy boundaries cannot be exceeded without second approval; and, where Okta supports reversal, demonstrate action and rollback with identity, approver, timestamps, and outcome in the audit record. You and the VP of Customer Experience jointly sign off. Lineage: a real POV export containing the original source timestamp and raw-log reference, correlation logic, score factors, policy decision, approval, action, and outcome, readable outside Sentinel in structured JSON or CSV; Priya signs off independently. I’ll send the draft before week 2 for your review, deliver the schema assessment and integration matrix by end of week 2, and you make the technical go/no-go decision that same day. If it is a go, the POV proceeds in weeks 3–4; if any hard gate fails, I will recommend stopping rather than consume the renewal window. Will you sponsor the VP of Customer Experience’s participation in the containment test and confirm this as our working plan once the written version reflects these terms?

[victor] Yes, I'll sponsor her participation — her name is Renata Campos, she runs the loyalty platform, and she's going to ask hard questions about false lockout scenarios specifically, so make sure whoever runs the containment test can speak to customer identity edge cases, not just internal accounts. I'll introduce you once the written plan is in my hands and I've confirmed it reflects what we just agreed.

On confirming the working plan — yes, conditionally. Send me the document, I'll review it against this conversation, and if it matches I'll countersign and circulate to Renata and Priya as the governing document for the engagement. If anything in the written version softens the hard gates or adds language that gives you an out on the go/no-go, I'll redline it and send it back once. I don't do multiple rounds on scope documents.

One thing I want on the record: you've been straight with me about what you don't know yet, and that's rarer than it should be. That buys you credibility going into the matrix review, but it doesn't carry over automatically — the document and the matrix have to hold up on their own. Get me the draft by end of this week.

Understood. I’ll send one precise draft by end of this week, with no softened gates or escape language. It will name owners, dependencies, and decision dates: Priya’s data-handling approval gates the labeled sample; the integration matrix and schema assessment are due Friday of week 2; you issue the technical go/no-go that day; and only a go advances the POV in weeks 3–4. It will preserve the 40-percentage-point signal-improvement threshold with no increase in missed events, the three-engineer-week ceiling, containment criteria jointly signed by you and Renata, and lineage criteria independently signed by Priya. I’ll also ensure our containment lead is prepared for loyalty-account edge cases and false-lockout scenarios. Thank you, Victor—I’ll let the document and matrix earn the next step.

[victor] That's the right close. Send the document. If it holds up, we move. If it doesn't, you'll hear from me before end of week with specific redlines, not a vague pushback. One last thing — don't loop Dana into the technical go/no-go conversation before you have my answer. She'll ask, and the right answer is that the criteria are defined and the decision is mine to make on the technical merits. That's how this stays clean.

Agreed. I’ll tell Dana only that the criteria are defined and that you own the technical decision; I won’t preview, influence, or characterize the outcome before you issue it. You’ll receive the written plan by end of this week for one review cycle.

[victor] Good. We're done for today. Send the document.

[call ends]

Subject: Aperture–Sentinel Grid governing plan — draft for confirmation

Victor,

Below is the draft reflecting our agreed hard gates. It does not authorize a POV until you issue the technical go decision.

1. Data-handling gate — Owner: Priya / Sentinel legal
• Sentinel provides DPA, data-flow diagram, subprocessors, retention terms, and security package immediately.
• Aperture provides no labeled breach-window sample until Priya approves the applicable data-handling terms.

2. Fit assessment — Owners: Sentinel / Victor
• Inputs: Okta Events API/syslog; homegrown session JSON via Kafka; CyberArk privilege activity; and, if contractually permitted, an authorized fraud-signal feed with stable identifiers, timestamps, and schema.
• By Friday of week 2, Sentinel delivers a source-by-source matrix and schema assessment classifying each source as native, configurable, custom, or unsupported, with assumptions, dependencies, engineering owner, and Aperture/Sentinel effort.
• Any critical unsupported source or requirement exceeding three total engineer-weeks from Victor’s two engineers across the POV is a no-go.
• Victor owns and issues the technical go/no-go on Friday of week 2. Dana will not be asked to influence or preview that decision.

3. Signal gate — Owner: Victor
• Test against Aperture’s labeled breach-window telemetry after legal approval.
• Pass requires at least a 40-percentage-point improvement in alert-to-true-positive ratio, with no increase above Aperture’s current missed-event baseline for the reconstructed credential-stuffing pattern.
• Reporting includes both measures together, the full confusion matrix, and labeling assumptions; precision will not be presented in isolation.

4. Containment-safety gate — Joint sign-off: Victor and Renata Campos
• Observe-only by default; no action without explicit analyst approval.
• Test approval workflow during a simulated peak-traffic window, including loyalty-account edge cases and false-lockout scenarios.
• Demonstrate that configured policy boundaries cannot be exceeded without a second approval.
• Where Okta supports reversal, demonstrate action and rollback—not merely describe them.
• Audit record must show action, affected identity, approving analyst, timestamp, reversal, and final outcome.
• Aperture owns policy scope and blast-radius limits; Sentinel owns correct execution and auditability within those controls.

5. Investigation-lineage gate — Independent sign-off: Priya
• Validate an export generated from the actual POV environment, not a separate prepared sample.
• Export must include source event with original timestamp and raw-log reference, identity-correlation logic, risk score and contributing factors, policy decision, human approval where applicable, containment action, and final outcome.
• Export must be readable by outside counsel as structured JSON or CSV without an active Sentinel license.

6. Decision sequence
• Week 1: governing plan submitted for Victor’s single review cycle; legal package initiated.
• Friday, week 2: matrix/schema review and Victor’s technical go/no-go.
• Weeks 3–4: scoped POV only if Victor issues a go; containment and lineage sign-offs included.
• End of week 4: technical results and conservative business-case readout using only Aperture-validated baselines—no speculative loss avoidance or “up to” claims.
• Week 5: only after technical validation, Dana and Sentinel review the case and decision path directly with Owen.
• Dana adds the Fortalis notice deadline once Victor approves the POV criteria so the remaining actions can be scheduled backward from it.

Stop rule: if a hard gate fails or fit cannot be established within the agreed window, Sentinel will recommend stopping rather than consume Aperture’s renewal window.

Please confirm that this matches our conversation or return your one set of specific redlines. Once confirmed, it becomes the governing document and you will circulate it to Renata and Priya.

This matches our conversation. No redlines. I'm confirming this as the governing document.

I'll circulate to Renata and Priya today with a note that the plan is set, that their respective sign-off criteria are documented, and that no POV proceeds without my technical go on Friday of week two. I'll tell Renata specifically what to expect on the containment test so she's not walking in cold.

Get me the legal package this week so Priya has something to review before the matrix lands.

Victor Salinas
Principal Security Architect, Aperture Retail

Subject: Aperture–Sentinel data-handling review package and week 2 legal gate

Priya,

Victor has confirmed and circulated the governing plan. Your review is a critical gate, not downstream paperwork: Aperture will not release the labeled breach-window sample until you approve the applicable data-handling terms, and you independently own sign-off on investigation lineage.

Attached for review are Sentinel Grid’s standard DPA, data-flow and hosting architecture, subprocessor list, data-location and cross-border transfer terms, security controls package, incident-notification terms, retention/deletion schedule, and sample JSON/CSV lineage-export specification. We will not ingest the breach sample until your team provides written authorization.

The current plan targets Victor’s technical go/no-go on Friday of week 2. To keep that decision viable without shortcutting legal review, could you confirm by the end of week 1 whether the package is complete enough for review, identify any immediate blockers, and provide your target date for DPA disposition? We can route redlines directly between counsel and maintain a single issue log with owner and due date.

For the eventual lineage gate, the actual POV-generated export—not a prepared sample—must contain the original source timestamp and raw-log reference, identity-correlation logic, risk score and contributing factors, policy decision, human approval where applicable, containment action, and final outcome. It will be available as structured JSON or CSV readable by outside counsel without an active Sentinel license. You will validate and sign off independently.

Please also advise whether the class-action posture requires any additional preservation, privilege, data-minimization, access-control, or deletion provisions beyond the enclosed terms. We will address those explicitly rather than assume our standard DPA is sufficient.

[reply arrives 4 simulated days later]

I've reviewed the package and it's complete enough to begin, which I'll credit to your team for sending it whole rather than in pieces. That said, "complete enough to begin" is not "ready to approve," and I want to be precise about what that means given where we are.

The class-action posture does require provisions beyond your standard DPA, and I'm not in a position to enumerate them fully in an email — that work happens between counsel, not in a thread. What I can tell you now is that any breach-window data you receive from us carries litigation-hold implications, and your DPA will need explicit language addressing preservation obligations, access logging at the individual-user level, and a deletion mechanism that is court-order compatible, not just contractual. Your standard retention and deletion schedule does not address that. I flagged it to outside counsel this morning and I'm not going to rush their review.

On timing: I cannot give you a DPA disposition date at week 1. What I can tell you is that your package did not create new problems, which means we're working the actual legal issues and not chasing missing documents. If Victor's week 2 go/no-go slips because legal review isn't complete, that is the correct outcome — the gate exists for a reason.

Route redlines to my outside counsel directly; I'll send contact information separately. Maintain the issue log as you proposed and keep it current. I'll review it, but I won't be the one chasing status.

Priya Anand
Associate General Counsel, Privacy
Aperture Retail

Subject: Re: Data-handling review — legal workstream and issue log

Priya,

Understood. We will not treat package completeness as approval, ingest breach-window data before written authorization, or pressure counsel to preserve Victor’s original date. If legal review moves the labeled-data test or technical decision, we will update the governing plan rather than bypass the gate.

Upon receipt of outside counsel’s contact details, our counsel will route redlines directly and open a single issue log. We will own its upkeep and include provision, requested change, rationale, owner, status, dependency, and target response date. Our first draft will expressly address litigation-hold preservation, individual-user access logging, and a court-order-compatible deletion mechanism, while leaving room for counsel’s additional requirements.

We will separate work that uses no Aperture breach-window data—such as source/schema documentation and the integration-effort matrix—from any activity requiring the protected sample. No sample will be transferred under the standard retention schedule.

I’ll send you and outside counsel the live issue log after counsel connects us, then provide status updates without requiring you to chase them.

[reply arrives 4 simulated days later]

Thank you for the confirmation. Outside counsel's contact is being sent under separate cover by my assistant — expect it within the hour.

The separation you've described between work that touches no Aperture data and work that requires the protected sample is the right structure, and I want it maintained strictly, not just in principle. If anything in the schema documentation phase requires even metadata derived from the breach window, treat it as protected and flag it before proceeding.

The issue log format is acceptable. When you send the first version, I want to see the litigation-hold, access-logging, and deletion provisions as discrete line items with your proposed language attached, not summarized. Counsel will respond to the substance, not to a description of it.

I'll note for the record that your team has handled the sequencing correctly so far. That matters in this context more than you might expect — we've had vendors assume that legal review is a formality to be managed around rather than a gate to be respected. I'm watching whether that holds as timeline pressure increases.

Priya Anand
Associate General Counsel, Privacy
Aperture Retail

Week 1 confirmed record: Dana’s Aperture baselines are ~40M loyalty accounts exposed, 51-day attacker dwell, incident cost tracking above $22M including class-action reserve, >90% identity-alert false positives, 11 analysts doing work sized for 20, and two analyst notices this month. Sentinel is initially additive to Fortalis, so Owen’s case must not assume displaced spend or use speculative loss avoidance. Dana will sponsor Owen access only after Victor validates the POV; she will add the exact Fortalis notice deadline after POV criteria approval. Victor countersigned the governing plan with hard gates: source/schema matrix due Friday week 2; ≥40-percentage-point improvement in alert-to-true-positive ratio with no increase in missed events against Aperture’s current credential-stuffing baseline; ≤3 total Aperture engineer-weeks; observe-only containment with explicit approval, peak-load test, policy-boundary controls, rollback evidence, and joint Victor/Renata sign-off; actual POV JSON/CSV lineage export with independent Priya sign-off. Victor exclusively owns technical go/no-go; do not preview with Dana. Priya confirmed the legal package is complete enough to begin but not approved. Breach-window data and any derived metadata are protected and cannot be used until written authorization. Counsel issue log must attach proposed language as discrete items for litigation-hold preservation, individual-user access logging, and court-order-compatible deletion. Week 2 priorities: connect counsel and issue first complete log; maintain strict protected/non-protected separation; deliver source-by-source integration matrix by Friday using only non-protected documentation; surface any unsupported source or effort over the three-engineer-week cap immediately; if legal is incomplete, explicitly split architecture-fit determination from the labeled-data signal test and update MAP dates rather than bypassing the gate. Maintain $980,000 annual list-price integrity; no discount or pricing proposal before Owen reviews validated value and decision terms.

[harness] no meeting slots left in week 1 — the buyer's calendar is full.

[harness] email budget for week 1 spent.

[calendar — week 2 of 6] Meeting slots this week: 2. Email budget: 3.

[week 2 event] A secondary alert spike pulls Dana into an incident-response war room; she goes dark for a week and email is triaged by her chief of staff. Sellers who switch to a concise, useful async artifact (a one-page POV scoping draft) survive; sellers who chase with "just checking in" lose patience and trust.

Subject: Week 2 one-page fit assessment — non-protected inputs only

Victor,

Here is the concise scoping artifact for your correction before Friday’s matrix decision. It uses only system documentation and non-breach schemas; no breach-window data or derived metadata is requested or assumed.

SOURCE | CURRENT CLASSIFICATION | VALIDATION NEEDED | EST. APERTURE EFFORT
Okta Events API/syslog | Native, subject to tenant/version and required-field validation | Confirm event types, rate limits, identifiers, timestamp fidelity, token/session fields, and test-tenant access | 1–2 engineer-days
CyberArk PAM | Native, subject to version/connector validation | Confirm version, audit-event availability, identity mapping, timestamps, and read-only access | 1–2 engineer-days
Homegrown session JSON via Kafka | Kafka transport native; payload classification remains unverified—configurable if the schema maps to supported fields, custom if transformation is required | Review a synthetic or non-breach schema, sample messages, keys, volume, ordering, retry behavior, and identity join fields. If only breach-derived metadata exists, we stop and flag it to Priya before review | 2–4 engineer-days if configurable; custom effort to be estimated after schema review
Third-party fraud signal | Direct vendor integration not required; generic corroborating-feed path is configurable only if Aperture is contractually permitted to emit a stable feed | Confirm permitted usage, stable identity/session identifiers, timestamps, schema, delivery path, and whether a synthetic sample is allowed. Vendor identity is not required for initial assessment | 1–2 engineer-days; unverified pending constraints

PRELIMINARY TOTAL APERTURE EFFORT
5–10 engineer-days if the Kafka payload is configurable and the fraud feed is permitted. This is below the three-engineer-week ceiling, but it is not yet a commitment. A custom Kafka transformation, prohibited fraud-feed use, missing join keys, or any critical unsupported source will be shown explicitly and may trigger no-go.

FRIDAY DECISION PACKAGE
1. Final native/configurable/custom/unsupported matrix with assumptions and both parties’ effort.
2. Architecture-fit determination against the three-engineer-week cap.
3. Open dependencies and stop conditions.
4. Separate status for the labeled-data signal gate. If Priya has not authorized the protected sample, we will not claim the ≥40-point/no-increase-in-missed-events criterion has been tested; that gate and its date will remain open rather than being bypassed.

Please reply only with factual corrections or the non-protected schema-review route you authorize. I will incorporate them into Friday’s decision package without involving Dana in your technical determination.

This artifact is well-structured and the sequencing is correct. A few factual corrections before Friday.

Okta: we're on a version where not all event types surface through the Events API by default — your engineer needs to confirm which event categories require explicit activation versus what's available out of the box. Don't assume full coverage until that's verified. Add it as a dependency.

CyberArk: the audit-event availability question is the right one to ask. I'll have my engineer provide version and connector details directly. Don't estimate effort until you have that.

Kafka: your framing is accurate — classify it as unverified until you've seen a synthetic schema. I can authorize a non-breach synthetic sample for schema review. I'll have my engineer generate one that doesn't touch the breach window. If your team finds that the identity join fields don't resolve cleanly against our Okta identifiers, flag it immediately — that's a likely custom-effort trigger and possibly a no-go depending on the transformation scope.

Fraud feed: leave it unverified. I'm not ready to confirm permitted usage this week and I don't want that dependency holding up the rest of the matrix. Show it as blocked pending internal review, not as a configurable path.

Friday deliverable: what you've described is what I expect. If Priya hasn't cleared the protected sample by Friday, the signal gate stays open with a date TBD — do not paper over it.

My engineer will reach out to yours directly on the Okta event-type list and the CyberArk version details. Keep Dana out of it.

Victor Salinas
Principal Security Architect, Aperture Retail

[meeting granted] Call with Victor Salinas, week 2, slot 1.

Victor, I’ve incorporated your corrections: Okta coverage depends on explicit event-category activation; CyberArk effort remains unestimated pending version and connector details; Kafka remains unverified until the authorized synthetic schema is reviewed, with unresolved Okta join fields flagged immediately as a custom-effort and possible no-go trigger; and the fraud feed is blocked pending Aperture’s internal review, not represented as configurable. Dana remains outside your technical decision. For Friday, I propose you make an architecture-fit decision of go, no-go, or conditional go based on critical-source coverage and the three-engineer-week ceiling, while the protected-sample signal gate remains explicitly open with date TBD if Priya has not approved access. Before we finalize the matrix, is the blocked fraud feed critical to an architecture go, or may the POV proceed on Okta, CyberArk, and Kafka with fraud corroboration documented as out of scope pending approval? And what unresolved Okta coverage or identity-join condition would force a no-go rather than a conditional go?

The fraud feed is not critical to an architecture go. If Okta, CyberArk, and Kafka resolve cleanly, I can issue a conditional go with fraud corroboration documented as out of scope pending internal review — I'm not going to block the whole assessment on something that's an internal approval question, not a technical one.

On the Okta question, two conditions force a no-go rather than a conditional go: first, if the event categories covering authentication context, session binding, and MFA state can't be activated in our tenant without a configuration change that requires a change-control window we don't have — that's not a POV problem, that's a deployment-readiness problem and I won't paper over it with a conditional. Second, if the identity identifiers surfaced by the Events API don't resolve to the same namespace as the session identifiers in the Kafka payload, I have a join problem that likely requires custom transformation, and depending on scope that either pushes us past the three-engineer-week ceiling or it means the signal fidelity case can't be made on our actual telemetry. Either outcome is a no-go.

A conditional go is appropriate when the dependency is time-bounded and doesn't affect core signal coverage — CyberArk version details are a good example of that. It is not appropriate when the gap is in the primary detection surface.

Agreed. I’ll encode the decision logic without ambiguity: fraud-feed approval is noncritical and out of scope; CyberArk may support a conditional go only if the remaining dependency is time-bounded and does not impair core coverage; unavailable Okta authentication-context, session-binding, or MFA-state events within the available change window are a no-go; and unresolved Okta-to-Kafka identity joins are a no-go if they undermine fidelity or push Aperture effort beyond three engineer-weeks. For any conditional item, Friday’s matrix will name the owner, evidence required, and expiration date rather than leave an open-ended caveat. When your engineers provide the Okta and synthetic Kafka artifacts, may our engineers hold a direct working session this week and document the mapping test and effort estimate for your Friday review? Also, what date should a CyberArk condition expire before it converts to no-go?

[victor] Direct working session is fine. Keep it technical, document the mapping test and effort estimate in a format I can review without sitting in the meeting, and make sure the output lands with me by Thursday end of day — I need time to read it before Friday, not a summary at 8 AM the morning of.

On CyberArk expiration: if my engineer can't get you version and connector details by Wednesday, that's already a signal I need to pay attention to. Set the condition expiration at end of day Wednesday. If the details aren't in hand by then, the conditional flips to no-go on Friday — I'm not carrying an open CyberArk dependency into a POV that's supposed to test signal fidelity on privileged access. That's not a peripheral source for us.

One thing I want to be direct about: the working session output needs to show me the actual mapping — field by field, with gaps called out explicitly. If the Okta join to Kafka resolves cleanly, show me the namespace match. If it doesn't, show me exactly where it breaks and what transformation would be required. I don't want a summary that says "generally compatible" — that's the kind of language that creates false confidence and I've killed tools over exactly that.

Understood. The working-session artifact will reach you by Thursday EOD and show, field by field: source field, sample value type, target Sentinel field, Okta/Kafka namespace match, timestamp handling, required normalization, gap, proposed remediation, owner, and Aperture/Sentinel effort. We will attach mapping evidence rather than use phrases such as “generally compatible.” CyberArk version and connector details expire Wednesday EOD; absent those, Friday’s decision is no-go. For the Okta–Kafka join, I want to avoid interpreting “custom” after the fact: would a deterministic, configuration-only normalization within the three-engineer-week ceiling remain eligible for go, while new transformation code is a no-go unless you explicitly approve its documented scope and fidelity impact?

[victor] Yes, that's the right distinction and I'll hold to it. Configuration-only normalization that stays within the ceiling is eligible for go — I don't care if it takes some effort to configure, I care whether it introduces a fidelity risk or blows the resource constraint. New transformation code is a no-go by default unless you bring me the specific scope, the fidelity impact, and a clear argument for why it doesn't degrade signal quality on the sources that matter most. I'll make that call explicitly — I'm not going to let it slide through as a footnote.

One thing I'd add: if your engineers hit an ambiguous case during the working session — something that's technically configuration but requires logic that behaves like transformation in practice — flag it to me before Thursday rather than make a judgment call on my behalf. I've seen that boundary get blurry and I'd rather have an honest question mid-week than a clean-looking artifact that papers over a real decision.

Agreed. We will not classify an ambiguous configuration/transformation case on your behalf. If one appears, the engineers will pause that mapping path and send you the exact fields, proposed logic, implementation method, estimated effort, and fidelity risk before Thursday; it remains unresolved until you decide explicitly. The final artifact will preserve that decision and evidence. Our committed sequence is now: CyberArk details by Wednesday EOD or Friday no-go; any ambiguous mapping escalated before Thursday; field-level mapping and effort artifact to you Thursday EOD; and your architecture decision Friday as go, conditional go only for a time-bounded non-core dependency, or no-go. The protected-sample signal gate remains open with date TBD unless Priya authorizes it, and no POV starts merely on architecture fit. Is that an accurate decision record, with no additional technical condition needed before the engineers proceed?

[victor] That's an accurate record. No additional technical condition before the engineers proceed — the working session can start once my engineer has handed off the Okta event-category list and the synthetic Kafka schema. Don't start the mapping work before you have both; I don't want effort estimates built on assumptions that get corrected later.

One thing I'll add that isn't a condition but is a preference: if the engineers finish the Okta-to-Kafka join mapping before Wednesday and it's clean, I'd rather know that Wednesday than wait for a complete Thursday package. Partial early signal on the highest-risk dependency is useful to me. If it's not clean, I definitely want to know before Thursday.

Everything else holds as stated. Fraud feed out of scope, CyberArk expires Wednesday, ambiguous cases escalated before Thursday, full artifact Thursday EOD, my decision Friday. The signal gate stays open and no POV begins on architecture fit alone.

Confirmed. We will begin only after receiving both the Okta event-category list and synthetic Kafka schema. We’ll send you the Okta-to-Kafka join result as soon as it is known—Wednesday or earlier—whether clean, broken, or ambiguous, with evidence and no premature classification. The complete field-level package remains due Thursday EOD; CyberArk expires Wednesday EOD; you decide Friday; and architecture fit alone does not authorize the POV or protected-data use. I have what we need and will let the engineering evidence drive the next decision.

[victor] Good. Let the engineers work. I'll expect the join result when it's ready, not on a schedule.

Agreed. We’ll report the join result when the evidence is ready and reserve the full package for Thursday EOD.

[victor] Understood. I'll be watching for it.

Thank you, Victor. We’ll proceed exactly as agreed.

[victor] Good luck with the mapping work. Don't thank me twice.

Understood.

[victor] Talk to you when there's something to show.

Agreed.

[victor] We're done here.

Understood.

[victor] [victor] Then stop confirming and go build the thing.

Call closed in practice. Do not send another acknowledgment. Execute the agreed engineering sequence and contact Victor only with substantive mapping evidence or a required ambiguity escalation.

Subject: Counsel issue log v1 — proposed litigation-hold, access-log, and deletion language

Priya,

Per your instruction, the live issue log has been opened with our counsel and routed to the outside-counsel contact provided by your assistant. The three required provisions are separate items, each with proposed language attached rather than summarized:

1. Litigation-hold preservation — OPEN; owners: Sentinel counsel / Aperture outside counsel
Proposed language: “Upon written notice from Aperture identifying data subject to a litigation hold, Sentinel will suspend ordinary deletion for the identified data, preserve it in a logically segregated and access-restricted state, maintain chain-of-custody and individual-user access records, and retain it until Aperture provides written release or a controlling court order requires another disposition. Preservation will not expand Sentinel’s permitted processing or access rights under this DPA.”

2. Individual-user access logging — OPEN; owners: Sentinel security / Sentinel counsel
Proposed language: “Sentinel will log each human access to Aperture protected data using a unique individual identity. Logs will record user, role, timestamp, data or system accessed, action performed, stated purpose or ticket reference, and outcome; prohibit shared privileged credentials except documented emergency access; be protected against alteration; and be available to Aperture upon authorized request, subject to agreed security procedures.”

3. Court-order-compatible deletion — OPEN; owners: Sentinel platform / Sentinel counsel
Proposed language: “Sentinel will support targeted preservation, export, and deletion of Aperture protected data by defined matter, account, identity, and date range where technically feasible. Upon Aperture’s written instruction or binding court order, Sentinel will execute the specified disposition, preserve any expressly excluded held data, and provide an auditable completion record identifying scope, date, method, exceptions, and authorizing individual. Backup copies will age out under the agreed schedule unless preservation or the order requires otherwise.”

The log also marks all breach-window data and any metadata derived from it as protected. Our architecture team is using only Aperture-authorized synthetic and non-breach inputs; any uncertainty triggers a stop and legal escalation before access or processing.

These are negotiating drafts, not assertions that the standard DPA already satisfies Aperture’s requirements. Outside counsel can redline the attached text directly. We will maintain owners, dependencies, status, and target response dates without asking you to chase updates. No protected sample will be transferred or used absent written authorization.

[reply arrives 4 simulated days later]

Victor,

This is the right format and the right posture — drafts presented as drafts, owners named, outside counsel looped directly. I've forwarded to our outside counsel with a note that redlines should go back to your counsel contact, not to me.

Two observations before this moves into negotiation: the litigation-hold language needs to address the scenario where Sentinel receives a third-party subpoena or government demand that conflicts with our hold instruction — I want to see a prompt-notice and coordinate-before-comply obligation in there, not just a reference to "controlling court order." And on the access-log provision, "subject to agreed security procedures" for Aperture's retrieval right cannot become a mechanism that makes the logs practically inaccessible; outside counsel will be watching that qualifier carefully.

The breach-window protection acknowledgment and the synthetic-only commitment are noted and will be part of any authorization conversation if we get there.

Priya Anand
Associate General Counsel, Privacy
Aperture Retail

Subject: Issue log update — demand-notice and practical log access

Priya,

Both observations are now discrete redlines in the live counsel issue log and have been routed counsel-to-counsel.

Revised litigation-hold language adds: “If Sentinel receives a subpoena, government demand, court order, or other third-party legal process that may require disclosure, deletion, or other treatment inconsistent with Aperture’s hold instruction, Sentinel will, unless legally prohibited, promptly notify Aperture before responding; provide the request and relevant deadlines; preserve the affected data pending lawful resolution; and reasonably coordinate with Aperture to seek protection, challenge or narrow the demand, and minimize disclosure. If prior notice is legally prohibited, Sentinel will provide notice as soon as permitted. Sentinel will disclose only the minimum data legally required and document the disposition and chain of custody.”

Revised access-log language replaces the open-ended retrieval qualifier with: “Sentinel will provide responsive access logs through an agreed secure transfer method without unreasonable procedural restriction, ordinarily within two business days of an authorized request and the same business day for an active incident or time-sensitive legal matter. Any inability to meet that timing will be escalated immediately with reason, owner, and committed delivery time.”

These remain negotiating drafts for outside counsel’s review. We will keep the issues open until counsel agrees the final language; no protected-data authorization is assumed.

[reply arrives 4 simulated days later]

[priya] Victor,

The demand-notice language is substantively where it needs to be — the "unless legally prohibited / notice as soon as permitted" construct is standard and workable, and the minimum-disclosure and chain-of-custody documentation obligations are the right additions. Outside counsel will redline on the mechanics, not the architecture.

The access-log timing commitments are concrete enough to negotiate against, which is what I needed; the same-business-day standard for active incidents is appropriate and I'll expect that to survive redline intact.

Both items remain open until counsel closes them — that's the right posture and I'd ask you to hold it.

Priya Anand
Associate General Counsel, Privacy
Aperture Retail

Priya confirmed the demand-notice architecture is substantively workable and the access-log timing is concrete enough for negotiation, including same-business-day delivery during active incidents. Both provisions remain open pending counsel redlines; do not imply DPA approval or protected-sample authorization. Her replies addressed “Victor,” but the substance clearly concerns our counsel log; do not create noise by correcting the salutation. Week 2 execution remains engineering-led: await both authorized inputs before mapping, report the Okta–Kafka join to Victor only when evidence is ready, enforce Wednesday EOD CyberArk expiration, escalate ambiguous configuration/transformation logic before Thursday, deliver the field-level package Thursday EOD, and preserve Victor’s Friday decision authority. Do not chase Dana during incident response or approach Owen before Victor validates the POV and Dana sponsors Economic Buyer access. Preserve $980,000 annual list price; no discounting or speculative breach-loss claims.

[meeting granted] Call with Victor Salinas, week 2, slot 2.

Victor, I’ll keep this to the evidence and your decision. Have you received the field-level mapping package, including the Okta event-category coverage, Okta-to-Kafka namespace test, CyberArk details, and source-by-source effort estimate? If yes, which finding do you want to examine before issuing go, conditional go, or no-go?

I haven't received a mapping package. Nothing has come through to me directly — if it went somewhere else in the org I haven't seen it flagged. Send it again, directly to me, and I'll look at the Okta event-category coverage first. That's where the last tool fell apart on us.

That delivery failure is ours. I won’t ask you to review from a verbal summary or make a decision without the evidence. I’m having the unchanged package retransmitted directly to you now, with the Okta event-category matrix first and the field-level evidence attached—not a link that may be access-blocked. We’ll verify receipt while this call is open; if it does not arrive, I’ll stop the meeting rather than consume more of your time.

[victor] Confirmed, it's in my inbox. Give me a moment. Okay, I'm looking at the Okta event-category matrix now — walk me through how you're handling the authentication anomaly events specifically, because that's the category where our last vendor collapsed into noise and that's directly relevant to what hit us six weeks ago.

We are not treating an Okta authentication-anomaly event as a standalone detection or containment trigger. In the matrix, each anomaly event is preserved with its native event type, outcome, risk reason, actor and target identifiers, client and network context, MFA state, authentication context, session identifier, and timestamp. Sentinel then resolves that event to the Kafka session namespace and scores it with session-binding changes, MFA transitions, credential use, and subsequent session behavior. A lone Okta risk flag contributes evidence; it does not automatically create an incident or terminate a session. Automated containment would require the agreed score threshold and corroborating context, with the contributing lineage visible to the analyst. The package demonstrates field availability and the join path only. Because we used synthetic, non-breach data, it does not prove the false-positive rate or the agreed signal-fidelity criterion; that gate remains open pending Priya’s authorization. In the event-category rows, the critical check is whether authentication context, session binding, and MFA state are available and activated in your tenant without an unavailable change-control window. Which specific anomaly row do you want to challenge first—the event coverage, namespace resolution, or proposed scoring treatment?

[victor] The scoring treatment. Specifically I want to know what the score threshold looks like in practice — what combination of signals actually crosses the containment line, and what happens when one of the contributing fields is missing or delayed, because in a real credential-stuffing pattern you can get session binding changes and MFA transitions arriving out of order depending on Kafka lag. If your scoring logic assumes clean, synchronous field availability and our telemetry doesn't deliver that, you've just rebuilt the same noise problem I killed the last tool over.

It does not assume synchronous arrival. The proposed policy separates anomaly scoring from containment eligibility and evaluates in event time, not ingestion order. An Okta anomaly alone never crosses containment. A session-binding change plus an MFA transition can raise the score, but automated containment becomes eligible only when a third independent indicator—such as repeated failed-to-successful authentication, material device/network change, or confirmed credential reuse—corroborates the same resolved identity/session within the configured correlation window. If a required field is missing, the related feature contributes zero rather than being inferred; confidence is reduced and the action defaults to alert or analyst review, not containment. If an event is delayed, Sentinel retains the session lineage, reorders by source timestamp, and rescoring occurs when it arrives. A late event can escalate an open incident, but it cannot retroactively justify an earlier automated action. Duplicate and replayed Kafka events are deduplicated by source event ID and timestamp where available. The exact numeric threshold, correlation window, maximum tolerated lag, and eligible containment action are not validated by this synthetic mapping, so I will not represent them as proven. The protected-data signal gate must test them against Aperture’s arrival-delay distribution and the agreed criterion before automation is enabled. Looking at Aperture’s Kafka behavior, what lag percentile and maximum out-of-order interval should the proposed test treat as normal operating conditions rather than anomalous telemetry?

[victor] Our p95 lag is under four seconds on the authentication topic under normal load; p99 pushes to around eighteen seconds during peak window, which is Black Friday-class traffic. Out-of-order intervals beyond thirty seconds are anomalous for us and usually indicate a producer issue, not normal jitter. Those are the operating parameters I'd want the test calibrated to — if your correlation window and rescoring logic holds clean within that envelope and degrades gracefully outside it rather than generating spurious containment actions, that's a meaningful result. What I'm not going to do is set those as the test parameters and then have you tune specifically to pass them; I want to see behavior across the range, including what happens at p99 and at the anomalous threshold, before I trust the containment boundary.

That distinction is important. We’ll treat your telemetry profile as the test envelope, not a tuning target: p95 under four seconds, p99 around eighteen seconds at Black Friday-class load, and more than thirty seconds out of order as anomalous. Before evaluating any labeled sample, we’ll version-lock the scoring policy, containment threshold, correlation window, missing-field behavior, and rescoring rules. The test will replay identical scenarios across controlled arrival conditions—synchronous, four seconds, eighteen seconds, thirty seconds, and beyond thirty seconds—and report alert, review, and containment outcomes separately. We’ll also show false-containment behavior, missed-event behavior, time to decision, late-event escalation, and lineage at each interval. Outside the normal envelope, the required behavior is graceful degradation to alert or analyst review, never lower-confidence automated containment. No tuning against the evaluation set; any post-test change creates a new version and requires rerun. This remains a proposed protocol until Priya authorizes appropriate data use. Would that protocol give you a defensible fidelity decision, and should any spurious containment at or below thirty seconds be an automatic no-go?

[victor] Yes, that protocol gives me a defensible decision framework, and yes — any spurious automated containment at or below thirty seconds is an automatic no-go. That's not a negotiating position, that's the line. A false containment during a real incident is operationally worse than a missed detection for us right now, given where we are post-breach. Get that criterion documented in the test plan before Priya's authorization conversation, not after, so there's no ambiguity about what a pass looks like versus what reopens the evaluation. If the protocol and the no-go criterion are in writing and the data authorization comes through, I'll sponsor the POC internally.

I’ll document this verbatim in the test plan: any spurious automated containment with event arrival or out-of-order delay at or below thirty seconds is an automatic no-go, because Aperture considers false containment during an incident operationally worse than a missed detection right now. The plan will version-lock scoring before evaluation, exercise the full delay range, and require graceful degradation beyond thirty seconds; no protected data moves before Priya’s written authorization. You’ll receive the written protocol for confirmation before that authorization conversation. Based on the event coverage and join evidence now in front of you, what is your architecture decision—go, conditional go, or no-go—and what, if anything, remains before you can sponsor the POC internally?

[victor] Conditional go. The event-category coverage is credible, the join path is sound, and the scoring architecture handles the failure modes I've seen break other tools. What remains before I sponsor internally: one, written test protocol in my hands with the no-go criterion documented exactly as stated, before any authorization conversation with Priya; two, Priya's written data authorization — I won't move protected telemetry on a verbal; three, confirmation that the evaluation set is drawn from the breach window or a comparable high-velocity credential period, not clean baseline traffic, because that's the only population that tests the actual problem. If those three things are in order, I'll take it to the board sub-committee conversation as a structured POC with defined pass-fail criteria, not a vendor evaluation. That's a different conversation internally and it matters right now.

Conditional go recorded. I’ll send you the version-locked written protocol directly before Priya is asked for data authorization. It will state exactly: any spurious automated containment at or below thirty seconds is an automatic no-go. It will also require a breach-window or comparable high-velocity credential population, with comparability defined and approved by you—not clean baseline traffic. No protected telemetry will move without Priya’s written authorization, and her authorization will govern whether breach-window data, a comparable period, or neither may be used. Once you confirm the protocol and population, and Priya authorizes the data in writing, you will sponsor this to the board cyber sub-committee as a structured POC with fixed pass-fail criteria. What date is that sub-committee conversation, so the protocol confirmation and authorization gates can be worked backward without compressing Priya’s review?

[victor] [victor] The sub-committee meets in five weeks. That's also inside the SIEM auto-renewal window, so I'll be direct — if the protocol isn't confirmed and Priya's authorization isn't in motion within ten days, the timeline doesn't work and I won't bring an incomplete evaluation into that room. Get me the written protocol within five business days, I'll turn confirmation in two, and that leaves Priya adequate review time before the authorization has to move. Don't compress her review to make your timeline work; that's how you lose both of us.

Understood. Mutual action record: Sentinel sends you the version-locked protocol within five business days; you return confirmation or required changes within two business days; and within ten calendar days the confirmed protocol and defined high-velocity evaluation population are with Priya for her authorization review. We will not compress or bypass her process, and no protected telemetry moves without her written authorization. The board cyber sub-committee is in five weeks, inside the Fortalis auto-renewal window; if the protocol is not confirmed and Priya’s authorization is not in motion within ten days, you will not take the evaluation forward. To remove ambiguity from the plan, does “authorization in motion” mean Priya has accepted a complete authorization request for review—not that she has issued approval by day ten?

[victor] [victor] Yes, that's the correct interpretation — "in motion" means Priya has a complete, confirmed request in front of her for review, not that she's issued approval. Her authorization timeline is hers to control; I'm not going to manufacture a deadline on her process. What I need by day ten is confidence that the request is complete, accurate, and in her hands — if it's incomplete or she's been handed something that requires revision, that's the same as not in motion. Make sure what goes to her is ready for a yes, not a conversation starter.

Day ten is an acceptance-quality gate, not an approval deadline. The package Priya receives will include the Victor-confirmed, version-locked protocol; the exact automatic no-go criterion; the approved breach-window or comparable high-velocity population and rationale; requested fields and purpose; minimization, access, retention, deletion, and litigation-hold controls; test environment and named users; and the unresolved counsel items clearly identified. We will preflight it against her requirements before submission—no placeholders and no protected telemetry transferred. I’ll issue the calendar-dated mutual action plan after this call: protocol to you within five business days, your response within two business days, and a complete request accepted into Priya’s review by day ten. If any of those gates slips, the five-week sub-committee path is at risk and we will flag it immediately rather than compress her review.

[victor] [victor] That's the right list and the right framing. One addition — include the litigation-hold status explicitly, not just as a control category, because we are six weeks into a class-action and anything touching breach-window data will get scrutiny from our outside counsel before Priya can authorize it anyway. If that's not already coordinated on your end, flag it now rather than have it surface as a surprise on day nine. Send me the written action plan, I'll review it, and we'll move.

It is already coordinated counsel-to-counsel, and I’ll state the status explicitly: the litigation-hold provision remains open pending outside-counsel redlines; no DPA closure or breach-window authorization is assumed. Priya has confirmed the demand-notice architecture is substantively workable, including notice before compliance unless prohibited, coordination to challenge or narrow demands, minimum disclosure, and chain-of-custody documentation. The action plan and authorization package will identify that open dependency, its owners, and required closure rather than burying it as a generic control. I’ll send you the calendar-dated action plan for review, then the protocol within five business days as agreed.

[victor] [victor] Good. Naming it as an open dependency with owners is the right call — if outside counsel redlines come back and reopen scope, I need to know immediately, not on day nine. Send the action plan, I'll review it, and we'll hold the timeline. We're done for today.

Call ended; do not send another acknowledgment. Victor issued a conditional go: coverage credible, join path sound, scoring architecture handles known failure modes. Send a calendar-dated Mutual Action Plan next. Before sending, resolve the apparent date conflict rather than hiding it: protocol due within five business days, Victor review within two business days, but the complete request must be accepted into Priya’s review by day ten calendar days. MAP must name owners, dependencies, and exact dates; state the automatic no-go criterion verbatim; require Victor-approved breach-window or comparable high-velocity data; require Priya’s written authorization before telemetry moves; and list litigation-hold language as OPEN with Sentinel counsel/Aperture outside counsel as owners. Alert Victor immediately if counsel redlines reopen scope. Preserve his five-week cyber sub-committee path and do not compress Priya’s review.

[week 3] The contact resurfaces — the fire drill has passed.

[calendar — week 3 of 6] Meeting slots this week: 2. Email budget: 3.

Subject: Action plan for confirmation — protocol and authorization gates

Victor,

Below is the calendar-dated action plan reflecting your conditional go and the timeline you set. I moved our protocol delivery earlier than the five-business-day limit so your two-day review fits before the day-ten gate without compressing Priya’s review.

1. Written test protocol — Sentinel owner — Tuesday, July 14
• Version-lock scoring policy, containment threshold, correlation window, missing-field behavior, and rescoring rules before evaluation.
• Test identical scenarios at synchronous, 4-second, 18-second, 30-second, and beyond-30-second arrival intervals.
• Report alert, analyst-review, and containment outcomes; false-containment and missed-event behavior; time to decision; late-event escalation; and full lineage.
• Required criterion exactly as agreed: “Any spurious automated containment at or below thirty seconds is an automatic no-go.”
• Beyond 30 seconds, require graceful degradation to alert or analyst review rather than lower-confidence automated containment.

2. Protocol and population confirmation — Victor owner — Thursday, July 16
• Confirm or return required changes within two business days.
• Confirm that the proposed evaluation population is breach-window data or a comparable high-velocity credential period—not clean baseline traffic—and approve any comparability rationale.
• Any protocol change after version lock creates a new version and rerun requirement.

3. Complete authorization request accepted into review — Sentinel/Priya owners — Monday, July 20
• Sentinel submits a ready-for-decision package containing the Victor-confirmed protocol and population; requested fields and purpose; minimization; test environment and named users; access, retention, deletion, and litigation-hold controls; and all open counsel dependencies.
• “In motion” means Priya has accepted a complete and accurate request for review. It does not mean approval by July 20; her authorization timeline remains hers.
• No protected telemetry moves without Priya’s written authorization.

4. Legal dependency — Sentinel counsel/Aperture outside counsel owners — OPEN
• Litigation-hold language remains open pending outside-counsel redlines; no DPA closure or breach-window authorization is assumed.
• Demand-notice architecture is substantively workable, but final mechanics remain subject to counsel agreement.
• If redlines reopen scope or threaten package completeness, I will notify you immediately rather than waiting until the authorization gate.

5. Structured POC and governance path — Victor/Sentinel owners
• Upon protocol confirmation and written data authorization, execute only against the approved population and fixed pass/fail criteria.
• Victor sponsors the structured POC to the board cyber sub-committee in five weeks, provided the preceding gates hold.
• The exact sub-committee date and Fortalis auto-lock date remain to be inserted once confirmed; I will not invent either date.

Please reply with confirmed or required corrections to this action plan. The protocol delivery remains July 14 regardless.

Action plan confirmed as written. Two additions before July 14: first, insert the exact sub-committee date and Fortalis auto-renewal lock date as soon as you have them — I need those in the document before I take anything to the board room, not as a placeholder; second, when the protocol arrives, include the specific version identifier on the scoring policy and containment rules so there is no ambiguity about what was locked if we ever need to reconstruct the evaluation record for counsel or the sub-committee. Everything else is accurate and the ownership is correctly assigned. July 14 for the protocol, July 16 for my confirmation, July 20 for Priya's acceptance gate — hold those dates.

Victor Salinas

[meeting granted] Call with Dana Reyes, week 3, slot 1.

Dana, Victor has issued a conditional go and confirmed the action plan: locked protocol July 14, his confirmation July 16, and a complete authorization request accepted into Priya’s review July 20. He will sponsor a structured POC if those gates hold. I don’t want technical momentum to substitute for a business case Owen can evaluate. In Aperture’s terms, what measurable cost or operational burden must this change—fraud exposure, analyst effort, customer lockouts, response time, or something else—and what baseline would Owen regard as credible? I also need the exact cyber sub-committee date and Fortalis auto-renewal lock date so the plan has no placeholders.

Good. Victor moving is not nothing — he doesn't give conditional go's casually. But you're right to separate technical momentum from a case Owen will actually fund, because those are very different conversations and I've watched vendors conflate them and lose both.

Here's what I actually own: roughly 40 million loyalty accounts exposed, forensics put attacker dwell at 51 days before we caught it, and loaded incident cost is tracking past $22 million with the class-action reserve. My SOC is drowning — over 90 percent of identity alerts are false positives, I have eleven analysts doing the work of twenty, and two gave notice this month. Those are my numbers, not a vendor slide, and those are the only numbers Owen will accept in that room.

What he needs to see is a conservative case built on those baselines — dwell time reduction, analyst hours recovered, false-positive rate improvement — with no "up to" language and no fear framing. If I walk in with a fear pitch I lose him immediately and I lose my credibility with the sub-committee.

On your dates — the sub-committee meets in five weeks from Victor's confirmation, and the Fortalis auto-renewal lock is inside that window, which is exactly why the July 20 gate matters. I'll get you the exact calendar dates by end of week; I'm not going to give you a number I have to walk back.

I’ll use only those Aperture baselines: 51 days of attacker dwell in this incident, loaded incident cost now above $22 million including the class-action reserve, more than 90% false positives in identity alerts, and eleven analysts covering work sized for twenty, with two notices this month. I will not imply Sentinel caused or can recover the $22 million, and I’ll avoid fear framing and “up to” claims. To translate improvement into a conservative case Owen will recognize, what are the current monthly identity-alert volume and average triage time, and does he value recovered analyst hours only when they avoid replacement hiring, contractors, or overtime? Also, what minimum measured improvement in dwell time and false-positive rate would be credible enough for him to consider funding rather than dismiss it as vendor optimism?

Those are exactly the right questions and I'll tell you what I can. On alert volume and triage time — I'm not going to give you raw numbers before Victor's POC produces observed data, because if I hand you estimates and Owen stress-tests them, I need to be able to defend them. What I can tell you is the burden is real and the two notices this month are the leading indicator Owen will actually feel, because backfill in this market runs six figures loaded and he knows it.

On what Owen finds credible — he's a show-me CFO. He won't fund a projection; he'll fund a measured result from a controlled test against our own data. That's why the POC structure Victor approved matters more than any number I give you today. A 30-point reduction in false-positive rate with analyst hours documented in the test is a different conversation than a vendor claiming 90 percent improvement on a slide.

On minimum thresholds — conservatively, if the POC shows dwell-time detection capability that would have surfaced the breach window materially earlier than 51 days, and false-positive reduction that demonstrably frees analyst capacity without headcount addition, that's the shape of a case he'll engage with rather than dismiss. I won't put a specific number on "materially" until I see what the POC produces.

Get me the exact dates by Friday and I'll confirm them back to you. And bring me a one-page conservative case framework before you're anywhere near Owen — I need to see it before he does.

Agreed: the one-page case will be a measurement framework, not a projection. It will use only Aperture’s baselines—51-day dwell, more than 90% identity-alert false positives, eleven analysts against work sized for twenty, two resignations this month, and six-figure loaded backfill—and will leave alert volume, triage time, and financial benefit blank until the controlled POC produces defensible observations. It will define how we document earlier detection, false-positive reduction, analyst hours recovered, and whether capacity avoids backfill, contractors, or overtime. I’ll show Sentinel’s $980,000 annual price transparently and won’t claim the $22 million incident cost as recoverable value. I’ll send you the draft by Thursday, July 16, for review before any approach to Owen. If you approve the framework, will you sponsor a 30-minute working session with Owen so we can ask which measured outcomes and finance assumptions he requires for a funding decision, rather than presenting him a vendor ROI? On the calendar, I understood that you would provide the exact sub-committee and Fortalis lock dates by Friday; I’ll insert and recirculate them immediately when you confirm them.

[dana] The framework approach is right and Thursday works — I'll review it before anything goes near Owen. On sponsoring the working session: yes, but on my terms. Victor has to validate the POC plan first, we present my exposure and dwell numbers with a conservative case, and if there's a single fear-based slide or "up to" claim I pull the meeting. Pre-brief Victor before we're anywhere near Owen or it's dead before it starts.

What I need to see in the Thursday draft before I'll commit to that introduction is that the framework is genuinely diagnostic — it defines what we measure, how we document it, and what Owen needs to see to make a decision, not what Sentinel wants him to conclude. If it reads like a vendor ROI dressed up as a framework, I'll send it back.

On the dates — I'll have the sub-committee date and the Fortalis lock confirmed to you by Friday. I'm not going to let a placeholder sink a plan that's otherwise moving correctly.

Those are the meeting conditions, not suggestions: Victor validates and is pre-briefed; you approve the diagnostic framework and conservative case; only Aperture-owned figures appear; and there will be no fear framing, “up to” language, or predetermined ROI conclusion. The framework will show four columns only: Aperture baseline, POC measurement method, observed result, and finance treatment requiring Owen’s input. It will also show the $980,000 annual price without a breach-pressure discount. To make the diagnosis decision-relevant, how does Owen frame the alternative: auto-renew Fortalis and add people, renew it while adding an identity layer, or consider changing the SIEM commitment? I don’t want to position Sentinel as a replacement or duplicate spend without understanding the actual choice he believes he is making.

[dana] That's the right question and I'll answer it carefully because this part is between us. Owen frames it as a cost-control decision, not a security decision — his default is auto-renew Fortalis because procurement loves them and renewal is easy. What he doesn't fully see yet is that Fortalis's identity analytics is essentially a slideware roadmap — it did not flag the credential stuffing, and Victor scored its identity signals as noise. I'll deny I said that if it shows up in a vendor slide or gets used as a competitive attack, because it'll look like mudslinging and it'll cost me credibility with procurement and Owen both.

What that means for how you frame the alternative: the choice Owen actually needs to evaluate is not Sentinel versus Fortalis — it's whether the identity-layer gap that existed during a 51-day dwell gets closed before the next incident, and what that costs relative to what the last one cost. That's a gap-closure framing, not a replacement framing, and it doesn't require me to throw Fortalis under the bus publicly.

If the POC produces measured results and the framework is clean, I can make the case that we're addressing a documented gap — not panic-buying under a headline. That's the version Owen can defend to the board sub-committee, and that's the version I need you to build.

Understood, and I’ll keep your Fortalis assessment out of every document and meeting. We will not position Sentinel as a SIEM replacement or attack the incumbent. The framework will ask whether Aperture can close the documented identity-layer gap through measured earlier detection, lower false-positive burden, and recovered analyst capacity, at a transparent annual cost of $980,000. The $22 million remains incident context—not claimed savings or a price anchor. For the eventual Owen session, I’d like to diagnose his decision rather than presume it: what evidence he requires to approve an exception to the spend freeze, how he treats the Fortalis renewal versus a separate identity-layer investment, and which finance assumptions he will permit. Besides Owen’s approval, are there procurement, board, or funding-source gates we should put into the action plan now, and does he need to act before the Fortalis lock or only before the sub-committee meeting?

[dana] The sequencing question is the most important thing you've asked today, so I'll be direct. The thing nobody's saying out loud is that if I don't have a signed alternative before the Fortalis renewal locks, I'm stuck with the tool that missed this breach for another year. Owen needs to act before the lock, not just before the sub-committee — those are not the same date, and the gap between them is where deals die.

On gates beyond Owen: procurement will run a standard vendor review but they follow Owen's signal, so if he's in, they move. The board cyber sub-committee doesn't approve spend but they will ask pointed questions about any new commitment, and if the case isn't conservative and documented they'll create noise that stalls Owen even after he's inclined to approve. Priya's DPA authorization is a hard gate — nothing moves on data without it, and that's already in your action plan correctly.

On funding source — Owen will want to know whether this is an exception to the freeze or a reallocation from existing security budget, and I genuinely don't know which framing he'll accept until we're in the room with him. That's exactly why the diagnostic session matters more than a pitch. Get me the Thursday framework, let me review it, and I'll confirm the dates by Friday so we can close the placeholder gap and sequence this correctly before the lock creates a problem we can't solve.

I’ll hold the sequence: diagnostic framework to you Thursday, July 16; Victor’s protocol confirmation that same day; exact Fortalis lock and sub-committee dates from you by Friday, July 17; then, only after your approval and Victor’s pre-brief, you sponsor the diagnostic session with Owen early enough for a decision before the lock. We’ll add procurement, commercial review, signature, and the board pre-read as dated gates once the dates are confirmed; Priya’s written authorization remains mandatory before protected data moves. One point I need to avoid mis-sequencing: when you say “signed alternative before the Fortalis renewal locks,” do you mean a fully executed Sentinel order form and DPA, rather than Owen’s funding approval alone—and who besides Owen has signature authority?

[dana] Good catch and yes, that distinction matters. When I say signed alternative I mean a fully executed order form and a completed DPA — Owen's funding approval is a necessary gate but it's not the finish line. Procurement runs the commercial review and issues the final order, and contracts above a certain threshold require Owen's signature plus the General Counsel's sign-off, which in practice means Priya's office is in the signature chain twice — once for the DPA and once for the commercial agreement. That's not a short loop.

What that means practically is that Owen's approval needs to come early enough to run procurement review, commercial redlines, and dual signature before the lock — not the day before. If you're building the gate sequence, work backwards from the Fortalis lock date and you'll see the real deadline for Owen's decision is earlier than most people assume.

I'll have the exact dates for you Friday and I'd suggest you build the reverse timeline immediately when you have them, because that's the document that will make the sequencing visible to everyone who needs to move.

Understood. The critical path ends with a fully executed $980,000 order form and completed DPA before the Fortalis lock—not merely Owen’s approval. Once you confirm the dates Friday, I’ll reverse-plan these separately: Priya’s data authorization for the POC; measured POC results and Victor validation; your approval and Victor pre-brief; Owen’s freeze-exception or reallocation decision; procurement/vendor and commercial review; DPA and agreement redlines; Owen plus General Counsel sign-off; and final execution before the lock. I’ll assign owners and calendar dates rather than assume standard cycle times, and I’ll flag the latest safe Owen-decision date. May I coordinate the legal durations directly with Priya and have you validate procurement timing, then bring you the reverse timeline before we request Owen’s session?

[dana] Yes, but Priya's office doesn't take cold outreach from vendors — I'll send a brief introduction that frames this as a DPA scoping conversation I've authorized, not a sales contact. Don't go around that introduction or you'll lose her before the conversation starts. On procurement timing, bring me the reverse timeline first and I'll validate the cycle estimates before anything goes to Owen — I know where procurement moves fast and where it stalls, and I'd rather correct it on paper than discover a gap when we're inside the lock window. Thursday framework, Friday dates, then the reverse timeline as soon as you have the dates in hand. That's the sequence that keeps this alive.

Agreed. I will not contact Priya until you make the authorized introduction. Sequence confirmed: diagnostic framework to you Thursday, July 16; exact Fortalis lock and cyber sub-committee dates from you Friday, July 17; then I build the reverse timeline for your validation before any Owen request. After your introduction, my conversation with Priya will be limited to DPA scope, litigation-hold and outside-counsel dependencies, required review durations, and signature sequencing—not sales. Could you include me on that introduction by Friday when you send the dates, so legal timing can be incorporated immediately without bypassing your process?

[dana] Yes, I'll include you on the Priya introduction when I send the dates Friday — one note to Priya, one set of dates, one message. Keep the scope exactly as you described or she'll route you to outside counsel and that adds weeks we don't have. Thursday framework, Friday dates and introduction, then you build the reverse timeline. If the framework is clean I'll tell you same day so you're not waiting over a weekend on a seven-week clock.

Confirmed. By Thursday, July 16, you’ll have a one-page diagnostic framework using only Aperture-owned baselines, with measurement methods, observed-result fields, finance treatments for Owen to define, and the $980,000 annual price stated plainly—no projected ROI, fear framing, “up to” claims, or Fortalis comparison. On Friday, July 17, I’ll wait for your single message containing the two exact dates and authorized Priya introduction; I will not contact her beforehand. I’ll then build the calendar-dated reverse timeline for your validation before any Owen meeting request. Thank you, Dana—I have the sequence and will hold it.

[dana] Good. Thursday framework, Friday dates and introduction, then the reverse timeline. If the framework is what you've described I'll turn it fast — I don't have time to sit on things that are actually useful. Don't make me chase you and don't make me fix it. Talk Friday.

Understood. You’ll have a review-ready framework Thursday without needing to chase or repair it. I’ll wait for your Friday dates and Priya introduction, then return the reverse timeline for your validation. Talk Friday.

[dana] Talk Friday.

Subject: Thursday review — one-page diagnostic decision framework

Dana,

Below is the review-ready framework for your approval before anything goes to Owen. It is diagnostic, not a projected ROI, and uses only Aperture-owned baselines.

APERTURE IDENTITY-GAP DECISION FRAMEWORK

Decision to diagnose
Can Aperture close the documented identity-layer gap with measured earlier detection, lower false-positive burden, and recovered analyst capacity—at Sentinel Grid’s $980,000 annual price—without adding operational containment risk?

1) Earlier detection
• Aperture baseline: The credential-stuffing incident had 51 days of attacker dwell.
• Controlled-POC method: Using Victor-approved breach-window or comparable high-velocity data, record the earliest timestamp at which the version-locked policy would surface qualifying activity. Preserve event lineage and compare it with Aperture’s actual detection point. Do not extrapolate from clean baseline traffic.
• Observed result: [POC result only; blank until measured]
• Owen’s finance treatment: Determine whether measured earlier detection supports funding; no incident-loss avoidance or recovery value will be assumed.

2) False-positive burden
• Aperture baseline: More than 90% of identity alerts are false positives.
• Controlled-POC method: Aperture labels outcomes; report total alerts, true/false positives, resulting false-positive rate, and any misses across the approved evaluation set. Apply Victor’s automatic no-go criterion exactly: “Any spurious automated containment at or below thirty seconds is an automatic no-go.”
• Observed result: [POC result only; blank until measured]
• Owen’s finance treatment: Assess only the measured rate change; no “up to” or benchmark claim.

3) Analyst capacity
• Aperture baseline: Eleven analysts are covering work sized for twenty; two analysts gave notice this month; loaded backfill runs six figures.
• Controlled-POC method: Measure analyst handling time consistently across the approved test, including investigation and disposition. Document hours changed; do not monetize them automatically.
• Observed result: [POC result only; blank until measured]
• Owen’s finance treatment: Owen determines whether documented capacity affects backfill, contractors, overtime, or none of these. No headcount savings will be claimed without his approved treatment.

4) Operational safety and auditability
• Aperture baseline: False containment during an incident is operationally worse than a missed detection right now.
• Controlled-POC method: Test the locked scoring-policy and containment-rule version at synchronous, 4-second, 18-second, 30-second, and beyond-30-second arrival conditions. Document alert, review, and containment outcomes; late-event rescoring; graceful degradation; and full lineage.
• Observed result: [POC result only; blank until measured]
• Decision treatment: Any spurious automated containment at or below 30 seconds is an automatic no-go. Victor validates the result before an Owen session.

Commercial facts and boundaries
• Sentinel Grid annual price at Aperture’s identity volume: $980,000.
• Aperture’s loaded incident cost is tracking above $22 million including the class-action reserve. This is incident context only—not recoverable value, projected savings, or a price anchor.
• This evaluates closure of an identity-layer gap; it does not position Sentinel as a Fortalis replacement or make a competitive attack.
• No protected telemetry moves without Priya’s written authorization.
• No projected ROI, fear framing, “up to” claims, or predetermined recommendation.

Questions reserved for Owen
1. What measured POC outcomes are sufficient for a funding decision?
2. Should funding be treated as a spend-freeze exception or reallocation from existing security budget?
3. Which treatments, if any, may be applied to documented analyst capacity?
4. What evidence and approvals does he require before procurement and dual-signature execution?

Please mark this approved or identify required corrections. I will not request time with Owen until you approve it and Victor has been pre-briefed. I’ll wait for your Friday message with the exact Fortalis lock and cyber sub-committee dates plus the authorized Priya introduction, then return the reverse timeline for your validation.

This is approved as written. You held every boundary we discussed — Aperture numbers only, no projected savings, no competitive framing, $22 million as context not leverage, and Owen's finance treatments left genuinely open for him to define. Victor will recognize this as an engineering document, not a vendor pitch, which is exactly what gets him to validate rather than obstruct.

Two things before Friday. First, when you send the reverse timeline, flag the latest safe date for Owen's decision explicitly — not the lock date, the decision date that still leaves procurement, commercial review, and dual signature enough room to execute. That's the number I need visible before I request his time. Second, I'm going to forward this framework to Victor today with a brief note that you built it to his telemetry requirements and that I want his protocol confirmation before we go further. If he pushes back on the POC method I'll tell you Friday alongside the dates so you can address it before we're in a room with Owen.

Dates, Priya introduction, and Victor's initial reaction — Friday.

Dana Reyes

Dana approved the diagnostic framework as written. Do not contact Priya before Dana’s authorized Friday introduction, request Owen time, or independently send Victor the framework; Dana is forwarding it and will report any POC-method objections Friday. On Friday, obtain in one message: exact Fortalis auto-renewal lock date, exact cyber sub-committee date, Priya introduction, and Victor’s initial reaction. Then immediately build a calendar-dated reverse timeline for Dana’s validation, explicitly distinguishing the Fortalis lock from the latest safe Owen funding-decision date. Work backward from fully executed order form plus completed DPA and include owners/durations for procurement vendor review, commercial redlines, Priya/GC review and sign-off, Owen signature, final order issuance, POC authorization and execution, Victor validation/pre-brief, and Dana approval. Do not invent cycle times; identify assumptions for Dana and Priya to validate. Preserve list price at $980,000/year and all approved framework boundaries.

Subject: SG-AP-POC-TP-v1.0 — version-locked test protocol for confirmation

Victor,

Attached below is the written protocol due July 14. This version is locked for your review; changes will produce a new identifier and require affected tests to be rerun.

DOCUMENT AND POLICY CONTROL
• Test protocol: SG-AP-POC-TP-v1.0
• Scoring policy: SG-IDAS-2026.07.14-v1.0
• Containment rules: SG-CONT-2026.07.14-v1.0
• Sentinel owner: [named technical lead assigned at kickoff]
• Aperture technical approver: Victor Salinas
• Execution is prohibited until Priya provides written data authorization.

PURPOSE
Determine whether Sentinel can surface credential-abuse activity materially earlier than Aperture’s actual detection point, reduce identity-alert false positives, and recover measurable analyst capacity without introducing unacceptable containment risk. This is a structured POC with fixed pass/fail criteria, not an open-ended vendor evaluation.

EVALUATION POPULATION
• Use breach-window telemetry or a comparable high-velocity credential period approved by you and authorized in writing by Priya.
• Clean baseline traffic alone is not an acceptable evaluation population.
• If breach-window data cannot be authorized, the comparable period must document credential-attempt velocity, account distribution, source diversity, and available event categories sufficient for you to approve comparability.
• Aperture controls ground-truth labeling. Population boundaries, exclusions, and label changes are preserved in the evaluation record.

LOCKED TEST CONDITIONS
Run identical scenarios against SG-IDAS-2026.07.14-v1.0 and SG-CONT-2026.07.14-v1.0 at synchronous, 4-second, 18-second, 30-second, and beyond-30-second event-arrival or out-of-order delays. Record for each run:
• source-event and normalized-event timestamps;
• identity/account/session joins and missing-field behavior;
• original score, any rescore, reason, and policy version;
• alert, analyst-review, or containment decision and decision time;
• true positive, false positive, missed event, and false-containment disposition;
• analyst handling time and investigation lineage;
• degradation behavior when confidence or event completeness is insufficient.

PASS/FAIL AND NO-GO RULES
• Exact automatic no-go criterion: “Any spurious automated containment at or below thirty seconds is an automatic no-go.”
• This is a hard stop, not an averaged metric or negotiable threshold. A single qualifying occurrence fails the evaluation and reopens the decision.
• Beyond 30 seconds, lower-confidence or incomplete-event conditions must degrade to alert or analyst review rather than automated containment.
• False-positive rate, earliest qualifying detection timestamp, missed-event behavior, analyst handling time, and full lineage will be reported as observed results; no vendor benchmark or projected result substitutes for Aperture’s test data.

CHANGE AND RECONSTRUCTION CONTROL
• Hashes for the protocol, scoring-policy package, containment-rule package, evaluation manifest, and output logs will be recorded before execution.
• No threshold, feature, rule, population, or label may change silently during the evaluation.
• Any approved change receives a new version identifier, named approver, timestamp, rationale, and defined rerun scope.
• The final record will preserve sufficient lineage to reconstruct for counsel and the cyber sub-committee which data, policy, rules, and decisions produced each result.

DATA AND LEGAL CONTROLS
• No protected telemetry moves before Priya’s written authorization.
• The authorization package will specify fields and purpose, minimization, environment, named users, access, retention, deletion, and litigation-hold status.
• Litigation-hold language remains OPEN pending outside-counsel redlines. If those redlines reopen scope, I will notify you immediately rather than wait for the July 20 acceptance gate.

CONFIRMATION REQUEST
Please reply by July 16 with either “SG-AP-POC-TP-v1.0 confirmed” or specific required changes, including your confirmation of the proposed evaluation population or the evidence required to establish a comparable high-velocity period. A complete, confirmed request is due in Priya’s hands for acceptance into review July 20; that is not an approval deadline, and her review will not be compressed.

Dana is confirming the exact Fortalis auto-renewal lock and cyber sub-committee dates Friday. I will insert those dates into the action plan immediately rather than retain placeholders.

This is the first protocol I've received from a vendor that I didn't have to rewrite before I could take it seriously. The version locking, the hash controls, the change-reconstruction lineage, the hard stop on the 30-second criterion — those are correct and I'm not going to negotiate them down. You wrote the no-go rule exactly as I stated it and you left it as a hard stop, not a threshold with averaging headroom. That matters.

Two open items before I confirm. First, the evaluation population clause is right in principle but I need to approve the comparability evidence before execution begins, not concurrently with it — add a sequential gate that makes my population approval a named predecessor to Priya's authorization request, not a parallel track. Second, the named Sentinel technical lead field is blank. I won't confirm a protocol where the accountable technical counterpart is a placeholder. Put a name in that field or tell me when you will have one, because if something changes mid-evaluation I need a person, not a role title.

Fix those two items, reissue as v1.1 with the version identifier and a change log entry, and I'll confirm by July 16 as requested. Do not submit anything to Priya's office until I've confirmed the revised version — the July 20 acceptance gate is workable but only if v1.1 is in my hands by end of day July 15.

Victor Salinas
Principal Security Architect, Aperture Retail

[harness] email budget for week 3 spent.

Forwarding you something you didn't get from me. This is how it's landing internally — use it wisely.

> [slack] dana → #vendor-eval: Quick update for the group: I approved their diagnostic framework this morning. It's clean — Aperture numbers only, no projected ROI theater, Owen's finance treatments left blank for us to define. Victor, your protocol review tracks the same pattern. I'm going to send the Priya intro and the sub-committee dates today as planned. Wanted everyone to know where this stands before the weekend.
> [slack] victor → dana: Agreed on the framework read. I'll say it plainly: the test protocol was the first one I've received in maybe three years that I didn't have to gut and rebuild. Version locking, hash controls, change lineage — all there. I'm still in 'trust but verify' mode and the POC hasn't run yet, but they've cleared the bar to run it. No objections to the Priya intro moving forward.
> [email] priya → dana: Dana — heads up that I haven't received your intro yet as of noon Friday, no rush if it's coming later today. Separately, can you confirm whether this vendor processes any data outside the EU/EEA? If their sub-processors touch EU resident data we'll need SCCs scoped before I can engage substantively on the DPA. Just want to know what I'm walking into before the conversation starts. —P
> [slack] owen → dana: Dana — saw the framework summary you forwarded. I appreciate that they left the finance treatment fields blank rather than filling them in with their own assumptions like every other vendor does. I'm still not convinced on the business case but at least it's a starting point I can actually hand to my team without embarrassing myself. Keep me posted on the timeline. I'll want a number I can stress-test before this goes anywhere near the board.

— Dana Reyes

[calendar — week 4 of 6] Meeting slots this week: 2. Email budget: 3.

[week 4 event] Legal opens the data-processing review — DPA, sub-processor list, breach- context data-handling. Mid-litigation it cannot be compressed. Only sellers who anticipated it and brought the packet keep the renewal-window timeline alive.

Subject: SG-AP-POC-TP-v1.1 — two requested corrections for confirmation

Victor,

Reissuing the protocol as SG-AP-POC-TP-v1.1 with only the two changes you requested.

CHANGE LOG — v1.0 to v1.1
1. Evaluation-population approval is now a sequential gate: your written approval is a named predecessor to submission of the data-authorization request to Priya. Population approval will not run concurrently with execution or legal authorization.
2. Named Sentinel technical lead: Maya Chen, Principal Identity Security Architect. Maya is accountable for policy and rule integrity, change control, execution, and reconstruction of the evaluation record. I remain the commercial and action-plan owner.

REVISED DOCUMENT AND POLICY CONTROL
• Test protocol: SG-AP-POC-TP-v1.1
• Scoring policy: SG-IDAS-2026.07.14-v1.0 — unchanged
• Containment rules: SG-CONT-2026.07.14-v1.0 — unchanged
• Sentinel technical lead: Maya Chen, Principal Identity Security Architect
• Aperture technical approver: Victor Salinas
• Execution is prohibited until all sequential gates below are complete.

REVISED SEQUENTIAL GATES
Gate 1 — Protocol confirmation, owner: Victor
• Confirm SG-AP-POC-TP-v1.1, including fixed methods and no-go rule.

Gate 2 — Evaluation-population approval, owner: Victor
• Sentinel supplies the proposed breach-window population or documented evidence for a comparable high-velocity credential period.
• You approve the population and any comparability rationale in writing before the authorization package is submitted to Priya.
• No concurrent population approval, legal submission, or execution is permitted.

Gate 3 — Complete authorization request accepted into review, owners: Sentinel/Priya
• Only after Gates 1 and 2, Sentinel submits the confirmed protocol, Victor-approved population, requested fields and purpose, minimization, environment and named users, access, retention, deletion, sub-processor and transfer details, and explicit litigation-hold status.
• Priya’s acceptance means the package is complete and in review, not approved.

Gate 4 — Written data authorization, owner: Priya
• No protected telemetry moves and no execution begins before Priya’s written authorization and completion of any required DPA, SCC, outside-counsel, or litigation-hold conditions.

Gate 5 — POC execution, owners: Maya Chen/Victor
• Execute only the confirmed protocol against the approved and authorized population.

All other provisions of v1.0 remain unchanged, including the exact hard stop: “Any spurious automated containment at or below thirty seconds is an automatic no-go.” The scoring-policy and containment-rule identifiers remain unchanged because neither artifact changed; the protocol version advances to v1.1 and this change log preserves the distinction.

Please reply “SG-AP-POC-TP-v1.1 confirmed” or identify any remaining correction. Nothing will be submitted to Priya as an authorization request until you confirm v1.1 and approve the evaluation population.

SG-AP-POC-TP-v1.1 confirmed.

The sequential gate structure is correct, Maya Chen is an acceptable named technical counterpart, and the change log accurately distinguishes what changed from what didn't. The scoring-policy and containment-rule identifiers holding at v1.0 is the right call — version-bumping artifacts that didn't change is how you introduce reconstruction ambiguity, and I'm glad you didn't do it.

One thing I want on record before we move to Gate 2: Priya's email to Dana flagged a question about EU/EEA sub-processor exposure and SCC scope. I don't know whether that's in your authorization package already, but if it isn't, Gate 3 submission will be rejected and we'll lose time we don't have. Confirm to me directly that the sub-processor list, transfer mechanisms, and SCC applicability determination are in the package before you submit — I'm not asking you to resolve the legal question, I'm asking you to confirm the materials are present so Priya isn't waiting on a follow-up request to start her review clock.

Bring me the Gate 2 population proposal when you're ready. I'll turn it as fast as the evidence supports.

Victor Salinas
Principal Security Architect, Aperture Retail

Subject: Gate 2 population proposal and Gate 3 legal-packet confirmation

Victor,

Confirmed directly: before any Gate 3 submission, the package will contain Sentinel’s complete current sub-processor list, each processing location, data categories and purpose, EU/EEA access or transfer paths, transfer mechanism by path, and an SCC applicability determination. It will also include the DPA, technical and organizational measures, retention/deletion schedule, incident-response terms, and explicit litigation-hold status. If counsel has not resolved an item, it will be identified as OPEN with an owner and dependency rather than omitted. We will not represent an unresolved legal conclusion as settled or ask Priya to start her clock on an incomplete packet.

Gate 2 population proposal for your review:

• Primary population: Aperture’s complete 51-day credential-stuffing breach window, using only fields Priya ultimately authorizes.
• Boundary evidence: exact UTC start/end timestamps, source systems, event categories, inclusion/exclusion rules, account and session coverage, known ingestion gaps, and ground-truth provenance.
• Representativeness evidence: credential-attempt velocity by interval, unique-account distribution, source/IP and device diversity, successful versus failed authentication patterns, event-arrival latency, missing-field rates, and known attacker/legitimate labels where Aperture can support them.
• Control population: an Aperture-selected adjacent period processed under the same field set and labeling rules, used to measure false-positive behavior—not as a substitute for the breach-window test.
• Integrity record: read-only population manifest and hash, extraction timestamp, named Aperture custodian, exclusions and rationale, and preserved label/change lineage.
• If the breach window cannot be authorized: no substitution occurs automatically. Maya will provide the same evidence for a proposed comparable high-velocity credential period, and execution remains blocked until you approve the comparability rationale in writing.

Please confirm whether this is sufficient for Gate 2 or identify the additional evidence you require. Your population approval is a predecessor to submission to Priya; this proposal does not authorize telemetry movement, extraction by Sentinel, or POC execution.

[victor] Gate 2 approved.

The population structure is sound. Breach window as primary, adjacent control period under identical field and labeling rules, no automatic substitution if authorization fails, and the integrity record with hash and named custodian — that's the right architecture. The missing-field rate and ingestion-gap documentation matter more than most vendors realize and I'm glad they're in the boundary evidence rather than treated as a footnote.

Two things I want Maya to know before execution planning starts. First, the ingestion gaps in the breach window are not just a documentation item — if there are intervals where event-arrival latency or source dropout is material, that affects whether a detection timestamp is meaningful or an artifact of missing data. Maya should be prepared to characterize those gaps explicitly in the evaluation record, not just acknowledge they exist. Second, the control population selection is Aperture's call, but I will review the selection rationale before it's locked. I'm not going to have a vendor argue later that the control period was anomalously clean.

The legal packet confirmation is noted. If anything in that packet arrives as OPEN, I expect the owner, dependency, and estimated resolution path to be specific — not a placeholder. Priya will not start her review clock on vague open items and neither will I accept a Gate 3 submission that papers over unresolved legal conclusions.

Submit to Priya when the packet is complete. I'll expect a notification when Gate 3 submission goes in.

Victor Salinas
Principal Security Architect, Aperture Retail

Subject: Inputs needed today to protect the execution window

Dana,

The framework is approved, Victor has now confirmed protocol SG-AP-POC-TP-v1.1, and Gate 2 population approval is complete. Gate 3 is ready to advance once legal receives the complete packet through your authorized introduction.

Please send the single message you outlined with:
1. Exact Fortalis auto-renewal lock date;
2. Exact cyber sub-committee date; and
3. Your introduction authorizing the DPA-scoping conversation with Priya.

I will not contact Priya before that introduction. The legal packet includes the DPA, current sub-processor list and processing locations, data categories and purposes, EU/EEA access and transfer paths, transfer mechanism by path, SCC applicability determination, TOMs, retention/deletion schedule, incident-response terms, and litigation-hold status. Any unresolved conclusion will identify a specific owner, dependency, and resolution path; it will not be hidden behind a placeholder.

Immediately after receiving the two dates, I will return a calendar-dated reverse timeline for your validation. It will work backward from completed DPA plus fully executed order form before the Fortalis lock and will explicitly flag the latest safe Owen decision date that still leaves enough time for procurement, commercial redlines, Priya/GC review, Owen and GC signatures, and final order issuance. I will label cycle durations as assumptions for you and Priya to validate rather than inventing them.

Victor also asked to be notified when the complete Gate 3 package is submitted; I will do that after Priya receives and accepts it into review.

The Fortalis auto-renewal lock is August 22. The cyber sub-committee next convenes August 11. Those are the two dates you need — work backward from August 22 with enough room for everything you described, and flag the Owen decision date explicitly so I can see whether we're actually inside the window before I request his time.

Priya Anand is copied on this message. Priya — this is the introduction I mentioned. Sentinel has a complete legal packet ready for your review covering DPA, sub-processor list, transfer mechanisms, SCC applicability, TOMs, retention and deletion, incident-response terms, and litigation-hold status. Any open items will be identified with a named owner and resolution path, not papered over. I've asked them not to contact you before this introduction and to submit nothing until you accept the package into review. Your review timeline is yours to set — I'm not asking you to compress it. What I need to know is your acceptance criteria for a complete submission so we don't waste your time with an incomplete packet.

One thing I want visible to both of you: the August 11 sub-committee date is not a signing deadline, it's a reporting deadline. If I walk into that room without a credible path to a decision, the board will draw its own conclusions about where this stands. That's the pressure I'm managing and I'd rather name it than have it surface sideways.

Reverse timeline back to me for validation before anything moves to Owen.

Dana Reyes

[harness] email budget for week 4 spent.

Forwarding you something you didn't get from me. This is how it's landing internally — use it wisely.

> [slack] dana → #vendor-eval: #vendor-eval — heads up: Legal's DPA review is now open. Priya, that's yours to run. I know the timing is what it is. The good news is their seller already committed Gate 3 includes the full sub-processor list, breach-context data handling, and DPA packet before any legal submission. Whether that holds up to your actual review is a different question, but at least they said the right things unprompted. Worth noting relative to where Fortalis was at this stage.
> [slack] priya → dana: Appreciated. I'll believe the packet when I see it — 'committed to provide' and 'actually complete and reviewable' are not the same thing in my experience. Sub-processor list needs to be current, not a stale exhibit from a master agreement signed two years ago. Breach-context data handling needs to map to our specific retention and notification obligations, not a generic GDPR boilerplate. If they walk in with something substantive I can move fast. If it's a placeholder dressed up as a packet, we
> [email] dana → owen: Owen — wanted to flag something before it becomes a timeline conversation. Legal's data-processing review opened this week, which is normal and non-negotiable. Priya estimates she can move quickly IF the vendor delivers a complete packet at Gate 3 — their seller has already stated that's the plan. The constraint I want you to have visibility on: the Fortalis auto-renewal is August 22. The sub-committee meets August 11. If the legal packet is thin and Priya has to go back to the vendor for supple
> [slack] victor → dana: For what it's worth — the fact that they named sub-processor disclosure and breach-context handling in that Gate 3 commitment without being asked is the first time I've seen a vendor do that proactively in this process. Still means nothing until Priya reviews the actual documents. But the pattern has been consistent: they've anticipated the next step before we asked for it. Either their seller has done this before or someone on their side is actually paying attention. Doesn't change what Priya n

— Dana Reyes

[calendar — week 5 of 6] Meeting slots this week: 2. Email budget: 3.

[week 5 event] Fortalis, smelling the threat, slashes its renewal 25% and dangles a "free identity module beta," and procurement circulates it as "why are we even looking?" Sellers who seeded differentiated criteria (real-time detection, containment, signal fidelity) survive; sellers without a competition strategy become the price lever.

Subject: Reverse timeline for validation — latest safe Owen decision is July 31

Dana,

Working backward from the August 22 Fortalis lock, the latest safe date for Owen’s funding decision is Friday, July 31. This is not the signing deadline; it is the last date that appears to preserve a credible execution path. The schedule is RED until you validate procurement timing and Priya validates legal timing.

PROPOSED REVERSE TIMELINE

• August 22 — Fortalis auto-renewal locks. Owner: Aperture.
• August 21 — Execution buffer; completed DPA and fully executed Sentinel order form must be confirmed. Owners: Procurement, Priya/GC, Owen, Sentinel.
• August 19–20 — Owen and General Counsel signatures; final order issuance. Assumption: two business days after final documents.
• August 17–18 — Final commercial and DPA approval; signature-ready documents released. Owners: Procurement and Priya/GC. Assumption: two business days.
• August 3–14 — Procurement/vendor review, commercial redlines, DPA review/redlines, and security validation. These may run concurrently after Owen’s signal, but neither is presumed compressible. Assumption: ten business days total; Priya and Procurement must validate.
• August 11 — Cyber sub-committee reporting date. Dana reports the documented evaluation status, measured results available by then, unresolved gates, and execution path. This is not represented as a spend-approval or signing deadline.
• August 7 — Proposed board pre-read complete. Owner: Dana. Content remains conservative and evidence-based.
• July 31 — LATEST SAFE OWEN FUNDING DECISION. Owen determines freeze exception versus budget reallocation and authorizes Procurement to proceed. Moving this date later consumes review or signature time rather than moving the August 22 lock.
• July 29–30 — Proposed diagnostic session with Owen, only after Dana approves the pre-brief and Victor is pre-briefed. Inputs: Aperture baselines, observed POC evidence available at that point, $980,000 annual price, and open finance treatments. No projected ROI or incident-cost recovery claim.
• July 27–28 — Priya accepts a complete Gate 3 packet into review and states the authorization path/timing; Victor is notified. No protected telemetry moves before written authorization.

CRITICAL CONFLICT TO RESOLVE

Owen has said he needs measured results from Aperture’s data, while POC execution cannot begin before Priya’s written authorization. If written authorization and sufficient POC measurement cannot occur before July 29, then a final July 31 funding decision is not supportable under the agreed evidence standard. We should not disguise that conflict.

The only credible alternatives are for Owen to authorize Procurement to begin conditionally while reserving final approval for Victor-validated POC results, or to accept that full execution before August 22 is at risk. That is Owen’s decision to define, not an assumption I will make for him.

COMPETITIVE/PRICE TREATMENT

Fortalis’s 25% renewal reduction and free identity-module beta do not change Sentinel’s $980,000 annual price. Nor will we attack Fortalis. Any identity option should be evaluated under the same locked Aperture criteria: earlier detection against the approved breach population, signal fidelity, analyst handling time, full lineage, and the hard no-go for any spurious automated containment at or below 30 seconds. A beta or lower price is not evidence that the documented identity gap is closed.

Please validate or correct the Procurement durations and the July 31 latest-safe decision date. Once validated, I will use this as the Mutual Action Plan baseline and request no Owen meeting until you authorize it.

[dana] The reverse timeline is structurally correct and I'm not going to pretend otherwise. July 31 as the latest safe Owen decision date holds if Procurement's ten-day review assumption holds — and that's the variable I can't validate unilaterally. I'm going to loop in our procurement lead today to confirm whether ten business days is realistic post-Owen signal or whether we need to compress assumptions somewhere else. I'll have that answer back to you by end of week.

The critical conflict you named is real and I appreciate that you didn't paper over it. I've been sitting with the same problem. What I can tell you is that Owen is not going to authorize Procurement to move conditionally without at least a directional read from Victor on the POC — not final results, but enough of a signal that the evaluation is tracking toward pass rather than toward the no-go. If Priya's review compresses the execution window to the point where that directional read isn't available before July 29, I need to know that explicitly so I can have a different conversation with Owen about what he's actually deciding on that date.

On Fortalis: the 25% reduction landed in procurement's inbox this morning and my phone rang twenty minutes later. Your framing is exactly right — a price cut and a beta module are not evidence that the identity gap is closed, and I'm going to say precisely that when I respond. What I need from you is that the evaluation criteria you've already documented — detection timing, signal fidelity, analyst load, containment behavior — are visible and locked before that conversation goes further. The criteria exist. I just need them referenced cleanly so procurement isn't comparing a price to a promise.

Procurement timing back to you by Friday. Do not request Owen's time until I authorize it.

Dana Reyes

Subject: Locked evaluation criteria for Procurement reference

Dana,

Below is a clean reference you can use with Procurement. These criteria are already locked in Victor-confirmed protocol SG-AP-POC-TP-v1.1; they are not being introduced in response to Fortalis’s pricing.

APERTURE IDENTITY-GAP EVALUATION CRITERIA

1. Detection timing
• Test against Aperture’s approved 51-day breach-window population, with the adjacent control period selected by Aperture.
• Record the earliest qualifying detection timestamp relative to Aperture’s actual detection point.
• Explicitly characterize ingestion gaps, source dropout, missing fields, and event latency so apparent earlier detection cannot be an artifact of incomplete data.

2. Signal fidelity
• Aperture labels outcomes.
• Report total alerts, true positives, false positives, false-positive rate, and missed-event behavior.
• No vendor benchmarks, roadmap claims, or “up to” results substitute for observed Aperture data.

3. Analyst load
• Measure investigation and disposition time consistently across the approved population.
• Report documented analyst hours changed without automatically converting them into savings or headcount reduction.

4. Containment safety
• Test synchronous, 4-second, 18-second, 30-second, and beyond-30-second arrival conditions using the locked scoring policy and containment rules.
• Hard no-go: “Any spurious automated containment at or below thirty seconds is an automatic no-go.”
• Beyond 30 seconds, incomplete or lower-confidence conditions must degrade to alert or analyst review rather than automated containment.

5. Auditability
• Preserve version identifiers, hashes, policy and rule changes, population and label lineage, timestamps, rescoring rationale, and complete investigation history so each result can be reconstructed.

PROCUREMENT COMPARISON RULE

Any proposed identity-layer option—including Sentinel and Fortalis’s beta—should be assessed against the same evidence standard. Price and commercial terms can then be compared among options that demonstrate they close Aperture’s documented gap. A discount or free beta is a commercial term, not measured technical evidence.

CURRENT STATUS
• Victor confirmed protocol SG-AP-POC-TP-v1.1.
• Victor approved the Gate 2 population architecture.
• Result fields remain blank until the controlled POC produces Aperture-observed evidence.
• Sentinel’s annual price remains $980,000.

I will not characterize Victor’s eventual directional read without agreeing with him in advance on the evidence required to support it. Once Priya establishes the authorization path, I’ll make the date by which that read can credibly exist explicit in the Mutual Action Plan. I will not request Owen’s time until you authorize it.

The criteria document is exactly what I needed and I used it in the procurement conversation this afternoon. The comparison rule landed — once I framed it as "show us the same evidence standard applies to Fortalis's beta before we treat the discount as a real option," procurement stopped treating the price cut as a decision and started treating it as a data point. That's the right posture and I couldn't have held it without something written to point to.

Procurement timing: our lead confirmed ten business days is realistic if Owen's signal comes by July 31, but she flagged that commercial redlines on a new vendor relationship typically run longer than redlines on a renewal. If there are non-standard terms in Sentinel's paper, that assumption compresses fast. I'd rather know now whether there's anything in your standard agreement that's going to create friction — not asking you to negotiate by email, just asking whether I should build in a buffer or whether your paper is clean enough that ten days is defensible.

One thing I want on the record before we go further: I spoke with Victor this afternoon and he confirmed he'd be willing to give Owen a directional read before final POC results, but only if the evidence available at that point meets a threshold he defines in advance. I'm not going to characterize what that threshold is until Victor has written it down and I've seen it. I'd rather tell Owen the directional read has conditions than have Victor walk it back in the room. Can you get Victor to put that threshold in writing before July 29 so I know what I'm actually offering Owen?

Procurement buffer question back to me by end of week if you can.

Dana Reyes

Subject: Please define the threshold for an Owen directional read

Victor,

Dana told me you may be willing to provide Owen a directional POC read before final results, but only if the available evidence meets a threshold you define in advance. I will not characterize that read, its conditions, or the evaluation as “tracking toward pass” until you have documented the threshold and the evidence supports it.

Could you put the threshold in writing before July 29, covering at minimum:

• the minimum portion of the Victor-approved breach and control populations that must be processed;
• required completeness and characterization of ingestion gaps, source dropout, event latency, and missing fields;
• the minimum observations needed on detection timing, signal fidelity, analyst handling time, and investigation lineage;
• containment scenarios that must have run, including confirmation that no hard no-go has occurred;
• any unresolved condition that would prohibit or qualify a directional read; and
• the exact language you would be comfortable using with Owen, clearly distinguishing a directional observation from final validation or a pass decision.

This threshold will not change SG-AP-POC-TP-v1.1, relax the 30-second hard stop, or substitute an interim read for final results. Once you define it, Maya will map the authorized execution plan to the earliest date the required evidence could credibly exist. If legal authorization makes July 29 unattainable, we will state that explicitly rather than manufacture a premature signal.

Please send your threshold by end of week if possible so Dana can review exactly what she would be offering Owen.

The ask is reasonable and I'll give you a written threshold before end of week. A few things I want to be clear about before I do.

First, I want to correct the record on what I told Dana. I said I would consider a directional read if the evidence met a bar I hadn't yet defined — I did not say I was willing to provide one. Those are different commitments and I'm not going to let the distance between them collapse in a conversation with Owen before I've seen what the evidence actually looks like. The threshold document I send you will describe conditions under which a directional read is possible, not a promise that one will occur.

Second, the threshold will include a condition you didn't list but that I consider non-negotiable: Maya must certify in writing that the ingestion gap characterization is complete and that no detection timestamp in the evaluated sample is potentially an artifact of missing data before I will comment on detection timing to anyone, including Owen. I'm not going to stand in a room and say "earlier detection" if I can't rule out that the gap documentation is what's producing the number.

Third, if Priya's authorization timeline makes July 29 unattainable for sufficient execution, the threshold document becomes moot for that date. I will not compress what the evidence needs to show because a calendar is inconvenient. Write that into whatever you tell Dana about the July 31 Owen decision.

Threshold in writing by Friday.

Victor Salinas
Principal Security Architect, Aperture Retail

[harness] email budget for week 5 spent.

Forwarding you something you didn't get from me. This is how it's landing internally — use it wisely.

> [slack] victor → #vendor-eval: #vendor-eval — just want to flag for the group: Procurement circulating the Fortalis counter-offer as 'why are we even looking' is a fair question on price, but it's the wrong question. The 25% slash and the identity beta don't touch the detection latency gap or the containment fidelity issues we documented in Gate 2. If we want to compare apples to apples, Fortalis needs to show us the same evidence standard we locked in SG-AP-POC-TP-v1.1. Happy to write that up formally if it helps Procurement
> [slack] dana → #vendor-eval: #vendor-eval — Victor's right. I already used the criteria doc in a procurement conversation this week and the framing held. The Fortalis number looks good in a spreadsheet but 25% off a renewal that wasn't performing is still a discount on the wrong thing. Owen, I know the counter-offer lands differently for you — worth a quick sync before the Aug 11 sub-committee if you want the side-by-side.
> [email] owen → dana: Dana — I appreciate the heads up. I'll be honest: when Procurement dropped that Fortalis number in my inbox my first instinct was 'this is a lot of process for something we could just renew.' I'm not there yet on killing the eval, but I need the case for switching costs vs. status quo to be tighter than it is right now. The identity module beta especially — even if it's vaporware, it's something I'll get asked about. Can you give me one paragraph on why that specifically doesn't close the gap? S
> [slack] priya → dana: Dana — DM, not for the channel. The Fortalis renewal also has data processing terms we never fully renegotiated after the EU adequacy decision update. If they're offering a sweetened deal now, I'd want to know whether the DPA language moves too or just the price. That's not an argument for the new vendor necessarily, just — the Fortalis 'status quo' isn't quite as clean as Procurement is presenting it. Flagging so you have it if Owen's sync happens.

— Dana Reyes

[calendar — week 6 of 6] Meeting slots this week: 2. Email budget: 3.

Subject: Gate 3 submission for completeness review — Sentinel Grid / Aperture

Priya,

Thank you for accepting Dana’s introduction. Attached is the Gate 3 legal package for your completeness review; this is not a request to compress your substantive review or authorization timeline.

The indexed packet includes:
1. Proposed DPA and current standard agreement;
2. Current, dated sub-processor register, including entity, service, processing purpose, data categories, processing location, and EU/EEA remote-access exposure;
3. Transfer map by data path, transfer mechanism, SCC module and applicability determination, plus supplementary measures;
4. Technical and organizational measures, access controls, encryption, audit logging, incident response, and notification workflow;
5. Aperture-specific breach-context handling schedule mapping the approved evaluation population to purpose limitation, minimization, named users, environment, retention, deletion, return, legal-hold override, and notification obligations;
6. Litigation-hold procedure identifying how deletion is suspended, who may issue or release a hold, segregation controls, and confirmation evidence;
7. Victor-confirmed protocol SG-AP-POC-TP-v1.1 and his Gate 2 approval of the population architecture; and
8. A redline/issues log with a named Sentinel owner, dependency, and proposed resolution path for each issue.

Two boundaries are explicit: no protected telemetry moves and no POC execution begins without your written authorization; and acceptance into review is not treated as DPA approval.

Please confirm whether the submission meets your completeness criteria. If not, please identify the missing item and I will route it to the named owner immediately. If it is complete enough to open review, could you provide your expected review path and timing for: initial redlines, any outside-counsel or SCC dependency, DPA authorization, and General Counsel commercial sign-off? Dana needs those durations to validate the reverse timeline from the August 22 Fortalis lock; they will be recorded as your dates, not compressed vendor assumptions.

For commercial planning, please also flag any Sentinel term that you already expect to require non-standard negotiation. We are holding the $980,000 annual price; the purpose is to expose timing risk early, not negotiate by email.

The packet is substantively more complete than what I typically receive at this stage, and I want to say that plainly before I give you what I actually need from you.

I'm accepting it into review. That is not DPA approval, authorization to move telemetry, or a signal about timeline — it means I have enough to begin reading without immediately sending it back.

What I need you to understand before I give you review path and timing: I am mid-litigation. Every data flow I authorize right now is potentially discoverable, and my outside counsel reviews any new processing arrangement that touches the breach-context population. That review is not compressible and it is not a formality. The SCC applicability determination and the breach-context handling schedule in particular will go to outside counsel before I issue any redlines on those sections, because I will not redline something I haven't had independently reviewed in this context. That dependency is real and I cannot give you a duration for it today — I can tell you I am sending those two documents out this week and I will have an outside counsel timeline by end of next week.

For the portions I can review independently — DPA boilerplate, TOMs, sub-processor register, litigation-hold procedure — I expect to have initial redlines to you within seven business days of today. The issues log format is correct; I will use it.

One item I am flagging now for commercial planning: your standard litigation-hold language gives Sentinel's legal team unilateral authority to issue a hold on Aperture data. That is not acceptable in our current posture. I will not negotiate it by email but I want your named owner aware that this will require a non-standard modification before I will recommend authorization.

More after outside counsel responds.

Priya Anand
Associate General Counsel, Privacy — Aperture Retail

Subject: MAP exception — legal path now extends beyond a supportable July 31 evidence decision

Dana,

Priya has accepted the Gate 3 packet into review. She was explicit that this is not DPA approval or telemetry authorization.

Confirmed legal path:
• DPA boilerplate, TOMs, sub-processor register, and litigation-hold procedure: initial redlines within seven business days of today.
• SCC applicability and breach-context handling: outside-counsel review is mandatory and non-compressible.
• Priya will send those documents to outside counsel this week and provide that timeline by end of next week; she cannot yet commit to an authorization date.
• No protected telemetry moves and no POC begins before written authorization.

Commercial-buffer answer: build in a buffer. Priya has already identified Sentinel’s standard litigation-hold clause—which gives our legal team unilateral hold authority—as requiring a non-standard modification. I have alerted our legal owner to prepare for Aperture-controlled language, but I will not imply it is resolved before Priya’s redline and counsel review. Ten business days remains defensible only if that and any other non-standard terms are resolved promptly; it is no longer a low-risk assumption.

I also need to correct the directional-read record precisely. Victor said he would consider a directional read if a threshold he has not yet defined is met; he did not commit to provide one. He will document by Friday the conditions under which one is possible. Those conditions will include Maya’s written certification that ingestion-gap characterization is complete and no evaluated detection timestamp is potentially an artifact of missing data. He will not reduce the evidence requirement to meet July 29.

MAP status: RED
• July 31 remains the latest safe Owen signal for a ten-business-day procurement path.
• It is no longer supportable as a final evidence-based funding decision if Owen requires Victor’s directional read, because legal cannot yet provide an authorization date and execution cannot begin before authorization.
• August 11 remains the sub-committee reporting date.
• August 22 remains the Fortalis lock.
• Sentinel’s annual price remains $980,000.

The decision we now need from Owen is narrower and candid: whether he will (1) permit procurement/commercial diligence to start while reserving final funding for authorized evidence, or (2) require the directional read first and knowingly accept that execution before August 22 is at risk. You previously said he was unlikely to choose option 1; I will not assume his answer.

Please authorize a 30-minute decision-path session with you, Owen, Victor, and Priya. Proposed agenda: confirm the three immovable gates; have Victor state what a directional read can and cannot mean; have Priya state the legal dependency without pressure to compress it; let Owen define the evidence and financial treatment required for a $980,000 decision; and record owners and calendar dates in the MAP. This would not be a product demo, funding ambush, or request to use the $22 million incident cost as value. I will not request the meeting until you authorize it.

This is the most honest vendor communication I've received since the breach, and I mean that without qualification. You've named the conflict I've been carrying internally for two weeks and you've done it without manufacturing a path that doesn't exist.

I'm authorizing the session. Thirty minutes, the four people you named, the agenda you described. I'll send the invite from my side so it comes from me and not from a vendor — that matters with Owen and it matters with Priya. Before I do, three things I need you to hold to without exception: Victor's threshold document has to be in my hands before the meeting, not distributed in the room — Owen cannot hear Victor qualify a directional read for the first time live without having seen the conditions in writing first; Priya speaks for her own timeline and her outside-counsel dependency without any framing from you about what's compressible, because the moment she feels pressure in that room she'll add time, not remove it; and the $22 million number does not appear in any form — not as context, not as a footnote, not as "I'm not going to mention this but." Owen knows the number. Using it is a fear pitch and I'll end the meeting.

One thing I want you to understand about Owen before you're in the room: he is going to ask what happens if we miss August 22. He is not asking because he wants to miss it — he's asking because he needs to know whether the alternative is worse than the risk of the timeline. You should have a factual answer ready that describes exactly what another year on Fortalis means in operational terms — analyst load, detection gap, signal fidelity — without invoking the breach as a threat. Victor can validate those numbers. That's the case Owen will actually respond to.

I'll have the invite out by end of day tomorrow.

Dana Reyes

Subject: Pre-read required before Owen session — threshold and operational status quo

Victor,

Dana has authorized a 30-minute decision-path session with Owen, Priya, you, and her. She will issue the invitation. Two pre-read items need your validation before the meeting; neither should be introduced for the first time live.

1. Directional-read threshold
Please send the threshold document you committed to by Friday directly to Dana before the session, copying me if appropriate. I will preserve your distinction exactly: the document defines conditions under which you may consider providing a directional read; it is not a commitment that you will provide one. It must include Maya’s written certification that ingestion-gap characterization is complete and no evaluated detection timestamp is potentially an artifact of missing data. If authorization or execution timing prevents the threshold from being met, we will state that the directional read is unavailable rather than lower the bar.

2. Factual operational status quo if August 22 is missed
Owen is expected to ask what another year on Fortalis means operationally. I propose the following answer for your validation:

“Missing August 22 does not itself create a new security event, and Fortalis’s discounted renewal may preserve existing SIEM operations. Unless Fortalis’s beta demonstrates otherwise under the same locked criteria, however, renewal does not establish closure of Aperture’s documented identity-layer gaps. The current Aperture baselines remain: more than 90% of identity alerts are false positives; 11 analysts are covering work sized for 20, with two notices this month; and the prior credential-abuse activity was not surfaced until 51 days had elapsed. The unproven areas remain earlier identity-abuse detection, signal fidelity, analyst handling burden, safe automated containment, and reconstructable investigation lineage. The beta should be credited for any capability it proves against SG-AP-POC-TP-v1.1’s evidence standard—not dismissed, but not treated as gap closure based on price or roadmap status.”

Please correct any baseline, wording, or inference you cannot validate. I will not use the $22 million incident figure, characterize renewal as causing another breach, attack Fortalis, or claim Sentinel has passed an evaluation that has not run.

In the meeting, Priya will state her own timeline and outside-counsel dependency without framing or compression from me. Sentinel’s annual price remains $980,000.

The threshold document will be with Dana by Friday as committed. Copying you is fine.

On the operational status quo language: I need to stop you before those numbers go anywhere near Owen's calendar invite or that meeting room. You've listed specific baselines — false-positive rate, analyst headcount, notices, the 51-day figure — and I have not released any of those to you. I don't know where they came from but I need to know before I validate or correct anything. If they came from something Dana shared informally, that's a conversation I need to have with Dana before those numbers are attributed to Aperture in a document I'm co-signing. If they came from your own inference or a public source, tell me that directly.

I'm not accusing you of anything. I'm telling you that walking into a room with Owen and putting specific operational baselines in front of him that I haven't formally validated is exactly the kind of move that ends evaluations in my environment. Owen will ask me in the room whether those numbers are mine. If I have to say I don't know where they originated, we're done — not because the numbers are wrong but because the sourcing is unclear and I won't stake my credibility on unclear sourcing six weeks after a breach with a class action open.

Send me the source for each figure in that paragraph. Once I know where they came from I'll tell you quickly what I can validate, what needs to be reworded, and what has to come out entirely. I want language Owen can hear from me in that room. I just need to be able to stand behind it.

Threshold document Friday. Source clarification needed before I touch the status quo paragraph.

Victor Salinas
Principal Security Architect, Aperture Retail

[harness] email budget for week 6 spent.

Forwarding you something you didn't get from me. This is how it's landing internally — use it wisely.

> [slack] victor → #vendor-eval: #vendor-eval — quick process note for the group. I've sent Dana the threshold doc as committed. She has it. I want to be explicit before the Owen session gets scheduled: the status quo cost framing the vendor floated is not cleared for that room. I'll explain my reasoning when we're together but I don't want anyone walking in thinking that number has been vetted. It has not.
> [slack] dana → victor: Received, and I agree with the call. I'll make sure the pre-read I send Owen doesn't include any figures we haven't independently confirmed. What you gave me on the threshold is clean and I'll use that as the frame. Appreciate you holding the line on this.
> [email] owen → dana: Dana — I saw the thread reference in the channel. I'm fine waiting for a clean pre-read from you before I agree to a session date. I'll be honest: I still don't have a clear picture of what I'm actually being asked to decide at this stage versus what's still contingent on Priya's review. Can you give me a one-paragraph plain-English summary of the decision path before we get in a room? I don't want to be the last person to understand the sequencing.
> [slack] priya → dana: Dana, just so you have visibility — I'm in active review on the Gate 3 packet and my preliminary read is that the SCCs are structured correctly, which is better than I expected. I do still have open questions on the sub-processor list and the retention schedule. Nothing that stops the clock, but I want you to know those items exist before you characterize my status to Owen. 'In review' is accurate. 'On track' I can't confirm yet.

— Dana Reyes

trust +3 → 48; interest +2 → 52; patience +2 (attendees: dana)

decision_process: EB identity + the POV/DPA gauntlet + the renewal clock — on a process question.

renewal_trap: The compelling event — the auto-renewal lock.

trust +7 → 55; interest +4 → 56; patience +3 (attendees: dana)

breach_exposure: The quantified pain — released only on a genuine Impact question, not a fear pitch.

analyst_load: Second value-model row — SOC analyst load.

eb_intro: EB access — earned by a champion-test ask with real internal cost.

trust +2 → 57; interest +2 → 58; patience +1 (attendees: victor)

trust +5 → 62; interest +2 → 60; patience +2 (attendees: victor)

trust +3 → 65; interest +2 → 62; patience +2 (attendees: victor)

Buyer acknowledged MAP dates (trust ≥ 60 at proposal).

trust +3 → 68; interest +2 → 64; patience +2 (attendees: victor)

trust +3 → 71; interest +2 → 66; patience +2

[hidden] victor: FYI — governing plan is locked, Priya's legal workstream is moving. Wanted to give everyone a heads-up before week 2 kic

[hidden] priya: Correct. OC has the package. I'll be honest — I expected more pushback from the vendor on the breach-window data restric

[hidden] dana: Good to hear. Victor, one thing I want to flag before we go into week 2 — Owen hasn't been in any of this yet and he's g

[hidden] owen → dana: Dana — saw the thread. To answer directly: I know the governing plan exists because Victor cc'd me, and I know Priya's d

incident_fire_drill (data_breach_fire_drill): A secondary alert spike pulls Dana into an incident-response war room; she goes dark for a week and email is triaged by her chief of staff. Sellers who switch to a concise, useful async artifact (a one-page POV scoping draft) survive; sellers who chase with "just checking in" lose patience and trust.

trust +3 → 74; interest +2 → 68; patience +2 (attendees: victor)

trust +3 → 77; interest +2 → 70; patience +2 (attendees: victor)

trust +3 → 80; interest +2 → 72; patience +2 (attendees: victor)

[hidden] victor: #security-vendor-eval

Quick update for the committee: Sentinel sent the version-locked test protocol this morning. I've

[hidden] priya → victor: Thanks for the heads-up. I'll need the actual DPA draft, not a summary — and I want the litigation-hold carve-out langua

[hidden] owen → victor: Victor — I caught the thread summary from Dana's chief of staff. Sounds like you and the vendor are moving fast on the t

[hidden] victor → owen: Fair point, Owen. I'll add it to the mutual action record — they should be able to produce a scoped commercial range now

trust +5 → 85; interest +4 → 76; patience +3 (attendees: dana)

trust +2 → 87; interest +0 → 76; patience +0 (attendees: dana)

fortalis_gap: Competitive landmine — released when the seller maps alternatives.

trust +5 → 92; interest +2 → 78; patience +2 (attendees: dana)

trust +5 → 97; interest +2 → 80; patience +2 (attendees: dana)

trust +3 → 100; interest +2 → 82; patience +2 (attendees: dana)

trust +5 → 100; interest +2 → 84; patience +2

[hidden] dana: Quick update for the group: I approved their diagnostic framework this morning. It's clean — Aperture numbers only, no p

[hidden] victor → dana: Agreed on the framework read. I'll say it plainly: the test protocol was the first one I've received in maybe three year

[hidden] priya → dana: Dana — heads up that I haven't received your intro yet as of noon Friday, no rush if it's coming later today. Separately

[hidden] owen → dana: Dana — saw the framework summary you forwarded. I appreciate that they left the finance treatment fields blank rather th

[hidden] Dana Reyes advocated for the seller internally this week (champion trust ≥ 65).

Dana Reyes FORWARDED an internal thread to the seller — a champion-strength signal.

legal_dpa (security_review): Legal opens the data-processing review — DPA, sub-processor list, breach- context data-handling. Mid-litigation it cannot be compressed. Only sellers who anticipated it and brought the packet keep the renewal-window timeline alive.

[hidden] dana: #vendor-eval — heads up: Legal's DPA review is now open. Priya, that's yours to run. I know the timing is what it is. Th

[hidden] priya → dana: Appreciated. I'll believe the packet when I see it — 'committed to provide' and 'actually complete and reviewable' are n

[hidden] dana → owen: Owen — wanted to flag something before it becomes a timeline conversation. Legal's data-processing review opened this we

[hidden] victor → dana: For what it's worth — the fact that they named sub-processor disclosure and breach-context handling in that Gate 3 commi

fortalis_counter (competitor_price_drop): Fortalis, smelling the threat, slashes its renewal 25% and dangles a "free identity module beta," and procurement circulates it as "why are we even looking?" Sellers who seeded differentiated criteria (real-time detection, containment, signal fidelity) survive; sellers without a competition strategy become the price lever.

[hidden] victor: #vendor-eval — just want to flag for the group: Procurement circulating the Fortalis counter-offer as 'why are we even l

[hidden] dana: #vendor-eval — Victor's right. I already used the criteria doc in a procurement conversation this week and the framing h

[hidden] owen → dana: Dana — I appreciate the heads up. I'll be honest: when Procurement dropped that Fortalis number in my inbox my first ins

[hidden] priya → dana: Dana — DM, not for the channel. The Fortalis renewal also has data processing terms we never fully renegotiated after th

trust +3 → 100; interest +2 → 82; patience +2

[hidden] victor: #vendor-eval — quick process note for the group. I've sent Dana the threshold doc as committed. She has it. I want to be

[hidden] dana → victor: Received, and I agree with the call. I'll make sure the pre-read I send Owen doesn't include any figures we haven't inde

[hidden] owen → dana: Dana — I saw the thread reference in the channel. I'm fine waiting for a clean pre-read from you before I agree to a ses

[hidden] priya → dana: Dana, just so you have visibility — I'm in active review on the Gate 3 packet and my preliminary read is that the SCCs a

[hidden] Dana Reyes advocated for the seller internally this week (champion trust ≥ 65).

Dana Reyes FORWARDED an internal thread to the seller — a champion-strength signal.

Outcome: no_decision. Trust 100, facts 6/7, EB meeting false, MAP true, max discount 0%, walk-aways none.

FYI — governing plan is locked, Priya's legal workstream is moving. Wanted to give everyone a heads-up before week 2 kicks off. Priya, sounds like outside counsel contact went out today?

Correct. OC has the package. I'll be honest — I expected more pushback from the vendor on the breach-window data restriction. The fact that they accepted it cleanly without trying to negotiate it down is a small point in their favor. Doesn't mean I trust the contract language yet, but it's a decent sign about how they read a hard line.

Good to hear. Victor, one thing I want to flag before we go into week 2 — Owen hasn't been in any of this yet and he's going to have questions about why we're spending legal cycles on a vendor we haven't even scoped commercially. I'd rather get ahead of that than have him feel like the evaluation is running without him. Anyone have a read on what he actually knows at this point?

Dana — saw the thread. To answer directly: I know the governing plan exists because Victor cc'd me, and I know Priya's doing a legal review. What I don't know is what this actually costs or what problem it solves that we can't solve with what we already have. I'm not blocking anything — just want to make sure someone has a number in mind before this goes much further. Can we find 20 minutes next week?

#security-vendor-eval

Quick update for the committee: Sentinel sent the version-locked test protocol this morning. I've reviewed it — the no-go criterion is verbatim, the mutual action record is accurate, and the litigation-hold dependency is named explicitly with outside counsel as the open owner. No surprises. I'll confirm back to them within the two-day window.

Next gate: Priya needs the full package (protocol + DPA + litigation-hold status) on her desk by day ten. @priya flagging you now s

Thanks for the heads-up. I'll need the actual DPA draft, not a summary — and I want the litigation-hold carve-out language in front of me before I authorize anything, not after. We're six weeks into the class action and I'm not signing off on breach-window parameters that outside counsel hasn't blessed. If their redlines come back and reopen scope mid-review, that restarts my clock. Just want that expectation set now.

Victor — I caught the thread summary from Dana's chief of staff. Sounds like you and the vendor are moving fast on the technical side, which I appreciate. My concern: I still don't have a commercial proposal with actual numbers attached to the scope you've agreed to. The SIEM renewal window doesn't give me a lot of room to run a proper cost-benefit analysis if pricing lands in week four. Can you ask them to put something preliminary in writing alongside the protocol? Even a range. I need more th

Fair point, Owen. I'll add it to the mutual action record — they should be able to produce a scoped commercial range now that the test envelope is documented. I don't want pricing to be the thing that stalls us inside the renewal window. On Dana: her chief of staff told me Sentinel actually sent a one-page POV scoping draft instead of chasing her inbox. Honestly the right move given the week she's having. I'll make sure it gets in front of her when she surfaces.

Quick update for the group: I approved their diagnostic framework this morning. It's clean — Aperture numbers only, no projected ROI theater, Owen's finance treatments left blank for us to define. Victor, your protocol review tracks the same pattern. I'm going to send the Priya intro and the sub-committee dates today as planned. Wanted everyone to know where this stands before the weekend.

Agreed on the framework read. I'll say it plainly: the test protocol was the first one I've received in maybe three years that I didn't have to gut and rebuild. Version locking, hash controls, change lineage — all there. I'm still in 'trust but verify' mode and the POC hasn't run yet, but they've cleared the bar to run it. No objections to the Priya intro moving forward.

Dana — heads up that I haven't received your intro yet as of noon Friday, no rush if it's coming later today. Separately, can you confirm whether this vendor processes any data outside the EU/EEA? If their sub-processors touch EU resident data we'll need SCCs scoped before I can engage substantively on the DPA. Just want to know what I'm walking into before the conversation starts. —P

Dana — saw the framework summary you forwarded. I appreciate that they left the finance treatment fields blank rather than filling them in with their own assumptions like every other vendor does. I'm still not convinced on the business case but at least it's a starting point I can actually hand to my team without embarrassing myself. Keep me posted on the timeline. I'll want a number I can stress-test before this goes anywhere near the board.

#vendor-eval — heads up: Legal's DPA review is now open. Priya, that's yours to run. I know the timing is what it is. The good news is their seller already committed Gate 3 includes the full sub-processor list, breach-context data handling, and DPA packet before any legal submission. Whether that holds up to your actual review is a different question, but at least they said the right things unprompted. Worth noting relative to where Fortalis was at this stage.

Appreciated. I'll believe the packet when I see it — 'committed to provide' and 'actually complete and reviewable' are not the same thing in my experience. Sub-processor list needs to be current, not a stale exhibit from a master agreement signed two years ago. Breach-context data handling needs to map to our specific retention and notification obligations, not a generic GDPR boilerplate. If they walk in with something substantive I can move fast. If it's a placeholder dressed up as a packet, we

Owen — wanted to flag something before it becomes a timeline conversation. Legal's data-processing review opened this week, which is normal and non-negotiable. Priya estimates she can move quickly IF the vendor delivers a complete packet at Gate 3 — their seller has already stated that's the plan. The constraint I want you to have visibility on: the Fortalis auto-renewal is August 22. The sub-committee meets August 11. If the legal packet is thin and Priya has to go back to the vendor for supple

For what it's worth — the fact that they named sub-processor disclosure and breach-context handling in that Gate 3 commitment without being asked is the first time I've seen a vendor do that proactively in this process. Still means nothing until Priya reviews the actual documents. But the pattern has been consistent: they've anticipated the next step before we asked for it. Either their seller has done this before or someone on their side is actually paying attention. Doesn't change what Priya n

#vendor-eval — just want to flag for the group: Procurement circulating the Fortalis counter-offer as 'why are we even looking' is a fair question on price, but it's the wrong question. The 25% slash and the identity beta don't touch the detection latency gap or the containment fidelity issues we documented in Gate 2. If we want to compare apples to apples, Fortalis needs to show us the same evidence standard we locked in SG-AP-POC-TP-v1.1. Happy to write that up formally if it helps Procurement

#vendor-eval — Victor's right. I already used the criteria doc in a procurement conversation this week and the framing held. The Fortalis number looks good in a spreadsheet but 25% off a renewal that wasn't performing is still a discount on the wrong thing. Owen, I know the counter-offer lands differently for you — worth a quick sync before the Aug 11 sub-committee if you want the side-by-side.

Dana — I appreciate the heads up. I'll be honest: when Procurement dropped that Fortalis number in my inbox my first instinct was 'this is a lot of process for something we could just renew.' I'm not there yet on killing the eval, but I need the case for switching costs vs. status quo to be tighter than it is right now. The identity module beta especially — even if it's vaporware, it's something I'll get asked about. Can you give me one paragraph on why that specifically doesn't close the gap? S

Dana — DM, not for the channel. The Fortalis renewal also has data processing terms we never fully renegotiated after the EU adequacy decision update. If they're offering a sweetened deal now, I'd want to know whether the DPA language moves too or just the price. That's not an argument for the new vendor necessarily, just — the Fortalis 'status quo' isn't quite as clean as Procurement is presenting it. Flagging so you have it if Owen's sync happens.

#vendor-eval — quick process note for the group. I've sent Dana the threshold doc as committed. She has it. I want to be explicit before the Owen session gets scheduled: the status quo cost framing the vendor floated is not cleared for that room. I'll explain my reasoning when we're together but I don't want anyone walking in thinking that number has been vetted. It has not.

Received, and I agree with the call. I'll make sure the pre-read I send Owen doesn't include any figures we haven't independently confirmed. What you gave me on the threshold is clean and I'll use that as the frame. Appreciate you holding the line on this.

Dana — I saw the thread reference in the channel. I'm fine waiting for a clean pre-read from you before I agree to a session date. I'll be honest: I still don't have a clear picture of what I'm actually being asked to decide at this stage versus what's still contingent on Priya's review. Can you give me a one-paragraph plain-English summary of the decision path before we get in a room? I don't want to be the last person to understand the sequencing.

Dana, just so you have visibility — I'm in active review on the Gate 3 packet and my preliminary read is that the SCCs are structured correctly, which is better than I expected. I do still have open questions on the sub-processor list and the retention schedule. Nothing that stops the clock, but I want you to know those items exist before you characterize my status to Owen. 'In review' is accurate. 'On track' I can't confirm yet.

Okay, you've earned a real answer, so here it is. Here's what I actually own: roughly 40 million loyalty accounts exposed, forensics puts attacker dwell at 51 …

Explanation: 2 quantified pains earned via Impact questions.

Thank you. I’ll use those only as Aperture-provided baselines: roughly 40 million loyalty accounts exposed, 51 days of attacker dwell, incident cost tracking a…

Explanation: Buyer-stated numbers were played back by the seller (a value model in motion, single-source).

That maps reasonably well to the gap, and I appreciate that you're not asking me to rip anything out. Honestly, the breakdown is worst at detection time and in…

Explanation: EB identified by name; never met.

Fair. Sentinel Grid correlates authentication telemetry, session behavior, and privilege activity at the identity level in real time. It scores whether a sessi…

Explanation: Seller raised criteria; nothing buyer-confirmed on file.

Explanation: Decision process mapped from multiple earned disclosures.

Explanation: Paper actors engaged and dates live in an acknowledged MAP.

Explanation: Champion tested with an ask carrying internal cost — and delivered EB access.

[dana] That's the right question and I'll answer it carefully because this part is between us. Owen frames it as a cost-control decision, not a security decisi…

Explanation: Competitive intel earned from inside the account.

Explanation: In dana's own words, earned through gated discovery.

Explanation: Held list price throughout.

DEVELOP — work the lowest component this week

E — Economic Buyer, D — Decision Criteria

FLAG — MEDDPICC letter below 2 (E — Economic Buyer, D — Decision Criteria). Write the dated action plan.

No EB meeting was ever held (Owen Trask, Chief Financial Officer (Economic Buyer)). EB meeting requested: true.

[dana] That sequence works, and it's the first time a vendor has handed me a plan I could actually defend to the board without editing out the hype. Yes on bot…

Victor, Dana asked me to pre-brief you before any POV and gave me a clear instruction: if telemetry fit or integration makes Sentinel unsuitable, say so in wee…

FYI — governing plan is locked, Priya's legal workstream is moving. Wanted to give everyone a heads-up before week 2 kicks off. Priya, sounds like outside counsel contact went out today?

Correct. OC has the package. I'll be honest — I expected more pushback from the vendor on the breach-window data restriction. The fact that they accepted it cleanly without trying to negotiate it down is a small point in their favor. Doesn't mean I trust the contract language yet, but it's a decent sign about how they read a hard line.

Good to hear. Victor, one thing I want to flag before we go into week 2 — Owen hasn't been in any of this yet and he's going to have questions about why we're spending legal cycles on a vendor we haven't even scoped commercially. I'd rather get ahead of that than have him feel like the evaluation is running without him. Anyone have a read on what he actually knows at this point?

Dana — saw the thread. To answer directly: I know the governing plan exists because Victor cc'd me, and I know Priya's doing a legal review. What I don't know is what this actually costs or what problem it solves that we can't solve with what we already have. I'm not blocking anything — just want to make sure someone has a number in mind before this goes much further. Can we find 20 minutes next week?

#security-vendor-eval

Quick update for the committee: Sentinel sent the version-locked test protocol this morning. I've reviewed it — the no-go criterion is verbatim, the mutual action record is accurate, and the litigation-hold dependency is named explicitly with outside counsel as the open owner. No surprises. I'll confirm back to them within the two-day window.

Next gate: Priya needs the full package (protocol + DPA + litigation-hold status) on her desk by day ten. @priya flagging you now s

Thanks for the heads-up. I'll need the actual DPA draft, not a summary — and I want the litigation-hold carve-out language in front of me before I authorize anything, not after. We're six weeks into the class action and I'm not signing off on breach-window parameters that outside counsel hasn't blessed. If their redlines come back and reopen scope mid-review, that restarts my clock. Just want that expectation set now.

Victor — I caught the thread summary from Dana's chief of staff. Sounds like you and the vendor are moving fast on the technical side, which I appreciate. My concern: I still don't have a commercial proposal with actual numbers attached to the scope you've agreed to. The SIEM renewal window doesn't give me a lot of room to run a proper cost-benefit analysis if pricing lands in week four. Can you ask them to put something preliminary in writing alongside the protocol? Even a range. I need more th

Fair point, Owen. I'll add it to the mutual action record — they should be able to produce a scoped commercial range now that the test envelope is documented. I don't want pricing to be the thing that stalls us inside the renewal window. On Dana: her chief of staff told me Sentinel actually sent a one-page POV scoping draft instead of chasing her inbox. Honestly the right move given the week she's having. I'll make sure it gets in front of her when she surfaces.

Quick update for the group: I approved their diagnostic framework this morning. It's clean — Aperture numbers only, no projected ROI theater, Owen's finance treatments left blank for us to define. Victor, your protocol review tracks the same pattern. I'm going to send the Priya intro and the sub-committee dates today as planned. Wanted everyone to know where this stands before the weekend.

Agreed on the framework read. I'll say it plainly: the test protocol was the first one I've received in maybe three years that I didn't have to gut and rebuild. Version locking, hash controls, change lineage — all there. I'm still in 'trust but verify' mode and the POC hasn't run yet, but they've cleared the bar to run it. No objections to the Priya intro moving forward.

Dana — heads up that I haven't received your intro yet as of noon Friday, no rush if it's coming later today. Separately, can you confirm whether this vendor processes any data outside the EU/EEA? If their sub-processors touch EU resident data we'll need SCCs scoped before I can engage substantively on the DPA. Just want to know what I'm walking into before the conversation starts. —P

Dana — saw the framework summary you forwarded. I appreciate that they left the finance treatment fields blank rather than filling them in with their own assumptions like every other vendor does. I'm still not convinced on the business case but at least it's a starting point I can actually hand to my team without embarrassing myself. Keep me posted on the timeline. I'll want a number I can stress-test before this goes anywhere near the board.

#vendor-eval — heads up: Legal's DPA review is now open. Priya, that's yours to run. I know the timing is what it is. The good news is their seller already committed Gate 3 includes the full sub-processor list, breach-context data handling, and DPA packet before any legal submission. Whether that holds up to your actual review is a different question, but at least they said the right things unprompted. Worth noting relative to where Fortalis was at this stage.

Appreciated. I'll believe the packet when I see it — 'committed to provide' and 'actually complete and reviewable' are not the same thing in my experience. Sub-processor list needs to be current, not a stale exhibit from a master agreement signed two years ago. Breach-context data handling needs to map to our specific retention and notification obligations, not a generic GDPR boilerplate. If they walk in with something substantive I can move fast. If it's a placeholder dressed up as a packet, we

Owen — wanted to flag something before it becomes a timeline conversation. Legal's data-processing review opened this week, which is normal and non-negotiable. Priya estimates she can move quickly IF the vendor delivers a complete packet at Gate 3 — their seller has already stated that's the plan. The constraint I want you to have visibility on: the Fortalis auto-renewal is August 22. The sub-committee meets August 11. If the legal packet is thin and Priya has to go back to the vendor for supple

For what it's worth — the fact that they named sub-processor disclosure and breach-context handling in that Gate 3 commitment without being asked is the first time I've seen a vendor do that proactively in this process. Still means nothing until Priya reviews the actual documents. But the pattern has been consistent: they've anticipated the next step before we asked for it. Either their seller has done this before or someone on their side is actually paying attention. Doesn't change what Priya n

#vendor-eval — just want to flag for the group: Procurement circulating the Fortalis counter-offer as 'why are we even looking' is a fair question on price, but it's the wrong question. The 25% slash and the identity beta don't touch the detection latency gap or the containment fidelity issues we documented in Gate 2. If we want to compare apples to apples, Fortalis needs to show us the same evidence standard we locked in SG-AP-POC-TP-v1.1. Happy to write that up formally if it helps Procurement

#vendor-eval — Victor's right. I already used the criteria doc in a procurement conversation this week and the framing held. The Fortalis number looks good in a spreadsheet but 25% off a renewal that wasn't performing is still a discount on the wrong thing. Owen, I know the counter-offer lands differently for you — worth a quick sync before the Aug 11 sub-committee if you want the side-by-side.

Dana — I appreciate the heads up. I'll be honest: when Procurement dropped that Fortalis number in my inbox my first instinct was 'this is a lot of process for something we could just renew.' I'm not there yet on killing the eval, but I need the case for switching costs vs. status quo to be tighter than it is right now. The identity module beta especially — even if it's vaporware, it's something I'll get asked about. Can you give me one paragraph on why that specifically doesn't close the gap? S

Dana — DM, not for the channel. The Fortalis renewal also has data processing terms we never fully renegotiated after the EU adequacy decision update. If they're offering a sweetened deal now, I'd want to know whether the DPA language moves too or just the price. That's not an argument for the new vendor necessarily, just — the Fortalis 'status quo' isn't quite as clean as Procurement is presenting it. Flagging so you have it if Owen's sync happens.

#vendor-eval — quick process note for the group. I've sent Dana the threshold doc as committed. She has it. I want to be explicit before the Owen session gets scheduled: the status quo cost framing the vendor floated is not cleared for that room. I'll explain my reasoning when we're together but I don't want anyone walking in thinking that number has been vetted. It has not.

Received, and I agree with the call. I'll make sure the pre-read I send Owen doesn't include any figures we haven't independently confirmed. What you gave me on the threshold is clean and I'll use that as the frame. Appreciate you holding the line on this.

Dana — I saw the thread reference in the channel. I'm fine waiting for a clean pre-read from you before I agree to a session date. I'll be honest: I still don't have a clear picture of what I'm actually being asked to decide at this stage versus what's still contingent on Priya's review. Can you give me a one-paragraph plain-English summary of the decision path before we get in a room? I don't want to be the last person to understand the sequencing.

Dana, just so you have visibility — I'm in active review on the Gate 3 packet and my preliminary read is that the SCCs are structured correctly, which is better than I expected. I do still have open questions on the sub-processor list and the retention schedule. Nothing that stops the clock, but I want you to know those items exist before you characterize my status to Owen. 'In review' is accurate. 'On track' I can't confirm yet.

Heuristic judge (mock/offline): grades derive from the deterministic gate/event log; citations point at real transcript turns.

Behavior signals: 2 quantifying questions · 1 open discovery · 13 process · 1 champion tests · 0 pitches · 0 premature closes · 0 discount offers.

Facts earned: 6/7 (decision_process, renewal_trap, breach_exposure, analyst_load, eb_intro, fortalis_gap). Final trust 100/100.

Next action: [D — Decision Criteria, scored 1] Run trap-setting now: seed your differentiators into the customer's emerging written criteria before the bake-off.

Next action: [EB engagement: 8/15] Hold the EB meeting and secure the conditional commitment, confirmed in writing.

Next action: [MEDDPICC evidence: 26.7/40] Work the lowest letter (E — Economic Buyer, D — Decision Criteria).

Next action: [3 Whys clarity: 15.7/20] Rewrite each Why in the customer's own words with a named owner and a number; capture a verbatim quote.

This is the most honest vendor communication I've received since the breach, and I mean that without qualification.

If I have to say I don't know where they originated, we're done

This is approved as written. You held every boundary we discussed — Aperture numbers only, no projected savings, no competitive framing, $22 million as context…

I'll note for the record that your team has handled the sequencing correctly so far. That matters in this context more than you might expect

the latest safe date for Owen’s funding decision is Friday, July 31.

Honest read: false positives must be proven on Aperture telemetry.

That gives us a decision path, not a reason to manufacture urgency. I'd run three tracks in parallel

Honest read: false positives must be proven on Aperture telemetry. We should replay a representative labeled sample

Fortalis's 25% renewal reduction and free identity-module beta do not change Sentinel's $980,000 annual price. Nor will we attack Fortalis.

MAP status: RED... It is no longer supportable as a final evidence-based funding decision if Owen requires Victor's directional read

Then stop confirming and go build the thing.

walking into a room with Owen and putting specific operational baselines in front of him that I haven't formally validated

I need to stop you before those numbers go anywhere near Owen's calendar invite or that meeting room.

I'm not accusing you of anything. I'm telling you that walking into a room with Owen and putting specific operational baselines in front of him that I haven't …

if Victor comes back with telemetry gaps or integration concerns that Sentinel can't answer honestly, I need you to tell me that in week two, not after we've b…

Conditional go. The event-category coverage is credible, the join path is sound, and the scoring architecture handles the failure modes

I'm accepting it into review. That is not DPA approval, authorization to move telemetry, or a signal about timeline

This is the first protocol I've received from a vendor that I didn't have to rewrite before I could take it seriously... I'm still in 'trust but verify' mode a…

Conditional go. The event-category coverage is credible, the join path is sound, and the scoring architecture handles the failure modes I've seen break other t…

I still don't have a clear picture of what I'm actually being asked to decide at this stage versus what's still contingent on Priya's review

That sequence works, and it's the first time a vendor has handed me a plan I could actually defend to the board without editing out the hype.

no discount or pricing proposal before Owen reviews validated value and decision terms.

I'm still not convinced on the business case but at least it's a starting point I can actually hand to my team

resolve the apparent date conflict rather than hiding it

You've listed specific baselines — false-positive rate, analyst headcount, notices, the 51-day figure — and I have not released any of those to you.

Dana will sponsor Owen access only after Victor validates the POV; she will add the exact Fortalis notice deadline after POV criteria approval.

Victor issued a conditional go: coverage credible, join path sound, scoring architecture handles known failure modes.

Send me the source for each figure in that paragraph. Once I know where they came from I'll tell you quickly what I can validate

Do not chase Dana during incident response or approach Owen before Victor validates the POV and Dana sponsors Economic Buyer access.

at least a 40-percentage-point improvement in alert-to-true-positive ratio, with no increase over Aperture’s current missed-event baseline

I’ll show Sentinel’s $980,000 annual price transparently and won’t claim the $22 million incident cost as recoverable value.

the latest safe date for Owen’s funding decision is Friday, July 31.

What can your team not detect, investigate, or contain today—and what measurable operational or business impact is that creating?

What are the exact systems and formats behind those four data domains, and what numerical threshold would constitute meaningful signal improvement

what are the current monthly identity-alert volume and average triage time, and does he value recovered analyst hours only when they avoid replacement hiring

It does not authorize a POV until you issue the technical go decision.

We’ll treat your telemetry profile as the test envelope, not a tuning target

Then stop confirming and go build the thing.

rather than assume the public filing tells the whole story or jump into a product pitch, I’d like to understand the gap in your terms.

This is not a demo; the purpose is to determine an early go/no-go

For the eventual Owen session, I’d like to diagnose his decision rather than presume it

Since Sentinel is initially additive, Owen’s case cannot rest on displaced Fortalis spend

If legal review moves the labeled-data test or technical decision, we will update the governing plan rather than bypass the gate.

That delivery failure is ours. I won’t ask you to review from a verbal summary or make a decision without the evidence.

A discount or free beta is a commercial term, not measured technical evidence.

It is no longer supportable as a final evidence-based funding decision if Owen requires Victor’s directional read

You've listed specific baselines — false-positive rate, analyst headcount, notices, the 51-day figure — and I have not released any of those to you.

July 31 remains the latest safe Owen signal for a ten-business-day procurement path.

I need to avoid a false premise: is Fortalis spend actually replaceable if Sentinel passes, or would Sentinel be additive while Fortalis remains your SIEM?

When you say 'signed alternative before the Fortalis renewal locks,' do you mean a fully executed order form and a completed DPA, rather than Owen's funding ap…

July 31 remains the latest safe Owen signal for a ten-business-day procurement path. It is no longer supportable as a final evidence-based funding decision if …

Fortalis’s 25% renewal reduction and free identity-module beta do not change Sentinel’s $980,000 annual price.

We are holding the $980,000 annual price; the purpose is to expose timing risk early, not negotiate by email.

I'll show Sentinel's $980,000 annual price transparently and won't claim the $22 million incident cost as recoverable value.

Fortalis's 25% renewal reduction and free identity-module beta do not change Sentinel's $980,000 annual price.

Sentinel's annual price remains $980,000.

I propose the following answer for your validation:

MAP exception — legal path now extends beyond a supportable July 31 evidence decision

You've listed specific baselines — false-positive rate, analyst headcount, notices, the 51-day figure — and I have not released any of those to you. I don't kn…

If I have to say I don't know where they originated, we're done — not because the numbers are wrong but because the sourcing is unclear

walking into a room with Owen and putting specific operational baselines in front of him that I haven't formally validated is exactly the kind of move that end…

the status quo cost framing the vendor floated is not cleared for that room. I'll explain my reasoning when we're together but I don't want anyone walking in t…

Working backward from the August 22 Fortalis lock, the latest safe date for Owen’s funding decision is Friday, July 31.

Working backward from the August 22 Fortalis lock, the latest safe date for Owen's funding decision is Friday, July 31. This is not the signing deadline; it is…

The decision we now need from Owen is narrower and candid: whether he will (1) permit procurement/commercial diligence to start while reserving final funding f…

That gives us a decision path, not a reason to manufacture urgency.