Fail-Closed Mindtickle Integration CI

Overview

Gate adapter changes on contract integrity and sanitized behavior while keeping external tenant access isolated, read-only, and manually authorized.

Prerequisites

• Deterministic local tests and sanitized fixtures from mindtickle-local-dev-loop
• Protected branches, pinned CI permissions, a secret scanner, and artifact retention policy
• A separately owned non-production tenant principal if a live smoke lane is justified

Tool Discipline

Use Read, Glob, and Grep to inspect workflows and dependency locks, WebFetch for current CI and tenant contracts, and Write or Edit for workflow files, tests, and redacted evidence.

Current Contract

The always-on lane must not depend on a live Mindtickle tenant. A live lane is optional and must use the customer's documented read-only operation, protected environment approval, bounded execution, and redacted logs.

Authentication

Grant workflow tokens minimal repository permissions. Store any tenant credential in the CI secret provider, restrict it to the protected environment, prevent fork access, and never expose it to pull-request code.

Instructions

1. Inventory CI triggers, permissions, third-party actions, caches, artifacts, and secret exposure paths.
2. Build an always-on lane for metadata validation, secret scanning, static checks, unit tests, contract fixtures, and generated-content drift.
3. Pin actions and dependencies according to repository policy and reject unreviewed network downloads.
4. Assert fixture sanitization, contract digest, tenant isolation, retry bounds, mutation denial, and stable output.
5. If justified, add a separate manual or protected-main smoke lane using one documented read-only operation and a strict timeout.
6. Ensure fork pull requests never receive tenant secrets and smoke logs record only status and safe identifiers.
7. Test success, missing secret, revoked access, contract mismatch, timeout, and artifact-redaction paths.
8. Record gate names, expected counts, owners, rollback, and credential rotation procedure.

Approval Boundaries

Do not expose secrets to forks, run live writes, weaken branch protection, or make a tenant-dependent lane mandatory without repository and tenant-owner approval.

Output

Return the CI threat model, gate graph, permissions, fixture and contract assertions, optional smoke boundary, failure tests, artifact policy, and verification receipt.

Error Handling

Evidence-First Mindtickle Failure Triage

Overview

Classify a failure by boundary, protect learner data, and produce the smallest reversible diagnosis before changing tenant state.

Prerequisites

• An incident owner, affected tenant, time window, population, and business impact
• The last known-good state and recent changes across identity, content, data, and integrations
• Approved access to redacted application and tenant evidence

Tool Discipline

Use Read, Glob, and Grep to inspect local logs and configuration, WebFetch for current official and authorized tenant guidance, and Write or Edit for a sanitized timeline and support packet.

Current Contract

Failures can cross customer identity providers, user sync, tenant roles, subscribed modules, managed connectors, customer adapters, and Mindtickle service boundaries. HTTP status alone does not prove root cause, and public material does not define universal error payloads.

Authentication

Use the least-privilege diagnostic principal. Redact tokens, cookies, personal data, assessment results, content URLs, and confidential tenant artifacts before sharing evidence.

Instructions

1. Freeze the symptom, first occurrence, blast radius, expected behavior, request or job identifiers, and recent changes.
2. Determine whether the failure is interactive access, provisioning, entitlement, content, assignment, reporting, connector, adapter, or platform availability.
3. Compare one failing case with one known-good case while changing only one variable at a time.
4. Validate tenant, principal, role, environment, contract digest, input identity, timestamps, and source-system state.
5. Check official service and support information, then distinguish customer-controlled remediation from vendor escalation.
6. Propose the smallest reversible repair with preview, approver, rollback, and post-change verification.
7. Reconcile the full affected set after repair; do not close on one successful sample.

Approval Boundaries

Do not reset identity settings, re-provision populations, republish content, edit scores, replay writes, or disable controls during diagnosis without the responsible owner.

Output

Return the timeline, impact, boundary classification, evidence table, ruled-out causes, proposed repair, approval requirement, verification, and support escalation packet.

Error Handling

Governed Mindtickle Learning Program Launch

Overview

Convert an approved enablement brief into a controlled program release with audience, content, measurement, communications, and rollback evidence.

Prerequisites

• A program owner, business outcome, audience source, due dates, and completion definition
• Confirmed tenant entitlements for the selected module types
• Approved content, accessibility review, privacy classification, and support owner

Tool Discipline

Use Read, Glob, and Grep to inspect briefs and rosters, WebFetch for current product and tenant contracts, and Write or Edit for plans, validation fixtures, and redacted receipts.

Current Contract

Mindtickle publicly describes courses, quick updates, checklists, certifications, instructor-led training, assessments, reinforcement, role-plays, coaching, and analytics. Exact creation, assignment, reminder, and reporting behavior depends on the subscribed package and current tenant configuration.

Authentication

Use an authorized program administrator or a documented tenant API principal with only the required capabilities. Separate authoring, assignment, and reporting permissions and never embed credentials in content packages.

Instructions

1. Freeze the brief: outcome, audience, exclusions, modules, passing rules, dates, locales, accessibility, and retention.
2. Confirm every module type and reporting field against the tenant entitlement and current documentation.
3. Validate content ownership, links, media, assessment answers, completion criteria, and representative mobile behavior.
4. Reconcile the audience to its system of record; quantify additions, removals, duplicates, disabled users, and managers.
5. Run a pilot with synthetic or approved users and verify assignment, navigation, completion, reporting, and support paths.
6. Present a launch preview with exact counts, schedule, notifications, risks, owner, and rollback.
7. After approval, publish and assign through the supported tenant path, then reconcile expected versus actual state.
8. Retain a redacted launch receipt and schedule outcome reviews rather than measuring completion alone.

Approval Boundaries

Do not publish, assign users, alter passing rules, send communications, or replace live content without the program and data owners.

Output

Return the frozen brief, entitlement check, content and audience validation, pilot evidence, mutation preview, launch receipt, reconciliation, and review schedule.

Error Handling

Mindtickle Readiness and Coaching Measurement Cycle

Overview

Create an explainable measurement plan that connects competencies, learning, coaching, and field outcomes without turning a readiness score into an unsupported employment decision.

Prerequisites

• A role owner, approved competency model, review population, and business outcome
• Defined lawful uses, access controls, retention, and employee communication
• Confirmed entitlements for Readiness Index, assessments, coaching, analytics, and any CRM integration

Tool Discipline

Use Read, Glob, and Grep for profiles and metric definitions, WebFetch for current official contracts, and Write or Edit for a governed measurement specification and redacted review receipt.

Current Contract

Mindtickle describes Ideal Rep Profiles, competency benchmarks, assessments, coaching, module-level insights, team and regional views, and correlation with CRM outcomes. The customer owns the validity, fairness, interpretation, and permitted decisions built on those measurements.

Authentication

Restrict learner-level data to approved roles. Use aggregate or de-identified data where possible, and keep CRM, HR, assessment, and coaching access independently authorized.

Instructions

1. Define the decision the measurement may inform and decisions it must never make automatically.
2. Version the role profile, competencies, weights, evidence sources, exclusions, and review cadence.
3. Establish baselines and minimum sample sizes before setting targets or claiming correlation.
4. Validate assessment accessibility, scoring reproducibility, manager calibration, and missing-data treatment.
5. Map learning and coaching interventions to named gaps; retain a human review and appeal route.
6. Present any tenant configuration change with population impact, effective date, and rollback.
7. After approval, run the cycle and reconcile source evidence, computed views, and authorized exports.
8. Report trends with uncertainty and confounders; do not infer causation from a dashboard correlation.

Approval Boundaries

Do not change competency weights, assign remediation, export learner-level results, or feed scores into compensation or employment actions without explicit policy and owner approval.

Output

Return the versioned model, purpose and prohibited uses, access matrix, validation evidence, approved interventions, aggregate results, limitations, and next review date.

Error Handling

Mindtickle Commercial and Adoption Review

Overview

Connect contracted spend to licensed population, package use, integration effort, support needs, and measured outcomes without inventing public pricing or consumption meters.

Prerequisites

• Current order, renewal date, packages, licensed populations, services, support tier, and owners
• Approved aggregate adoption and outcome evidence for the review period
• Finance rules for allocation, savings claims, and renewal decisions

Tool Discipline

Use Read, Glob, and Grep to inspect contract summaries and aggregate reports, WebFetch for current public service descriptions, and Write or Edit for a sanitized cost model and decision record.

Current Contract

Mindtickle publicly describes package-dependent modules, standard and premium support, implementation services, and separately scoped custom work. Public pages do not establish a universal seat price or API-consumption charge; signed commercial terms control.

Authentication

Use approved aggregate reports and contract summaries. Restrict learner-level adoption, invoices, pricing, and negotiated terms to authorized reviewers and exclude them from public artifacts.

Instructions

1. Freeze the contract baseline: term, packages, licensed units, support, services, commitments, renewal windows, and termination obligations.
2. Map each paid capability to an accountable owner, intended population, workflow, adoption measure, and business outcome.
3. Reconcile licensed, provisioned, active, disabled, duplicate, and exception populations using their systems of record.
4. Separate subscription spend from customer engineering, administration, content, identity, support, and change-management costs.
5. Identify unused entitlements, overlapping tools, inactive access, avoidable custom work, and unsupported savings assumptions.
6. Model keep, right-size, consolidate, and expand scenarios with one-time costs, risks, evidence confidence, and decision dates.
7. Present all seat, package, or support changes for business, finance, identity, and commercial approval.
8. Record the decision and validate realized outcomes against the baseline after implementation.

Approval Boundaries

Do not remove access, change packages, disclose negotiated pricing, or count forecast savings as realized without the authorized owners.

Output

Return the contract baseline, entitlement-to-outcome map, population reconciliation, total-cost view, scenarios, confidence, approvals, decision, and realization review.

Error Handling

Privacy-Safe Mindtickle Support Bundle

Overview

Create a deterministic evidence manifest that helps customer and Mindtickle support diagnose a problem without exporting secrets or unnecessary learner data.

Prerequisites

• A tracked incident, disclosure audience, retention deadline, and support severity
• An approved redaction policy and secure transfer destination
• Read-only access to relevant customer-side configuration, logs, and receipts

Tool Discipline

Use Read, Glob, and Grep to locate evidence, WebFetch to confirm current support requirements, and Write or Edit only inside the approved bundle path and manifest.

Current Contract

Mindtickle Support may request business context, logs, files, and appropriate remote access. Official support guidance defines severity and response paths; the customer remains responsible for minimizing and sanitizing what is disclosed.

Authentication

Do not collect passwords, tokens, cookies, authorization headers, private keys, raw identity-provider assertions, or unrestricted tenant exports. Replace user identifiers with stable incident-local aliases where individual evidence is necessary.

Instructions

1. Define the incident window, symptom, affected workflow, audience, severity, and questions the bundle must answer.
2. Create an evidence allowlist and explicit denylist before reading files.
3. Collect configuration names and digests, adapter version, contract digest, deployment receipt, timestamps, safe request IDs, and representative sanitized errors.
4. Add expected-versus-actual behavior, one known-good comparison, reproduction limits, recent changes, and attempted mitigations.
5. Scan every artifact for secrets, cookies, personal data, assessment data, content URLs, and internal infrastructure details.
6. Produce a manifest with artifact digests, provenance, redactions, collector, collection time, and expiry.
7. Obtain disclosure approval, transfer through the contracted secure channel, and record the support receipt.

Approval Boundaries

Do not run new production probes, grant remote access, include raw tenant exports, or send the bundle before security and data-owner approval.

Output

Return the sanitized bundle path, manifest, digest list, redaction report, reproduction summary, severity rationale, disclosure approval, transfer receipt, and destruction date.

Error Handling

Controlled Mindtickle Adapter Deployment

Overview

Promote a verified adapter without assuming a deployment platform, then prove tenant binding, safe behavior, and rollback from production evidence.

Prerequisites

• An immutable build, passing CI receipt, contract digest, and dependency inventory
• Environment owners, secret references, tenant mapping, observability, and on-call coverage
• A canary workload, success thresholds, abort criteria, and tested rollback

Tool Discipline

Use Read, Glob, and Grep to inspect manifests and receipts, WebFetch for current authorized contracts, and Write or Edit for deployment configuration, runbooks, and redacted evidence.

Current Contract

Deployment architecture is customer-controlled. The adapter must use the exact tenant API or managed-connector contract already approved; health checks must prove local readiness separately from optional external dependency readiness.

Authentication

Resolve secrets at runtime from the approved provider, bind them to one environment and tenant, deny shell or log exposure, and verify rotation and revocation ownership before rollout.

Instructions

1. Freeze build identity, contract digest, configuration digest, tenant map, dependencies, and data-flow classification.
2. Validate least-privilege runtime identity, egress allowlist, encryption, secret references, resource limits, and log redaction.
3. Separate liveness, local readiness, and external dependency signals so a vendor outage does not cause uncontrolled restart storms.
4. Present the deployment diff, canary population, expected operations, alert thresholds, approvers, and rollback command.
5. After approval, deploy the canary and observe latency, errors, throttling, backlog, duplicate prevention, and reconciliation.
6. Expand only when the evidence window passes; stop automatically on an abort threshold.
7. Reconcile expected versus actual tenant state and retain deployment and rollback receipts without sensitive payloads.
8. Confirm the previous build and compatible contract fixtures remain deployable until the observation window closes.

Approval Boundaries

Do not alter tenant configuration, inject credentials, enable production writes, expand the canary, or destroy the rollback build without named approvals.

Output

Return build and contract identities, configuration review, deployment preview, approvals, canary metrics, reconciliation, promotion decision, and rollback readiness.

Error Handling

Mindtickle Capability Discovery and First Proof

Overview

Turn a business outcome into an entitlement-aware, read-only proof that establishes the real tenant contract before implementation begins.

Prerequisites

• A named tenant site owner and one measurable business outcome
• The purchased package or order summary and an approved non-production audience
• Access to current tenant documentation without copying confidential content into the repository

Tool Discipline

Use Read, Glob, and Grep for existing assumptions and fixtures, WebFetch for current official sources, and Write or Edit for a redacted capability matrix and proof plan.

Current Contract

Package contents differ. Public descriptions identify learning modules, assessments, certifications, coaching, Readiness Index, Asset Hub, Digital Sales Rooms, analytics, and Call AI in different combinations. Availability in one tenant is evidence, not a universal product contract.

Authentication

Use the onboarding decision from mindtickle-install-auth. Discovery must use a named least-privilege principal; never use shared administrator credentials or scrape authenticated UI pages as an API substitute.

Instructions

1. Define the outcome, audience, data sensitivity, success metric, and maximum proof scope.
2. Compare the purchased package, visible tenant modules, managed integration catalogue, and tenant API documentation.
3. Mark each needed capability confirmed, absent, restricted, or vendor clarification required.
4. Choose the smallest reversible proof: a local fixture exercise, a tenant read, or a site-owner-led UI walkthrough.
5. Define acceptance before execution, including expected fields, freshness, authorization, and zero unintended mutations.
6. Obtain approval for any tenant access, then run the proof once and capture redacted evidence.
7. Convert confirmed observations into a contract fixture; label every tenant-specific inference and expiry date.

Approval Boundaries

Do not create courses, users, assignments, rooms, exports, or connectors during discovery unless the proof explicitly authorizes that mutation and rollback.

Output

Return the outcome statement, capability matrix, authoritative sources, proof method, redacted receipt, gaps, and a go/no-go recommendation.

Error Handling

Mindtickle Tenant Access and Integration Onboarding

Overview

Choose the supported access model, establish ownership, and verify the smallest safe capability without inventing a universal endpoint or credential format.

Prerequisites

• The customer's tenant URL, subscription package, site owner, and integration purpose
• An identity, security, and data owner for the affected users and records
• Customer-authorized tenant documentation or a Mindtickle Technical Solutions contact

Tool Discipline

Use Read, Glob, and Grep to inspect local configuration, WebFetch to re-check official public and tenant-authorized contracts, and Write or Edit only for secretless configuration and redacted evidence.

Current Contract

Mindtickle documents tenant-specific web URLs, role-based administration, managed integrations, REST-based Content/User/Reporting APIs, and standards including SCIM, SAML, and OpenID. Exact API hosts, routes, schemas, credentials, and entitlements are tenant-controlled and must be obtained from authorized documentation.

Authentication

Separate interactive SSO, automated provisioning, managed connector authorization, and API credentials. Do not treat an SSO session as API authorization, guess headers, reuse administrator cookies, or place secrets in files, logs, prompts, or receipts.

Instructions

1. Record the tenant, package, data classes, systems of record, intended reads and writes, and accountable owners.
2. Classify the path as browser SSO, SCIM/user sync, a catalogued managed integration, or a customer-issued API contract.
3. Re-fetch the applicable public product description and the customer's current tenant documentation.
4. Build an access matrix covering principal, roles, scopes, environments, expiration, rotation, revocation, and break-glass ownership.
5. Inspect the repository for guessed hosts, hard-coded secrets, browser-session reuse, and mixed tenant configuration.
6. Present every tenant setting, consent, connector enablement, and credential request for explicit approval.
7. After authorized provisioning, perform the smallest documented read-only check and retain only redacted status, principal class, tenant, and request identifiers.

Approval Boundaries

Do not invite users, change SSO or provisioning, enable a connector, issue credentials, broaden access, or test production writes without the relevant owner.

Output

Return the selected access path, entitlement evidence, access matrix, secretless configuration, verification receipt, rotation/revocation owner, and unresolved vendor questions.

Error Handling

Mindtickle Contract-Fixture Development Loop

Overview

Make adapter development deterministic by separating domain behavior from the tenant transport and exercising only sanitized, versioned fixtures locally.

Prerequisites

• An authorized tenant contract digest and sanitized success and failure examples
• A product-specific adapter boundary from mindtickle-sdk-patterns
• A secret scanner and repository policy for generated or confidential artifacts

Tool Discipline

Use Read, Glob, and Grep to inspect code and fixtures, WebFetch only to refresh approved contract sources, and Write or Edit for local adapters, fixtures, tests, and documentation.

Current Contract

Public Mindtickle pages establish API families but not a public emulator or universal SDK. Local mode must therefore emulate the frozen customer contract, identify synthetic values clearly, and fail closed when an unrecorded operation appears.

Authentication

Local mode accepts no real credential. Represent auth outcomes with synthetic fixtures and reserve any tenant smoke test for a separately approved integration lane.

Instructions

1. Record the contract digest, fixture provenance, sanitization method, and supported operation list.
2. Route domain code through the adapter interface; reject direct network calls outside the transport module.
3. Add deterministic fixtures for success, empty results, pagination, validation, authorization, throttling signal, timeout ambiguity, and schema drift.
4. Validate fixtures against internal schemas and scan them for secrets and identifying data.
5. Provide a fake clock, stable identifiers, bounded randomness, and deterministic retry scheduling.
6. Run focused tests after every change and compare normalized outputs rather than vendor-specific ordering unless documented.
7. Fail the local server when code requests an unknown route, tenant, or fixture instead of silently returning a generic response.
8. Document the exact command, expected test count, contract expiry, and handoff to the integration lane.

Approval Boundaries

Do not copy production responses wholesale, enable fallback network access, or accept real tokens in local mode.

Output

Return the adapter boundary, fixture inventory and digest, sanitization receipt, deterministic commands, test results, unsupported operations, and contract refresh date.

Error Handling

Evidence-Driven Mindtickle Integration Performance

Overview

Improve the customer-controlled integration path from a reproducible baseline while respecting tenant contracts, privacy, freshness, and correctness.

Prerequisites

• A service-level objective, representative workload, current contract digest, and observation window
• Metrics for latency, attempts, errors, retries, backlog age, throughput, freshness, and reconciliation
• A non-production load path or approved canary with explicit abort thresholds

Tool Discipline

Use Read, Glob, and Grep to inspect traces and configuration, WebFetch for current authorized contracts, and Write or Edit for benchmarks, controlled changes, tests, and redacted receipts.

Current Contract

Performance spans the customer application, network, identity, adapter, tenant operations, and downstream systems. Mindtickle states support for scalable integrations but does not publish universal latency or quota targets, so customer objectives and tenant-specific evidence must remain separate.

Authentication

Benchmark with synthetic or aggregate data and a least-privilege non-production principal. Never use extra credentials to create artificial concurrency or include payload contents in traces.

Instructions

1. Define the user or business symptom, objective, correctness invariant, workload, and baseline window.
2. Break elapsed time into queue, customer processing, network, tenant response, downstream processing, and reconciliation.
3. Segment by operation, page or batch, payload class, tenant, response class, and time without exposing personal data.
4. Rank bottlenecks by measured contribution and distinguish latency from throttling, backlog, and data-quality delay.
5. Propose one controlled change at a time: scheduling, bounded concurrency, pagination, batching, caching, indexing, or payload reduction only where the contract permits it.
6. Define cache ownership, freshness, invalidation, privacy, and stale-data behavior before enabling a cache.
7. Run the experiment within abort thresholds and compare p50, tail latency, errors, retries, backlog, freshness, and reconciliation.
8. Retain the change only when the improvement is repeatable and correctness is unchanged; otherwise roll back.

Approval Boundaries

Do not load-test production, raise concurrency, retain learner data in a cache, or trade correctness for speed without explicit owners.

Output

Return the objective, baseline, bottleneck evidence, experiment, approvals, before-and-after metrics, correctness reconciliation, decision, and rollback receipt.

Error Handling

Mindtickle Production Readiness Gate

Overview

Issue an evidence-backed go, conditional-go, or no-go decision across entitlement, identity, data, reliability, support, and rollback.

Prerequisites

• A frozen scope, owners, launch window, user population, data classes, and business acceptance
• Current tenant entitlement, architecture, threat model, test results, and operational runbooks
• Named support plan, on-call coverage, communications, rollback, and evidence retention

Tool Discipline

Use Read, Glob, and Grep to inspect evidence and configuration, WebFetch for current official and authorized terms, and Write or Edit for the review record and remediation evidence.

Current Contract

Mindtickle assigns tenant administration capabilities by role and package, provides managed integrations and customer-specific technical solutions, and publishes Support and SLA terms. Production readiness must also cover the customer's identity provider, data systems, adapters, and business process.

Authentication

Verify named principals, least privilege, tenant isolation, SSO and provisioning ownership, credential rotation, revocation, break-glass access, and evidence that no secrets enter logs or artifacts.

Instructions

1. Confirm scope, package entitlement, tenant and environment identity, supported operations, and contract digests.
2. Review data minimization, lawful use, retention, deletion, residency commitments, export controls, and learner communications.
3. Validate SSO, lifecycle provisioning, roles, disabled-user handling, tenant isolation, and periodic access review.
4. Verify contract tests, pilot or canary evidence, capacity policy, monitoring, reconciliation, backup assumptions, and dependency failure behavior.
5. Exercise credential revocation, ambiguous write handling, partial rollout rollback, and support escalation through tabletop or non-production tests.
6. Reconcile launch population, content, schedules, notifications, and downstream mappings with their systems of record.
7. List every exception with risk owner, compensating control, expiry, and blocking status.
8. Obtain independent sign-off and record go, conditional-go, or no-go with immutable evidence links.

Approval Boundaries

Do not waive a control, accept residual risk for another owner, enable production, or mark an untested rollback ready.

Output

Return the reviewed scope, evidence matrix, blockers, expiring exceptions, sign-offs, decision, launch conditions, rollback state, and first operational review date.

Error Handling

Mindtickle Capacity and Retry Contract

Overview

Replace guessed quotas with an evidence-backed workload envelope and a conservative client policy that protects the tenant and downstream systems.

Prerequisites

• Current tenant documentation or written vendor guidance for the operations in scope
• A workload profile with record counts, freshness target, windows, and priority
• Metrics for attempts, latency, responses, retries, backlog, and reconciliation

Tool Discipline

Use Read, Glob, and Grep for workload and adapter configuration, WebFetch for current authorized contracts, and Write or Edit for a versioned policy and synthetic test fixtures.

Current Contract

Mindtickle publicly states its integrations support high-volume transactions but does not publish universal endpoint quotas. Numeric limits, response headers, pagination, safe concurrency, and retry behavior must come from the customer's current contract or observed authorized responses.

Authentication

Use a non-production, least-privilege principal for any capacity probe. Never distribute load across extra credentials or tenants to evade a documented limit.

Instructions

1. Inventory each operation's documented pagination, batch size, concurrency, timeout, retry, and idempotency behavior.
2. Mark every missing value unknown; do not fill gaps with generic numbers.
3. Model peak demand, allowable staleness, downstream limits, and replay volume after an outage.
4. Define a conservative token or concurrency policy, bounded exponential backoff with jitter, and a total retry budget.
5. Add backpressure, dead-letter or quarantine handling, and write reconciliation where the contract permits.
6. Validate locally with synthetic throttle, timeout, malformed-response, and recovery fixtures.
7. Obtain approval before a controlled tenant probe; stop at the first throttling or instability signal.
8. Version the resulting envelope with evidence, owner, expiry, dashboards, and escalation thresholds.

Approval Boundaries

Do not load-test production, evade limits, increase concurrency, or replay writes without tenant and service-owner approval.

Output

Return the operation inventory, known and unknown limits, workload model, client policy, retry budget, test evidence, monitoring thresholds, and vendor questions.

Error Handling

Tenant-Scoped Mindtickle Integration Architecture

Overview

Produce a decision-ready architecture that identifies every trust boundary, system of record, contract, data flow, failure mode, and operational owner.

Prerequisites

• A business workflow, tenant and environment inventory, package entitlement, and data classification
• Current identity, connector, and tenant API artifacts with owners and provenance
• Customer security, retention, residency, reliability, and support requirements

Tool Discipline

Use Read, Glob, and Grep to inspect repository topology and existing decisions, WebFetch for current official contracts, and Write or Edit for diagrams, decisions, threat models, and redacted evidence.

Current Contract

Mindtickle supports tenant-specific access, roles, managed integrations, REST-based API families, SCIM, SAML, OpenID, and package-dependent product modules. The architecture must not assume every tenant has every module or that managed connectors and custom APIs share one authorization model.

Authentication

Model interactive SSO, lifecycle provisioning, managed connectors, and API principals separately. Bind every principal, secret, queue, store, cache, and log to a tenant and environment with least privilege and revocation ownership.

Instructions

1. Define scope, outcomes, non-goals, actors, systems of record, tenants, environments, and data classes.
2. Draw trust boundaries and directional flows for identity, content, users, reporting, events, administration, support, and deletion.
3. Attach an authoritative contract, owner, authentication class, and permitted operations to every external edge.
4. Choose managed integration, file exchange, tenant API, or human workflow per use case based on supportability and risk.
5. Define tenant isolation, schema validation, idempotency, reconciliation, backpressure, retention, encryption, and audit evidence.
6. Model dependency outage, identity drift, partial writes, duplicate delivery, schema drift, credential compromise, and tenant misrouting.
7. Specify service objectives, alerts, runbooks, support severity, capacity, recovery, and cost ownership.
8. Record alternatives and tradeoffs, then obtain independent security, data, platform, and business review before implementation.

Approval Boundaries

Do not select a tenant default, combine credentials, export restricted data, introduce an unsupported integration path, or accept residual risk for another owner.

Output

Return context and data-flow diagrams, contract registry, trust boundaries, tenancy controls, decision records, threat model, failure matrix, owners, open questions, and approval state.

Error Handling

Contract-First Mindtickle Adapter Patterns

Overview

Turn an authorized tenant API contract into a narrow adapter with explicit operations, validation, retries, tenancy, and evidence—without fabricating an SDK or route.

Prerequisites

• A versioned tenant API artifact with provenance, permitted operations, and data classification
• Confirmed authentication, environment, capacity, support, and change-notification contracts
• Test fixtures that contain no production secrets or learner PII

Tool Discipline

Use Read, Glob, and Grep to inspect contract artifacts and code, WebFetch only for authorized current documentation, and Write or Edit for adapter code, fixtures, and redacted receipts.

Current Contract

Public Mindtickle material confirms REST-based Content, User, and Reporting APIs but does not define a universal public SDK, base URL, route set, or credential header. Treat the tenant artifact as the executable authority and record its digest and expiry.

Authentication

Inject credentials through the approved runtime secret provider. Bind configuration to one tenant and environment, redact request logs, and reject startup when tenant, host, or credential provenance is ambiguous.

Instructions

1. Inventory only documented operations needed for the business workflow and classify each read, write, idempotency, and privacy property.
2. Freeze the source artifact digest, tenant, environment, auth scheme, schemas, pagination, errors, and capacity signals.
3. Generate or handwrite internal transport types behind a product-specific interface; never leak vendor payloads into domain logic.
4. Validate requests and responses at the boundary and reject undocumented fields or status assumptions.
5. Implement bounded retries only for documented transient conditions, with idempotency or reconciliation for writes.
6. Add fixtures for success, authorization failure, validation failure, pagination, throttling signals, timeout ambiguity, and schema drift.
7. Produce a mutation preview and require approval before the first tenant write.
8. Capture contract digest, test results, deployed adapter version, and rollback compatibility.

Approval Boundaries

Do not reverse engineer tenant traffic, scrape the authenticated UI, publish confidential API artifacts, add undocumented operations, or run writes without resource-owner approval.

Output

Return the contract inventory and digest, adapter boundary, auth and tenant controls, fixture coverage, retry/reconciliation policy, mutation preview, and rollback plan.

Error Handling

Mindtickle Security and Privacy Control Review

Overview

Translate shared responsibility into testable controls for identities, tenant boundaries, employee data, content, integrations, evidence, and incident response.

Prerequisites

• A scoped architecture, data inventory, identity model, contract registry, and accountable owners
• Current customer policy, threat model, retention schedule, and incident process
• Authorized access to Mindtickle trust artifacts and tenant-specific security documentation

Tool Discipline

Use Read, Glob, and Grep to inspect configuration and evidence, WebFetch for current official security material, and Write or Edit for the threat model, control matrix, and sanitized findings.

Current Contract

Mindtickle describes role-based access, customer responsibility for SSO, roles, provisioning, and data lifecycle, plus independent compliance and security assessments. Certifications inform assurance but do not replace customer control validation.

Authentication

Separate users, administrators, provisioning identities, managed connectors, API principals, and support access. Require least privilege, phishing-resistant identity controls where available, rotation, revocation, access review, and no shared credentials.

Instructions

1. Inventory tenants, environments, principals, roles, integrations, data classes, content audiences, exports, caches, logs, and support paths.
2. Map threats across account takeover, overprivilege, tenant misrouting, lifecycle drift, data leakage, malicious content, replay, schema injection, and compromised dependencies.
3. Verify SSO enforcement, identity-provider MFA, provisioning ownership, disabled-user handling, administrator separation, and periodic access review.
4. Test tenant binding, input and output validation, secret handling, egress restrictions, encryption, logging redaction, and evidence integrity.
5. Review data minimization, retention, deletion, exports, residency commitments, learner transparency, and restricted assessment or coaching data.
6. Validate connector and adapter scopes, contract provenance, dependency controls, incident contacts, support disclosure, and credential compromise response.
7. Rank findings by exploitable path and business impact; assign owner, remediation, verification, and due date.
8. Re-test changed controls and preserve redacted evidence rather than closing on configuration screenshots alone.

Approval Boundaries

Do not weaken SSO, grant roles, rotate production credentials, access learner records, change retention, or conduct intrusive testing without explicit authorization.

Output

Return the asset and data inventory, trust boundaries, threat model, control evidence, finding…

Controlled Mindtickle Contract Migration

Overview

Move from a frozen current contract to a verified target while preserving identity, data meaning, operational continuity, and a tested reversal path.

Prerequisites

• Current and target artifacts with provenance, digests, effective dates, and vendor or customer owners
• Inventory of affected operations, fields, identities, mappings, reports, programs, and downstream consumers
• Representative sanitized fixtures, a migration window, communications, and rollback authority

Tool Discipline

Use Read, Glob, and Grep to inspect contracts, mappings, and consumers, WebFetch for current authorized change material, and Write or Edit for compatibility tests, migration plans, and redacted receipts.

Current Contract

Mindtickle may update subscription services and tenant capabilities, while customer profile fields, integrations, custom reports, and migrations can require separately scoped work. Do not infer API versioning or backward compatibility when the authorized artifacts do not state it.

Authentication

Validate target credential compatibility and scopes in non-production. Keep current and target credentials separately owned, prevent downgrade to broader access, and preserve revocation plans for both.

Instructions

1. Freeze current and target contracts and build a semantic diff of operations, schemas, meanings, defaults, permissions, limits, and support status.
2. Trace every changed element to code, fixtures, identity mappings, reports, content, data stores, alerts, and business owners.
3. Classify changes as compatible, transformable, destructive, entitlement-dependent, or clarification required.
4. Define transformation, validation, duplicate prevention, reconciliation, retention, and rollback for each affected data set.
5. Run old fixtures against the new adapter and target fixtures against the compatibility boundary; include partial and ambiguous failures.
6. Rehearse migration and rollback with synthetic or approved non-production data and compare counts, identities, meanings, and permissions.
7. Present the exact change set, downtime or dual-run window, approvers, abort thresholds, and support coverage.
8. After approval, migrate incrementally, reconcile at each boundary, then revoke obsolete access only after the rollback window closes.

Approval Boundaries

Do not transform learner records, change identity attributes, enable target writes, accept destructive loss, or revoke rollback credentials without accountable owners.

Output

Return contract digests and diff, impact graph, migration and rollback plan, fixture results, rehearsal reconciliation, approvals, live receipts, and decommission decision.

Error …

Mindtickle Change Ingestion and Event Governance

Overview

Choose the least risky supported delivery mode and make duplicates, ordering, authenticity, replay, privacy, reconciliation, and fallback explicit.

Prerequisites

• A use case, source of truth, freshness objective, event or record volume, and downstream owner
• Current tenant documentation for available events, APIs, reports, exports, or managed connectors
• A data classification, retention policy, capacity contract, and recovery objective

Tool Discipline

Use Read, Glob, and Grep to inspect consumers and schemas, WebFetch for current authorized contracts, and Write or Edit for ingestion code, fixtures, mappings, and redacted receipts.

Current Contract

Mindtickle publicly confirms REST-based API families and managed integrations but does not publish a universal webhook registration route, event catalogue, signature header, or retry schedule. Treat webhook delivery as unavailable until tenant-authorized documentation explicitly defines it.

Authentication

For documented push delivery, use the exact authenticity mechanism and secret lifecycle in the tenant contract. For polling or export, use a least-privilege tenant principal. Never invent an HMAC header or accept unauthenticated events.

Instructions

1. Define the business transition, required fields, allowed delay, source authority, privacy class, and downstream mutation.
2. Inventory supported modes: managed connector, documented event delivery, incremental API read, scheduled report or export, and approved manual handoff.
3. Select the mode using supportability, authenticity, freshness, replay, observability, capacity, and cost—not a preference for webhooks.
4. Freeze schemas and define stable identity, deduplication, ordering assumptions, cursor or checkpoint ownership, and deletion behavior.
5. Implement validate-before-acknowledge, quarantine, bounded retry, dead-letter handling, and a reconciliation read or report.
6. Test valid, invalid, duplicate, late, out-of-order, missing-field, replay, revoked-auth, and outage cases with synthetic fixtures.
7. Present subscription, endpoint, schedule, or connector changes with exposure, owner, rollback, and secret plan.
8. After approval, canary the ingestion, reconcile against the source of truth, and retain only redacted operational evidence.

Approval Boundaries

Do not expose an endpoint, create a subscription, enable a connector, poll production, replay messages, or mutate downstream records without named owners.

Output

Return the selected mode and evidence, frozen schema, auth and secret plan, deduplication and ordering policy, failure tests, mutation preview, canary reconciliation, and fallback.

…