grok14ENGINEERING FIELD SCHOOL
Curriculum/Module 14
Ship / Week 14

Enterprise integrations

Connect AI workflows to operational systems without losing authorization, consistency, or failure visibility.

5 lesson sections16-hour study & practice planModule 13 or equivalent experience

See the system

Connect AI workflows to operational systems without losing authorization, consistency, or failure visibility.

The model proposes. Trusted code validates. An authorized reviewer approves the exact payload. Execution rechecks permissions, expiry, and state; idempotency and audit bind the result to one operation.
Proposal is separate from execution. The model proposes. Trusted code validates. An authorized reviewer approves the exact payload. Execution rechecks permissions, expiry, and state; idempotency and audit bind the result to one operation.
Module 14 / Lesson 01

Define the external contract

Document the integration’s operations, identifiers, schemas, authentication, authorization, error responses, rate limits, and versioning. Separate observed API behavior from assumptions. A sandbox may have different permissions or limits from production.

Keep the adapter narrow so provider-specific details do not spread across the application. Contract tests should reveal a changed field or status before it becomes silent data loss.

Apply the ideaWrite a ticket-service contract including read, propose, update, and error outcomes.
Module 14 / Lesson 02

Preserve the caller’s authority

An integration service may have broad machine access. That does not mean every user can ask it to act on every resource. Verify the user’s entitlement and the target resource before a write.

Use supported service or delegated identity mechanisms as appropriate. Avoid treating a user-supplied ID as proof of ownership. Permissions may change between proposal and execution; recheck at the action boundary.

Apply the ideaTrace authorization from an authenticated user to the final external update.
Module 14 / Lesson 03

Handle duplicate and reordered events

Webhooks and queues often deliver messages more than once and may not preserve the order you expect. Use stable event IDs, resource versions, or explicit sequence logic according to the upstream contract.

Acknowledge an event only after the required durable handling step. If downstream work fails, retain a recoverable record. A dead-letter queue needs an investigation and replay procedure, not just a place where failures disappear.

Apply the ideaDefine what happens when a ticket-updated event arrives before a ticket-created event.
Module 14 / Lesson 04

Bound retries and protect dependencies

Retry transient failures with limits and an overall deadline. Respect documented rate limits and backoff guidance. A circuit breaker can reduce pressure on a persistently failing dependency, but also needs recovery behavior and useful visibility.

Distinguish accepted, completed, and failed work in the user interface. Never tell a user that a write succeeded merely because it was queued. Provide a stable operation identifier for follow-up.

Apply the ideaWrite user-facing states for queued, executing, completed, and failed ticket updates.
Module 14 / Lesson 05

Reconcile uncertain outcomes

A timeout can leave the caller unsure whether a write committed. Use an idempotency key or a supported lookup to determine the result before repeating the action. Keep an audit record linking proposal, approval, request, and outcome.

Periodic reconciliation can reveal discrepancies between internal state and the external system. Define ownership and remediation; do not silently overwrite the external system just to make counts match.

Apply the ideaDescribe recovery after the external API commits but the application loses the response.

Worked scenario

A webhook is delivered twice, and the first ticket update succeeded before its response was lost. Reusing the logical operation’s idempotency key should return the recorded result. Sending a new key would risk a second side effect. The user should see the final verified outcome rather than two apparent successes.

Practical assignment

Use the downloadable local reference lab where indicated. It uses synthetic data and Python’s standard library. The managed Databricks extension requires separate workspace verification.
  1. Define a synthetic ticket-service adapter.
  2. Test invalid identifiers and unauthorized targets.
  3. Simulate duplicate events and timeouts.
  4. Verify stable logical-operation identity.
  5. Document reconciliation for an uncertain result.
  6. Submit contract tests and an audit trace.

What to submit

Submit the artifacts named above, a short explanation of your decisions, and evidence of the checks you performed. Distinguish measured results from estimates and designs from executed integrations.

Review dimensionSubmission evidence
CorrectnessShow the expected behavior and a meaningful counterexample.
ReproducibilityState setup, inputs, versions, and what was actually executed.
Delivery judgmentExplain the client impact, alternative, and unresolved assumption.
Operational boundaryIdentify permissions, failure behavior, and any resource cleanup.
Open the lab workbenchGet delivery templates

Knowledge check

1. Does a service credential authorize every end user?
2. What should happen after an ambiguous write timeout?
3. A queued action is…

Answer guide
  1. No. The application must preserve the user’s actual authority.
  2. Reconcile using the operation’s identity. The write may already have committed.
  3. Accepted for later processing. Acceptance and completion are distinct states.

References & next step

Platform examples are environment-dependent. Start with the official documentation in the reference library and verify the exact cloud, region, privileges, and versions you use.

Open the official reference library

Editorial edition: 5 October 2026. The local reference lab is executed locally; this course does not claim a live Databricks deployment.