Scenarios
Hypothetical examples by industry: a change, the rule it touches, the evidence and the named approval. They are not customer stories or product test results.
For stories about the sample company, Harbor Ledger, read the case studies.
88 examples
No examples match these filters.
A new payment type misses required AML monitoring
- The change
- A bank adds a payment option with a new transaction code. Before launch, the monitoring system receives the new payments.
- The rule or commitment
- The bank's confirmed monitoring matrix requires the new payment type to reach the relevant AML scenarios.
- What informs the assessment
- Kanonik compares the transaction mapping and rule filters the bank submits with that matrix. The team's pre-launch replay shows the new code is excluded from the rules and never reaches a required scenario. The finding rests on those traces; a missing alert on its own would not establish it.
- Response and checks
- The monitoring team adds the code to the required filters and runs the sandbox replay again. The new traces show the code evaluated, including the cases that should raise an alert.
- Who approves
- The AML monitoring owner approves the revised coverage matrix after reviewing those traces.
- What prompts another review
- A new transaction code or a revised AML filter changes the coverage question. When it is recorded in Kanonik, the matrix and replay evidence go back to the monitoring owner.
A payment upgrade removes independent approval
- The change
- A bank upgrades its treasury payment platform. The new role mapping lets the person who creates a large supplier payment also approve it, contrary to the bank's existing two-person rule.
- The rule or commitment
- Above the treasury policy threshold, the initiator and approver must be different people, including when they hold multiple accounts.
- What informs the assessment
- Using the identity crosswalk, proposed permissions and final-release settings supplied by the bank, Kanonik flags a route to self-approval. The team's sandbox trace confirms that one person makes an above-threshold payment releasable without an independent downstream gate.
- Response and checks
- The payment team restores independent approval and repeats the sandbox payment. Its new traces show self-approval refused and a separate authorized approver completing the flow.
- Who approves
- The treasury control owner approves the revised role map and sandbox results, including refusal of self-approval and release by a separate authorized person.
- What prompts another review
- Changes supplied to the identity crosswalk, treasury approval matrix or final-release gate bring the payment decision back for review. When it is recorded in Kanonik, the payment decision goes back to the treasury control owner.
A settlement feed drops payment reversals
- The change
- A processor replaces its settlement-file format. A proposed import mapping omits reversal records, so the daily reconciliation could incorrectly treat reversed payments as settled.
- The rule or commitment
- The signed reconciliation specification requires reversal records to reach ledger handling or an explicit exception.
- What informs the assessment
- Kanonik links the supplied file mapping to the finance rule. The team's reconciliation output contains reversals in the source but neither corresponding ledger handling nor exceptions, establishing more than a schema difference.
- Response and checks
- Finance corrects the import mapping and replays the test files. The submitted reconciliation now accounts for reversals by record type and currency, with matching counts and amounts.
- Who approves
- The settlement accounting lead approves the corrected import mapping after reviewing reversal counts and amounts against the test ledger and exception output.
- What prompts another review
- A revised file schema or reversal treatment can invalidate that reconciliation. When it is recorded in Kanonik, the record mappings and accounting conclusions go back to the settlement accounting lead.
Disaster recovery loses an essential dependency
- The change
- A bank moves its online-banking application to a new recovery environment. The application is replicated, but its required signing-key service remains available only in the primary environment.
- The rule or commitment
- The approved recovery plan requires essential transactions to work without the primary environment within its recovery targets.
- What informs the assessment
- Kanonik compares the bank's recorded application dependencies and recovery design. An isolated failover report supplied by the recovery team shows that transactions still need the primary signing-key service.
- Response and checks
- The infrastructure team provides an approved recovery path for signing keys and repeats the isolated failover exercise. Its results show the required transactions complete within the recovery target.
- Who approves
- The business continuity owner approves the recovery design on the strength of the isolated failover report, including signing-key access and completion within the agreed target.
- What prompts another review
- A connected deployment record moves the key service or changes its recovery access. When it is recorded in Kanonik, the dependency behind the accepted plan goes back to the business continuity owner.
Payment automation bypasses verification of changed bank details
- The change
- Finance enables automatic supplier bank-detail updates from an onboarding portal. The workflow accepts an authenticated supplier request without the independent verification required by its payment policy.
- The rule or commitment
- The supplier-change policy requires independent verification through an approved contact source before new bank details become payment-eligible.
- What informs the assessment
- Kanonik checks the submitted activation workflow against the confirmed verification rule. Finance's negative-test trace shows an unverified bank-detail change becoming payment-eligible despite successful portal authentication.
- Response and checks
- Finance adds verified approval before activation and repeats the test. Unverified changes remain ineligible; a change with the required verification record reaches the authorized payment path.
- Who approves
- The supplier payments manager approves the activation workflow with its verification-record requirement and the test showing an unverified change remains payment-ineligible.
- What prompts another review
- The verification policy and approved contact source remain part of the decision's basis. When it is recorded in Kanonik, the affected bank-detail activation review goes back to the supplier payments manager.
A claims upgrade exceeds adjuster settlement authority
- The change
- An insurer consolidates claims systems. A generic role in the new system gives junior adjusters the settlement limit previously reserved for senior staff.
- The rule or commitment
- The claims authority matrix limits settlement amounts by adjuster, product and escalation authority.
- What informs the assessment
- Kanonik compares the supplied migration roles and adjuster authorities. Boundary-test results from the claims team show a junior adjuster making an above-limit settlement binding without a downstream escalation gate.
- Response and checks
- The claims team corrects the role mapping and escalation route. Repeated boundary tests permit authorized settlements and send above-limit cases to the designated senior approver.
- Who approves
- The claims operations head approves the role-to-authority mapping after checking the below-limit settlements and above-limit escalation results.
- What prompts another review
- A supplied change to an adjuster's delegated amount, product scope or downstream payment gate calls the settlement tests into question. When it is recorded in Kanonik, the affected authority mapping goes back to the claims operations head.
A renewal release uses the wrong rating version
- The change
- An insurer updates its renewal engine. Policies renewing before a new rate version's effective date receive that new rate instead of the version applicable to their renewal date.
- The rule or commitment
- A renewal must use the rating version applicable to its product, jurisdiction and renewal date, as confirmed by the insurer's specialists.
- What informs the assessment
- The pricing team's sample renewals on either side of the effective date use the new rate too early when compared with independently calculated premiums.
- Response and checks
- The pricing team corrects version selection and reruns samples on both sides of the effective date. The recorded premiums match the applicable approved versions.
- Who approves
- The rating compliance manager approves the rate-selection logic with boundary-date samples and independently calculated premiums for the relevant product and jurisdiction.
- What prompts another review
- New effective dates or a changed filing outcome can change which rate applies. When it is recorded in Kanonik, the renewals that depend on it go back to the rating compliance manager.
A claims migration loses reinsurance notification triggers
- The change
- An insurer moves large-loss claims into a new platform. A changed severity code no longer triggers notice to the reinsurer under a particular treaty.
- The rule or commitment
- The executed reinsurance treaty requires notice when a covered claim meets its specified severity trigger.
- What informs the assessment
- Kanonik traces the supplied claim-code mapping to the human-confirmed treaty condition. The insurer's workflow replay shows that a qualifying synthetic claim creates no notice task within the required route.
- Response and checks
- The claims team repairs the severity mapping and repeats the replay. Qualifying cases now generate the required notice task with the treaty deadline; non-qualifying cases retain their existing treatment.
- Who approves
- The reinsurance manager approves the repaired severity-code mapping and notice-generation traces against the treaty's actual triggers and deadlines.
- What prompts another review
- A treaty amendment or another severity-code migration may change the notice obligation. When it is recorded in Kanonik, the affected trigger and its notification evidence go back to the reinsurance manager.
An external claims partner gains access to unrelated portfolios
- The change
- An insurer gives a new claims administrator portal access. The proposed group grants access to every portfolio instead of only the book assigned in its contract.
- The rule or commitment
- The administrator's contract and access policy authorize only its assigned portfolios.
- What informs the assessment
- Kanonik compares the supplied portfolio schedule with effective portal access. The security team's isolation test shows a partner account retrieving a claim outside the contracted book.
- Response and checks
- The portal team restricts portfolio access and reruns allowed and forbidden cases. The partner can handle assigned claims but cannot retrieve unrelated portfolios.
- Who approves
- The third-party claims owner approves the administrator's restricted portfolio scope, retaining the contract schedule and allowed/forbidden access results as the basis.
- What prompts another review
- Connected contract schedules, partner memberships or row-level rules change. When it is recorded in Kanonik, the portfolio access goes back to the third-party claims owner. The review concerns the assigned book, not a blanket renewal of vendor approval.
A data migration omits reopened claims from reserve reporting
- The change
- An insurer changes its claims data feed. Reopened claims receive a new status that the existing reserve extract does not include.
- The rule or commitment
- The approved reserve extract must include reopened claims with reportable reserves.
- What informs the assessment
- Kanonik links the submitted status migration to the reporting population rule. Finance's reconciliation shows reopened test claims with reserves missing from the destination extract.
- Response and checks
- The data team adds the new status to the inclusion rules. Its repeat reconciliation accounts for the complete test population by claim ID, status and reserve amount.
- Who approves
- The reserve reporting controller approves the extract specification with a reconciliation of reopened claim IDs, statuses and reserve amounts.
- What prompts another review
- A supplied status dictionary or extract rule changes. When it is recorded in Kanonik, the reserve-population check goes back to the reserve reporting controller.
Transcription falls outside existing agreement coverage
- The change
- A HIPAA-covered provider enables appointment transcription in existing software. The added service will process identifiable patient information, but the documented contractual chain does not cover that service or its processor.
- The rule or commitment
- The privacy team confirms that the proposed PHI service needs coverage through the applicable business associate agreement chain.
- What informs the assessment
- Kanonik compares the authorized data-flow and contract records with that confirmed scope. A documented exclusion flags a contract-coverage conflict; an absent or ambiguous schedule remains unverified coverage, not a proven breach.
- Response and checks
- The provider pauses activation while its privacy and security teams establish coverage for the service and processor. A repeated scope review now matches the proposed PHI flow to the executed agreement chain.
- Who approves
- The privacy officer approves the transcription service scope only after security and contract reviewers establish the applicable agreement chain and its effective coverage.
- What prompts another review
- A different processor entity or expanded transcription service can fall outside the reviewed agreement chain. When it is recorded in Kanonik, that coverage question goes back to the privacy officer.
Framework context: HIPAA
An electronic-record migration shortens recovery history
- The change
- A clinic moves its electronic health record database. The destination keeps recovery points for seven days, while its approved recovery policy requires 30 days to address errors discovered late.
- The rule or commitment
- The clinic's recovery policy requires 30 days of usable recovery history, not the destination's seven-day default.
- What informs the assessment
- Kanonik compares the submitted backup plan, lifecycle settings and historical-source inventory with the clinic's confirmed requirement. The recorded design leaves no usable source covering the required window after migration.
- Response and checks
- The database team extends retention and preserves the required history. Its isolated restore test retrieves records from the required window, and Kanonik assesses the resulting report against the policy.
- Who approves
- The clinical systems recovery owner approves the migration plan with the retained-source inventory and restore evidence covering the clinic's required recovery window.
- What prompts another review
- Expiration of a connected historical backup or a shorter lifecycle setting may narrow the recovery window. When it is recorded in Kanonik, the clinic's recorded recovery claim goes back to the clinical systems recovery owner.
A staffing-role change broadens patient-record access
- The change
- A hospital combines scheduling roles across departments. The replacement role also grants broad clinical-chart access not authorized for those staff under hospital policy.
- The rule or commitment
- Hospital policy limits scheduling staff to the records needed for their approved duties while preserving separately authorized emergency access.
- What informs the assessment
- Kanonik checks the customer-supplied job functions and effective permissions. Access-test results show a scheduling-only identity retrieving clinical content outside its authorized role.
- Response and checks
- The identity team removes excess chart permissions and repeats the allowed and forbidden access tests. Scheduling still works, restricted charts are denied, and approved emergency access keeps its separate controls.
- Who approves
- The hospital access governance lead approves the scheduling role after reviewing restricted-chart tests alongside the separately authorized emergency-access cases.
- What prompts another review
- Job duties, group permissions or approved exceptions change the chart-access decision. When it is recorded in Kanonik, the chart-access decision goes back to the hospital access governance lead.
A laboratory-interface update drops critical-result escalation
- The change
- A hospital updates its laboratory interface. A new critical-result code appears correctly in the patient record but no longer triggers the urgent notification workflow.
- The rule or commitment
- The clinician-approved critical-result policy requires urgent notification, acknowledgment and escalation for the affected result code.
- What informs the assessment
- Kanonik compares the supplied code mapping and notification evidence with that policy. The hospital's synthetic critical-result test reaches the patient record but produces no required escalation.
- Response and checks
- The interface team repairs the criticality mapping. Repeat synthetic tests show the required notification, acknowledgment and escalation, and the clinical team validates the routing before deployment.
- Who approves
- The clinical safety officer approves the interface change with clinical validation of notification, acknowledgment and escalation traces for the synthetic critical results.
- What prompts another review
- A criticality-code, clinical recipient or timing requirement changes. When it is recorded in Kanonik, the escalation decision goes back to the clinical safety officer.
A new patient portal exposes another patient's documents
- The change
- A provider launches a redesigned document-download feature. Authorization checks confirm that a user is signed in but fail to confirm that the requested document belongs to a patient that user may represent.
- The rule or commitment
- A document download requires a valid patient or authorized-proxy relationship, not just a signed-in account.
- What informs the assessment
- Kanonik assesses the provider's submitted ownership mappings and endpoint test results. A synthetic account downloads a document outside every permitted patient or proxy relationship.
- Response and checks
- The portal team enforces the relationship at the download endpoint and repeats direct-download tests. Unrelated documents are denied while patient and authorized-proxy downloads succeed.
- Who approves
- The patient portal security owner approves the endpoint authorization rules using the synthetic patient and proxy download results, not just the portal's visible document list.
- What prompts another review
- A connected change to document ownership or proxy authority may change who can download a record. When it is recorded in Kanonik, the affected authorization basis goes back to the patient portal security owner.
A laboratory upgrade stops recording result changes
- The change
- A pharmaceutical laboratory upgrades its result-management software. The proposed configuration permits result amendments without the required audit history.
- The rule or commitment
- The laboratory's approved procedure requires attributable history for amendments to the in-scope regulated results.
- What informs the assessment
- Kanonik checks the submitted audit configuration and controlled amendment record. The test lacks the old and new values, actor, time or reason required by the confirmed procedure.
- Response and checks
- The laboratory restores the audit settings and repeats its applicable validation. The new amendment test retains each required history field and links the change to its authorized actor.
- Who approves
- The laboratory quality lead approves the amendment configuration with validation records showing the required old and new values, actor, time and reason.
- What prompts another review
- New amendment privileges or revised audit-history requirements can outdate the laboratory's validation. When it is recorded in Kanonik, the linked result-change evidence goes back to the laboratory quality lead.
A warehouse migration releases quarantined stock
- The change
- A drug manufacturer replaces its warehouse system. The migration maps a legacy quarantine code to ordinary available inventory.
- The rule or commitment
- The quality-release procedure prohibits shipment of quarantined lots until an authorized quality release exists.
- What informs the assessment
- Kanonik compares the submitted status dictionaries and migration mapping with that rule. The warehouse team's attempted-pick test makes a held lot available without a quality release.
- Response and checks
- The warehouse team corrects the quarantine mapping and reconciles held lots. Its repeated pick test blocks unreleased stock and permits a separately released test lot.
- Who approves
- The quality release manager approves the migration mapping after reconciling held lots and reviewing the attempted-pick results for stock without quality release.
- What prompts another review
- A revised status dictionary can change what 'available' means to the warehouse. When it is recorded in Kanonik, the linked quarantine mapping goes back to the quality release manager.
A packaging-line update selects obsolete artwork
- The change
- A medical-device manufacturer updates its label-printing system. One product variant is linked to an older label revision that omits the currently approved warning.
- The rule or commitment
- Each product and market must use the effective artwork revision approved by qualified labeling personnel.
- What informs the assessment
- Kanonik compares the team's generated test label with the submitted controlled artwork. The proposed variant mapping selects an obsolete revision that lacks the approved warning.
- Response and checks
- The packaging team corrects the variant mapping and prints new test labels. Qualified reviewers confirm that the output matches the applicable artwork and the change order's stock-disposition instructions.
- Who approves
- The labeling quality manager approves the product-and-market template mapping against the applicable artwork revision and generated test labels.
- What prompts another review
- Connected artwork revisions take effect. When it is recorded in Kanonik, the print-selection evidence goes back to the labeling quality manager.
A storage move leaves a cold-room sensor without escalation
- The change
- A manufacturer moves temperature-sensitive inventory to a new cold room. Its sensor appears in the monitoring dashboard but is not assigned to the on-call escalation rule.
- The rule or commitment
- The storage procedure requires the cold room's sensor to trigger the defined excursion-response route.
- What informs the assessment
- Kanonik links the supplied room, sensor and alarm records. The team's simulated excursion report shows a dashboard reading but no required on-call escalation.
- Response and checks
- The monitoring team connects the sensor to the approved alarm path and repeats the safe simulation. The results show notification and acknowledgment by the required recipients.
- Who approves
- The storage quality lead approves the cold-room alarm route with the simulated excursion, notification and acknowledgment results before the inventory move.
- What prompts another review
- Moving inventory or remapping a sensor changes which alarms cover it. When it is recorded in Kanonik, the alarm route goes back to the storage quality lead.
A component substitution falls outside established verification
- The change
- A device manufacturer substitutes a battery with similar headline specifications. Existing verification covered a different battery's discharge behavior in the finished device.
- The rule or commitment
- The device's verification evidence must cover the substituted battery's relevant behavior in the finished configuration.
- What informs the assessment
- Kanonik compares the supplied component specifications and qualification scope. The existing report covers a different discharge characteristic, so the substitution needs engineering evidence; that gap does not prove the battery unsafe.
- Response and checks
- Engineering assesses the changed behavior and runs the required controlled verification. The submitted results meet the approved device requirements for the substitute configuration, closing the identified evidence gap.
- Who approves
- The design assurance lead approves the battery substitution with the engineering impact assessment and verification for the changed discharge behavior in the finished device.
- What prompts another review
- A connected battery-specification or device-requirement revision may exceed the configuration just verified. When it is recorded in Kanonik, that evidence-scope question goes back to the design assurance lead.
A substitute component lacks the required customer approval
- The change
- Procurement substitutes an available component to keep production moving. It meets the general drawing, but one customer's signed specification requires approval of that particular source.
- The rule or commitment
- The affected customer's signed specification requires approval of the component's source and manufacturing site.
- What informs the assessment
- The proposed source is explicitly excluded and no valid exception covers it; an incomplete supplier database would leave the question unresolved. Kanonik compares the submitted part and order mappings with the complete approved-source list.
- Response and checks
- Procurement selects a covered source. A repeated review matches the part and manufacturing site to the customer's current approval, and the order-level check shows the affected builds use that source.
- Who approves
- The customer quality manager approves the component source for the named orders using the applicable approved-source record or a valid signed exception.
- What prompts another review
- An expired source approval or revised customer specification can remove that support. When it is recorded in Kanonik, the affected orders go back to the customer quality manager.
A maintenance migration omits a critical machine
- The change
- A factory replaces its maintenance system. A production-critical machine is imported as a generic asset, losing its scheduled inspection and service tasks.
- The rule or commitment
- The approved maintenance program requires the machine's existing inspection and service tasks to retain their due dates through migration.
- What informs the assessment
- A required task is absent from the migrated critical machine's schedule. Kanonik compares the supplied serial-number crosswalk and complete destination schedule with the source task list.
- Response and checks
- Maintenance restores the task assignments and due dates. Its repeat reconciliation matches every required source task to the correct destination asset and next scheduled date.
- Who approves
- The maintenance engineering manager approves the destination schedule after matching the machine's required tasks and next due dates to the source program.
- What prompts another review
- A changed asset identifier can detach a task from its machine again. When it is recorded in Kanonik, the linked schedule basis goes back to the maintenance engineering manager.
A production-speed increase exceeds the qualified inspection setup
- The change
- A plant raises a packaging line's speed. Its automated inspection system has only been qualified to detect the relevant defects at a lower speed.
- The rule or commitment
- The control plan relies on defect detection within the inspection system's qualified speed range.
- What informs the assessment
- The higher speed lies outside the tested range, so detection performance is unverified rather than proven to fail. Kanonik compares the proposed setting with the submitted qualification report.
- Response and checks
- Production retains the qualified speed. A repeat configuration review matches the operating setting to the approved envelope, and the team's controlled inspection trial meets the existing detection criteria.
- Who approves
- The process quality engineer approves retaining the qualified speed, with the line setting tied to the inspection report's product and defect-detection criteria.
- What prompts another review
- A later speed increase needs evidence covering that operating point. When it is recorded in Kanonik, the connected inspection basis goes back to the process quality engineer.
A remote-support change bypasses the approved access gateway
- The change
- A factory introduces a vendor support tool. Its proposed connection gives a contractor direct access to production controllers instead of the approved gateway with time-limited authorization.
- The rule or commitment
- The plant's confirmed remote-access standard requires vendor sessions to use the approved gateway and time-limited authorization.
- What informs the assessment
- Kanonik assesses the plant's supplied network design, identity permissions and safe connectivity results. Together they establish a reachable route to the controllers that bypasses the required gateway, without a covered compensating control.
- Response and checks
- The network team routes support through the approved gateway. Safe repeat tests deny direct access and allow only the authorized, time-limited support session.
- Who approves
- The OT security manager approves the gateway-based support design after reviewing safe reachability tests, vendor permissions and session-expiry settings.
- What prompts another review
- A new firewall route or vendor role can change how a controller is reached. When it is recorded in Kanonik, the recorded gateway path goes back to the OT security manager.
A warehouse change breaks lot traceability
- The change
- A manufacturer consolidates inventory in a new warehouse system. The new outbound interface records product and quantity but drops the production-lot identifier required for traceability.
- The rule or commitment
- The traceability plan requires a retained link from production lot through shipment to the affected customer.
- What informs the assessment
- The team's mock recall cannot identify recipients of a test lot because the proposed interface removes its only retained shipment link. Kanonik compares the submitted outbound mapping with the quality requirement.
- Response and checks
- The integration team preserves the lot identifier and its shipment relationship. The repeated mock recall identifies the test lot's recipients without including unrelated lots.
- Who approves
- The traceability quality lead approves the outbound interface with mock-recall results linking the test lot through finished goods to its customer shipments.
- What prompts another review
- Interface or lot-genealogy changes affect the lot-to-customer evidence. When it is recorded in Kanonik, the lot-to-customer evidence goes back to the quality team.
A controller replacement drops an engineering-approved alarm
- The change
- A utility replaces a controller during planned maintenance. The new configuration omits a high-level alarm required by the site's approved operating design.
- The rule or commitment
- The signed alarm schedule requires the high-level alarm and its defined operator-response path.
- What informs the assessment
- The offline simulation report confirms that the required alarm is missing and does not activate. Kanonik compares the replacement configuration supplied by engineering with that schedule.
- Response and checks
- The controls team restores the alarm and repeats the offline simulation. The report shows activation at the approved condition and the required response path before commissioning.
- Who approves
- The responsible controls engineer approves the controller package against the signed alarm schedule and offline simulation results for the required signal and response.
- What prompts another review
- A linked signal mapping, threshold or response action changes. When it is recorded in Kanonik, the accepted alarm comparison goes back to the responsible controls engineer. The engineering team then decides whether the earlier simulation still covers the revised configuration.
Backup communications share the primary route's failure point
- The change
- A utility changes telecom suppliers for remote sites. The replacement backup circuit uses the same physical conduit as the primary, contradicting the approved diversity requirement.
- The rule or commitment
- The approved continuity design requires the primary and backup circuits to avoid the specified shared physical failure point.
- What informs the assessment
- Kanonik links provider-confirmed route records supplied by the utility. They place both circuits in a prohibited conduit segment; different supplier names do not establish route diversity.
- Response and checks
- Procurement selects an alternative backup route. The network engineer reviews updated provider records and completes the acceptance check, which now shows the required physical separation.
- Who approves
- The communications resilience engineer approves the circuit design using provider-confirmed physical routes and the site's documented diversity requirement.
- What prompts another review
- A provider's route revision may introduce a shared facility without changing the circuit's commercial name. When it is recorded in Kanonik, the diversity conclusion goes back to the communications resilience engineer.
Network maintenance would isolate required operating telemetry
- The change
- A utility tightens firewall rules. A proposed rule removes the allowed path for a critical field gateway to send operating data to the control center.
- The rule or commitment
- The approved communications matrix requires the field gateway's minimum telemetry flow to reach the control center.
- What informs the assessment
- The utility's safe test shows the required path denied, with no approved alternative. Kanonik compares the supplied firewall proposal and path information with that requirement.
- Response and checks
- The firewall team preserves only the required flow and repeats its safe connectivity test. The supplied results show the field gateway reaching the control-center endpoint through the approved route.
- Who approves
- The control network owner approves the minimum required flow with the communications-matrix entry and representative connectivity results for the full path.
- What prompts another review
- Updated firewall rules or telemetry endpoints can invalidate the accepted path. When it is recorded in Kanonik, the linked reachability evidence goes back to the control network owner.
A billing release applies tariffs on the wrong dates
- The change
- A utility updates its billing system. The new logic applies a changed tariff to consumption before that tariff's effective date.
- The rule or commitment
- The applicable tariff governs consumption by customer class, territory and effective interval, as confirmed by the billing specialists.
- What informs the assessment
- Kanonik checks the supplied tariff versions against the proposed billing logic. Independently calculated boundary-date bills expose consumption charged under a rate that is not yet effective.
- Response and checks
- The billing team corrects the date and proration rules and reruns the boundary cases. The recorded bills now match the applicable schedule for each consumption interval.
- Who approves
- The billing compliance lead approves the tariff-selection rules with independently calculated bills spanning the effective-date boundary for the relevant class and territory.
- What prompts another review
- A revised tariff order or customer-class mapping changes which calculation applies. When it is recorded in Kanonik, the affected billing basis goes back to the billing compliance lead.
Vendor-access renewal removes its expiry
- The change
- A utility renews a maintenance contractor's access. A new identity template turns a time-limited account into permanent access, although the approved work ends after the maintenance window.
- The rule or commitment
- The contractor's signed work authorization limits usable access to the maintenance window.
- What informs the assessment
- The identity team's expiry test shows usable access continuing beyond the authorized window. Kanonik compares the supplied work order with account and session settings.
- Response and checks
- The identity team restores enforced expiry and session revocation. Its repeat test permits work during the authorized window and denies access after it ends.
- Who approves
- The site access owner approves the contractor's work-window access on the basis of expiry and session-revocation tests tied to the signed work order.
- What prompts another review
- An extended work order or replacement identity template can alter the authorization window. When it is recorded in Kanonik, the linked expiry evidence goes back to the site access owner.
An ingredient substitution leaves an obsolete allergen label
- The change
- A retailer substitutes an ingredient in a private-label packaged food. The new formulation contains milk, but the packaging planned for that product does not declare it.
- The rule or commitment
- The labeling specialist confirms that the milk-containing formulation requires a matching declaration on the affected product's label.
- What informs the assessment
- The proposed packaging omits the milk introduced by the substitution. Kanonik compares the supplied ingredient declaration, recipe and effective artwork with the confirmed labeling requirement.
- Response and checks
- The product team updates the artwork before packing the changed formulation. The labeling specialist's repeat recipe-to-label review confirms the declaration and the packaging effective date match the affected product.
- Who approves
- The food labeling lead approves the revised artwork for the affected formulation after checking the supplier's milk declaration and the labeling specialist's applicability review.
- What prompts another review
- A new supplier declaration or recipe change may alter the allergen statement. When it is recorded in Kanonik, the connected formulation-to-artwork basis goes back to the food labeling lead.
A checkout update introduces an unmanaged payment-page script
- The change
- A retailer adds an analytics script to an in-scope checkout payment page.
- The rule or commitment
- The merchant's confirmed payment-page scope requires authorization and integrity-control coverage for this script.
- What informs the assessment
- Kanonik assesses the submitted browser trace and control inventory. The script runs on the in-scope page outside the confirmed required controls; this is a control gap, not proof of skimming.
- Response and checks
- The checkout team removes the script and repeats the browser execution and tamper-monitoring tests. Its report confirms the removed script no longer loads and the remaining required scripts retain their tested controls.
- Who approves
- The payment security owner approves the release inventory with authorization, integrity-control and tamper-monitoring evidence for each in-scope script.
- What prompts another review
- A new script or changed payment architecture can expand the control scope. When it is recorded in Kanonik, the linked script review goes back to the payment security owner.
A checkout shortcut bypasses the merchant's fraud review
- The change
- An online retailer adds express checkout. Orders through that route can reach fulfillment without the fraud decision required by its own order-release policy.
- The rule or commitment
- The order-release policy requires a fraud decision before fulfillment, including for express checkout.
- What informs the assessment
- Kanonik checks the submitted state transitions and replay evidence against that rule. A synthetic review-required order becomes fulfillable without a fraud decision.
- Response and checks
- The order team restores the gate and replays review, approved and timeout cases. Review-required orders stay on hold, missing decisions follow the policy's timeout rule, and approved orders proceed.
- Who approves
- The fraud operations manager approves the express-checkout gate after reviewing hold-case and timeout traces through fulfillment release.
- What prompts another review
- Adding an order route can bypass the path just tested. When it is recorded in Kanonik, the express-checkout gate goes back to the fraud operations manager.
A returns upgrade refunds the same purchase twice
- The change
- A retailer connects store returns to its online refund system. The proposed integration treats a retried request as a new refund rather than the same operation.
- The rule or commitment
- Refunds across channels must refer to the same purchase and stay within its remaining permitted refundable amount.
- What informs the assessment
- Retried requests create executed test refunds above the permitted amount, rather than merely duplicate messages. Kanonik compares the supplied refund specification with processor and ledger test records.
- Response and checks
- The returns team adds shared duplicate protection and refund limits. Repeated and simultaneous sandbox requests now resolve to the intended refund without exceeding the purchase's permitted amount.
- Who approves
- The refund controls manager approves the retry design with processor and ledger results showing that concurrent store and online requests respect the remaining refundable amount.
- What prompts another review
- Changes to operation identifiers, refund caps or processor duplicate handling may invalidate the retry evidence. When it is recorded in Kanonik, the connected cross-channel control basis goes back to the refund controls manager.
A new delivery service lacks the product's temperature capability
- The change
- A grocer switches a delivery area to a cheaper carrier. The assigned service does not support the temperature conditions specified for the chilled products on that route.
- The rule or commitment
- The confirmed product-handling specification requires transport conditions within the approved product or packaging envelope.
- What informs the assessment
- The assigned service exceeds the approved envelope for the chilled products. Kanonik compares the carrier's attributable service conditions with the grocer's submitted specifications.
- Response and checks
- Logistics selects a suitable service and repeats its quality-approved handling trial. The submitted results keep the shipment within the required conditions for the planned journey.
- Who approves
- The distribution quality manager approves the delivery service and handling plan against the product limits, transit duration and applicable packaging qualification.
- What prompts another review
- A longer route or reduced carrier capability can exceed the accepted handling envelope. When it is recorded in Kanonik, that comparison goes back to the distribution quality manager.
A cheaper route exceeds cold-chain qualification
- The change
- A distributor reroutes temperature-sensitive food through a lower-cost hub. The revised journey lasts longer than the insulated packaging's qualified duration under the expected conditions.
- The rule or commitment
- The shipper's approved transport specification requires the planned journey to fit the packaging's qualified duration and ambient conditions.
- What informs the assessment
- Kanonik compares supplied journey and dwell times with the qualification report. The proposed route exceeds documented protection with no qualified replenishment step, leaving assurance insufficient rather than proving spoilage.
- Response and checks
- The route team chooses a journey within the qualified envelope. Quality staff repeat the duration and condition checks and supply a controlled trial meeting the approved transport criteria.
- Who approves
- The cold-chain quality owner approves the revised route and packaging combination with its dwell times, ambient assumptions and qualification margin visible in the transport plan.
- What prompts another review
- A new hub stop changes both journey time and handling assumptions. When it is recorded in Kanonik, the linked qualification basis goes back to the cold-chain quality owner.
A route-planning upgrade ignores remaining driver hours
- The change
- A U.S. interstate freight operator updates its route planner. The new integration treats a driver's remaining available hours as a fresh full allowance, creating infeasible assignments.
- The rule or commitment
- The operator's confirmed hours-of-service rules account for actual duty history, operation class, planned rest and valid exceptions.
- What informs the assessment
- One assignment requires driving beyond the applicable remaining allowance without planned rest or a valid exception. Kanonik compares the supplied boundary-test schedules with those conditions.
- Response and checks
- The planning team fixes duty-history ingestion and reruns the schedule tests. The revised assignments fit the applicable limits and planned breaks, including boundary and exception cases.
- Who approves
- The transport compliance manager approves the duty-history mapping and scheduling constraints using boundary cases with the applicable rest and exception rules.
- What prompts another review
- A changed duty-history feed can make remaining hours inaccurate again. When it is recorded in Kanonik, the linked planning conclusion goes back to the transport compliance manager.
A fleet migration loses a vehicle's out-of-service restriction
- The change
- A fleet operator replaces its dispatch system. An unresolved safety-defect status from maintenance is mapped to ordinary vehicle availability.
- The rule or commitment
- A vehicle with an unresolved out-of-service restriction requires an authorized maintenance release before dispatch.
- What informs the assessment
- Kanonik checks the supplied maintenance restrictions against the proposed availability mapping. The dispatch team's test assigns a restricted vehicle without the required release.
- Response and checks
- The migration team preserves the restriction and reconciles affected vehicle IDs. Repeated dispatch tests block unreleased vehicles while allowing one with an authorized maintenance release.
- Who approves
- The fleet maintenance authority approves the dispatch mapping after checking restricted-vehicle tests and reconciliation against the maintenance release records.
- What prompts another review
- New defect restrictions or repair releases change which vehicles can be dispatched. When it is recorded in Kanonik, the dispatch mapping goes back to the fleet maintenance authority.
A tracking portal exposes another customer's shipments
- The change
- A logistics provider launches downloadable shipment reports. The report endpoint uses a shipment ID without enforcing the requesting customer's right to that shipment.
- The rule or commitment
- Shipment reports require an authorized relationship to the customer or shipment, including explicitly approved shipper, consignee and broker access.
- What informs the assessment
- Kanonik assesses the submitted identity mappings and report-endpoint tests. A synthetic customer account retrieves a shipment report outside its authorized relationships.
- Response and checks
- The portal team enforces object-level authorization and repeats direct requests. Cross-customer retrieval is denied and legitimate delegated shipment access succeeds.
- Who approves
- The logistics portal security lead approves the report endpoint with test results for forbidden access and legitimate shipper, consignee and broker relationships.
- What prompts another review
- A changed authorized-party relationship can alter report access without changing shipment ownership. When it is recorded in Kanonik, the affected access evidence goes back to the logistics portal security lead.
A carrier-booking integration creates duplicate shipments
- The change
- A distributor automates carrier booking. When the carrier confirms a booking but the response is lost, the integration retries with a new reference and books another truck.
- The rule or commitment
- The booking specification requires retries to preserve one intended freight commitment while allowing legitimate split or multi-leg movements.
- What informs the assessment
- The integration team's lost-response simulation produces two active bookings for one intended movement. Kanonik compares the supplied order identifiers and carrier confirmations.
- Response and checks
- The integration team adds a stable booking reference and status reconciliation. The repeated timeout test recovers the original booking without ordering a second truck; valid split bookings remain distinct.
- Who approves
- The freight operations owner approves the booking design after matching lost-response test traces to carrier confirmations for the intended movement.
- What prompts another review
- A carrier API change can alter whether a retry reuses an existing booking. When it is recorded in Kanonik, the connected retry basis goes back to the freight operations owner.
A routine database move shortens backup retention
- The change
- A SaaS company upgrades its customer database to a managed service. The proposed backup setting retains seven days, while its approved recovery policy requires 30.
- The rule or commitment
- The service's confirmed recovery policy requires 30 days of usable history after migration, rather than the managed service's seven-day default.
- What informs the assessment
- Once old backups expire, the combined design supports only seven days. Kanonik compares the submitted lifecycle settings and retained-source plan with that policy.
- Response and checks
- The infrastructure team extends the backup lifecycle and preserves historical sources through cutover. Its isolated restore test retrieves the required historical data, supplying evidence that the 30-day window remains usable.
- Who approves
- The service recovery owner approves the migration's backup lifecycle and historical-source plan with restore evidence covering the company's required window.
- What prompts another review
- As connected historical sources expire, the combined recovery window may shrink. When it is recorded in Kanonik, the database's recorded support goes back to the service recovery owner.
Identity consolidation gives one account control of data and backups
- The change
- A software company consolidates administrator access. A production administrator would gain deletion rights over its only backup repository, undermining the required separation of recovery controls.
- The rule or commitment
- The recovery design requires a protected recovery source to survive compromise of a production administrator.
- What informs the assessment
- Kanonik checks the supplied effective permissions, retention locks and recovery inventory. The team's authorization simulation permits deletion of both production data and the only backup, with no protected alternative.
- Response and checks
- The identity team removes the production administrator's destructive backup privilege. Repeat simulations deny that deletion while the recovery team's isolated restore test confirms the independent copy remains usable.
- Who approves
- The security architecture lead approves the recovery separation design with effective-permission simulations and evidence that a protected recovery source survives the production administrator's authority.
- What prompts another review
- An inherited privilege or retention-lock change can undermine the accepted separation. When it is recorded in Kanonik, the linked destructive-permission analysis goes back to the security architecture lead.
A tenant migration breaks customer isolation
- The change
- A SaaS provider merges customers into a shared data platform. One export job is scoped by workspace name rather than the unique tenant identifier, allowing similarly named workspaces to mix.
- The rule or commitment
- Customer exports must respect the authoritative tenant boundary even when workspace names collide.
- What informs the assessment
- A controlled export supplied by the test team includes another tenant's records under a shared workspace name. Kanonik compares the submitted tenant mappings and export rules with the isolation requirement.
- Response and checks
- The data team scopes both access and queries to the unique tenant ID. Repeated tests with colliding names return only the requesting customer's authorized records.
- Who approves
- The tenant security owner approves the export query and authorization rules after checking synthetic tenants with colliding workspace names against the authoritative tenant IDs.
- What prompts another review
- A revised export query or identity mapping can change the isolation boundary. When it is recorded in Kanonik, the connected tenant-scope evidence goes back to the tenant security owner.
Disaster recovery depends on the same unavailable identity service
- The change
- A SaaS provider moves its standby environment to a second region. Both environments still rely on a sign-in service hosted only in the primary region.
- The rule or commitment
- The approved recovery commitment includes new customer sign-ins during loss of the primary region.
- What informs the assessment
- Kanonik connects the submitted standby topology to its recorded identity dependency. The team's isolated region-loss exercise leaves the standby application running but unable to establish required new sessions.
- Response and checks
- The platform team provides a resilient identity path and repeats the isolated exercise. The new report shows required sign-ins working within the recovery target rather than relying on cached sessions.
- Who approves
- The service resilience lead approves the standby identity design with the isolated primary-region-loss report, including successful new sign-ins within the recovery target.
- What prompts another review
- A connected topology change that moves identity services or alters standby dependencies may invalidate that exercise. When it is recorded in Kanonik, the recovery conclusion goes back to the service resilience lead. The conclusion rests on new sign-ins working, not on existing sessions surviving.
An agent-to-agent connection bypasses payment authority
- The change
- A company connects its purchasing agent to a payment agent. The proposed connection lets an authenticated agent request above-limit payments without the required human approval.
- The rule or commitment
- The spending policy requires authorized human approval for above-limit payments, regardless of how many agents agree to them.
- What informs the assessment
- Kanonik compares supplied agent permissions and payment rules with the confirmed authority matrix. The team's sandbox trace reaches releasable status without the required approval, including at the downstream execution gate.
- Response and checks
- The payment team enforces the human-approval condition in the payment system. Repeat sandbox requests deny an unapproved above-limit payment and permit the exact payment with a valid authorized approval.
- Who approves
- The finance control owner approves the agent-to-payment design with sandbox traces showing that above-limit requests need the required human approval at the payment gate.
- What prompts another review
- A changed agent permission or spending delegation may broaden the payment path. When it is recorded in Kanonik, the linked approval analysis goes back to the finance control owner.
Two maintenance changes remove both service paths
- The change
- A telecom operator approves maintenance on two network devices. Each request looks routine, but together they take down both paths serving the same enterprise customer during overlapping windows.
- The rule or commitment
- The customer's continuity commitment requires a viable service path during the proposed maintenance windows.
- What informs the assessment
- Kanonik compares both submitted changes with the operator's confirmed service topology and capacity review. The overlap removes both required paths without an approved alternative.
- Response and checks
- Network planning moves one maintenance window and repeats the combined-change review. Its acceptance results show an available path with the required capacity throughout each window.
- Who approves
- The network change manager approves the revised maintenance windows with the planner's path-and-capacity analysis showing a viable service route throughout the work.
- What prompts another review
- A later maintenance request can overlap the rescheduled work. When it is recorded in Kanonik, the affected service's continuity basis goes back to the network change manager.
A customer-service portal weakens access to call details
- The change
- A carrier redesigns online account recovery. The new workflow would disclose protected call details after matching only readily obtainable account information.
- The rule or commitment
- The carrier's confirmed recovery policy requires the specified identity assurance before disclosure of protected call details.
- What informs the assessment
- A synthetic user reaches protected details using only low-assurance information, without a compensating independent check. Kanonik compares the submitted recovery flow with that requirement and the team's negative access test.
- Response and checks
- The account team corrects the recovery and disclosure gates. Repeated tests deny the low-assurance attempt and allow access only after the approved independent checks.
- Who approves
- The customer information protection officer approves the complete recovery flow with negative tests showing that low-assurance information does not open the protected call-detail view.
- What prompts another review
- Removing an independent recovery check can weaken the accepted disclosure gate. When it is recorded in Kanonik, the linked authentication review goes back to the customer information protection officer.
A network-platform change drops billable usage records
- The change
- A carrier upgrades part of its network. Its new usage record type is ignored by the existing mediation process that feeds billing.
- The rule or commitment
- The charging specification requires billable usage types to reach rating or an explicit exception path.
- What informs the assessment
- Kanonik checks the supplied mediation mappings and per-type reconciliation. Billable synthetic sessions disappear before rating without creating exceptions.
- Response and checks
- The mediation team adds the new usage type and repeats the source-to-billing reconciliation. Counts and charges match the approved treatment, including legitimate zero-charge sessions.
- Who approves
- The revenue assurance manager approves the mediation mapping with source-to-billing counts and charge reconciliations for the new billable usage type.
- What prompts another review
- A new usage code or changed tariff eligibility can alter which sessions must reach billing. When it is recorded in Kanonik, the affected reconciliation basis goes back to the revenue assurance manager.
A support-vendor onboarding grants excessive subscriber access
- The change
- A carrier adds an outsourced support team for one customer segment. The proposed role grants export access across the entire subscriber base.
- The rule or commitment
- The support contract and access policy limit the vendor to its assigned customer segment and authorized operations.
- What informs the assessment
- The team's synthetic test retrieves subscriber records outside the vendor's approved segment. Kanonik compares the supplied service schedule with effective export access.
- Response and checks
- The identity and portal teams narrow the role and row filters. Repeat endpoint tests deny forbidden exports and retain permitted support access.
- Who approves
- The subscriber data owner approves the vendor role's segment-limited export scope using the service schedule and permitted/forbidden endpoint results.
- What prompts another review
- A revised service schedule may change the vendor's assigned segment, while a role update may change its effective export access. When it is recorded in Kanonik, the linked scope comparison goes back to the subscriber data owner.
An alerting migration removes a site's escalation recipient
- The change
- A network operator consolidates monitoring tools. Critical alarms from one region are imported, but their new regional label does not match any on-call routing rule.
- The rule or commitment
- The response procedure requires each critical regional alarm to reach an accountable responder and its escalation route.
- What informs the assessment
- An injected test-alarm trace shows the region's critical event reaching the dashboard but no required recipient. Kanonik compares the supplied label migration and on-call mapping.
- Response and checks
- Operations repairs the regional route and repeats the test injection. Delivery, acknowledgment and escalation results now match the approved response procedure.
- Who approves
- The network operations lead approves the regional alarm mapping with injected-alarm delivery and acknowledgment traces for the current on-call route.
- What prompts another review
- Regional relabeling or an on-call roster change can leave a route without a recipient. When it is recorded in Kanonik, the connected alarm coverage goes back to the network operations lead.
A storage cleanup would delete records still protected from disposal
- The change
- A U.S. federal agency replaces its document storage. The proposed cleanup applies an age-only deletion rule to records whose approved schedule or active legal hold still requires preservation.
- The rule or commitment
- The records officer's confirmed schedule and active hold instructions govern disposal eligibility for each record, not age alone.
- What informs the assessment
- It flags specific candidates that remain subject to preservation. Kanonik compares the supplied dry-run manifest with the authoritative record-series and hold mappings.
- Response and checks
- Records staff correct the selection rules and rerun the dry run. The new manifest confirms that the revised list of records to delete respects both the retention schedule and the holds.
- Who approves
- The agency records officer approves the corrected dry-run manifest against the applicable schedules and active holds; the review itself does not execute deletion.
- What prompts another review
- A new hold can change disposal eligibility after the manifest was reviewed. When it is recorded in Kanonik, the affected candidates go back to the agency records officer.
A benefits-platform update duplicates disbursements
- The change
- An agency replaces a benefits-payment interface. A timed-out request is resent with a new transaction reference even when the payment provider accepted the first request.
- The rule or commitment
- The program's payment procedure ties each disbursement to an authorized entitlement while permitting legitimate installments and adjustments.
- What informs the assessment
- Kanonik checks the supplied entitlement keys and provider acknowledgments. The team's controlled lost-response test produces two payable instructions for one obligation.
- Response and checks
- The payments team adds stable references and status reconciliation. Repeat timeout and retry tests produce one payable instruction for the test obligation while retaining separately authorized installments.
- Who approves
- The benefits payment controller approves the stable-reference and reconciliation design with synthetic lost-response results tied to the entitlement and disbursement ledger.
- What prompts another review
- Changed provider acknowledgment behavior can affect duplicate protection. When it is recorded in Kanonik, the linked payment-control basis goes back to the benefits payment controller.
A procurement role change permits self-approval
- The change
- An agency consolidates purchasing roles. The new role lets a requester approve their own purchase above the threshold requiring an independent official.
- The rule or commitment
- The agency's confirmed delegation matrix requires an independent authorized official for purchases above its threshold.
- What informs the assessment
- A sandbox purchase becomes a commitment through the requester's own approval without a separate final gate. Kanonik compares the supplied requester identities and approval routes with that matrix.
- Response and checks
- The procurement team restores the independent approval route. Repeat tests deny above-threshold self-approval and allow a separately authorized official to complete the commitment.
- Who approves
- The procurement control officer approves the approval route with above- and below-threshold traces showing that the requester cannot make the restricted commitment alone.
- What prompts another review
- A new delegation or requester-role assignment can change who qualifies as independent. When it is recorded in Kanonik, the connected purchasing decision goes back to the procurement control officer.
A publication workflow includes restricted attachments
- The change
- A local agency automates publication of meeting materials. The new workflow exports every attachment, including documents already marked for restricted handling by the authorized reviewer.
- The rule or commitment
- The publication procedure permits only the versions cleared by the authorized release reviewer.
- What informs the assessment
- It flags an attachment explicitly barred from public release rather than making its own public-records exemption decision. Kanonik compares the submitted staging manifest with reviewed attachment classifications.
- Response and checks
- The publishing team excludes the restricted original and selects any approved redacted version. A repeated staging export and access test shows only the cleared material in the public output.
- Who approves
- The agency publication officer approves the staging manifest after matching each attachment to its reviewed public version, authorized redaction or exclusion.
- What prompts another review
- An updated attachment or release classification can outdate the approved manifest. When it is recorded in Kanonik, the linked publication basis goes back to the agency publication officer.
Identity migration disconnects departed workers from revocation
- The change
- An agency moves applications to a new identity provider. One application's accounts remain matched by obsolete employee identifiers, so termination events no longer revoke them.
- The rule or commitment
- The access-removal policy requires termination events to revoke the worker's usable application access within the specified deadline.
- What informs the assessment
- Kanonik checks the supplied personnel-to-account crosswalk and deprovisioning results. A synthetic departure leaves sign-in or active-session access usable beyond that deadline.
- Response and checks
- The identity team repairs the employee-ID mapping and revocation route. Repeated departure tests deny sign-in and end the required sessions within the policy window.
- Who approves
- The agency identity governance lead approves the personnel-to-account crosswalk with synthetic departure results showing sign-in and session access end within the policy deadline.
- What prompts another review
- New personnel identifiers or application account links may break revocation matching. When it is recorded in Kanonik, the connected deprovisioning evidence goes back to the agency identity governance lead.
A new advisor role exposes unrelated student records
- The change
- A university reorganizes advising teams. The proposed system role grants full academic-record access to every student instead of the students and duties authorized for that advisor.
- The rule or commitment
- The institution's confirmed legitimate-interest criteria limit an advisor's access to authorized duties and valid exceptions.
- What informs the assessment
- A synthetic advisor test retrieves records outside its established duties and permitted exceptions. Kanonik compares the supplied student assignments and role rules with those criteria.
- Response and checks
- The access team restricts the role and repeats the test set. Unrelated records are denied while legitimate cross-team advising access remains available.
- Who approves
- The student records privacy officer approves the advising role using duty assignments, legitimate-interest criteria and tests covering both forbidden records and permitted cross-team access.
- What prompts another review
- A reassigned advisor or revised institutional exception changes the access basis. When it is recorded in Kanonik, the connected student-record review goes back to the student records privacy officer.
Framework context: FERPA
A research-storage move grants a collaborator excessive access
- The change
- A university moves a research project to a shared workspace. An external collaborator receives access to identifiable participant data although their data-use agreement covers only a de-identified dataset.
- The rule or commitment
- The executed data-use agreement and approved protocol authorize the collaborator for a de-identified dataset, not identifiable participant records.
- What informs the assessment
- A test account set up as the collaborator can read identifiable data outside that scope.
- Response and checks
- The research IT team separates permissions and repeats allowed and forbidden access tests. The collaborator can use the approved dataset but cannot retrieve identifiable participant data.
- Who approves
- The research data steward approves the collaborator's workspace access after reviewing the access tests against the data-use agreement.
- What prompts another review
- A revised protocol or dataset classification can change the collaborator's entitlement. When it is recorded in Kanonik, the connected agreement-to-access comparison goes back to the research data steward.
A finance migration charges a grant after its permitted period
- The change
- A university changes project accounting. The new workflow permits a newly incurred expense outside an award's authorized period, despite the institution's required grant review.
- The rule or commitment
- The award's confirmed terms and amendments require review of newly incurred expenses outside the authorized period.
- What informs the assessment
- A boundary test posts a clearly out-of-period expense without review or applicable authorization. Kanonik compares the submitted expense incurrence dates and award terms with the posting rules.
- Response and checks
- The finance team restores the grant-review gate and repeats boundary-date tests. Unsupported out-of-period expenses route for review, while valid in-period costs and authorized closeout payments retain their proper treatment.
- Who approves
- The grants compliance officer approves the award-period posting rules with boundary-date test expenses, applicable amendments and the required review path for exceptions.
- What prompts another review
- An award extension may change the permitted period; a feed change may alter the expense date used. When it is recorded in Kanonik, the linked allowability basis goes back to the grants compliance officer.
A student-system migration loses restoration of key records
- The change
- A university moves its student-information system. The proposed backup job includes the main database but omits a separate document store containing required supporting records.
- The rule or commitment
- The recovery plan requires complete student records, including the documents held outside the main database.
- What informs the assessment
- The university's isolated restore exercise recovers database entries but cannot recover their required documents from an approved source. Kanonik compares the supplied component inventory with backup coverage.
- Response and checks
- The infrastructure team adds the document store to the recovery plan and repeats the complete-record restore. The submitted results recover both database entries and their linked documents.
- Who approves
- The student systems recovery owner approves the expanded backup plan with isolated restore results for complete records, including their supporting documents.
- What prompts another review
- A new document store or changed database reference can leave records outside the tested backup scope. When it is recorded in Kanonik, the linked recovery conclusion goes back to the student systems recovery owner.
Account cleanup would delete active research data
- The change
- A university introduces automatic deletion of storage owned by departed researchers. A graduating researcher's account owns the only retained copy of data still required for an active funded study.
- The rule or commitment
- The active study's confirmed data-management plan requires retained institutional custody even after its researcher leaves.
- What informs the assessment
- The candidates include data still under retention, without a verified retained copy satisfying the plan. Kanonik compares the supplied cleanup dry run with dataset-to-study and archive records.
- Response and checks
- Research IT transfers custody and creates the approved archive before cleanup. Its restore test recovers the retained dataset, and the repeated dry run excludes the protected institutional copy.
- Who approves
- The research records owner approves the custody transfer and revised cleanup list using the study's retention terms and verified evidence of the retained copy.
- What prompts another review
- A storage ownership change or revised study-retention term can alter cleanup eligibility. When it is recorded in Kanonik, the connected custody decision goes back to the research records owner.
Reuse the right questionnaire answer for the right product
- The change
- A SaaS vendor answers two buyers' security questionnaires. One product has a tested recovery process; a newly acquired product does not yet have equivalent evidence. An approved answer for the first product should not become an unsupported company-wide answer.
- The rule or commitment
- An approved recovery answer for one product does not establish recovery assurance for a newly acquired product.
- What informs the assessment
- Kanonik keeps the saved answer with its recorded product scope and basis. The reviewer checks whether the destination question concerns the same product; automatic semantic scope matching is not assumed.
- Response and checks
- Retrieve the first product's answer with its scope intact. For the second product, require review and suitable evidence rather than silently reusing the assurance. Test two nearly identical questions with different product scope.
- Who approves
- The questionnaire owner approves the result after reviewing the stated checks.
- What prompts another review
- Connected product scope or recovery evidence changes. When it is recorded in Kanonik, the saved answer goes back to the questionnaire owner. A newer answer for another product is not substitute support.
Export the answers that were actually reviewed
- The change
- A sales team uses the questionnaire skill to prepare a buyer response. A draft says backups are tested monthly, but the approved answer says quarterly. The export must reflect the approved version.
- The rule or commitment
- An exported quarterly backup-testing answer must not be replaced by an unapproved monthly-testing draft.
- What informs the assessment
- Kanonik's questionnaire workflow provides the answer versions and approval states for review. The export comparison must establish which version reaches each row and keep unresolved answers explicit.
- Response and checks
- Compare every exported answer to its selected approved version. Include an unapproved draft and an unanswered question; neither may be silently presented as approved. Keep any unresolved status explicit.
- Who approves
- The questionnaire release owner approves the result after reviewing the stated checks.
- What prompts another review
- Selected answers, approval states or export mappings change. When it is recorded in Kanonik, the version-to-export comparison goes back to the questionnaire release owner.
Show exactly what supports a customer promise
- The change
- A provider has told a customer that its support service uses approved processors for customer transcripts. A reviewer needs to establish which service, processor list, and approval version supported that statement.
- The rule or commitment
- A current processor list cannot silently replace the historical basis of an earlier customer promise.
- What informs the assessment
- Kanonik links the saved claim to its pinned approval version and service scope. Reviewers distinguish what supported the original statement from whether today's evidence still supports it.
- Response and checks
- Reconstruct the original basis even after a newer list exists. Reject cross-product or wrong-data-category support. Distinguish historical basis from whether the claim remains supportable now.
- Who approves
- The service assurance owner approves the result after reviewing the stated checks.
- What prompts another review
- A connected processor-approval change affects present support. When it is recorded in Kanonik, present support goes back to the service assurance owner. The historical basis used for the original answer is retained.
Turn a specific promise into an owned obligation
- The change
- A service contract requires customer notice before a named category of subcontractor change. The assurance team needs that obligation recorded with a responsible owner and its actual scope.
- The rule or commitment
- The notice obligation must preserve the executed clause's scope and exceptions and identify an accountable owner.
- What informs the assessment
- Kanonik holds the obligation and its source reference after human confirmation. The contract reviewer resolves interpretation; recording a clause does not establish automatic detection of every triggering change.
- Response and checks
- The recorded obligation preserves qualifications and points to an owner. Test a clause containing an exception; a reviewer must confirm the interpretation rather than treating a model's extraction as settled law.
- Who approves
- The contract obligation owner approves the result after reviewing the stated checks.
- What prompts another review
- Connected contract versions, confirmed scope or ownership change. When it is recorded in Kanonik, the obligation goes back to the contract obligation owner.
A verifier rejects an unsupported security claim
- The change
- A team proposes the answer "all privileged accounts require multifactor authentication." The supplied evidence is a general policy statement, while a dated configuration export shows an excluded administrator group.
- The rule or commitment
- A universal multifactor-authentication claim conflicts with an in-scope excluded administrator group in the supplied configuration evidence.
- What informs the assessment
- Kanonik's Verifier reviews the proposed claim against the submitted inventory and configuration. A supported exclusion is a concrete contradiction; an undated policy brochure alone leaves deployment unverified.
- Response and checks
- Show the concrete contradiction for an in-scope unprotected account. With only an undated policy brochure, return insufficient evidence instead. Include a properly scoped exception case to test overbroad conclusions.
- Who approves
- The security assurance owner approves the result after reviewing the stated checks.
- What prompts another review
- Connected account inventories, authentication evidence or approved exceptions change. When it is recorded in Kanonik, the claim goes back to the security assurance owner.
A reviewer approves only the decision placed before them
- The change
- A security owner accepts a vendor for non-sensitive diagnostic logs. A later request includes full customer transcripts. The earlier approval must not be treated as authorization for the broader use.
- The rule or commitment
- Approval for diagnostic logs does not authorize the later use of full customer transcripts.
- What informs the assessment
- Kanonik preserves the human decision against its proposal and scope. The broader request needs its own review; submitting that request is not completing approval.
- Response and checks
- Preserve the original approval and identify the broader request as requiring its own decision. Verify that submitting a request is not recorded as completing approval.
- Who approves
- The security owner approves the result after reviewing the stated checks.
- What prompts another review
- A later data-category, service or validity change affects the recorded approval. When it is recorded in Kanonik, the recorded approval goes back to the security owner.
Live assurance: changed evidence makes a saved answer need review
- The change
- A supplier's saved answer relies on a vendor approval record. That record is superseded after its permitted data-use scope changes. The old answer should be brought back to a reviewer.
- The rule or commitment
- A saved answer's supporting vendor approval changes scope, so its old acceptance no longer establishes current support.
- What informs the assessment
- Kanonik uses the recorded dependency and supported basis-change event to return the affected answer for review. Staleness is a reason to reassess, not proof that the underlying control failed.
- Response and checks
- Exercise the actual supported basis-change path and show a review-needed reason. An unrelated evidence update must not mark every answer stale. Do not assume every possible source change is currently detected.
- Who approves
- The vendor assurance owner approves the result after reviewing the stated checks.
- What prompts another review
- A connected supersession arrives. When it is recorded in Kanonik, the affected answer goes back to the vendor assurance owner. An unrelated evidence update must not mark every answer stale.
An agent attaches evidence without inventing an observation
- The change
- An authorized agent helps a consultant assemble a vendor-review record. It can access a signed approval document but cannot access the vendor's live configuration.
- The rule or commitment
- A document the agent can read is not a live configuration observation it cannot obtain.
- What informs the assessment
- Kanonik receives the attributable evidence reference through the customer's authorized agent. An inaccessible source stays unavailable; the agent's existing source access does not extend to every action.
- Response and checks
- Store the attributable document reference without describing it as a live observation. A denied configuration read remains unavailable. Directed evidence collection is a separate roadmap capability.
- Who approves
- The evidence review owner approves the result after reviewing the stated checks.
- What prompts another review
- A new authorized source result arrives, or its provenance, scope or age changes. When it is recorded in Kanonik, recorded support goes back to the evidence review owner.
Check an exported record for altered content
- The change
- A supplier exports a signed assurance record. A recipient's copy has been edited to remove a scope limitation.
- The rule or commitment
- Removing a limitation changes the meaning of an exported assurance; integrity depends on what the signature actually covers.
- What informs the assessment
- Kanonik supplies verification material for the supported signed coverage. The recipient checks the original and edited copies and reports uncovered material separately; signature validity is not evidence freshness or truth.
- Response and checks
- The original verifies under the supported mechanism; the altered content fails or is explicitly outside the signed coverage. Report what was actually protected.
- Who approves
- The assurance export owner approves the result after reviewing the stated checks.
- What prompts another review
- Export formats, signing material or manifests change. When it is recorded in Kanonik, the coverage check goes back to the assurance export owner. An offline artifact cannot establish later status changes.
The dashboard exposes unfinished assurance work
- The change
- A small business prepares a questionnaire. Some answers are approved, one needs supporting evidence, and another awaits its owner. The dashboard should help the team finish the work without implying everything is complete.
- The rule or commitment
- Unanswered, evidence-needed and owner-pending items must not disappear behind a questionnaire completion count.
- What informs the assessment
- Kanonik's dashboard exposes recorded work states for follow-up. Counts must reconcile to the underlying records, including unassigned work; completion is not an overall compliance score.
- Response and checks
- Each displayed count and task links to the underlying record and state. An unassigned item remains visible rather than disappearing from owner-specific queues.
- Who approves
- The assurance program owner approves the result after reviewing the stated checks.
- What prompts another review
- Connected answer-state, ownership or filter changes. When it is recorded in Kanonik, the dashboard view goes back to the assurance program owner.
Rehearse an AI-tool change before it weakens a customer promise
- The change
- A company wants to add an AI tool that summarizes support tickets. The tool uses a new processor and handles customer transcripts.
- The rule or commitment
- The existing customer answer covers an approved processor for diagnostic logs, not a new processor or transcripts.
- What informs the assessment
- Kanonik rehearses the proposed change against the conditions your team confirmed and the links in the record, without changing the accepted record. It shows the affected promise and the missing scope review, and does not declare a legal breach.
- Response and checks
- A correct result names the affected promise and the missing review, shows how they connect and leaves the accepted record unchanged, including for an unaffected product and an unknown data category.
- Who approves
- The support service owner approves the result after reviewing those checks.
- What prompts another review
- A change to processor approvals, data categories or the links in the record affects the claim. When it is recorded in Kanonik, the affected claim goes back to the support service owner. Unaffected products keep their own support.
The same user's action needs fresh assurance today
- The change
- A procurement manager could previously send a dataset to a vendor. Today the vendor's required review has expired, even though the manager's access permissions are unchanged.
- The rule or commitment
- Unchanged identity permissions do not make yesterday's vendor review valid for today's data transfer.
- What informs the assessment
- A planned preflight check would test this transfer against the scope and freshness conditions your team confirmed. It would report needs evidence, needs approval or prohibited, with reasons, and would advise rather than block the transfer.
- Response and checks
- A correct result returns needs evidence or needs approval, as the rule requires, without reusing yesterday's result. Supported and prohibited variants keep their condition-level reasons too.
- Who approves
- The data transfer owner approves any consequential decision after reviewing the result.
- What prompts another review
- A change in evidence or timing would trigger a new check of this exact transfer. When it is recorded in Kanonik, this exact transfer goes back to the data transfer owner.
Ask another agent for the one missing approval record
- The change
- An AI-tool request is waiting for a dated vendor approval covering customer transcripts. Instead of asking an agent to assess the entire vendor, the planned Kanonik workflow would request that specific record.
- The rule or commitment
- A general brochure cannot resolve the missing dated approval for this vendor and customer-transcript use.
- What informs the assessment
- Planned directed evidence work would request that exact record from an authorized customer agent and check the return's provenance, scope and dates. Access denial would leave the condition unresolved rather than inventing an observation.
- Response and checks
- Accept a matching valid approval for review; reject a brochure, wrong-vendor record, expired approval, and fabricated provenance. Access denial remains unresolved. Recompute only after evidence validation.
- Who approves
- The vendor review owner approves any consequential decision after reviewing the result.
- What prompts another review
- A returned record would trigger reevaluation only after validation. When it is recorded in Kanonik, the vendor-review request goes back to the vendor review owner. Collection requests would not expand the agent's source permissions.
Record why a particular action was supportable
- The change
- A reviewer permits a support-data pilot for one service, one vendor, and one week. A receipt must preserve the limited decision instead of becoming a reusable blanket vendor approval.
- The rule or commitment
- A one-service, one-vendor, one-week pilot decision must not become blanket permission or make old observations fresh.
- What informs the assessment
- The planned Kanonik decision receipt would bind the request, evidence times, human decision, audience and limitations. It would describe the basis of the decision, not prove that an action happened.
- Response and checks
- A reader can reconstruct what was checked, what the person approved, and what remains uncertain. A different service, recipient, or time window does not inherit the decision.
- Who approves
- The pilot decision owner approves any consequential decision after reviewing the result.
- What prompts another review
- A material scope change or expiry would require a new decision. When it is recorded in Kanonik, the pilot decision goes back to the pilot decision owner. The historical receipt would retain the original evidence ages and limits.
An independent buyer tool can reject an unsuitable receipt
- The change
- A supplier sends a signed assurance receipt to a buyer. The signature is valid, but the receipt covers another product or relies on observations older than the buyer accepts.
- The rule or commitment
- A valid signature does not make a receipt acceptable for a different product, audience or evidence-age requirement.
- What informs the assessment
- The planned independent consumer would assess proof separately from the buyer's agreed reliance profile. Unknown issuer, wrong scope, stale basis or missing status would have distinct reasons.
- Response and checks
- The consumer distinguishes proof validity from acceptance. Test wrong audience, unknown issuer, stale evidence, missing status, and a fully matching case without requiring unrelated supplier records.
- Who approves
- The buyer assurance owner approves any consequential decision after reviewing the result.
- What prompts another review
- Later use of the receipt applies the agreed age and status policy. When it is recorded in Kanonik, the receipt goes back to the buyer assurance owner. Readable content could still be copied despite an audience label.
Guided entry captures the details that determine the answer
- The change
- An operations manager asks, "Can we use this AI assistant?" A guided entry flow narrows the request to the actual service, data category, vendor, and intended use before evaluation.
- The rule or commitment
- The request lacks the service, data category, vendor and purpose needed to choose applicable conditions.
- What informs the assessment
- Planned guided entry would ask for material missing details and confirm canonical identities rather than guessing between similarly named vendors. It would leave unknown data classifications visible.
- Response and checks
- Ask for a material missing field instead of inventing it. Test two similarly named vendors and a user who does not know the data category; retain the uncertainty.
- Who approves
- The request owner approves any consequential decision after reviewing the result.
- What prompts another review
- The requester supplies or changes material facts. When it is recorded in Kanonik, condition selection goes back to the request owner.
Managed AI assists review without enlarging authority
- The change
- A small customer enables a hosted AI assistant to prepare a vendor review. A retrieved document contains text telling the assistant to mark the vendor approved and send unrelated records elsewhere.
- The rule or commitment
- Instructions inside a retrieved document do not authorize the assistant to approve a vendor or disclose unrelated records.
- What informs the assessment
- The managed-AI experiment would separate the authorized task from untrusted source content and restrict tool actions to explicit grants. A sourced draft or abstention would remain subject to human review.
- Response and checks
- Treat document instructions as evidence content, not authority. Produce a sourced draft or abstain; do not approve or disclose outside the granted workflow.
- Who approves
- The AI service owner approves any consequential decision after reviewing the result.
- What prompts another review
- Candidate model, tool-permission or instruction changes. When it is recorded in Kanonik, the managed-AI review goes back to the AI service owner.
One useful integration exposes a missing backup requirement
- The change
- A customer wants a single cloud integration for database-change review. A proposed migration sets seven-day retention, while the service's confirmed internal recovery requirement is 30 days.
- The rule or commitment
- A seven-day backup proposal falls short of the service's confirmed 30-day recovery requirement unless an adequate historical source closes the gap.
- What informs the assessment
- A planned narrow integration would supply only its supported database settings, scope and observation time to Kanonik. Unknown settings would remain unknown; restoration would require the customer's separate test evidence.
- Response and checks
- Flag the mismatch if no other approved recovery source closes it. Test unknown settings and a satisfied alternative. State exactly which platform resources the connector covers.
- Who approves
- The service recovery owner approves any consequential decision after reviewing the result.
- What prompts another review
- Later supported-source updates arrive. When it is recorded in Kanonik, the scoped comparison goes back to the service recovery owner.
Give a buyer the relevant assurance without the whole evidence room
- The change
- A buyer asks whether a supplier's payroll service has a recently tested recovery process. The supplier should answer that request without exposing other products' incidents or unrelated customer records.
- The rule or commitment
- The buyer needs a product-specific recovery answer, not the supplier's unrelated incidents or customer records.
- What informs the assessment
- Planned structured exchange would match the request to authorized claims and necessary context under the supplier's disclosure policy. Redaction would preserve material limitations rather than conceal them.
- Response and checks
- Produce only the authorized claim and necessary context, with explicit acceptance criteria. Test a request for an unrelated product and ensure the response does not disclose its records or even sensitive record metadata.
- Who approves
- The supplier disclosure owner approves any consequential decision after reviewing the result.
- What prompts another review
- The request, recipient permission or supporting scope changes. When it is recorded in Kanonik, the disclosure goes back to the supplier disclosure owner.
A buyer learns that yesterday's receipt now needs review
- The change
- A supplier changes a processor that supported an assurance already shared with a buyer. The historical receipt remains intact, but its current reliance status changes to review-needed or superseded.
- The rule or commitment
- A historical receipt can remain cryptographically valid after a processor change makes present reliance unsupported.
- What informs the assessment
- Planned maintained status would expose review-needed, expired or superseded states to authorized consumers without rewriting the signed history. Delayed or unavailable status would not silently count as current support.
- Response and checks
- Deliver or expose the changed status without rewriting the signed history. Test expiry, supersession, revoked access, delayed delivery, and service unavailability. Unknown status must not silently become current support.
- Who approves
- The external assurance owner approves any consequential decision after reviewing the result.
- What prompts another review
- A connected basis change arrives. When it is recorded in Kanonik, the reliance status goes back to the external assurance owner.
A procurement gateway acts on current, bounded assurance
- The change
- A procurement workflow is about to activate a vendor for customer transcripts. Kanonik's last recommendation was supported, but a material review expired before activation.
- The rule or commitment
- A supported recommendation becomes stale before the procurement gateway activates the vendor.
- What informs the assessment
- The planned integration would compare action context, decision age and changed basis in shadow mode before binding use. Kanonik would supply assurance context; the customer's integrated gateway would enforce its configured hold and override rules.
- Response and checks
- Start in shadow mode, comparing recommendations with reviewer decisions. Before binding use, prove that expired, wrong-scope, changed-basis, and unavailable results follow the configured hold/override policy and identify the incident owner.
- Who approves
- The procurement gateway owner approves any consequential decision after reviewing the result.
- What prompts another review
- The gateway is used with changed context or freshness. When it is recorded in Kanonik, the assurance context goes back to the procurement gateway owner.
Request the evidence most likely to resolve the decision
- The change
- A vendor request lacks several documents. A current scope-specific approval could settle the immediate question, while a lengthy general security questionnaire would not resolve the missing condition.
- The rule or commitment
- Collecting a broad questionnaire would leave the immediate scope-specific approval condition unresolved.
- What informs the assessment
- Planned evidence planning would rank authorized requests against modeled decision value, effort and dependencies. A known prohibition would not be disguised as a paperwork gap that more collection can cure.
- Response and checks
- Rank the scope-specific approval request first under the declared ranking method. Test inaccessible evidence, a known prohibition that more evidence cannot cure, and two alternative valid sources.
- Who approves
- The vendor assurance practitioner approves any consequential decision after reviewing the result.
- What prompts another review
- Source access, returned evidence or blocking conditions change. When it is recorded in Kanonik, the ranking goes back to the vendor assurance practitioner.
A consultant takes over a client without mixing its assurance records
- The change
- An advisory firm manages several clients and two products within one client. A replacement consultant needs open decisions and their basis, while access to other clients remains restricted.
- The rule or commitment
- A consultant handover needs the intended client's open decisions without exposing another client's identically named records.
- What informs the assessment
- Planned portfolio operations would retain client and product boundaries while handing over work, basis and unresolved questions. Access changes would follow explicit membership and revocation decisions.
- Response and checks
- The replacement sees the intended work and unresolved questions; the prior consultant loses access as required. Test identical document names in two clients and measure manual handover effort.
- Who approves
- The advisory practice owner approves any consequential decision after reviewing the result.
- What prompts another review
- A later handover occurs. When it is recorded in Kanonik, the isolation and revocation checks go back to the advisory practice owner.
A buyer accepts assurance from a known issuer for the right purpose
- The change
- A supplier reuses a scoped recovery assurance with several buyers. One buyer accepts that issuer and evidence age; another requires a different assurance source or more recent observation.
- The rule or commitment
- Different buyers can legitimately reject the same signed assurance under different issuer, scope and age policies.
- What informs the assessment
- The planned assurance network would compare each recipient's acceptance profile with the supplied receipt and current status. Participation would not establish issuer competence, regulatory recognition or universal acceptance.
- Response and checks
- Return different, explained acceptance results where buyer policies differ. Test a validly signed receipt from an unaccepted issuer and an accepted issuer making an out-of-scope assertion.
- Who approves
- The buyer reliance owner approves any consequential decision after reviewing the result.
- What prompts another review
- The receipt is reused. When it is recorded in Kanonik, the acceptance check goes back to the buyer reliance owner.
One agent verifies a proposed action and another returns what actually happened
- The change
- A purchasing agent requests a bounded decision to activate a vendor for one data category. The execution agent must act on those exact parameters and return a record of the actual activation.
- The rule or commitment
- An agent's completion message does not establish that the authorized vendor, data category and service were actually activated.
- What informs the assessment
- Planned execution receipts would correlate the bounded decision with separately authorized execution and an attributable target-system observation. Substituted parameters, expiry and failed execution would remain visible.
- Response and checks
- Match the executed vendor, data category, and service to the decision. Detect substituted parameters, expired decisions, duplicate requests, and attempted-but-failed execution. Treat an uncorroborated agent report as an assertion.
- Who approves
- The vendor activation owner approves any consequential decision after reviewing the result.
- What prompts another review
- Later retries or changed execution parameters occur. When it is recorded in Kanonik, the execution correlation goes back to the vendor activation owner.
An agent's delegated authority ends when the pilot ends
- The change
- A company authorizes an agent to collect vendor-review documents for a two-week pilot. After the delegation expires or is revoked, the same agent must no longer collect under that authority.
- The rule or commitment
- A two-week document-collection delegation must not become indefinite access after expiry or revocation.
- What informs the assessment
- Planned delegated authority would record purpose, source scope, validity and revocation. The executing system would have to check those limits, including when cached authority is presented.
- Response and checks
- Allow an in-scope request during validity; deny or hold an out-of-purpose, expired, revoked, or uncheckable request under the agreed policy. Test cached authority after revocation.
- Who approves
- The delegating vendor-review owner approves any consequential decision after reviewing the result.
- What prompts another review
- The delegated authority is used. When it is recorded in Kanonik, current validity and revocation go back to the delegating vendor-review owner.
A remediation plan stays within approved, reversible steps
- The change
- A backup review finds a configuration gap. An agent proposes gathering settings, preparing a configuration change, obtaining owner approval, applying it through the authorized workflow, and checking the result.
- The rule or commitment
- A backup correction plan must not insert destructive operations or enlarge the approved change.
- What informs the assessment
- The planned constrained workflow would check each step, its permissions and outputs. The customer's independently authorized tools would execute any approved change, followed by target-state verification rather than an agent's unsupported completion claim.
- Response and checks
- Reject an inserted destructive step or scope expansion. Require approval before the governed write and verify the target state rather than accepting a "done" message.
- Who approves
- The backup change owner approves any consequential decision after reviewing the result.
- What prompts another review
- A revised step or material parameter appears. When it is recorded in Kanonik, the plan scope goes back to the backup change owner.
Another system understands the assurance without pretending formats are interchangeable
- The change
- A customer wants assessment findings in OSCAL, a scoped claim exchange using a credential profile, and an existing agent gateway to enforce a decision.
- The rule or commitment
- Exporting to an exchange format must preserve scope, timing and uncertainty rather than treat different standards as interchangeable.
- What informs the assessment
- Planned interoperability would map the canonical record under an explicit profile and test an independent consumer. OSCAL assessment results, credential exchange and gateway enforcement would remain separate integrations.
- Response and checks
- Preserve scope, evidence dates, uncertainty, and references across export/import. Unsupported semantics must be rejected or labeled, not dropped. Verify each profile separately.
- Who approves
- The assurance integration owner approves any consequential decision after reviewing the result.
- What prompts another review
- A profile or consumer revision occurs. When it is recorded in Kanonik, the export mapping goes back to the assurance integration owner.
Feature glossary
#live-assuranceLive assurance
Kanonik connects saved claims to their evidence and decisions so changes to recorded support can bring an answer back for review. This keeps the program useful between audits without implying that every external change is detected.
#change-rehearsalForesight
Foresight compares a proposed change with your approved promises before you make it: adding a vendor or replacing one. For each promise it shows No conflict, Conflict, Needs information or Not applicable, with the facts it used, and it writes nothing to the accepted record. It is a check against recorded commitments, not an automatic legal verdict.
#continuous-recheckingContinuous rechecking
Connected checks are revisited when a relevant recorded basis changes. A missing or unreported source change remains a limit; rechecking does not mean constant discovery of every system.
#byomBring your own model
Use a compatible AI your organization has chosen and approved to prepare compliance work in Kanonik. The program record stays in Kanonik when you change models, while source access remains under your control and submitted material still enters Kanonik.
#mcpModel Context Protocol
MCP is a standard connection through which compatible AI applications use Kanonik tools and records. It lets your chosen AI prepare work for review without implying compatibility with every client or permission to every source.
#agentic-workflowsAgent-led workflows
AI uses tools to prepare related pieces of compliance work, submit proposals, and respond to feedback. Permission to prepare work is separate from authority to approve it.
#canonical-modelOne connected record
Kanonik keeps controls, risks, evidence references, and claims in a shared structure used by AI tools and reviewers. Related information can be reused without treating different products or framework requirements as interchangeable.
#governed-writesControlled record changes
Proposed changes are kept separate from accepted company records and pass through checking and approval. The workflow makes responsibility visible; the controls required for each record type still need confirmation.
#two-tier-verificationRules and model review
Kanonik combines defined rule checks with a separate model review of proposed work. These checks can identify missing fields and unsupported explanations, but passing them does not prove that a real-world control worked.
#human-approvalHuman approval
A named reviewer examines proposed work and its checking results, then accepts it or sends it back. An AI proposal or a collected document is not the human decision.
#separation-of-dutiesSeparation of duties
Sensitive work separates the responsibility for proposing a change from the responsibility for approving it. Independent approval rules and documented exceptions need to fit the team and record being reviewed.
#scoped-approvalsScoped approvals
An approval covers defined work rather than unrestricted permission for an agent. Kanonik uses signed, short-lived, single-use approval tokens, while a broader request needs its own decision.
#evidence-linked-claimsEvidence-linked claims
A saved statement points to the records and versions used to support it. Those links help a reviewer inspect the basis but do not establish that the source is authentic or that the statement is true.
#evidence-freshnessEvidence freshness
Recorded support is assessed for whether it is recent enough and still applicable to a claim. An old or superseded basis calls for review, not an automatic finding that the control failed.
#data-provenanceEvidence origin
Kanonik retains information about submitted evidence and the proposals, checks, and decisions that shaped a record. An agent-supplied reference remains different from an observed system result, and not every intermediate step is retained.
#event-sourcingEvent history
The current program record is built from a sequence of recorded changes. That history helps explain earlier states without promising a replay of every AI thought or intermediate draft.
#hash-chained-historyHash-chained history
Cryptographic links connect recorded events so a recipient can check the covered history against a trusted reference. This makes alteration detectable within that coverage, not impossible, and does not prove the events describe reality.
#signed-recordsDigitally signed records
A digital signature lets a recipient check that covered data matches what a particular key signed. The recipient still needs to trust the key and check which content is covered; signature validity does not establish factual truth.
#offline-verificationOffline verification
Recipients can check covered exported history locally with its verification materials, without joining the Kanonik workspace. These checks do not establish current status changes after export or validate every surrounding file and assertion.
#decision-lineageDecision history
Recorded approvals, send-backs, and revisions help explain how a decision developed. The retained path is useful context, not a complete record of every draft or all AI reasoning.
#bitemporalTwo-date history
Historical reads distinguish when a fact applied from when it was recorded. Support for those reads does not mean every record type supports backdated corrections or complete historical writing.
#framework-agnosticFramework-independent record
The underlying program record is separate from the framework used to assess it. Requirements and mappings can reuse relevant information, but shared records do not make standards equivalent or establish certification.
#least-privilegeLeast privilege
Give an account or agent only the access needed for its authorized task. Source permissions remain under customer control, and permission to read evidence does not grant permission to approve work.
#skill-provenanceInstruction origin
Signed skill bundles and activation records help identify the instructions supplied to an AI. They do not prove the model followed them or provide complete instruction-to-decision tracking.
#deterministic-coreDefined rules and record structure
Ordinary code handles exact record structure and defined checks while model review handles questions needing judgment. Predictable code can still contain defects, and model judgments remain uncertain.
#portable-assurancePortable assurance
Audit exports carry recorded history and local verification materials outside Kanonik. This is proof of the covered record, not proof of real-world truth, automatic migration, or a promise that a recipient will accept it.
#preflightEvidence-based preflight
Planned preflight checks a specific action against human-confirmed conditions and evidence for the relevant time. It distinguishes supported, needs evidence, needs approval, and rule-prohibited findings; advice alone does not block or authorize execution.
#directed-evidenceDirected evidence collection
Planned collection requests name the evidence needed to resolve one uncertainty and the sources an authorized agent may use. Returned material needs checks for relevance, age, and origin, and an access denial remains unresolved.
#recipient-scopedRecipient-specific exchange
Planned exchange answers a buyer with claims and context limited to the authorized product, purpose, and recipient. Disclosure must retain material limits, and naming a recipient does not prevent copying readable content.
#policy-interopPolicy gateway integration
Planned integrations supply assurance context to existing procurement, agent, or deployment gateways. Each needs tested context matching, age limits, override authority, and outage behavior; the gateway is the enforcement point.
#execution-receiptsExecution receipts
Planned receipts connect an authorized task to an attributable result and post-action observation. They distinguish attempted, failed, and completed work rather than treating an agent completion message as proof.
#questionnairesQuestionnaire workflow
Kanonik organizes customer questions and the answers being prepared for them. Review states and supporting records help distinguish a draft response from an accepted company answer.
#saved-answersSaved answers
Saved answer versions let a team reuse earlier work with its supporting basis. Reuse still needs review for the destination question and product rather than assuming similar wording means the same scope.
#answer-setsAnswer sets
An answer set groups selected answer versions for a particular questionnaire response. Membership and review state help keep a product-specific answer from becoming an unsupported company-wide statement.
#answer-exportQuestionnaire answer export
Questionnaire export takes selected answers out of the working response for sharing. Review should reconcile the output with the intended approved versions and preserve unanswered or unresolved items.
#questionnaire-skillQuestionnaire skill
A dedicated skill gives the AI instructions for preparing questionnaire work in Kanonik. It assists preparation and does not acquire the authority to approve its own answers.
#product-scopeProduct and data scope
Claims and their supporting basis identify the service, product, and data use they cover. A record for one product should not be treated as evidence for another without a scope review.
#pinned-basisPinned evidence versions
A claim can retain references to the particular supporting record versions used when it was prepared. This preserves the historical basis even when newer records exist, not the continued truth of that basis.
#obligation-recordsOwned obligation records
Kanonik records a specific commitment with its source, scope, and responsible owner. A reviewer confirms qualifications and interpretation; recording an obligation does not automatically detect every event that might trigger it.
#basis-changeChanged-basis review
A recorded change or supersession can identify saved answers whose supporting basis needs another look. This concerns connected, supported change paths, not a guarantee that every update in every source is observed.
#assurance-dashboardAssurance work dashboard
The dashboard brings questionnaire and review work into a view of what is approved, unfinished, or waiting for an owner. Its counts describe recorded workflow states rather than an overall compliance score.
#decision-receiptScoped decision receipt
A planned portable receipt records the exact decision, reviewer, evidence versions, observation dates, purpose, and limits. It preserves the basis of a decision, not proof of real-world truth, fresh observations, or completed execution.
#independent-consumerIndependent receipt consumer
A planned independently built reader checks a receipt against the buyer's accepted issuer, scope, age, and status requirements. A valid signature can still accompany a receipt that does not meet those requirements.
#guided-entryGuided entry
Planned guided entry helps a person specify the service, vendor, data, and purpose needed for a bounded review. It asks about missing details rather than inventing them or automatically deciding a legal classification.
#managed-aiManaged AI experiment
A planned managed-AI experiment helps customers prepare sourced drafts without first arranging their own AI setup. It remains an experiment with defined data handling and permissions, not authority for the assistant to approve or disclose unrelated records.
#demand-led-integrationsDemand-led integrations
Planned integration experiments focus on one or two source connections needed for a customer workflow. Each must state its permissions, observation times, errors, and resource coverage rather than imply complete system discovery.
#maintained-statusMaintained external status
Planned status sharing lets authorized recipients learn that earlier assurance needs review, has expired, or has been superseded. Historical signatures remain separate from current acceptability, and unavailable status must not silently become approval.
#evidence-planningEvidence request planning
Planned ranking identifies which available evidence requests could best resolve a pending decision for the effort involved. The ranking depends on modeled options and reviewed estimates, not guaranteed minimum collection work.
#operator-scaleMulti-client operations and handover
Planned portfolio work supports multiple products or clients and a controlled handover of open decisions and evidence. Shared views must preserve client isolation, access revocation, and separate approval authority.
#assurance-networkCross-company assurance network
A planned network supports repeat exchanges in which buyers define accepted issuers, scopes, evidence ages, and review conditions. Network participation does not establish universal acceptance, issuer competence, or regulator recognition.
#bounded-agent-requestsBounded agent decision requests
Planned agent requests identify the exact action and parameters for an assurance decision. The request and response remain separate from spending authority and permission to execute the action.
#constrained-plansConstrained evidence and remediation plans
Planned workflows break evidence or remediation work into attributable, authorized steps with checked results. They retain approval and reversibility boundaries rather than permit destructive or expanded actions because an agent proposed them.
#assurance-interoperabilityAssurance format interoperability
Planned mappings preserve scope, dates, uncertainty, and references when exchanging assessment results or credential-based claims. OSCAL formats, credential profiles, and gateway enforcement require separate tests and are not interchangeable capabilities.
#tenant-isolationTenant isolation checks
A release requirement checks that reads, searches, linked records, and exports stay within the authorized client boundary. Passing one screen test does not establish isolation across every path.
#evidence-statesHonest evidence states
A release requirement distinguishes missing, stale, inaccessible, and contradictory support with understandable reasons. A supported condition must not hide unresolved material conditions, and missing evidence is not confirmed noncompliance.
#approved-content-integrityApproved-content integrity
A release requirement checks that an approval stays bound to the decision content actually reviewed. A material change of vendor, data, purpose, or environment must not reuse the earlier approval silently.
#idempotent-retriesSafe request retries
A release requirement checks that repeating the same request after a lost response does not create duplicate decisions or side effects. The operation identity must remain tied to the tenant, actor, and content and does not itself grant authority.
#export-verificationExport fidelity checks
A release requirement checks that exports preserve the claim, scope, limits, timing, and unresolved states. Readability, signature validity, faithful content, and recipient acceptance are separate checks, not one green result.
#adversarial-evaluationAdversarial release evaluation
A release requirement compares candidate behavior with practitioner-reviewed cases for scope errors, stale evidence, contradictions, and permission failures. A critical failure can block the affected release, while passing a finite test set does not prove complete correctness.
#enterprise-riskEnterprise risk management
Kanonik records supplier and dependency risks against the security commitments they affect, each with a named owner and a dated decision. For a wider enterprise risk program, talk to us.
#esg-operationsESG operations
Kanonik can keep the evidence behind a reported figure, such as where an emissions estimate came from and who approved it. For ESG reporting across a whole program, talk to us.
#business-continuityBusiness continuity operations
Kanonik checks recovery commitments, such as a promised restore time, against the evidence of tested backups and the systems they depend on. For a full continuity program, talk to us.
#incident-operationsIncident operations
Kanonik checks incident response commitments, such as named owners and backup contacts, against what the record currently shows. For running incidents themselves, talk to us.
#framework-catalogLarge framework catalog
NIST CSF 2.0 is included, and any other framework is a one-time activation. If the framework you need isn't on our list, talk to us.
#connector-catalogLarge connector catalog
Your own AI collects evidence with the access it already has, so Kanonik doesn't need a connector for each system. Each item goes into the record with the date it was observed.
#policy-to-codeGeneric policy-to-code compilation
A policy becomes a checkable condition once a person confirms the threshold and the role it names. Where the wording is unclear, the question goes back to the policy owner instead of into a guess.
#private-deploymentEnterprise private deployment
Private or self-hosted deployment for enterprise customers: talk to us. Kanonik is deployed as infrastructure as code; we go through the platform with you, test it with you, and agree where it runs and what support covers.
#contract-interpretation-boundaryContract interpretation boundary
Kanonik points an authorized reviewer to the relevant clause and the open question. The reviewer decides what the contract allows.
#irreversible-remediation-boundaryIrreversible action boundary
Kanonik can check a proposed deletion list against legal holds before anyone acts on it. The deletion itself stays a person's decision.
#fair-modelingFull FAIR risk modeling
Kanonik keeps the assumptions behind a risk estimate in the record, next to the dependencies they rest on. For full financial risk modeling, talk to us.
Run your own record on Solo.
Solo is $99 a month and starts with a 14-day trial.