[{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/agentic-architecture/","section":"Tags","summary":"","title":"Agentic-Architecture","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/ai-fluency/","section":"Tags","summary":"","title":"Ai-Fluency","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/anthropic/","section":"Tags","summary":"","title":"Anthropic","type":"tags"},{"content":" What this is # This wraps up the Becoming a Claude Architect series with a self-check: 100 practice questions, 20 per domain, covering everything from Domain 1 — Agentic Architecture \u0026amp; Orchestration through Domain 5 — Context Management \u0026amp; Reliability. Click an answer and you\u0026rsquo;ll see immediately whether it\u0026rsquo;s right, with a short explanation either way.\nThis is an unofficial, AI-assisted study aid — not vetted against the real exam\u0026rsquo;s style or difficulty. I drafted these questions myself, grounded in the official exam guide\u0026rsquo;s task statements and the content of Posts 2 through 6 in this series, but Anthropic hasn\u0026rsquo;t reviewed or endorsed them. Treat this as a way to stress-test your own understanding, not a substitute for the official exam guide or Anthropic\u0026rsquo;s own prep material.\n20 questions per domain, matched to each domain\u0026rsquo;s share of the real exam How to use it # flowchart LR A[Read the question] --\u003e B[Pick an answer] B --\u003e C{Correct?} C --\u003e|Yes| D[Green check + explanation] C --\u003e|No| E[Red X on your pick,green check on the right one,+ explanation] D --\u003e F[Move to the next question] E --\u003e G[Re-read the relevantdomain post section] G --\u003e F style D fill:#28c840,stroke:#1c9c30,color:#fff style E fill:#e0524a,stroke:#b3261e,color:#fff No scoring, no shuffling, no timer — just click through all 20 questions in a domain, in order, and see how you do. If a question trips you up, it names the concept clearly enough in the explanation to go back to that domain\u0026rsquo;s post for the fuller version.\nDomain 1 — Agentic Architecture \u0026amp; Orchestration (27%) # Domain 2 — Tool Design \u0026amp; MCP Integration (18%) # Domain 3 — Claude Code Configuration \u0026amp; Workflows (20%) # Domain 4 — Prompt Engineering \u0026amp; Structured Output (20%) # Domain 5 — Context Management \u0026amp; Reliability (15%) # Conclusion # That\u0026rsquo;s the series: five domains, thirty-one key points, five diagrams, five charts, and now a hundred questions to check what stuck. The Claude Certified Architect – Foundations exam tests real architectural judgment — when to reach for a subagent versus doing the work inline, how to design a tool description that a model can actually parse correctly, when plan mode earns its overhead, how to guarantee structured output instead of hoping for it, and how to keep a long-running agent honest about what it does and doesn\u0026rsquo;t know. If this quiz surfaced a gap, the linked domain posts above are the fastest way to close it.\nSources # Claude Certified Architect – Foundations Exam Guide — task statements for all five domains Becoming a Claude Architect series — Parts 1 through 6, the primary source for every question above These 100 questions are AI-drafted and AI-checked against the domain posts\u0026rsquo; own content and the exam guide; I reviewed them for accuracy and fit, but they haven\u0026rsquo;t been validated against the real exam\u0026rsquo;s actual question style or difficulty.\nWhere this fits # Part 7 — the finale — of Becoming a Claude Architect, following Domain 5 — Context Management \u0026amp; Reliability. That\u0026rsquo;s the full series: Part 1 — Overview through this practice quiz.\n","date":"24 September 2026","externalUrl":null,"permalink":"/posts/claude-architect-07-practice-quiz/","section":"Posts","summary":"What this is # This wraps up the Becoming a Claude Architect series with a self-check: 100 practice questions, 20 per domain, covering everything from Domain 1 — Agentic Architecture \u0026 Orchestration through Domain 5 — Context Management \u0026 Reliability. Click an answer and you’ll see immediately whether it’s right, with a short explanation either way.\n","title":"Becoming a Claude Architect: 100-Question Practice Quiz — Part 7","type":"posts"},{"content":" What this is about # Domain 1 — Agentic Architecture \u0026amp; Orchestration — is the single heaviest domain on the Claude Certified Architect – Foundations exam, worth 27% on its own. The exam guide breaks it into seven task areas: the agentic loop, multi-agent orchestration, subagent configuration, multi-step workflows, SDK hooks, task decomposition, and session management. That\u0026rsquo;s a lot of ground, so this post condenses it into the five ideas that actually carry the weight, with the smaller two folded into a quick round-up at the end.\nKey point 1: the agentic loop runs on stop_reason, not on parsing Claude\u0026rsquo;s words # The whole agentic loop comes down to one signal: stop_reason. Your application sends a request, Claude responds, and you check that field. stop_reason: \u0026quot;tool_use\u0026quot; means Claude has decided to call one or more tools — you execute them, package the output as tool_result blocks, and send a new request with the results appended. The loop repeats while stop_reason == \u0026quot;tool_use\u0026quot;. Anything else — most commonly \u0026quot;end_turn\u0026quot; — means Claude has produced its final answer and the loop exits.\nThe architect-level point here is the anti-pattern to avoid: don\u0026rsquo;t try to detect \u0026ldquo;is Claude done?\u0026rdquo; by parsing the text of its reply for phrases like \u0026ldquo;I\u0026rsquo;m finished\u0026rdquo; or \u0026ldquo;here\u0026rsquo;s the answer.\u0026rdquo; That\u0026rsquo;s fragile and model-dependent. stop_reason is a structured, contractual signal built for exactly this — use it.\nKey point 2: multi-agent orchestration is a hub, not a mesh # When one agent isn\u0026rsquo;t enough, the pattern the exam tests is coordinator/subagent hub-and-spoke: a single coordinator agent manages all inter-subagent communication, error handling, and information routing. Subagents don\u0026rsquo;t talk to each other directly — everything routes through the coordinator. This keeps failure handling centralized and avoids the combinatorial mess of every agent needing to know about every other agent.\nTwo design habits matter inside that pattern: dynamic subagent selection (the coordinator decides which subagent(s) a given task actually needs, rather than always fanning out to all of them) and scope partitioning — dividing the work so subagents aren\u0026rsquo;t duplicating effort on overlapping pieces of the same problem. Well-designed orchestration also allows for iterative refinement loops, where a subagent\u0026rsquo;s output can trigger another pass rather than the coordinator treating every result as final.\nflowchart LR U[Request] --\u003e C[Coordinator agent] C --\u003e S1[Subagent A] C --\u003e S2[Subagent B] C --\u003e S3[Subagent C] S1 --\u003e C S2 --\u003e C S3 --\u003e C C --\u003e R[Routed result] style C fill:#2a78d6,stroke:#1c5cab,color:#fff style S1 fill:#c9ddf6,stroke:#86b6ef,color:#0b0b0b style S2 fill:#c9ddf6,stroke:#86b6ef,color:#0b0b0b style S3 fill:#c9ddf6,stroke:#86b6ef,color:#0b0b0b Notice what\u0026rsquo;s not in that diagram: no arrows between the subagents. That\u0026rsquo;s the hub-and-spoke discipline — every path runs through the coordinator.\nKey point 3: subagents don\u0026rsquo;t inherit context, you have to hand it to them # This is the detail that trips people up most: spawning a subagent (via the Agent tool — internally still built on the Task mechanism, so a coordinator\u0026rsquo;s allowedTools needs to include it) does not automatically hand that subagent the parent conversation\u0026rsquo;s history. A non-forked subagent starts fresh — it gets its own system prompt and whatever you put in the Agent tool\u0026rsquo;s prompt string, and nothing else from the parent. No prior tool results, no earlier reasoning, no assumed shared context.\nThe architectural implication: if a subagent needs a file path, an error message, an earlier decision, or any other detail from the parent\u0026rsquo;s work so far, that detail has to be written explicitly into the prompt you hand it. This is also why subagents are useful for context isolation — a research subagent can read dozens of files without any of that content leaking into the main conversation, because only its final message returns to the parent. The isolation and the \u0026ldquo;you must pass context explicitly\u0026rdquo; rule are the same mechanism, seen from two sides.\nKey point 4: for compliance-critical steps, enforce with hooks — don\u0026rsquo;t just ask nicely in a prompt # A prompt instruction (\u0026ldquo;always validate the amount before submitting a payment\u0026rdquo;) is guidance, not a guarantee — an agent under enough context pressure can still skip it. When a step genuinely cannot be allowed to happen out of order or unchecked — the exam guide\u0026rsquo;s example is financial operations — the architect-level answer is programmatic enforcement: hooks and prerequisite gates that run in code, not in the model\u0026rsquo;s discretion.\nThe Claude Agent SDK\u0026rsquo;s hooks fire on specific lifecycle events — a tool about to run (PreToolUse), a tool that just returned (PostToolUse), a subagent starting or stopping, and others. A PostToolUse hook, for example, can inspect and normalize a tool\u0026rsquo;s output, or block a non-compliant result, before it ever reaches the next step of the agentic loop. The distinction to hold onto for the exam: prompt-based guidance shapes behavior probabilistically; hooks enforce it deterministically. Reach for hooks when \u0026ldquo;probably follows the rule\u0026rdquo; isn\u0026rsquo;t good enough.\nA quick note on scale: task decomposition and session management # Two smaller pieces round out the domain. Task decomposition is the choice between a fixed, sequential pipeline (prompt chaining — do A, then B, then C, always in that order) and adaptive decomposition, where the next step is chosen based on what the previous step actually found. Session management covers resuming a named session to continue exactly where an agent left off, fork_session to branch off and explore an alternative direction without disturbing the original conversation\u0026rsquo;s history, and knowing when a fresh session with an injected summary beats resuming a long one outright (shorter context, but you control exactly what carries forward).\nHow much this matters # More than a quarter of the entire exam rides on getting this one domain right Conclusion # Domain 1 in one pass: the agentic loop is a stop_reason state machine, not a text-parsing problem. Multi-agent work should route through a coordinator, never a subagent mesh. Subagents start with a blank context — hand them what they need explicitly. Compliance-critical steps get enforced with hooks, not just requested in a prompt. And task decomposition/session management round out the domain as the supporting pieces around those four bigger ideas. At 27% of the exam, this is the domain most worth over-preparing.\nSources # Claude Certified Architect – Foundations Exam Guide — Domain 1 task statements How tool use works — Claude Platform Docs — stop_reason, tool_use, end_turn Subagents in the SDK — Claude API Docs — coordinator pattern, context inheritance, tool restrictions Intercept and control agent behavior with hooks — Claude API Docs — PreToolUse/PostToolUse Work with sessions — Claude API Docs — resume vs. fork vs. fresh session The research and the technical accuracy check against the official docs are AI-assisted; the framing, the \u0026ldquo;what this means for the exam\u0026rdquo; judgment calls, and any war stories are mine.\nWhere this fits # Part 2 of Becoming a Claude Architect, following the series overview. Part 3 takes on Domain 2 — Tool Design \u0026amp; MCP Integration.\n","date":"24 September 2026","externalUrl":null,"permalink":"/posts/claude-architect-02-agentic-architecture-orchestration/","section":"Posts","summary":"What this is about # Domain 1 — Agentic Architecture \u0026 Orchestration — is the single heaviest domain on the Claude Certified Architect – Foundations exam, worth 27% on its own. The exam guide breaks it into seven task areas: the agentic loop, multi-agent orchestration, subagent configuration, multi-step workflows, SDK hooks, task decomposition, and session management. That’s a lot of ground, so this post condenses it into the five ideas that actually carry the weight, with the smaller two folded into a quick round-up at the end.\n","title":"Becoming a Claude Architect: Agentic Architecture \u0026 Orchestration — Domain 1","type":"posts"},{"content":" What this is about # Domain 3 — Claude Code Configuration \u0026amp; Workflows — ties Prompt Engineering \u0026amp; Structured Output for second-heaviest domain on the Claude Certified Architect – Foundations exam, at 20%. Its six task areas are all about how you set up and drive Claude Code itself: configuration file hierarchy, custom commands and skills, conditional rules, choosing plan mode vs. diving straight in, iterating well, and wiring Claude Code into CI/CD.\nKey point 1: CLAUDE.md has a hierarchy — know where each rule belongs # Claude Code loads instructions from several scopes, broadest to narrowest: an organization-wide managed policy file (IT-controlled), a user-level ~/.claude/CLAUDE.md (your personal preferences across every project), project-level (./CLAUDE.md or ./.claude/CLAUDE.md, shared with the team via version control), and a gitignored CLAUDE.local.md for your own project-specific preferences that shouldn\u0026rsquo;t be committed. They load in that order, so a project instruction appears in context after a user instruction — put a rule at the scope where it actually belongs, not wherever\u0026rsquo;s convenient. For a large project, @path/to/file import syntax lets one CLAUDE.md pull in a README, a package.json, or a dedicated workflow guide without duplicating that content, with imports resolving relative to the file that references them and nesting up to four hops deep.\nKey point 2: custom commands and skills — scoped, and with tool access you control # Project-scoped commands live in .claude/commands/ (checked into version control, shared with the team) versus user-scoped commands in ~/.claude/commands/ (personal, not shared). Skills go further: a SKILL.md\u0026rsquo;s frontmatter can set context: fork to run the skill in an isolated subagent with no visibility into the main conversation\u0026rsquo;s history — useful for a self-contained task like a code review — and allowed-tools to pre-approve a specific, scoped set of tools for that invocation only (the grant clears after the next message), rather than the skill inheriting blanket tool access.\nKey point 3: path-specific rules load only when they\u0026rsquo;re relevant # Rather than stuffing every convention into one CLAUDE.md that loads on every single session regardless of what you\u0026rsquo;re touching, .claude/rules/ files can carry a paths field in their YAML frontmatter — a glob pattern like src/api/**/*.ts — so that rule only enters context when Claude is actually working with matching files. This keeps a big project\u0026rsquo;s conventions modular by topic (testing.md, security.md, api-design.md) and keeps context usage down, since a rule about API validation doesn\u0026rsquo;t need to be loaded while you\u0026rsquo;re editing a CSS file.\nKey point 4: plan mode is for uncertainty and multi-file changes, not everything # Plan mode — Claude reads and reasons without making changes, then proposes a plan you approve before it touches anything — is designed for complex, large-scale work: when you\u0026rsquo;re unsure of the right approach, the change spans multiple files, or you\u0026rsquo;re unfamiliar with the code being modified. For a simple, well-scoped change — a typo fix, a log line, a variable rename — plan mode is overhead you don\u0026rsquo;t need. The practical test: if you could describe the diff in one sentence, skip the plan and let Claude execute directly.\nflowchart TD A[New task] --\u003e B{Could you describethe diff in one sentence?} B --\u003e|Yes| C[Direct execution] B --\u003e|No| D{Multi-file, unfamiliar code,or unsure of approach?} D --\u003e|Yes| E[Plan mode] D --\u003e|No| C style C fill:#c9ddf6,stroke:#86b6ef,color:#0b0b0b style E fill:#2a78d6,stroke:#1c5cab,color:#fff Key point 5: iterate with examples, tests, and an upfront interview — not vague feedback # Three concrete techniques for progressive improvement, all about giving Claude something to check its own work against rather than \u0026ldquo;make it better\u0026rdquo;: providing input/output examples (\u0026ldquo;this input should produce that output\u0026rdquo;) instead of describing behavior abstractly; test-driven iteration, where Claude runs a real check — a test suite, a build, a screenshot comparison — and keeps iterating until it passes, rather than stopping the moment the work merely looks done; and the interview pattern for larger features, where you have Claude ask you about technical implementation, UI/UX, and edge cases before writing a spec and starting implementation, surfacing considerations you might not have thought to mention upfront.\nA quick note on scale: CI/CD integration # Rounding out the domain: Claude Code runs non-interactively with the -p (or --print) flag, which is what makes it usable inside a CI pipeline, a pre-commit hook, or any script rather than only an interactive terminal session. Pair it with --output-format json to get a structured response your pipeline can parse programmatically instead of scraping plain text — useful for anything from a typo linter run on every PR diff to a build-log summarizer that writes its findings to a file.\nHow much this matters # Tied for second at 20% — configuration habits you set up once pay off on every session after Conclusion # Domain 3 in one pass: CLAUDE.md has a real hierarchy — managed, user, project, local — and imports let you pull in reference material without duplicating it. Commands and skills scope by project vs. personal, and skills add context: fork and allowed-tools for isolation and controlled tool access. Path-specific rules keep large projects\u0026rsquo; conventions modular without bloating every session\u0026rsquo;s context. Plan mode earns its overhead on uncertain, multi-file work and costs you nothing on a one-sentence diff. Iteration works best with examples, real checks, and an upfront interview for bigger features. And -p plus --output-format json is what turns Claude Code into a CI/CD citizen instead of a terminal-only tool.\nSources # Claude Certified Architect – Foundations Exam Guide — Domain 3 task statements How Claude remembers your project — Claude Code Docs — CLAUDE.md hierarchy, imports, .claude/rules/ Extend Claude with skills — Claude Code Docs — context: fork, allowed-tools, command scoping Best practices for Claude Code — Claude Code Docs — plan mode, verification, the interview pattern Run Claude Code programmatically — Claude Code Docs — -p, --output-format json The research and the technical accuracy check against the official docs are AI-assisted; the framing, the \u0026ldquo;what this means for the exam\u0026rdquo; judgment calls, and any war stories are mine.\nWhere this fits # Part 4 of Becoming a Claude Architect, following Domain 2 — Tool Design \u0026amp; MCP Integration. Part 5 takes on Domain 4 — Prompt Engineering \u0026amp; Structured Output.\n","date":"24 September 2026","externalUrl":null,"permalink":"/posts/claude-architect-04-claude-code-configuration-workflows/","section":"Posts","summary":"What this is about # Domain 3 — Claude Code Configuration \u0026 Workflows — ties Prompt Engineering \u0026 Structured Output for second-heaviest domain on the Claude Certified Architect – Foundations exam, at 20%. Its six task areas are all about how you set up and drive Claude Code itself: configuration file hierarchy, custom commands and skills, conditional rules, choosing plan mode vs. diving straight in, iterating well, and wiring Claude Code into CI/CD.\n","title":"Becoming a Claude Architect: Claude Code Configuration \u0026 Workflows — Domain 3","type":"posts"},{"content":" What this is about # Domain 5 — Context Management \u0026amp; Reliability — is the lightest domain on the Claude Certified Architect – Foundations exam at 15%, but its six task areas cover what decides whether a long-running agent stays trustworthy: preserving critical facts across long interactions, knowing when to escalate, letting a multi-agent system recover from failure instead of silently degrading, managing context at scale, and calibrating how much to trust the output.\nKey point 1: progressive summarization quietly deletes the facts that matter # Condensing a long conversation into a summary is where information dies: dates, percentages, and a customer\u0026rsquo;s exact stated expectation get smoothed into vague prose, and the model\u0026rsquo;s own \u0026ldquo;lost in the middle\u0026rdquo; tendency means anything buried in a long input is less reliable than what\u0026rsquo;s near the start or end. The architect-level fix is to stop treating summarization as the only mechanism — extract transactional facts into a persistent, structured block (a \u0026ldquo;case facts\u0026rdquo; record) that survives independently of the narrative summary, trim verbose tool output before it accumulates rather than after, and put summaries at the beginning of a prompt to work with the position effect instead of against it.\nKey point 2: escalation needs explicit triggers, not sentiment or confidence scores # Neither sentiment analysis nor a model\u0026rsquo;s own confidence score is a reliable signal for when to hand off to a human — both can look calm on a case that\u0026rsquo;s actually stuck, or anxious on one that isn\u0026rsquo;t. The exam\u0026rsquo;s fix is explicit escalation criteria backed by few-shot examples: an outright customer request for a human gets honored immediately, a policy exception or gap escalates rather than getting worked around, and multiple ambiguous customer matches trigger a request for another identifier rather than a best-guess selection. The distinction that matters in practice: acknowledge frustration when it\u0026rsquo;s present, but don\u0026rsquo;t treat frustration itself as the escalation trigger when the issue is actually resolvable.\nKey point 3: structured error propagation is what lets a coordinator actually recover # A generic \u0026ldquo;failed\u0026rdquo; status thrown up from a subagent hides everything a coordinator would need to act intelligently. The pattern this domain tests: return structured error context — failure type, and what alternatives exist — rather than a bare status; distinguish a genuine access failure from a valid-but-empty result, since collapsing those two into \u0026ldquo;no data\u0026rdquo; produces the wrong recovery decision; attempt local recovery inside the subagent before propagating a failure upward at all; and when synthesizing results from several subagents, annotate the output with coverage gaps instead of silently presenting partial results as complete.\nflowchart TD A[Subagent task fails] --\u003e B{Recoverable locally?} B --\u003e|Yes| C[Retry / fall backinside subagent] C --\u003e D[Return result] B --\u003e|No| E[Return structured error:failure type + alternatives] E --\u003e F[Coordinator decides:retry, reroute, or annotate gap] style D fill:#28c840,stroke:#1c9c30,color:#fff style E fill:#2a78d6,stroke:#1c5cab,color:#fff style F fill:#1c5cab,stroke:#14417f,color:#fff Key point 4: large codebase exploration needs its own context discipline # Extended sessions degrade — the exam names this directly, describing context degradation that produces inconsistent answers the longer a session runs. The countermeasures are concrete: scratchpad files that persist key findings across context boundaries so they survive even if the session doesn\u0026rsquo;t; spawning subagents to isolate verbose exploration, so the noise of searching a large codebase never enters the main conversation; summarizing a phase\u0026rsquo;s findings before delegating the next one, rather than letting raw exploration compound; designing state exports specifically for crash recovery; and using Claude Code\u0026rsquo;s /compact command during a long session to reclaim space with instructions about what to preserve, rather than letting auto-compaction guess.\nKey point 5: calibrate confidence and preserve provenance — don\u0026rsquo;t trust an aggregate number # An aggregate accuracy metric can hide a model that\u0026rsquo;s excellent on one document type and unreliable on another; the fix is stratified random sampling across segments, not a single overall percentage, plus field-level confidence scores calibrated against a labeled dataset so low-confidence extractions route to human review before they ship. The same discipline applies to multi-source synthesis: source attribution gets lost the moment a fact is summarized without its origin, so structured claim-to-source mappings (URL, excerpt, publication date) need to survive synthesis intact, conflicting statistics from credible sources should be shown side by side with attribution rather than silently merged into one number, and anything time-sensitive needs its collection or publication date carried through rather than presented as current.\nHow much this matters # 15% of the exam — and the domain most likely to determine whether your agent is still trustworthy after hour six Conclusion # Domain 5 in one pass: summarization silently deletes hard facts unless you extract them into a structured record that survives independently, and the lost-in-the-middle effect means position in the prompt matters as much as content. Escalation needs explicit, example-backed triggers — sentiment and confidence scores aren\u0026rsquo;t reliable signals on their own. Structured error propagation, with a real distinction between failure and empty-but-valid, is what lets a multi-agent system recover instead of quietly degrading. Large codebase exploration needs scratchpads, subagent isolation, and deliberate compaction to avoid context rot. And trust in output comes from stratified sampling and calibrated confidence scores, not an aggregate accuracy number — paired with provenance that survives synthesis instead of dissolving into it.\nSources # Claude Certified Architect – Foundations Exam Guide — Domain 5 task statements Context editing — Claude Platform Docs — automatic tool-result clearing, the memory tool Manage costs effectively — Claude Code Docs — /compact, context management in long sessions Best practices for Claude Code — Claude Code Docs — subagent delegation for verbose exploration The research and the technical accuracy check against the official docs are AI-assisted; the framing, the \u0026ldquo;what this means for the exam\u0026rdquo; judgment calls, and any war stories are mine.\nWhere this fits # Part 6 of Becoming a Claude Architect, following Domain 4 — Prompt Engineering \u0026amp; Structured Output. Part 7 wraps the series with a 100-question interactive practice quiz across all five domains.\n","date":"24 September 2026","externalUrl":null,"permalink":"/posts/claude-architect-06-context-management-reliability/","section":"Posts","summary":"What this is about # Domain 5 — Context Management \u0026 Reliability — is the lightest domain on the Claude Certified Architect – Foundations exam at 15%, but its six task areas cover what decides whether a long-running agent stays trustworthy: preserving critical facts across long interactions, knowing when to escalate, letting a multi-agent system recover from failure instead of silently degrading, managing context at scale, and calibrating how much to trust the output.\n","title":"Becoming a Claude Architect: Context Management \u0026 Reliability — Domain 5","type":"posts"},{"content":" What this is about # Claude Certified Architect – Foundations is Anthropic\u0026rsquo;s certification for designing Claude systems, not just using them. Where the Claude Certified Associate exam tests whether you can operate Claude with professional discipline — good prompts, sound judgment on output, the right entry point for the job — the Architect exam tests something a level up: can you design the agentic system, the tool integrations, and the configuration that other people build on top of. The ideal candidate has 6+ months of hands-on experience building with the Claude API, the Claude Agent SDK, Claude Code, and Model Context Protocol (MCP) — this isn\u0026rsquo;t a first certification, it\u0026rsquo;s the next one.\nThis kicks off a new series, Becoming a Claude Architect, separate from my Getting Claude Certified series on the Associate exam. If you haven\u0026rsquo;t sat that one yet, it\u0026rsquo;s the natural place to start — this series assumes the fluency habits from that one are already in place.\nKey point 1: the exam, by the numbers # 60 items, multiple-choice and multiple-response, 120 minutes, delivered proctored online or at a test center. Passing is a scaled score of 720 on a 100–1,000 scale — Anthropic doesn\u0026rsquo;t publish the raw-to-scaled conversion, so \u0026ldquo;720\u0026rdquo; isn\u0026rsquo;t \u0026ldquo;72% of questions right,\u0026rdquo; it\u0026rsquo;s a calibrated bar. The credential costs $125 and stays valid for 12 months, and scoring comes back as pass/fail plus a percent-correct breakdown by domain, so you know exactly where a retake needs to focus.\nKey point 2: five domains, one clear heaviest # flowchart LR A[Agentic Architecture\u0026 Orchestration — 27%] --\u003e F[Architect exam] B[Claude Code Configuration\u0026 Workflows — 20%] --\u003e F C[Prompt Engineering\u0026 Structured Output — 20%] --\u003e F D[Tool Design\u0026 MCP Integration — 18%] --\u003e F E[Context Management\u0026 Reliability — 15%] --\u003e F style A fill:#2a78d6,stroke:#1c5cab,color:#fff style B fill:#86b6ef,stroke:#5598e7,color:#0b0b0b style C fill:#86b6ef,stroke:#5598e7,color:#0b0b0b style D fill:#c9ddf6,stroke:#86b6ef,color:#0b0b0b style E fill:#c9ddf6,stroke:#86b6ef,color:#0b0b0b Agentic Architecture and Orchestration alone is worth more than the two lightest domains combined Agentic Architecture \u0026amp; Orchestration carries more weight than any other single domain — over a quarter of the exam — which tells you where Anthropic thinks the real skill gap sits between someone who uses Claude well and someone who architects Claude systems: not in knowing the API surface, but in designing how autonomous work gets orchestrated, handed off, and kept reliable.\nKey point 3: usage skill and architecture skill are different exams for a reason # Being good at prompting doesn\u0026rsquo;t automatically make someone good at deciding when a workflow should become a multi-agent system, what a tool\u0026rsquo;s interface should look like to an LLM calling it blind, or how a Claude Code deployment should be configured so a team can trust it in production. The Associate exam tests judgment inside a single conversation. The Architect exam tests judgment about the system around the conversation — the parts a single good prompt can\u0026rsquo;t fix.\nKey point 4: what this series covers # Six more posts follow this one, each taking on one domain in the order of the exam guide: Agentic Architecture \u0026amp; Orchestration, Tool Design \u0026amp; MCP Integration, Claude Code Configuration \u0026amp; Workflows, Prompt Engineering \u0026amp; Structured Output, and Context Management \u0026amp; Reliability. The series closes with a 100-question interactive practice set — 20 per domain, click an answer and see immediately whether it\u0026rsquo;s right — built as an unofficial study aid once all five domain posts are written.\nConclusion # Claude Certified Architect – Foundations in one pass: it\u0026rsquo;s the next certification after Associate, not a harder version of the same one — it tests systems design, not usage discipline. 60 items, 120 minutes, a scaled 720 to pass. Agentic Architecture \u0026amp; Orchestration is the domain to take most seriously at 27% of the exam, with Claude Code Configuration \u0026amp; Workflows and Prompt Engineering \u0026amp; Structured Output tied right behind it at 20% each. Six domain-by-domain posts and a practice quiz follow.\nSources # Claude Certified Architect – Foundations Certification — Anthropic Partner Academy Claude Certified Architect – Foundations Exam Guide — official PDF Where this fits # Part 1 of Becoming a Claude Architect. This series follows on from Getting Claude Certified, my 9-part series on the Claude Certified Associate – Foundations exam — start there if you\u0026rsquo;re newer to Claude. Part 2 takes on Domain 1 — Agentic Architecture \u0026amp; Orchestration.\n","date":"24 September 2026","externalUrl":null,"permalink":"/posts/claude-architect-01-overview/","section":"Posts","summary":"What this is about # Claude Certified Architect – Foundations is Anthropic’s certification for designing Claude systems, not just using them. Where the Claude Certified Associate exam tests whether you can operate Claude with professional discipline — good prompts, sound judgment on output, the right entry point for the job — the Architect exam tests something a level up: can you design the agentic system, the tool integrations, and the configuration that other people build on top of. The ideal candidate has 6+ months of hands-on experience building with the Claude API, the Claude Agent SDK, Claude Code, and Model Context Protocol (MCP) — this isn’t a first certification, it’s the next one.\n","title":"Becoming a Claude Architect: Overview — Claude Certified Architect – Foundations","type":"posts"},{"content":" What this is about # Domain 4 — Prompt Engineering \u0026amp; Structured Output — ties Claude Code Configuration \u0026amp; Workflows for second-heaviest domain on the Claude Certified Architect – Foundations exam, at 20%. Its six task areas move from how you write a prompt to how you guarantee what comes back is actually usable: explicit criteria, few-shot examples, schema-enforced output, validation loops, multi-instance review, and batch processing for scale.\nKey point 1: explicit criteria beat vague instructions, every time # Claude\u0026rsquo;s own prompting docs frame this well: treat Claude like a brilliant but new employee who has no context on your norms. \u0026ldquo;Review this code\u0026rdquo; leaves Claude guessing what counts as worth flagging. \u0026ldquo;Report security vulnerabilities and logic errors; skip style preferences\u0026rdquo; doesn\u0026rsquo;t. The architect-level version of this shows up in things like severity classification — giving Claude concrete criteria for what\u0026rsquo;s critical versus minor, with actual code examples of each — rather than trusting it to calibrate severity from a one-line instruction. The test the docs suggest: show your prompt to a colleague with minimal context and see if they\u0026rsquo;d know exactly what to do. If they\u0026rsquo;d be confused, so will Claude.\nKey point 2: a handful of good examples beats a page of description # Few-shot (multishot) prompting is one of the most reliable ways to steer output format, tone, and structure — Claude generalizes from concrete examples far more reliably than from abstract rules. For extraction tasks specifically, where source documents vary in structure, 2-4 well-chosen examples covering the ambiguous or edge-case scenarios do more to reduce hallucination than a longer written specification would. The examples have to earn their place, though: relevant (close to your real use case), diverse (covering edge cases so Claude doesn\u0026rsquo;t lock onto an unintended pattern), and clearly marked off from the rest of the prompt (Claude\u0026rsquo;s docs recommend wrapping them in \u0026lt;example\u0026gt; tags so they read as demonstrations, not instructions).\nKey point 3: tool use with JSON schemas is how you guarantee the shape of the output # Asking nicely for JSON in a text prompt gets you JSON most of the time. Tool use with a JSON schema — especially with strict: true — gets you schema-compliant output through constrained decoding, which is a materially different guarantee: no parsing errors, no retries for a malformed shape. tool_choice gives you the dial on top of that: auto lets Claude decide whether to call the tool, any guarantees some tool gets called, and a forced choice pins it to one specific tool. The detail worth internalizing for real-world extraction: when source documents might not contain every field, design those fields as optional in the schema (leave them out of required) rather than forcing Claude to fabricate a value just to satisfy the schema.\nKey point 4: when validation fails, feed the failure back — don\u0026rsquo;t just retry blind # A retry that resends the identical prompt after a validation failure wastes a call and often reproduces the same mistake. The stronger pattern appends the specific validation error to the prompt on retry, so Claude sees exactly what was wrong and can correct it directly rather than guessing again from scratch. Part of designing this well is distinguishing semantic errors (the data\u0026rsquo;s wrong — a field has an implausible value) from syntax errors (the shape\u0026rsquo;s wrong — malformed JSON, a missing required key): they call for different feedback and, at scale, tracking which error types recur tells you where the schema or prompt itself needs to change, not just the retry logic.\nflowchart LR A[Generate output] --\u003e B{Passes validation?} B --\u003e|Yes| C[Accept] B --\u003e|No| D[Append specific errorto prompt] D --\u003e A style C fill:#28c840,stroke:#1c9c30,color:#fff style D fill:#2a78d6,stroke:#1c5cab,color:#fff Key point 5: a model reviewing its own output is a weaker check than a fresh instance reviewing it # Self-review has a structural limitation: the model still holds the context from generating the thing it\u0026rsquo;s now reviewing, which makes it less likely to question its own choices — it\u0026rsquo;s primed to confirm, not interrogate. An independent review instance, with no memory of having written the work, catches subtler issues more reliably because it has nothing invested in the original approach. For large reviews, the same idea scales into multi-pass review: split the work into a local pass (checking each piece on its own) and a separate cross-file or integration pass (checking how the pieces fit together), rather than expecting one pass to catch both kinds of problems at once.\nA quick note on scale: batch processing for latency-tolerant workloads # Rounding out the domain: the Message Batches API trades immediacy for cost — roughly 50% off standard token pricing, with most batches finishing within an hour and a maximum 24-hour processing window. It\u0026rsquo;s built for exactly the kind of work this domain is about: bulk extraction, large-scale evaluation, content moderation at volume — anything non-blocking where a user isn\u0026rsquo;t waiting on the response in real time. Each request in a batch carries a custom_id, which matters because results come back in arbitrary order, not the order you submitted them; that same ID is what lets you cleanly identify and resubmit just the failed requests rather than re-running the whole batch.\nHow much this matters # Tied for second at 20% — the domain where a good prompt stops being enough on its own Conclusion # Domain 4 in one pass: explicit, verifiable criteria beat vague instructions every time. A handful of relevant, diverse examples steers output more reliably than a longer written description. Tool use with a strict JSON schema is what actually guarantees the shape of your output, with tool_choice as the dial and optional fields for incomplete source data. Validation failures should feed their specific error back into the retry, not just repeat the prompt. Independent review instances catch what self-review structurally can\u0026rsquo;t. And the Message Batches API is the lever for scale once latency stops being a constraint.\nSources # Claude Certified Architect – Foundations Exam Guide — Domain 4 task statements Prompting best practices — Claude Platform Docs — explicit criteria, few-shot examples Structured outputs — Claude Platform Docs — strict tool use, JSON schema, optional fields Batch processing — Claude Platform Docs — Message Batches API, custom_id Best practices for Claude Code — Claude Code Docs — adversarial/independent review pattern The research and the technical accuracy check against the official docs are AI-assisted; the framing, the \u0026ldquo;what this means for the exam\u0026rdquo; judgment calls, and any war stories are mine.\nWhere this fits # Part 5 of Becoming a Claude Architect, following Domain 3 — Claude Code Configuration \u0026amp; Workflows. Part 6 takes on Domain 5 — Context Management \u0026amp; Reliability.\n","date":"24 September 2026","externalUrl":null,"permalink":"/posts/claude-architect-05-prompt-engineering-structured-output/","section":"Posts","summary":"What this is about # Domain 4 — Prompt Engineering \u0026 Structured Output — ties Claude Code Configuration \u0026 Workflows for second-heaviest domain on the Claude Certified Architect – Foundations exam, at 20%. Its six task areas move from how you write a prompt to how you guarantee what comes back is actually usable: explicit criteria, few-shot examples, schema-enforced output, validation loops, multi-instance review, and batch processing for scale.\n","title":"Becoming a Claude Architect: Prompt Engineering \u0026 Structured Output — Domain 4","type":"posts"},{"content":" What this is about # Domain 2 — Tool Design \u0026amp; MCP Integration — is 18% of the Claude Certified Architect – Foundations exam, across five task areas: designing tool interfaces, structuring error responses, distributing tools across agents, integrating MCP servers, and choosing built-in tools well. It\u0026rsquo;s a lighter domain than Agentic Architecture, but arguably the most immediately practical one — every point here shows up the first time you give an agent a tool that doesn\u0026rsquo;t work the way you expected.\nKey point 1: the tool description is the selection mechanism # An LLM doesn\u0026rsquo;t read your tool\u0026rsquo;s code before deciding to call it — it reads the description. That\u0026rsquo;s the entire basis for tool selection, which means a minimal description (\u0026ldquo;searches files\u0026rdquo;) is a liability the moment you have two tools that could plausibly match a request. The exam\u0026rsquo;s fix is specific: descriptions should include input formats, example queries, edge cases, and explicit boundaries — what the tool does and doesn\u0026rsquo;t cover. In practice this often means renaming tools to eliminate functional overlap, or splitting one generic tool into several purpose-specific ones with clearly defined contracts, rather than trying to write an ever-longer description for one tool that does too much.\nKey point 2: structured errors let the agent recover, generic ones don\u0026rsquo;t # When a tool call fails, \u0026ldquo;Operation failed\u0026rdquo; tells the model nothing it can act on. MCP\u0026rsquo;s actual mechanism distinguishes two layers: protocol errors (malformed request, unknown tool — returned as JSON-RPC errors, and less recoverable) versus tool execution errors (validation failures, business-logic errors, API failures — returned inside the tool result with isError: true, specifically so the model can self-correct and retry with adjusted parameters). The architect-level skill is going further than the flag alone: returning structured error metadata that categorizes the failure (transient, validation, business, permission) with a retryable flag, and distinguishing a genuine access failure from a valid-but-empty result — because those two should never look the same to the agent.\nKey point 3: fewer tools per agent, chosen on purpose # The exam guide states this almost as a rule of thumb: giving an agent access to too many tools — its example is 18 instead of 4-5 — degrades tool selection reliability. The fix isn\u0026rsquo;t fewer capabilities overall, it\u0026rsquo;s scoped access: give each subagent only the tools relevant to its role, and replace an overly generic tool with a more constrained, purpose-built alternative when one subagent keeps misusing it. Claude\u0026rsquo;s API gives you a second lever for the same problem: tool_choice. auto lets Claude decide whether to call a tool at all; any (or a forced tool choice naming one specifically) guarantees a tool gets used, which is the right call when you need a particular tool invoked first, before Claude reasons about anything else.\nKey point 4: MCP servers are scoped for a reason — don\u0026rsquo;t default to the wrong one # Claude Code separates MCP server configuration by scope: project-level (.mcp.json, checked into version control) is for shared team tooling everyone on the repo gets automatically, while user-level (~/.claude.json) is for personal or experimental servers you don\u0026rsquo;t want committed. Credentials go through environment variable expansion (${API_KEY}, with ${VAR:-default} fallback syntax) rather than hardcoded into the config file, which is what makes a .mcp.json safe to commit in the first place — the file has the shape of the config, not the secret. The other architect-level habit worth calling out: reach for an existing, well-maintained community MCP server before building a custom one, and expose read-heavy content (like a catalog or knowledge base) as MCP resources rather than wrapping it in a tool that just returns a blob of text.\nProject scope (.mcp.json) User scope (~/.claude.json) Loads in Current project All your projects Shared with team Yes, via version control No Typical use Shared team tooling Personal or experimental servers Key point 5: pick the right built-in tool for the job # The exam also tests plain tool-selection judgment among Claude Code\u0026rsquo;s own built-ins. Grep is for content search — finding where a function is called across a codebase. Glob is for file path pattern matching — finding files by name or extension, not by what\u0026rsquo;s inside them. Read and Write handle whole-file operations; Edit is for a targeted, in-place modification rather than rewriting a file wholesale. Strung together well, these build up codebase understanding incrementally — Glob to find candidates, Grep to narrow by content, Read to confirm, Edit to change — rather than reaching for Read on every file in a directory out of caution.\nflowchart TD A[What do you need to do?] --\u003e B{Searching for something?} B --\u003e|By file name / pattern| C[Glob] B --\u003e|By file content| D[Grep] A --\u003e E{Changing a file?} E --\u003e|Small, targeted change| F[Edit] E --\u003e|Full file read or rewrite| G[Read / Write] style C fill:#c9ddf6,stroke:#86b6ef,color:#0b0b0b style D fill:#c9ddf6,stroke:#86b6ef,color:#0b0b0b style F fill:#2a78d6,stroke:#1c5cab,color:#fff style G fill:#86b6ef,stroke:#5598e7,color:#0b0b0b How much this matters # 18% of the exam, but the domain most likely to break your first working agent in production Conclusion # Domain 2 in one pass: the description is the interface — write it like the model is choosing blind, because it is. Structured errors with isError and a category/retryable flag let an agent recover instead of just failing. Fewer, well-scoped tools per agent beat a kitchen-sink tool list, and tool_choice gives you a second lever to guarantee the right one gets called. MCP servers split cleanly into project-shared and user-personal for a reason — respect the scoping. And the built-in tools reward picking deliberately: Grep for content, Glob for paths, Edit for small changes, Read/Write for whole files.\nSources # Claude Certified Architect – Foundations Exam Guide — Domain 2 task statements Tools — Model Context Protocol specification — isError, protocol errors vs. tool execution errors Implement tool use — Claude API Docs — tool_choice options Connect Claude Code to tools via MCP — Claude Code Docs — project vs. user server scoping, environment variable expansion The research and the technical accuracy check against the official docs are AI-assisted; the framing, the \u0026ldquo;what this means for the exam\u0026rdquo; judgment calls, and any war stories are mine.\nWhere this fits # Part 3 of Becoming a Claude Architect, following Domain 1 — Agentic Architecture \u0026amp; Orchestration. Part 4 takes on Domain 3 — Claude Code Configuration \u0026amp; Workflows.\n","date":"24 September 2026","externalUrl":null,"permalink":"/posts/claude-architect-03-tool-design-mcp-integration/","section":"Posts","summary":"What this is about # Domain 2 — Tool Design \u0026 MCP Integration — is 18% of the Claude Certified Architect – Foundations exam, across five task areas: designing tool interfaces, structuring error responses, distributing tools across agents, integrating MCP servers, and choosing built-in tools well. It’s a lighter domain than Agentic Architecture, but arguably the most immediately practical one — every point here shows up the first time you give an agent a tool that doesn’t work the way you expected.\n","title":"Becoming a Claude Architect: Tool Design \u0026 MCP Integration — Domain 2","type":"posts"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/series/becoming-a-claude-architect/","section":"Series","summary":"","title":"Becoming-a-Claude-Architect","type":"series"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/certification/","section":"Tags","summary":"","title":"Certification","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/ci-cd/","section":"Tags","summary":"","title":"Ci-Cd","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/categories/claude/","section":"Categories","summary":"","title":"Claude","type":"categories"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/claude/","section":"Tags","summary":"","title":"Claude","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/claude-agent-sdk/","section":"Tags","summary":"","title":"Claude-Agent-Sdk","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/claude-architect/","section":"Tags","summary":"","title":"Claude-Architect","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/claude-code/","section":"Tags","summary":"","title":"Claude-Code","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/claude-md/","section":"Tags","summary":"","title":"Claude-Md","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/context-management/","section":"Tags","summary":"","title":"Context-Management","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/json-schema/","section":"Tags","summary":"","title":"Json-Schema","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/mcp/","section":"Tags","summary":"","title":"Mcp","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/multi-agent/","section":"Tags","summary":"","title":"Multi-Agent","type":"tags"},{"content":" About me ","date":"24 September 2026","externalUrl":null,"permalink":"/","section":"Newton Rocha","summary":" About me ","title":"Newton Rocha","type":"page"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/practice-quiz/","section":"Tags","summary":"","title":"Practice-Quiz","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/prompt-engineering/","section":"Tags","summary":"","title":"Prompt-Engineering","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/reliability/","section":"Tags","summary":"","title":"Reliability","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/structured-output/","section":"Tags","summary":"","title":"Structured-Output","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/subagents/","section":"Tags","summary":"","title":"Subagents","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"24 September 2026","externalUrl":null,"permalink":"/tags/tool-use/","section":"Tags","summary":"","title":"Tool-Use","type":"tags"},{"content":" What this is about # Domain 7 of the Claude Certified Associate – Foundations exam is Troubleshooting and Optimization. It\u0026rsquo;s worth 10% — the lightest domain on the exam. But it\u0026rsquo;s the one that closes the loop on the other six: everything from prompting to configuration to model selection eventually produces an output that underperforms, and this domain is the discipline of tracing that failure to its root cause, fixing it, and making sure the fix persists instead of getting re-discovered next week.\nTroubleshooting and Optimization is the lightest domain on the exam — but it\u0026rsquo;s the one every other domain eventually routes through Key point 1: four failure patterns, four different fixes # Underperformance almost always traces to one of four patterns, and each leaves a distinct symptom signature. Under-specification — the prompt leaves too much to inference — shows up as inconsistent output shape across otherwise similar runs. Context overload — too much competing information crowding out early instructions — shows up as quality that was fine, then quietly drifted as the session grew. Wrong feature or model — the task needs a different tool entirely — shows up as a prompt that\u0026rsquo;s fine but capped by the setup underneath it. Stale configuration — instructions, knowledge, or a Skill reflecting an old process — shows up as output that was correct for months and then wrong for no prompt-side reason at all. Naming the pattern before reaching for a fix is most of the diagnosis.\nMatch the symptom to the pattern before touching anything — the four patterns rarely share a fix Key point 2: fix cheapest first # The diagnostic sequence runs from lowest cost to highest: check the prompt and instructions before switching models, check configuration before rebuilding the workflow. Reaching for a bigger model or a full workflow redesign before ruling out a vague instruction or a stale piece of configuration burns time and often doesn\u0026rsquo;t even fix the problem, because the root cause was never model capability in the first place.\nflowchart TD A[Output underperforming] --\u003e B{Is the prompt orinstruction specific enough?} B --\u003e|No| C[Fix the prompt/instructionscheapest, try first] B --\u003e|Yes| D{Is configurationstale or missing?} D --\u003e|Yes| E[Update instructions,knowledge, or Skill] D --\u003e|No| F{Is this the rightfeature or model tier?} F --\u003e|No| G[Switch entry pointor model tier] F --\u003e|Yes| H[Redesign the workflowlast resort, highest cost] style C fill:#86b6ef,stroke:#5598e7,color:#0b0b0b style E fill:#2a78d6,stroke:#1c5cab,color:#fff style G fill:#104281,stroke:#0d366b,color:#fff style H fill:#d03b3b,stroke:#a32e2e,color:#fff Key point 3: turn vague critique into a specific adjustment # \u0026ldquo;Make it better\u0026rdquo; isn\u0026rsquo;t actionable — it gives Claude nothing new to act on, so the next attempt drifts the same way the first one did. Naming the exact dimension that failed is what actually changes the output: not \u0026ldquo;the tone is off\u0026rdquo; but \u0026ldquo;drop the exclamation points and cut every sentence that restates the previous one.\u0026rdquo; The difference between a captured fix and a lost one is whether that specific adjustment gets written into a standing instruction, or just applied once in the moment and forgotten by the next session.\nKey point 4: find friction with three signals, then promote the fix # Three signals point at a fix worth making permanent: repetition (you\u0026rsquo;re typing the same correction across sessions), correction (you\u0026rsquo;re editing the same kind of mistake out of the output every time), and variance (the same request produces meaningfully different quality depending on who asks or when). Once a signal shows up, the fix needs a home — and the test for which one is simple: a rule about behavior goes in standing instructions, a reference fact goes in the knowledge base, a procedure with multiple steps becomes a Skill. Promoting the fix to the right slot is what stops the correction from recurring.\nKey point 5: measure improvement against the metric that matters # A workflow audit that goes from 45 minutes to 25 minutes only counts if the 45 minutes was the actual bottleneck and 25 minutes is measured the same way — same task, same reviewer standard, not a looser one. The temptation is to optimize whatever is easiest to measure; the discipline is optimizing the metric that was actually the complaint in the first place, whether that\u0026rsquo;s time, revision count, or how often a human has to step in.\nThe full Domain 7 diagnostic-to-optimization loop in one reference sheet Conclusion # Domain 7 in one pass: name the failure pattern before reaching for a fix — under-specification, context overload, wrong feature or model, stale configuration each leave a different symptom. Fix cheapest first: prompt and instructions before model switches, configuration before workflow redesigns. Turn vague critique into a specific, capturable adjustment instead of a one-off fix. Watch for repetition, correction, and variance, then promote the fix into the right home — rule, reference, or procedure. And measure improvement against the metric that was the actual complaint, not whatever\u0026rsquo;s easiest to track.\nSources # Troubleshooting \u0026amp; Optimization — Anthropic Partner Academy Claude Certified Associate – Foundations Exam Guide — official PDF Where this fits # Part 9 of Getting Claude Certified. Part 1 covered the 4D Framework, Part 2 covered Chat, Projects, Artifacts, and Research, Part 3 covered Domain 1 — Output Evaluation and Validation, Part 4 covered Domain 2 — Workflow Integration and Solution Design, Part 5 covered Domain 3 — Governance, Risk, and Responsible Use, Part 6 covered Domain 4 — Prompting and Task Execution, Part 7 covered Domain 5 — Product and Model Selection, Part 8 covered Domain 6 — Configuration and Knowledge Management. That\u0026rsquo;s all 7 exam domains — the series closes here.\n","date":"19 September 2026","externalUrl":null,"permalink":"/posts/claude-cert-09-troubleshooting-and-optimization/","section":"Posts","summary":"What this is about # Domain 7 of the Claude Certified Associate – Foundations exam is Troubleshooting and Optimization. It’s worth 10% — the lightest domain on the exam. But it’s the one that closes the loop on the other six: everything from prompting to configuration to model selection eventually produces an output that underperforms, and this domain is the discipline of tracing that failure to its root cause, fixing it, and making sure the fix persists instead of getting re-discovered next week.\n","title":"Claude Certified Associate – Foundations: Domain 7 — Troubleshooting and Optimization","type":"posts"},{"content":"","date":"19 September 2026","externalUrl":null,"permalink":"/series/getting-claude-certified/","section":"Series","summary":"","title":"Getting-Claude-Certified","type":"series"},{"content":"","date":"19 September 2026","externalUrl":null,"permalink":"/tags/optimization/","section":"Tags","summary":"","title":"Optimization","type":"tags"},{"content":"","date":"19 September 2026","externalUrl":null,"permalink":"/tags/troubleshooting/","section":"Tags","summary":"","title":"Troubleshooting","type":"tags"},{"content":" What this is about # Domain 6 of the Claude Certified Associate – Foundations exam is Configuration and Knowledge Management. It\u0026rsquo;s worth 12%. The line it draws: using Claude means typing a good prompt today. Operating Claude means building an environment where the right context, instructions, and procedures already exist, so every conversation starts from a configured baseline instead of a blank slate. Configuration is leverage — set it up once, benefit on every conversation that follows — and it\u0026rsquo;s also what turns individual skill into team capability, since two people asking the same question against the same configured Project get the same quality of answer.\nConfiguration and Knowledge Management ties for fifth-heaviest on the exam Key point 1: four mechanisms, four different jobs # Instructions govern behavior — tone, format defaults, verification habits — not facts. The knowledge base holds facts and reference material Claude should draw on without re-uploading — not behavior. Skills carry a repeatable procedure, built once at the account level under Customize and reused across any Project that needs it — not a one-off instruction. Scoped Memory keeps continuity within one Project, isolated from your other Projects so context never bleeds between workstreams.\nMatch the need to the slot — putting a procedure in instructions or a behavior rule in knowledge is the most common configuration mistake flowchart TD A[A recurring need] --\u003e B{What kind ofneed is it?} B --\u003e|How Claude should behave| C[Instructions] B --\u003e|A fact Claude should know| D[Knowledge base] B --\u003e|A repeatable multi-step procedure| E[Skill] B --\u003e|Continuity within this Project| F[Scoped Memory] style C fill:#2a78d6,stroke:#1c5cab,color:#fff style D fill:#eb6834,stroke:#c14e22,color:#fff style E fill:#1baf7a,stroke:#0d8a5c,color:#fff style F fill:#eda100,stroke:#c98500,color:#fff Key point 2: most needs map to two slots wired together # The cleanest configurations rarely fit one mechanism alone. \u0026ldquo;Always cite the source document for factual claims\u0026rdquo; is a standing instruction, but the documents it cites live in the knowledge base — neither works without the other. A consultant running one Project per client pairs the same way: standing instructions set the formal register and citation habit, the knowledge base holds the client\u0026rsquo;s brand guide and current statement of work, an account-level Skill formats every status report the same way, and scoped Memory holds that client\u0026rsquo;s stakeholder names — kept out of every other client\u0026rsquo;s Project entirely.\nKey point 3: connectors have capability boundaries, not bugs # A connector — Google Drive, Gmail — extends Claude\u0026rsquo;s reach into data you authorize, and each one has a defined edge. A mail connector that can search and read but not send isn\u0026rsquo;t broken; it\u0026rsquo;s at its boundary. Two pitfalls show up often in the field: the obvious \u0026ldquo;add a connector\u0026rdquo; path can route to a public directory instead of your organization\u0026rsquo;s vetted ones, so confirm the right path with your admin on Team or Enterprise; and when a connector hits its boundary, the failure looks like a bug rather than documented behavior, which sends reports to the wrong team and stalls the fix. Knowing each connector\u0026rsquo;s edge before you build a workflow on it avoids both.\nKey point 4: an instruction that\u0026rsquo;s vague fails silently # \u0026ldquo;Make the reports good and accurate\u0026rdquo; gives Claude almost nothing to act on — output quality drifts conversation to conversation and nothing ever announces the failure. \u0026ldquo;For every figure in a report, state its source. If a figure isn\u0026rsquo;t in the provided data, mark it \u0026lsquo;unverified\u0026rsquo; rather than including it. Lead each report with a one-sentence headline\u0026rdquo; is precise enough to actually change output, consistently. The test for any standing instruction: would two different people reading it produce the same behavior?\nKey point 5: configurations age — schedule the maintenance # Instructions, knowledge, Skills, and Memory all drift toward stale, and none of them throw an error when they do — output just quietly degrades. A monthly review pass on active Projects catches most of it: do the standing instructions still match the current process, is the knowledge base free of superseded documents, are the right Skills enabled. Anthropic-built and org-provisioned Skills update automatically; your own custom Skills only change when you re-upload them. A recurring report Project drifting on stale figures is a textbook case — the knowledge base already had the current targets, but the standing instruction and a Memory entry still pointed at last year\u0026rsquo;s template. The fix was updating those two, not writing a better prompt.\nThe whole Domain 6 framework on one page — built to share as a standalone summary Conclusion # Domain 6 in one pass: match each recurring need to the right mechanism — instructions for behavior, knowledge for facts, Skills for procedure, scoped Memory for continuity — and expect most real needs to wire two of them together. Know each connector\u0026rsquo;s capability boundary before building on it. Write instructions precise enough that two people would read them the same way. And schedule maintenance, because configuration decays silently and the fix is almost always updating the setup, not the prompt.\nSources # Configuration \u0026amp; Knowledge Management — Anthropic Partner Academy Claude Certified Associate – Foundations Exam Guide — official PDF Where this fits # Part 8 of Getting Claude Certified. Part 1 covered the 4D Framework, Part 2 covered Chat, Projects, Artifacts, and Research, Part 3 covered Domain 1 — Output Evaluation and Validation, Part 4 covered Domain 2 — Workflow Integration and Solution Design, Part 5 covered Domain 3 — Governance, Risk, and Responsible Use, Part 6 covered Domain 4 — Prompting and Task Execution, Part 7 covered Domain 5 — Product and Model Selection. Part 9 covered Domain 7 — Troubleshooting and Optimization — that closes out all 7 exam domains.\n","date":"18 September 2026","externalUrl":null,"permalink":"/posts/claude-cert-08-configuration-and-knowledge-management/","section":"Posts","summary":"What this is about # Domain 6 of the Claude Certified Associate – Foundations exam is Configuration and Knowledge Management. It’s worth 12%. The line it draws: using Claude means typing a good prompt today. Operating Claude means building an environment where the right context, instructions, and procedures already exist, so every conversation starts from a configured baseline instead of a blank slate. Configuration is leverage — set it up once, benefit on every conversation that follows — and it’s also what turns individual skill into team capability, since two people asking the same question against the same configured Project get the same quality of answer.\n","title":"Claude Certified Associate – Foundations: Domain 6 — Configuration and Knowledge Management","type":"posts"},{"content":"","date":"18 September 2026","externalUrl":null,"permalink":"/tags/configuration/","section":"Tags","summary":"","title":"Configuration","type":"tags"},{"content":"","date":"18 September 2026","externalUrl":null,"permalink":"/tags/knowledge-management/","section":"Tags","summary":"","title":"Knowledge-Management","type":"tags"},{"content":" What this is about # Domain 5 of the Claude Certified Associate – Foundations exam is Product and Model Selection. It\u0026rsquo;s worth 12%. The framing: before prompting even starts, four decisions already set the quality ceiling for the session — the right entry point, the right capability layer, the right model tier, the right context strategy. Get those four wrong and no amount of prompt polish fixes it. Get them right and the prompt has to do a lot less work.\nProduct and Model Selection ties for fifth-heaviest on the exam Key point 1: pick the entry point by the job, not by habit # Chat is for a one-off question or quick task with no recurring setup. A Project is for recurring work with stable context and a consistent output format. An Artifact is for a standalone, editable deliverable meant to outlive the chat. Research is for a deep, current, multi-source investigation with citations. Defaulting to Chat for everything is the most common mismatch — it works, but it throws away the context-carrying value the other three exist for.\nPick the entry point by what the task needs, not by which one you opened first There\u0026rsquo;s a quick test for whether a Project is worth building at all: does the task recur, is the background context stable, is the output format consistent? If two or more of those are true, a Project usually pays for itself.\nKey point 2: four capability layers, one memory hook # Projects carry recurring context and standing configuration. Skills define a repeatable procedure. Code Execution verifies anything that needs to be computed rather than estimated. Memory persists relevant facts across sessions. The layers are independent and stack — a Project can use Skills, which can trigger Code Execution, in a conversation Memory also has context on. The shorthand worth remembering: Projects store knowledge; Skills perform tasks.\nKey point 3: the Haiku / Sonnet / Opus decision frame # Three tiers, matched to how structured and how consequential the task is. Haiku fits fast, structured, high-volume, low-ambiguity work — extraction, classification, formatting, straightforward summarization. Sonnet is the balanced starting tier for most professional work — drafting, synthesis, analysis, research assistance, document review. Opus earns its cost when the quality ceiling matters more than speed — nuanced judgment, complex multi-step reasoning, ambiguous inputs, high-stakes synthesis.\nflowchart TD A[New task] --\u003e B{Structured, high-volume,low ambiguity?} B --\u003e|Yes| C[Haikuextraction, classification, formatting] B --\u003e|No| D{Most professional work:drafting, analysis, synthesis?} D --\u003e|Yes| E[Sonnetbalanced starting tier] D --\u003e|No, needs nuanced orhigh-stakes judgment| F[Opusquality ceiling over speed] style C fill:#86b6ef,stroke:#5598e7,color:#0b0b0b style E fill:#2a78d6,stroke:#1c5cab,color:#fff style F fill:#104281,stroke:#0d366b,color:#fff The exam trap worth remembering: don\u0026rsquo;t reach for Opus just because the subject sounds important. If the task is highly structured, unambiguous, and high-volume, Haiku is usually the better answer regardless of how weighty the topic feels.\nKey point 4: manage context before it degrades the output # Long sessions lose early detail as context fills and gets compressed. When a conversation that worked well for a long time suddenly stops following an early instruction, the signal is context degradation, not a model-quality problem. The fix has three moves: restart a new conversation once the current one is no longer reliable; before restarting, write a state summary of decisions, progress, and unresolved questions, and start the new conversation from that; and persist anything that should outlive the conversation into Memory, Project knowledge, or standing instructions instead of re-explaining it every time.\nKey point 5: web search, Research, Enterprise Search, or Thinking # Four different retrieval and reasoning tools, easy to reach for the wrong one. Web search is for a quick current fact from a small number of sources. Research is for comprehensive, multi-source, citation-backed investigation and comparative synthesis. Enterprise Search is for internal organizational knowledge — policies, Slack, email, docs, cross-source company context. Thinking is for deep reasoning where external information isn\u0026rsquo;t the core need at all.\nNeed Reach for Quick current fact Web search Comprehensive multi-source investigation Research Internal company knowledge across tools Enterprise Search Deep reasoning, no external lookup needed Thinking The whole Domain 5 framework on one page — built to share as a standalone summary Conclusion # Domain 5 in one pass: pick the entry point that matches the job (Chat, Project, Artifact, or Research), know which of the four capability layers the task actually needs and remember Projects store knowledge while Skills perform tasks, match the model tier to how structured and consequential the work is instead of defaulting to the biggest model, and treat a conversation that stopped following instructions as a context problem to restart-summarize-persist through, not a model problem to fight. These four decisions happen before the prompt does any work at all.\nSources # Claude Platform \u0026amp; Model Foundations — Anthropic Partner Academy Claude Certified Associate – Foundations Exam Guide — official PDF Where this fits # Part 7 of Getting Claude Certified. Part 1 covered the 4D Framework, Part 2 covered Chat, Projects, Artifacts, and Research, Part 3 covered Domain 1 — Output Evaluation and Validation, Part 4 covered Domain 2 — Workflow Integration and Solution Design, Part 5 covered Domain 3 — Governance, Risk, and Responsible Use, Part 6 covered Domain 4 — Prompting and Task Execution. Part 8 takes on Domain 6 — Configuration and Knowledge Management.\n","date":"17 September 2026","externalUrl":null,"permalink":"/posts/claude-cert-07-product-and-model-selection/","section":"Posts","summary":"What this is about # Domain 5 of the Claude Certified Associate – Foundations exam is Product and Model Selection. It’s worth 12%. The framing: before prompting even starts, four decisions already set the quality ceiling for the session — the right entry point, the right capability layer, the right model tier, the right context strategy. Get those four wrong and no amount of prompt polish fixes it. Get them right and the prompt has to do a lot less work.\n","title":"Claude Certified Associate – Foundations: Domain 5 — Product and Model Selection","type":"posts"},{"content":"","date":"17 September 2026","externalUrl":null,"permalink":"/tags/model-selection/","section":"Tags","summary":"","title":"Model-Selection","type":"tags"},{"content":"","date":"17 September 2026","externalUrl":null,"permalink":"/tags/product-selection/","section":"Tags","summary":"","title":"Product-Selection","type":"tags"},{"content":" What this is about # Domain 4 of the Claude Certified Associate – Foundations exam is Prompting and Task Execution. It\u0026rsquo;s worth 14%. The framing that matters here: ask Claude to \u0026ldquo;write something about our Q3 results\u0026rdquo; and you get a generic paragraph. Specify the audience, the three results that matter, the format, and the length, and you get a draft you can almost send. The model didn\u0026rsquo;t get smarter between those two requests. The prompt did. This domain treats prompting as a communication discipline with learnable structure, not a knack some people have.\nPrompting and Task Execution is the fourth-heaviest domain on the exam Key point 1: the five-component stack # Five components carry almost all the weight in a professional prompt: Role (who Claude should be for this task), Context (the background Claude can\u0026rsquo;t know unless you give it), Task (one unambiguous action), Constraints (length, tone, what to include or avoid), and Output format (the shape of the result). Not every prompt needs all five — a quick question needs a task and maybe a constraint. Context is the one professionals skip most often, because it lives in your head and never makes it into the prompt.\nMost weak prompts are missing one row on this list, usually Context Key point 2: decompose complex requests into ordered steps # A request with several distinct stages packed into one prompt produces shallow work on every stage. \u0026ldquo;Evaluate these three vendors and tell me which to pick\u0026rdquo; forces Claude to invent criteria, apply them, weigh trade-offs, and recommend, all in one pass — you never see the reasoning. Break it into a sequence instead, and each step produces a checkable result before the next one runs.\nflowchart LR A[Derive criteriafrom requirements doc] --\u003e B[Score each vendoragainst those criteria] B --\u003e C[Raise trade-offswhere vendors diverge] C --\u003e D[Recommendtied back to weighted criteria] style A fill:#2a78d6,stroke:#1c5cab,color:#fff style B fill:#2a78d6,stroke:#1c5cab,color:#fff style C fill:#2a78d6,stroke:#1c5cab,color:#fff style D fill:#1c5cab,stroke:#104281,color:#fff If the criteria in step one are wrong, you catch it before scoring, not after the recommendation ships. Keep steps that build on each other in one conversation; split off into a new one only when a step is genuinely independent or the thread has grown long enough that early context is degrading.\nKey point 3: iterate on the component that failed, not the whole prompt # A first draft rarely lands perfectly, and the fix is never rewriting the whole prompt — that loses the parts that worked and hides which change actually fixed the problem. Read the output as a diagnostic instead: it points straight back to the component that fell short.\nSymptom Likely cause Fix Output is generic or off-base Context was thin Add the background Claude couldn\u0026rsquo;t infer Output answered the wrong question Task verb was ambiguous Sharpen the instruction Output is the wrong length, tone, or shape A constraint or format was missing Add it Output is close but misses one section — Iterate on that section only Change the one component the output told you to change, resend, and compare. Stop when a round produces marginal change instead of real improvement — at that point a quick manual edit beats another round of prompting.\nKey point 4: match strategy to task type # The five components apply everywhere, but the emphasis shifts with what you\u0026rsquo;re actually doing. Analysis wants tight constraints and explicit criteria — low creative latitude, high specification. Research wants clear scope and source discipline, with citations you can actually check. Drafting wants audience, tone, and format fixed, with room for Claude to find the phrasing. Brainstorming wants loose constraints and high latitude — over-specifying kills the range you\u0026rsquo;re after.\nTask type Tighten Loosen Analysis Criteria, standards, scope Phrasing Research Question, sources, citations Synthesis approach Drafting Audience, tone, format Word choice Brainstorming Goal and guardrails only Quantity and direction Key point 5: a weak prompt, repaired # Weak: \u0026ldquo;Summarize the customer feedback and tell me what to do.\u0026rdquo; Output: a generic five-bullet list of themes, nothing tied to the actual data, nothing actionable — because the prompt specified almost nothing.\nRepaired: \u0026ldquo;You are a product analyst (role). Attached are 200 customer survey responses (context). Identify the three most frequently raised issues, ranked by how many responses mention each (task), and for each include one representative verbatim quote and the approximate share of responses it appears in (constraints) — use code execution to count accurately rather than estimating. Format as a ranked list, most frequent first (output format).\u0026rdquo;\nSame model, same data. The gap between the two outputs is entirely in the specification, not the underlying capability.\nThe whole Domain 4 framework on one page — built to share as a standalone summary Conclusion # Domain 4 in one pass: run every non-trivial prompt against the five components (role, context, task, constraints, format), and expect context to be the one you forgot. Decompose multi-stage work into ordered steps so each one produces a checkable result before the next runs. When output disappoints, diagnose which component failed and fix only that — don\u0026rsquo;t start over. Match your specification style to the task: tight for analysis and research, looser for drafting, loosest for brainstorming. Structure drives quality here, not cleverness.\nSources # Prompting \u0026amp; Task Execution — Anthropic Partner Academy Claude Certified Associate – Foundations Exam Guide — official PDF Where this fits # Part 6 of Getting Claude Certified. Part 1 covered the 4D Framework, Part 2 covered Chat, Projects, Artifacts, and Research, Part 3 covered Domain 1 — Output Evaluation and Validation, Part 4 covered Domain 2 — Workflow Integration and Solution Design, Part 5 covered Domain 3 — Governance, Risk, and Responsible Use. Part 7 takes on Domain 5 — Product and Model Selection.\n","date":"16 September 2026","externalUrl":null,"permalink":"/posts/claude-cert-06-prompting-and-task-execution/","section":"Posts","summary":"What this is about # Domain 4 of the Claude Certified Associate – Foundations exam is Prompting and Task Execution. It’s worth 14%. The framing that matters here: ask Claude to “write something about our Q3 results” and you get a generic paragraph. Specify the audience, the three results that matter, the format, and the length, and you get a draft you can almost send. The model didn’t get smarter between those two requests. The prompt did. This domain treats prompting as a communication discipline with learnable structure, not a knack some people have.\n","title":"Claude Certified Associate – Foundations: Domain 4 — Prompting and Task Execution","type":"posts"},{"content":"","date":"16 September 2026","externalUrl":null,"permalink":"/tags/prompting/","section":"Tags","summary":"","title":"Prompting","type":"tags"},{"content":"","date":"16 September 2026","externalUrl":null,"permalink":"/tags/task-execution/","section":"Tags","summary":"","title":"Task-Execution","type":"tags"},{"content":" What this is about # Domain 3 of the Claude Certified Associate – Foundations exam is Governance, Risk, and Responsible Use. It\u0026rsquo;s worth 15%. The framing is blunt: sensitive data uploaded to the wrong place, an untrusted Skill granted broad access, a quiet policy violation at the wrong moment — any one of these can freeze an entire organization\u0026rsquo;s AI program and cost every team the productivity it had gained. Governance isn\u0026rsquo;t a policy binder on a shelf. It\u0026rsquo;s exercised by practitioners, one decision at a time — which makes it a skill you build, not a document you read once.\nGovernance, Risk, and Responsible Use is the third-heaviest domain on the exam Key point 1: screen use cases with four questions, not a gut feeling # Every proposed use case gets tested against four criteria: reversibility (can a wrong output be caught before it causes harm?), consequence of error (what does it cost if it\u0026rsquo;s wrong?), need for human creativity or empathy (does this require judgment a model can\u0026rsquo;t supply?), and accountability (who answers for the outcome?). Run all four, then name the one that\u0026rsquo;s load-bearing — the one that, if it changed, would move the use case into a different category. That\u0026rsquo;s what makes a classification defensible to a reviewer instead of just a feeling.\nflowchart TD A[Proposed use case] --\u003e B{Run the 4 criteria:reversibility, consequence,human element, accountability} B --\u003e|All clear| C[Fully appropriatenormal review] B --\u003e|Useful, but stakes oraccountability need a gate| D[Appropriate with human reviewdefine who/what/when] B --\u003e|Irreversible, high consequence,or non-transferable accountability| E[Inappropriatename the human role that must own it] style C fill:#0ca30c,stroke:#087a08,color:#fff style D fill:#fab219,stroke:#c98500,color:#0b0b0b style E fill:#d03b3b,stroke:#a82f2f,color:#fff The middle box is where most people get sloppy: \u0026ldquo;appropriate with human review\u0026rdquo; isn\u0026rsquo;t real until the gate is specific — who reviews, what they check, and when in the workflow it happens. \u0026ldquo;A manager reviews the shortlist for adverse-impact patterns before any candidate is contacted\u0026rdquo; is a gate. \u0026ldquo;We\u0026rsquo;ll keep a human in the loop\u0026rdquo; is not.\nKey point 2: a Skill is software — vet it like software # A Skill can access whatever your session already has access to and can take actions through code execution. It doesn\u0026rsquo;t request permissions; it inherits them. Before enabling one, check three things: source (who published it — Anthropic, internally-approved, or an unknown third party), reach (what could it actually touch in the sessions it runs in, and is that proportional to the task), and appropriateness (is it the right tool for the job, or more capability than needed). \u0026ldquo;Internal\u0026rdquo; isn\u0026rsquo;t the same as \u0026ldquo;vetted\u0026rdquo; — a Skill built by another team in your own company still needs the same check.\nThree outcomes fall out of that check: enable it when source, permissions, and appropriateness are all clear; escalate it to your admin or security function when it\u0026rsquo;s useful but the source or permissions are unclear; decline it when the permissions are clearly disproportionate or the source can\u0026rsquo;t be established. The same proportionality habit applies to any capability that can read or act on your data, not just Skills — least privilege, revisited when the job changes.\nKey point 3: classify data before it touches a feature # Sort data into three tiers before it goes near any feature. Green — public, anonymized, or already-cleared internal material — needs no special handling. Yellow — internal-only documents, anything with names or contact details, unannounced deal or product material — needs a policy check first, and Incognito mode so it skips Memory and chat history (though your organization\u0026rsquo;s underlying retention policy still applies). Red — regulated data, credentials, anything under a third-party confidentiality obligation — needs an approved entry point confirmed before anything uploads, full stop.\nIncognito controls what gets remembered, not whether the data was allowed in the first place — for red data, that question comes first The common mistake is treating Incognito as a safety net for red data. It isn\u0026rsquo;t. Incognito controls whether something gets remembered — it says nothing about whether the data was allowed into that feature to begin with. For regulated data, \u0026ldquo;is this allowed here\u0026rdquo; gets answered before \u0026ldquo;how do I handle it here.\u0026rdquo;\nKey point 4: diligence is a habit, not a one-time check # A policy followed only when someone\u0026rsquo;s watching isn\u0026rsquo;t governance — the gap between what the policy says and what people actually do is exactly where risk accumulates, quietly, on the routine low-visibility decisions rather than the obvious high-stakes ones. The fix is a periodic audit: compare what your team is actually doing against what policy requires, and treat every divergence — an unapproved upload, a skipped review gate, an unvetted Skill — as a closeable gap, not a violation to punish. Most drift isn\u0026rsquo;t malicious. It\u0026rsquo;s friction: people take the easy path when the approved one is slower, so the durable fix is usually removing the friction, not adding a rule.\nKey point 5: ethical risk hides in ordinary outputs # Bias and fairness risk doesn\u0026rsquo;t show up labeled as an ethics problem — it shows up as a routine summary, recommendation, or shortlist that quietly favors one group, built on a framing nobody questioned. It belongs in routine review, especially in people-facing work like hiring or evaluation, not a separate ethics exercise. Transparency matters too: know when your context or policy requires disclosing AI assistance, and default to disclosing when you\u0026rsquo;re unsure. For genuinely ambiguous cases, reason through who\u0026rsquo;s affected, what could go wrong, what fair looks like, and what disclosure applies — and when the affected population is large or the harm significant, escalate the reasoning rather than deciding alone. A documented \u0026ldquo;I don\u0026rsquo;t know, and here\u0026rsquo;s why\u0026rdquo; is more useful to a reviewer than a confident guess.\nThe whole Domain 3 framework on one page — built to share as a standalone summary Conclusion # Domain 3 in one pass: screen every use case against reversibility, consequence, human element, and accountability, and make the human-review gate specific when that\u0026rsquo;s the answer. Vet a Skill\u0026rsquo;s source and reach like you\u0026rsquo;d vet any software before installing it. Classify data green, yellow, or red before it touches a feature, and remember Incognito isn\u0026rsquo;t a substitute for that classification. Audit real usage against policy on a schedule, because drift happens quietly. And check routine outputs for bias and disclosure the same way you\u0026rsquo;d check them for accuracy — because the ethical risk was never going to announce itself.\nSources # Governance, Risk \u0026amp; Responsible Use — Anthropic Partner Academy Claude Certified Associate – Foundations Exam Guide — official PDF Where this fits # Part 5 of Getting Claude Certified. Part 1 covered the 4D Framework, Part 2 covered Chat, Projects, Artifacts, and Research, Part 3 covered Domain 1 — Output Evaluation and Validation, Part 4 covered Domain 2 — Workflow Integration and Solution Design. Part 6 takes on Domain 4 — Prompting and Task Execution.\n","date":"15 September 2026","externalUrl":null,"permalink":"/posts/claude-cert-05-governance-risk-and-responsible-use/","section":"Posts","summary":"What this is about # Domain 3 of the Claude Certified Associate – Foundations exam is Governance, Risk, and Responsible Use. It’s worth 15%. The framing is blunt: sensitive data uploaded to the wrong place, an untrusted Skill granted broad access, a quiet policy violation at the wrong moment — any one of these can freeze an entire organization’s AI program and cost every team the productivity it had gained. Governance isn’t a policy binder on a shelf. It’s exercised by practitioners, one decision at a time — which makes it a skill you build, not a document you read once.\n","title":"Claude Certified Associate – Foundations: Domain 3 — Governance, Risk, and Responsible Use","type":"posts"},{"content":"","date":"15 September 2026","externalUrl":null,"permalink":"/tags/governance/","section":"Tags","summary":"","title":"Governance","type":"tags"},{"content":"","date":"15 September 2026","externalUrl":null,"permalink":"/tags/responsible-ai/","section":"Tags","summary":"","title":"Responsible-Ai","type":"tags"},{"content":" What this is about # Domain 2 of the Claude Certified Associate – Foundations exam is Workflow Integration and Solution Design. It\u0026rsquo;s worth 16% — second only to Output Evaluation, which Part 3 already covered. Where that domain asked \u0026ldquo;is this one output good?\u0026rdquo;, this one asks a different question entirely: where does Claude actually belong in a workflow made of multiple steps, systems, and people — and where doesn\u0026rsquo;t it? Getting an individual answer right doesn\u0026rsquo;t matter much if you\u0026rsquo;ve wired it into the wrong place in the process.\nDomain weight # Workflow Integration and Solution Design is the second-heaviest domain on the exam, right behind Output Evaluation Key point 1: three interaction patterns, not one # Claude fits into a solution three different ways, and each carries a different cost and a different amount of oversight it needs: augmented calls, where a human runs each step and Claude assists one call at a time; workflows, where Claude runs a fixed, predictable sequence of steps on its own; and agents, where Claude plans its own steps to reach a goal. Autonomy goes up at each stage — and so does the cost of it going wrong unsupervised.\nAutonomy and the cost of getting it wrong rise together — pick the pattern that matches how much oversight the task actually needs Picking between the three comes down to two questions: does the task need more than one step, and does it need Claude to decide the steps itself?\nflowchart TD A[New task] --\u003e B{More thanone step?} B --\u003e|No| C[Augmented callhuman runs it, Claude assists] B --\u003e|Yes| D{Steps are fixedand predictable?} D --\u003e|Yes| E[WorkflowClaude runs the fixed sequence] D --\u003e|No, Claude needs todecide the steps| F[AgentClaude plans and adapts as it goes] style C fill:#86b6ef,stroke:#5598e7,color:#0b0b0b style E fill:#2a78d6,stroke:#1c5cab,color:#fff style F fill:#104281,stroke:#0d366b,color:#fff Each step down this tree trades predictability for reach — an agent can handle a task nobody scripted in advance, but it also needs the most oversight to catch when its own plan goes wrong.\nKey point 2: decompose the requirement before picking a pattern # Before choosing a pattern, split the problem into three ownership questions: what\u0026rsquo;s Claude\u0026rsquo;s job, what\u0026rsquo;s the existing system\u0026rsquo;s job, and what\u0026rsquo;s the human\u0026rsquo;s job. Skipping this step is how a task that should\u0026rsquo;ve been a single augmented call ends up over-engineered as an agent, or how a genuinely multi-step process gets crammed into one long prompt because nobody separated \u0026ldquo;what Claude does\u0026rdquo; from \u0026ldquo;what the database already does.\u0026rdquo;\nKey point 3: reference architecture — retrieval vs. live-state # Once Claude\u0026rsquo;s role is scoped, the next design decision is how it reaches information: retrieval, pulling from indexed or stored content that doesn\u0026rsquo;t need to be current to the second, or live-state integration, calling a live system or API when the answer has to reflect what\u0026rsquo;s true right now. Pricing, inventory, and account balances need live-state. A knowledge base answer about a policy from last quarter usually doesn\u0026rsquo;t.\nKey point 4: picking the entry point # Claude shows up through several doors — Claude.ai, the API, SDKs, Claude Code, MCP servers — and each one is the right layer for a different kind of customization. Claude.ai is the user-facing interface for people working directly with Claude. The API and SDKs are the build-time engineering layer for embedding Claude into your own product. MCP servers are how Claude reaches external tools and data without custom integration code for each one. Picking the wrong entry point means re-solving a problem the platform already solved at a different layer.\nKey point 5: communicating value and limits to stakeholders # The last piece of this domain isn\u0026rsquo;t technical at all: being able to explain to a stakeholder what Claude will actually do, what it won\u0026rsquo;t, and where a human still has to be involved — before the solution ships, not after it disappoints someone. A solution nobody trusts because nobody explained its limits up front fails for a reason that had nothing to do with the model.\nThe whole Domain 2 framework on one page — built to share as a standalone summary Conclusion # Domain 2 comes down to this: pick the interaction pattern that matches how much autonomy the task actually needs (augmented call, workflow, or agent), decompose the requirement so Claude, the existing system, and the human each own a clear piece, choose retrieval or live-state based on whether the answer needs to be current, pick the platform entry point that matches the kind of customization the job needs, and be straight with stakeholders about what the solution will and won\u0026rsquo;t do. That\u0026rsquo;s solution design — the layer above any single good output.\nSources # Claude Platform \u0026amp; Solution Design — Anthropic Partner Academy Claude Certified Associate – Foundations Exam Guide — official PDF Where this fits # Part 4 of Getting Claude Certified. Part 1 covered the 4D Framework, Part 2 covered Chat, Projects, Artifacts, and Research, Part 3 covered Domain 1 — Output Evaluation and Validation. Part 5 takes on Domain 3 — Governance, Risk, and Responsible Use.\n","date":"14 September 2026","externalUrl":null,"permalink":"/posts/claude-cert-04-workflow-integration-and-solution-design/","section":"Posts","summary":"What this is about # Domain 2 of the Claude Certified Associate – Foundations exam is Workflow Integration and Solution Design. It’s worth 16% — second only to Output Evaluation, which Part 3 already covered. Where that domain asked “is this one output good?”, this one asks a different question entirely: where does Claude actually belong in a workflow made of multiple steps, systems, and people — and where doesn’t it? Getting an individual answer right doesn’t matter much if you’ve wired it into the wrong place in the process.\n","title":"Claude Certified Associate – Foundations: Domain 2 — Workflow Integration and Solution Design","type":"posts"},{"content":"","date":"14 September 2026","externalUrl":null,"permalink":"/tags/solution-design/","section":"Tags","summary":"","title":"Solution-Design","type":"tags"},{"content":"","date":"14 September 2026","externalUrl":null,"permalink":"/tags/workflow-integration/","section":"Tags","summary":"","title":"Workflow-Integration","type":"tags"},{"content":" What this is about # Domain 1 of the Claude Certified Associate – Foundations exam is Output Evaluation and Validation. It\u0026rsquo;s worth 21% — more than any other domain on the exam. The whole domain comes down to one idea: good-looking output is not the same thing as validated output. Fluent, confident text doesn\u0026rsquo;t tell you anything about whether it\u0026rsquo;s actually correct. This post breaks down the framework for closing that gap, on purpose, instead of by accident.\nWhy this domain gets more weight than any other # Domain 1 alone outweighs Product \u0026amp; Model Selection and Configuration \u0026amp; Knowledge Management combined A quick snapshot of the exam itself, from Anthropic\u0026rsquo;s official exam guide:\nLength 120 minutes Questions 60 Price $99 USD Passing score 720 (scaled 100–1,000) Key point 1: check output against three references, not one # Every meaningful output gets evaluated against three separate things:\nRequirements — did it answer what was actually asked? Right sections, right audience, right scope, right format. Source material — does it match what it\u0026rsquo;s supposed to be drawing from? Don\u0026rsquo;t assume Claude \u0026ldquo;read it correctly\u0026rdquo; — trace important claims back yourself. Professional standards — would it survive review in the field it\u0026rsquo;s going into? A number with no units, a citation nobody can find, a conclusion nothing supports — these pass a casual read and fail a real one. Checking only one of the three and calling it validated is the mistake behind most of what follows.\nKey point 2: accuracy and completeness are different tests # Accuracy asks: is what\u0026rsquo;s present correct? Completeness asks: is something important missing? An answer can be fully accurate and still unusable because it left out a factor that mattered. If the figures all check out but something feels missing, the fix isn\u0026rsquo;t re-checking the numbers again — it\u0026rsquo;s running a separate completeness check against the original requirements.\nKey point 3: the three-way triage # Every output lands in one of three buckets:\nflowchart TD A[Output produced] --\u003e B{Requirements met?Source checks pass?Professional standard OK?} B --\u003e|Yes, risk acceptable| C[Ready to use] B --\u003e|Specific, correctable gap| D[Needs revision] B --\u003e|Stakes, regulatory exposure,or accountability requires it| E[Needs human override] D --\u003e|Fix and re-check| B E --\u003e|Human decides,regardless of output quality| F[Human review] style C fill:#1baf7a,stroke:#0d8a5c,color:#fff style D fill:#eda100,stroke:#c98500,color:#fff style E fill:#e34948,stroke:#c73b3a,color:#fff The distinction that matters is between the last two boxes. A wrong subtotal needs revision — fix it, move on. A regulatory interpretation headed for an actual filing needs a human expert\u0026rsquo;s sign-off even if it looks completely correct to you, because \u0026ldquo;looks correct to me\u0026rdquo; was never the bar for that category of output.\nKey point 4: spotting a hallucination by its shape # Six recognizable patterns, not one vague warning:\nPlausible-but-unsupported claim — sounds reasonable, no grounding underneath Fabricated specific — an invented statistic, date, name, or citation. Precision without a source is suspicious, not reassuring Confident tone masking uncertainty — confidence is not evidence Internal contradiction — a number or assumption stated early conflicts with one stated later Confirmation bias in framing — a prompt that implies the answer gets that answer Capability hallucination — Claude says \u0026ldquo;I sent the email\u0026rdquo; or \u0026ldquo;I saved the file\u0026rdquo; when no tool that could do that was actually available. Always verify the action happened Key point 5: when a human has to be in the loop # Four questions decide it, regardless of how good the output looks:\nStakes — what does it cost if this is wrong? Reversibility — can it be undone? Audience — internal draft, or external / executive / regulatory? Regulatory exposure — does law, policy, or contract govern this? Final client deliverables, audit-critical calculations, and public or legal communications sit in \u0026ldquo;review required\u0026rdquo; territory by default. A polished draft does not reduce the need for review — if anything, polish is what gets something waved through without one.\nA few more checks worth knowing # Code Execution computes, it doesn\u0026rsquo;t validate logic. Use it for totals, projections, and anything that needs to be calculated rather than estimated — but a computed result still isn\u0026rsquo;t automatically correct methodology. Input curation is part of validation, not prep. Noisy, contradictory source material produces noisy output. A bigger model doesn\u0026rsquo;t fix that — de-duplicating and labeling your sources does. Same facts, different delivery. An executive wants the decision and the impact first. A working team wants the method and the owner. An external audience needs controlled disclosure. Sending the same raw draft to all three fails at least two of them. The whole Domain 1 framework on one page — built to share as a standalone summary Conclusion # Domain 1 is the highest-weighted section of the Claude certification exam because evaluation is the actual skill — not prompting, not workflow design. The short version: check output against requirements, source, and professional standard; treat accuracy and completeness as separate tests; triage into ready / needs revision / needs a human; know the six hallucination patterns; and know the four questions that force human review no matter how good the output looks. That\u0026rsquo;s the whole domain, and it\u0026rsquo;s the part of working with Claude that pays off the most.\nSources # Claude Certified Associate – Foundations Exam Guide — official PDF Claude Certified Associate – Foundations Prep Course — \u0026ldquo;Evaluating \u0026amp; Validating Claude\u0026rsquo;s Output\u0026rdquo; module Where this fits # Part 3 of Getting Claude Certified. Part 1 covered the 4D Framework, Part 2 covered Chat, Projects, Artifacts, and Research. Part 4 takes on Domain 2 — Workflow Integration and Solution Design.\n","date":"13 September 2026","externalUrl":null,"permalink":"/posts/claude-cert-03-output-evaluation-and-validation/","section":"Posts","summary":"What this is about # Domain 1 of the Claude Certified Associate – Foundations exam is Output Evaluation and Validation. It’s worth 21% — more than any other domain on the exam. The whole domain comes down to one idea: good-looking output is not the same thing as validated output. Fluent, confident text doesn’t tell you anything about whether it’s actually correct. This post breaks down the framework for closing that gap, on purpose, instead of by accident.\n","title":"Claude Certified Associate – Foundations: Domain 1 — Output Evaluation and Validation","type":"posts"},{"content":"","date":"13 September 2026","externalUrl":null,"permalink":"/tags/discernment/","section":"Tags","summary":"","title":"Discernment","type":"tags"},{"content":"","date":"13 September 2026","externalUrl":null,"permalink":"/tags/evaluation/","section":"Tags","summary":"","title":"Evaluation","type":"tags"},{"content":"","date":"12 September 2026","externalUrl":null,"permalink":"/tags/artifacts/","section":"Tags","summary":"","title":"Artifacts","type":"tags"},{"content":"","date":"12 September 2026","externalUrl":null,"permalink":"/tags/projects/","section":"Tags","summary":"","title":"Projects","type":"tags"},{"content":"","date":"12 September 2026","externalUrl":null,"permalink":"/tags/research/","section":"Tags","summary":"","title":"Research","type":"tags"},{"content":" The chat window is where most people stop # Open Claude, type a question, get an answer, close the tab. Next week, same question-shaped task, same blank chat window, same explaining from zero: who you are, what you\u0026rsquo;re working on, what \u0026ldquo;good\u0026rdquo; looks like for this kind of output. If that\u0026rsquo;s the whole relationship, you\u0026rsquo;re using one of the most capable tools available today exactly like you\u0026rsquo;d use a search box — or, more to the point, exactly like people used ChatGPT in 2020, when a fresh context window every time was just how these things worked.\nIt isn\u0026rsquo;t anymore, and treating Claude that way costs more than it looks like it does.\nWhat re-explaining yourself every session actually costs you # None of this shows up as a single dramatic failure. It shows up as friction you\u0026rsquo;ve stopped noticing.\nYou re-upload the same brand guidelines, the same architecture notes, the same \u0026ldquo;here\u0026rsquo;s how our team writes docs\u0026rdquo; preamble, every single time, because the last chat didn\u0026rsquo;t carry any of it forward. You get a genuinely useful diagram or draft back, and it lives exactly one scroll-length deep in a chat transcript — findable if you remember which conversation, gone in practice if you don\u0026rsquo;t. You ask a question that actually needs someone to dig across a handful of sources, compare them, and synthesize a real answer, and you get back a confident single-pass response that reads like it did that work but didn\u0026rsquo;t. It looked thorough. It wasn\u0026rsquo;t. And the next person on your team who asks Claude the same thing you already worked through starts over too, because none of what you figured out is anywhere Claude — or they — can find it.\nNone of that is a Claude limitation. It\u0026rsquo;s a Chat limitation, and Chat is one of several ways to work with Claude, not the only one.\nThe map for the rest of this post — four surfaces, four different jobs Chat: still the right tool for a lot of things # To be clear, Chat isn\u0026rsquo;t the problem — it\u0026rsquo;s the default, and defaults are supposed to handle most cases well. A one-off question, a quick draft, a \u0026ldquo;help me think through this\u0026rdquo; conversation that won\u0026rsquo;t need to exist next week: Chat is exactly right for that. The mistake isn\u0026rsquo;t using Chat. It\u0026rsquo;s using only Chat for work that\u0026rsquo;s actually ongoing, reusable, or genuinely complex enough to need real investigation.\nChat\u0026rsquo;s own limitation, spelled out plainly: context doesn\u0026rsquo;t persist between separate chats Here\u0026rsquo;s what I reach for instead, and when.\nProjects: stop re-uploading the same context # A project is a self-contained workspace with its own knowledge base, its own instructions, and its own chat history — separate from your regular Chat. You upload the reference material once (my site\u0026rsquo;s writing conventions, past post drafts, my resume and cert notes), write instructions once (\u0026ldquo;first-person practitioner voice, cite sources inline, no comparisons between the IBM Sterling and Claude categories\u0026rdquo;), and every chat inside that project just has it. No re-explaining.\nI keep a project for this blog specifically. When I start drafting a new post, Claude already knows the frontmatter format, the tone I want, and the one hard rule about not cross-linking my middleware content with my Claude content — because I said it once, in the project instructions, instead of every single time I open a new chat. That\u0026rsquo;s the whole value: the context compounds instead of resetting.\nThe practical trigger for \u0026ldquo;this should be a project, not another chat\u0026rdquo; is simple — if you can picture asking a variant of the same question again next month, it belongs in a project.\nWhat actually lives inside a project — knowledge, instructions, and chats, all scoped to one workspace Artifacts: the output should outlive the conversation # An artifact is content substantial enough to get its own dedicated window next to the conversation — a document, a diagram, a working HTML page, a piece of code — instead of a block of text buried in chat that you\u0026rsquo;ll never scroll back to find. Claude creates one automatically once something crosses the line into \u0026ldquo;significant and self-contained\u0026rdquo;: generally over 15 lines, and something you\u0026rsquo;re actually going to edit, reuse, or reference later rather than just read once.\nThe distinction that matters here isn\u0026rsquo;t length, it\u0026rsquo;s disposability. A quick explanation belongs in chat. A diagram of your onboarding process, a first draft of a report, a working prototype — those are things with a life after this conversation ends, and burying them in scrollback is how you lose them. I used exactly this for the 4D framework iceberg graphic in the first post of this series: it needed to exist as its own thing I could pull out, refine, and reuse on LinkedIn — not as a description in the middle of a chat reply.\nIf you ask for something substantial and Claude just answers in the chat instead, you can say so directly: \u0026ldquo;create that as an artifact.\u0026rdquo; It\u0026rsquo;s not always automatic, and it\u0026rsquo;s worth the ask.\nThe artifact panel next to the chat — the output gets its own space instead of living in scrollback Research: when the answer actually requires digging # Research is where the \u0026ldquo;confident single-pass answer that only looks thorough\u0026rdquo; problem actually gets solved. Turn it on and Claude stops doing one lookup — it plans an approach, runs multiple searches that build on each other, decides what to chase next based on what it already found, and compiles the result into a report with citations you can actually check. It takes minutes instead of seconds, because it\u0026rsquo;s doing minutes of work instead of seconds of work.\nThat trade-off is the whole point, and it means Research isn\u0026rsquo;t the right call for everything. A quick fact — today\u0026rsquo;s date, a single number, one specific claim — doesn\u0026rsquo;t need it; a single web search answers that faster and Research would just be slower for no benefit. Where it earns its time is comparative or multi-angle work: evaluating a handful of options against the same criteria, pulling together a technical picture from documentation scattered across several sources, or synthesizing what\u0026rsquo;s already been discussed across your own connected tools before adding outside research on top. The test I use: if the honest answer to \u0026ldquo;how many sources would I need to check to actually trust this?\u0026rdquo; is more than two or three, that\u0026rsquo;s a Research question, not a Chat question.\nThe step most people skip mentally: Research plans before it searches, instead of running one lookup and calling it done Match the tool to the job # Chat Projects Artifacts Research Persists across sessions? No Yes — knowledge base + instructions Yes — lives in its own window No — output can become an artifact Best for One-off questions, quick drafts Ongoing work with reusable context Substantial, reusable outputs Multi-source investigation Skip it when The task is genuinely ongoing It\u0026rsquo;s a true one-off The content is short or disposable One or two sources would settle it None of these four replace each other. They stack — a project holding your context, producing an artifact worth keeping, occasionally kicking off a Research pass when a question in that project needs real digging. The 4D Framework from Part 1 of this series is exactly this in miniature: Delegation and Description are you deciding which of these tools the task actually calls for and saying so clearly; Discernment and Diligence are still yours no matter which one you used.\nA diligence statement, since the series keeps making me write one # I collaborated with Claude to research and draft this post, working from Anthropic\u0026rsquo;s own support documentation on Projects, Artifacts, and Research, and from my own experience using each of them for this site. The framing, the examples, and the \u0026ldquo;match the tool to the job\u0026rdquo; argument are mine; I checked the feature descriptions against the linked documentation before publishing and stand behind this as an accurate account of how these tools work and how I actually use them.\nSources \u0026amp; further reading # Claude Help Center — get started with Claude What are projects? What are artifacts and how do I use them? Use research on Claude As with the rest of this site: the feature definitions are Anthropic\u0026rsquo;s, the framing and the \u0026ldquo;you\u0026rsquo;re leaving value on the table\u0026rdquo; argument are mine.\nWhere this fits # This is Part 2 of Getting Claude Certified. Part 1 covered the 4D Framework — the decision-making layer underneath everything. This post is the surface layer: which Claude surface to actually reach for once you\u0026rsquo;ve made that decision.\nWhat\u0026rsquo;s next # Part 3, Domain 1 — Output Evaluation and Validation, takes Discernment further: it\u0026rsquo;s the highest-weighted domain on the actual certification exam, and it deserves the same rigor I\u0026rsquo;d apply to verifying any other system before trusting it in production.\n","date":"12 September 2026","externalUrl":null,"permalink":"/posts/claude-cert-02-using-claude-chat-projects-artifacts-and-research/","section":"Posts","summary":"The chat window is where most people stop # Open Claude, type a question, get an answer, close the tab. Next week, same question-shaped task, same blank chat window, same explaining from zero: who you are, what you’re working on, what “good” looks like for this kind of output. If that’s the whole relationship, you’re using one of the most capable tools available today exactly like you’d use a search box — or, more to the point, exactly like people used ChatGPT in 2020, when a fresh context window every time was just how these things worked.\n","title":"You're Using Claude Like It's ChatGPT 2020","type":"posts"},{"content":"","date":"11 September 2026","externalUrl":null,"permalink":"/tags/ai-ops/","section":"Tags","summary":"","title":"Ai-Ops","type":"tags"},{"content":" What this is about # Anthropic\u0026rsquo;s AI Fluency course breaks working with AI into four competencies instead of a pile of prompt tricks: Delegation, Description, Discernment, Diligence. The 4Ds. I went in expecting a prompting course and came out with a decision framework instead — one that\u0026rsquo;s less about writing better prompts and more about deciding what to hand off, how to communicate it, how to judge what comes back, and who\u0026rsquo;s accountable for it. Here\u0026rsquo;s each one, condensed to what actually matters.\nKey point 1: Delegation — the decision before the prompt # Delegation is deciding what\u0026rsquo;s yours to do, what\u0026rsquo;s AI\u0026rsquo;s to do, and what\u0026rsquo;s worth doing together — before any of that becomes a prompt. It comes down to knowing the actual goal, knowing what the specific AI system in front of you is good and bad at, and only then making the handoff call. The part most people underrate: what\u0026rsquo;s safe to delegate changes by context. A quick chat answer and an unattended agent running tool calls don\u0026rsquo;t get the same trust by default, so the question gets re-asked every time, not decided once and reused.\nKey point 2: Description — AI can\u0026rsquo;t read your mind # Description is telling AI what you want clearly enough that it can actually deliver — not just the end result, but the method you want followed and how it should behave while working with you. Most disappointing AI output traces back to specifying only the end result and skipping the other two. Ask for a summary without saying how blunt the feedback should be, and don\u0026rsquo;t be surprised when it agrees with everything you wrote.\nKey point 3: Discernment — the flip side of description # Discernment is judging what comes back: the output itself, the reasoning behind it, and whether the interaction was actually responsive to your direction or just agreeable. The catch — your discernment is only as strong as your own expertise in the topic. A wrong claim in your own field jumps out in a sentence. The same wrong claim outside your field reads as confidently correct, because to you, it\u0026rsquo;s indistinguishable from a right one.\nKey point 4: Diligence — the part that isn\u0026rsquo;t about quality at all # Diligence isn\u0026rsquo;t about getting better output — it\u0026rsquo;s about owning what you did to get it: being thoughtful about which system you use, being honest with people about AI\u0026rsquo;s role when they see the result, and actually standing behind it once it ships under your name. The piece most often skipped is standing behind it — nobody checks until something\u0026rsquo;s wrong in front of someone who matters, and \u0026ldquo;the AI wrote that part\u0026rdquo; doesn\u0026rsquo;t hold up in that moment.\nHow the four fit together # flowchart LR A[Delegationdecide what to hand off] --\u003e B[Descriptionsay how, not just what] B --\u003e C{Discernmentjudge the output} C --\u003e|Gaps found| B C --\u003e|Holds up| D[Diligenceown the outcome] D --\u003e|Next task| A style A fill:#2a78d6,stroke:#1a5fb4,color:#fff style B fill:#2a78d6,stroke:#1a5fb4,color:#fff style C fill:#eda100,stroke:#c98500,color:#fff style D fill:#eda100,stroke:#c98500,color:#fff Delegation and Description are the two competencies visible in any AI demo — they\u0026rsquo;re what produce the output. Discernment and Diligence are the two nobody sees on stage, and they\u0026rsquo;re the two that actually determine whether that output was safe to use.\nDelegation and description are the visible half of the work. Discernment and diligence are the half nobody sees in the demo. Conclusion # The 4D framework in one line: decide what to delegate, describe it fully (not just the end result), judge what comes back with the same rigor you\u0026rsquo;d apply to a colleague\u0026rsquo;s work, and own the outcome once it ships. Most disappointing AI experiences trace back to skipping one of these four — usually Description or Diligence — not to the model itself. That\u0026rsquo;s the whole framework, and everything else about using Claude well builds on it.\nSources # AI Fluency: Framework \u0026amp; Foundations — Claude Academy AI Fluency Framework — documentation, papers, and open resources Where this fits # Part 1 of Getting Claude Certified. Part 2 covers Chat, Projects, Artifacts, and Research, Part 3 covers Domain 1 — Output Evaluation and Validation, which is Discernment\u0026rsquo;s deep dive.\n","date":"11 September 2026","externalUrl":null,"permalink":"/posts/claude-cert-01-fluency-4d-framework/","section":"Posts","summary":"What this is about # Anthropic’s AI Fluency course breaks working with AI into four competencies instead of a pile of prompt tricks: Delegation, Description, Discernment, Diligence. The 4Ds. I went in expecting a prompting course and came out with a decision framework instead — one that’s less about writing better prompts and more about deciding what to hand off, how to communicate it, how to judge what comes back, and who’s accountable for it. Here’s each one, condensed to what actually matters.\n","title":"The 4D Framework: Delegation, Description, Discernment, Diligence","type":"posts"},{"content":"","date":"10 September 2026","externalUrl":null,"permalink":"/categories/ibm-sterling/","section":"Categories","summary":"","title":"IBM Sterling","type":"categories"},{"content":"","date":"10 September 2026","externalUrl":null,"permalink":"/tags/ibm-sterling/","section":"Tags","summary":"","title":"Ibm-Sterling","type":"tags"},{"content":"","date":"10 September 2026","externalUrl":null,"permalink":"/tags/mft/","section":"Tags","summary":"","title":"Mft","type":"tags"},{"content":"","date":"10 September 2026","externalUrl":null,"permalink":"/tags/security/","section":"Tags","summary":"","title":"Security","type":"tags"},{"content":"","date":"10 September 2026","externalUrl":null,"permalink":"/tags/sftp/","section":"Tags","summary":"","title":"Sftp","type":"tags"},{"content":"","date":"10 September 2026","externalUrl":null,"permalink":"/tags/ssh/","section":"Tags","summary":"","title":"Ssh","type":"tags"},{"content":" The warning nobody should click past # Every SSH and SFTP client has the same scary moment: you connect to a server you\u0026rsquo;ve connected to a hundred times before, and instead of a normal prompt you get something like this from OpenSSH:\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! I called this out in passing in the SFTP/FTP/FTPS post as one of the operational things that trips people up, and it deserves its own post, because the honest, complete answer to \u0026ldquo;what do I do here\u0026rdquo; is more than one sentence — and \u0026ldquo;just disable strict checking\u0026rdquo; is the wrong answer often enough that it\u0026rsquo;s worth explaining exactly why.\nWhat known_hosts actually is # During the SSH handshake — the same one from the SFTP post\u0026rsquo;s sequence diagram — the server presents a host key to prove its identity, the same way a private/public key pair proves a client\u0026rsquo;s identity during authentication. The client\u0026rsquo;s job is to verify that host key actually belongs to the server it thinks it\u0026rsquo;s talking to, before trusting anything else about the connection, including where it sends your password or which files it hands over.\nSSH does this with a trust-on-first-use (TOFU) model, not a certificate authority chain like TLS normally uses. The first time you connect to a given host, OpenSSH shows you the server\u0026rsquo;s key fingerprint and asks you to confirm it, then stores an entry — hostname (or IP), key algorithm, and the key itself — in a local known_hosts file (~/.ssh/known_hosts per user, or /etc/ssh/ssh_known_hosts system-wide). Every connection after that compares the presented key against the stored entry automatically, with no prompt, unless something doesn\u0026rsquo;t match.\nThis is genuinely simple and it\u0026rsquo;s exactly why the warning above is scary: a mismatch means one of exactly two things happened, and the client has no way to tell which one on its own — either the server legitimately got a new host key, or something is intercepting your connection and presenting a different key entirely. ssh(1) and sshd(8) both cover this model in detail; ssh_config(5) is where the behavior is actually configured.\nStrictHostKeyChecking modes # StrictHostKeyChecking in ssh_config controls what happens on a first connection and on a mismatch:\nyes — refuses to connect to an unknown host at all, and refuses on any mismatch. No prompts, fails closed. The right setting for anything automated and unattended. accept-new — the current OpenSSH default for interactive use. Silently accepts and stores a key on first connection (still TOFU), but still fails closed on a mismatch against an existing entry. ask — prompts on first connection (the classic \u0026ldquo;are you sure you want to continue connecting?\u0026rdquo; dialog) and still fails closed on mismatch. no — accepts and auto-stores any key, first connection or changed, no prompts, ever. This disables host verification entirely. It shows up in \u0026ldquo;fix\u0026rdquo; instructions on forums constantly, and it defeats the entire purpose of the mechanism — you\u0026rsquo;d accept a man-in-the-middle\u0026rsquo;s key just as readily as the real one. For anything partner-facing or automated — which describes basically every B2Bi SFTP connection — StrictHostKeyChecking yes with a deliberately managed known_hosts file is the right posture. Unattended jobs should never be the ones deciding whether to trust a changed key.\nHere\u0026rsquo;s the whole verification decision as one picture — this is what runs on every SSH or SFTP connection, not just the scary ones:\nflowchart TD A[\"Client connects\"] --\u003e B{\"Host already in\\nknown_hosts?\"} B --\u003e|\"No — first time\"| C{\"StrictHostKeyChecking\\nmode\"} C --\u003e|\"yes\"| D[\"Refuse connection\"] C --\u003e|\"accept-new\"| E[\"Store key silently,\\nproceed\"] C --\u003e|\"ask\"| F[\"Prompt user,\\nthen store if confirmed\"] C --\u003e|\"no\"| G[\"Store key silently,\\nproceed — no verification\"] B --\u003e|\"Yes\"| H{\"Presented key matches\\nstored entry?\"} H --\u003e|\"Match\"| I[\"Proceed normally —\\nno prompt, no warning\"] H --\u003e|\"Mismatch\"| J[\"⚠ REMOTE HOST IDENTIFICATION\\nHAS CHANGED — fail closed\"] style D fill:#4a1a1a,stroke:#c0392b style J fill:#4a1a1a,stroke:#c0392b style G fill:#4a1a1a,stroke:#c0392b style I fill:#1a3a1a,stroke:#27ae60 That bottom-right red box is the warning from the top of this post. Everything above it is what got you there — and the no path (bottom left, also red) is the forum \u0026ldquo;fix\u0026rdquo; that skips verification entirely rather than actually resolving anything.\nFingerprints and host key algorithms # A host key fingerprint is a short hash of the actual key, used because comparing a full key visually is impractical. Modern OpenSSH shows fingerprints as base64-encoded SHA256 by default:\nSHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Older tooling and documentation sometimes still shows the legacy hex-colon MD5 format — both represent the same underlying key, just hashed differently for display; ssh-keygen -l can print either (-E md5 forces the old format).\nServers can hold multiple host keys of different types simultaneously — commonly RSA and ed25519 side by side, sometimes ECDSA too — and the client and server negotiate which one to use the same way they negotiate ciphers and MACs, via HostKeyAlgorithms preference order. This matters practically: if a server rotates only its RSA host key but a client is configured to prefer ed25519, that client may not even notice the RSA key changed, because it never uses that key type. Worth knowing which key type your automated jobs are actually pinned to before assuming a rotation was \u0026ldquo;silent.\u0026rdquo;\nssh-keyscan fetches a host\u0026rsquo;s currently-presented key(s) without going through the interactive TOFU prompt — useful for pre-populating a known_hosts file from a trusted, automated process rather than an interactive \u0026ldquo;yes, I\u0026rsquo;m sure\u0026rdquo; click, and it\u0026rsquo;s how I generate the known_hosts entries I ship as part of a partner onboarding checklist rather than trusting whatever an engineer clicked through once.\nHashed known_hosts # By default, modern OpenSSH stores known_hosts entries with the hostname itself hashed (HashKnownHosts), specifically so that a leaked known_hosts file doesn\u0026rsquo;t hand an attacker a ready-made list of every host you connect to. Worth knowing this is on by default and why, especially on any shared or multi-tenant box — like a Sterling Perimeter Server that\u0026rsquo;s terminating connections to dozens of trading partners — where that file becomes a meaningful piece of information on its own.\nThe rotation problem: legitimate change vs. something worse # Here\u0026rsquo;s the actual decision you\u0026rsquo;re facing when that warning appears, stripped of the scary formatting: a key changed — was it supposed to?\nThe only reliable way to answer that is to verify the new fingerprint through a channel that isn\u0026rsquo;t the SSH connection itself. In practice, for partner connections, that means:\nDon\u0026rsquo;t accept anything yet. The stale entry failing closed is doing its job. Contact the partner through an already-trusted channel — a phone call to a known number, a message through an established support portal, a signed email thread you already have a relationship with — and ask them to confirm the new fingerprint directly. Not \u0026ldquo;did you change your SFTP server,\u0026rdquo; specifically the new key\u0026rsquo;s SHA256 fingerprint, read back to you or sent through that separate channel. Compare it to what the connection is actually presenting. ssh-keyscan or a manual connection attempt will show you the fingerprint being offered; it needs to match what the partner confirmed, not just \u0026ldquo;look plausible.\u0026rdquo; Only then remove the stale entry and reconnect. ssh-keygen -R hostname removes the old entry from known_hosts cleanly (it also handles the hashed-hostname case correctly, which manually editing the file doesn\u0026rsquo;t); reconnecting under accept-new or interactively then stores the verified new key. Skipping straight to ssh-keygen -R the moment a connection fails is the single most common mistake here — it \u0026ldquo;fixes\u0026rdquo; the symptom identically whether the cause was a legitimate server rebuild or an active interception, which is exactly the distinction this whole mechanism exists to preserve.\nAs a decision tree, the four steps above look like this:\nflowchart TD A[\"⚠ Host key mismatch warning\"] --\u003e B[\"Do NOT accept —\\nleave the connection failed\"] B --\u003e C[\"Contact the partner via an\\nalready-trusted out-of-band channel\"] C --\u003e D[\"Partner reads back the new\\nSHA256 fingerprint directly\"] D --\u003e E{\"Matches what the\\nconnection is presenting?\"} E --\u003e|\"Yes\"| F[\"ssh-keygen -R hostname\\n— remove stale entry\"] F --\u003e G[\"Reconnect — new key\\nstored and trusted\"] E --\u003e|\"No\"| H[\"STOP — treat as a\\npossible interception\"] H --\u003e I[\"Investigate the network path.\\nDo not connect.\"] style A fill:#4a3a1a,stroke:#d4a017 style H fill:#4a1a1a,stroke:#c0392b style I fill:#4a1a1a,stroke:#c0392b style G fill:#1a3a1a,stroke:#27ae60 The entire point of the flow is that the verification step (D → E) happens on a channel the attacker in a MITM scenario doesn\u0026rsquo;t control. Skip that step and the flowchart collapses into \u0026ldquo;accept whatever the connection shows me\u0026rdquo; — which is just StrictHostKeyChecking no with extra steps.\nScaling this beyond one-off verification # Phone-call verification doesn\u0026rsquo;t scale past a handful of partners. Two approaches that do:\nA documented, automated known_hosts distribution process — populate and update known_hosts entries from a controlled pipeline (infrastructure-as-code, a config management run, a signed manifest) rather than individual interactive prompts, so \u0026ldquo;accepting a new key\u0026rdquo; is an auditable, deliberate change rather than an ad hoc click. SSH certificates (a CA signs host keys, and clients trust the CA rather than pinning individual host keys) solve this properly at scale, though they require a CA infrastructure and coordination most partner relationships won\u0026rsquo;t have in place. ssh-keygen\u0026rsquo;s certificate authority options and sshd_config\u0026rsquo;s TrustedUserCAKeys/host cert options cover the mechanics; worth knowing the option exists even if most partner SFTP setups you\u0026rsquo;ll touch are plain TOFU key pinning. Can I keep the same host key across a Linux upgrade? # Yes — and for anything partner-facing, you generally should. A host key is nothing more than a file pair on disk (typically under /etc/ssh/, one private key like ssh_host_ecdsa_key and its matching .pub), and sshd presents whatever key material those files contain. Nothing about the key is tied to the OS version, the package version, or the hardware — as long as the exact same key files exist at the paths sshd_config\u0026rsquo;s HostKey directives point to when sshd starts, it\u0026rsquo;ll present the identical key, with the identical fingerprint, and no client anywhere will see anything change.\nThat means the safe pattern for an OS upgrade (or a server migration, a container rebuild, a disaster-recovery restore, anything where the box itself changes but its identity shouldn\u0026rsquo;t) is:\nBack up /etc/ssh/ssh_host_*_key and ssh_host_*_key.pub (all key types you\u0026rsquo;re currently serving) before the upgrade, preserving ownership and permissions — private keys need to stay 600, owned by root. Run the upgrade. Most package managers will generate fresh host keys automatically if none exist, which is exactly the case you\u0026rsquo;re avoiding. Restore the original key files to the same paths, with the same permissions, before sshd starts serving connections again (or restart it after restoring). Verify the fingerprint with ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub (or whichever type) and confirm it matches what it was before — cheap insurance before you call the upgrade done. Do this correctly and every partner\u0026rsquo;s known_hosts entry, and every registered host key inside Sterling\u0026rsquo;s trading partner configuration, stays valid with zero coordination required. Skip it — let the upgrade regenerate fresh keys — and you\u0026rsquo;ve manufactured exactly the \u0026ldquo;REMOTE HOST IDENTIFICATION HAS CHANGED\u0026rdquo; scenario from the top of this post, for every single partner connecting to that box, on a self-inflicted schedule. If you do end up rotating (deliberately, or because a fresh key was unavoidable), that\u0026rsquo;s the moment to loop back to the verification steps above and treat it like any other planned rotation: fingerprint communicated in advance, through a channel you already trust.\nWhat this looks like in B2Bi # Sterling\u0026rsquo;s own version of a known_hosts file is the SSH Known Host Key screen under trading partner / adapter configuration — this is where B2Bi stores the host keys it has collected from remote SFTP servers before trusting them, whether that\u0026rsquo;s a partner\u0026rsquo;s server (for an outbound SFTP Client Adapter connection) or another node in your own cluster.\nCollecting a new key walks through the same fingerprint-review step ssh does on first connection, just with a UI in front of it — here it\u0026rsquo;s pulling the key from 192.168.100.251, showing the algorithm, bit length, and SHA256 fingerprint before anything is trusted:\nReviewing a freshly-collected host key before trusting it — this is Sterling\u0026rsquo;s UI over the exact TOFU verification step described above Notice the Save To Disk option at the bottom, with a choice between OpenSSH Format and SECSH Format — the exact same two key file formats covered in the SFTP/FTP/FTPS post. This is precisely why that distinction matters in practice: exporting a host key from Sterling to hand to a partner (or importing one they send you) means picking the format the receiving system actually understands, not just downloading whatever the default is.\nOnce a key is reviewed and checked in, it shows up as a managed entry — key ID, name, type, length, status, and fingerprint, all visible at a glance:\nA checked-in host key entry — the Sterling equivalent of a known_hosts line, with the fingerprint front and center That Key Type: EC / Key Length: 256 is Sterling\u0026rsquo;s label for an ECDSA key on the P-256 curve — the same ecdsa-sha2-nistp256 algorithm shown in the collection screen above, just surfaced with friendlier field names.\nWhen a partner\u0026rsquo;s host key changes and the old one is what\u0026rsquo;s registered here, the outbound connection simply starts failing with a host key verification error in the Business Process logs — the same fail-closed behavior as an ssh client hitting a known_hosts mismatch, just logged differently. There\u0026rsquo;s no ambiguity in the failure mode, but it does mean a partner rebuilding their server over a weekend becomes a Monday-morning stuck Business Process if nobody was told in advance.\nThe practical process I run: partner notifies us (or we notice the failure) → verify the new fingerprint through an out-of-band channel per the steps above → collect and review the new key on this screen, confirming the fingerprint matches what was verified → check it in, replacing the stale entry → re-test with a single manual transfer before letting the automated schedule pick back up. Worth having this written down somewhere your team can find at 2am, because \u0026ldquo;which screen do I even update this on\u0026rdquo; is not a question you want to be researching during an incident.\nSources \u0026amp; further reading # ssh(1) sshd(8) ssh_config(5) ssh-keygen(1) ssh-keyscan(1) IBM Documentation: Services \u0026amp; Adapters As with the rest of what I write about this stuff: the man page content is the authoritative source linked above, the framing, the rotation process, and the B2Bi-specific notes are mine.\nThis post is a spin-off from SFTP, FTP, FTPS: Protocol Behind the Adapters — worth reading first if you want the full picture of where host key verification fits into the SSH handshake.\n","date":"10 September 2026","externalUrl":null,"permalink":"/posts/sterling-b2bi-08-ssh-known-hosts-host-key-verification/","section":"Posts","summary":"The warning nobody should click past # Every SSH and SFTP client has the same scary moment: you connect to a server you’ve connected to a hundred times before, and instead of a normal prompt you get something like this from OpenSSH:\n","title":"SSH known_hosts: How Host Key Verification Actually Works (and What to Do When It Breaks)","type":"posts"},{"content":"","date":"9 September 2026","externalUrl":null,"permalink":"/tags/ftp/","section":"Tags","summary":"","title":"Ftp","type":"tags"},{"content":"","date":"9 September 2026","externalUrl":null,"permalink":"/tags/ftps/","section":"Tags","summary":"","title":"Ftps","type":"tags"},{"content":"","date":"9 September 2026","externalUrl":null,"permalink":"/tags/middleware/","section":"Tags","summary":"","title":"Middleware","type":"tags"},{"content":"","date":"9 September 2026","externalUrl":null,"permalink":"/tags/networking/","section":"Tags","summary":"","title":"Networking","type":"tags"},{"content":" Three protocols, one job, very different guts # FTP, FTPS, and SFTP all claim to do the same thing — move a file from one place to another — and partners use the names almost interchangeably, which is exactly the problem. They are three genuinely different protocols with different port models, different security properties, and different failure modes, and the SFTP Server Adapter and SFTP Client Adapter you configure in Sterling only make sense once you know which one you\u0026rsquo;re actually running. This post goes through each one on its own terms, then spends the back half on SFTP specifically, since that\u0026rsquo;s what carries the overwhelming majority of partner traffic in B2Bi.\nWhat is FTP # File Transfer Protocol, defined all the way back in RFC 959 (1985), is the oldest of the three and the one everything else is reacting to. Its defining, and defeating, characteristic is that it uses two separate TCP connections: a control connection that stays open for the session and carries commands and responses, and a completely separate data connection that gets opened fresh for every file transfer or directory listing.\nsequenceDiagram participant Client participant Server Client-\u003e\u003eServer: TCP connect, port 21 (control) Server-\u003e\u003eClient: Welcome banner Client-\u003e\u003eServer: USER / PASS (plaintext) Server-\u003e\u003eClient: Login OK Note over Client,Server: Control connection stays open rect rgb(40,40,40) Note over Client,Server: Active mode Client-\u003e\u003eServer: PORT (client's IP:port to connect back to) Server-\u003e\u003eClient: Connects from port 20 to client's port end rect rgb(40,40,40) Note over Client,Server: Passive mode Client-\u003e\u003eServer: PASV Server-\u003e\u003eClient: Here's a random high port to connect to Client-\u003e\u003eServer: Connects to that port end Note over Client,Server: File data flows over this SECOND,separate connection — unencrypted Ports: 21 for control, plus either port 20 (active mode, server connects back to the client) or a random high port negotiated via PASV (passive mode, client connects out to the server). Active mode expects the server to open an inbound connection to the client — which almost never survives a NAT or a firewall today, so passive mode became the practical default. Security: none, by default. Username, password, commands, and the file contents themselves all cross the wire in plaintext. Anyone positioned on the network path can read credentials and data with a packet capture and zero effort. Why it\u0026rsquo;s still around: legacy systems, internal-only transfers on networks already considered trusted, and some genuinely ancient partner integrations that predate anyone currently working on them. Why not to use it for partner exchange: plaintext credentials and plaintext file contents over the open internet is not a defensible position in 2026, full stop. If a partner asks for plain FTP today, that\u0026rsquo;s a conversation, not a configuration task. What is FTPS # FTP over TLS/SSL (also written FTPES for the explicit variant) is FTP\u0026rsquo;s attempt to fix the plaintext problem without redesigning the protocol — it wraps the same two-connection FTP model in TLS. This gets you encryption, but it inherits FTP\u0026rsquo;s fundamental architecture problem: two connections still means two things to secure and two things that can fail independently.\nsequenceDiagram participant Client participant Server rect rgb(40,40,40) Note over Client,Server: Explicit FTPS (FTPES) — port 21 Client-\u003e\u003eServer: TCP connect, port 21 Client-\u003e\u003eServer: AUTH TLS Server-\u003e\u003eClient: TLS handshake begins Note over Client,Server: Control connection now encrypted Client-\u003e\u003eServer: USER / PASS (now encrypted) Client-\u003e\u003eServer: PBSZ / PROT P (request encrypted data channel) Client-\u003e\u003eServer: PASV → data connection, also TLS-wrapped end rect rgb(40,40,40) Note over Client,Server: Implicit FTPS — port 990 Client-\u003e\u003eServer: TCP connect, port 990 Note over Client,Server: TLS handshake happens immediately,before any FTP command is sent end Ports: explicit FTPS negotiates TLS on the standard port 21 after connecting (AUTH TLS); implicit FTPS expects TLS immediately on a dedicated port, conventionally 990. Both still need a second data connection, which — because it\u0026rsquo;s now TLS-wrapped too — makes passive-mode port ranges through a firewall even more of a headache than plain FTP, since the firewall has to allow a TLS session it can\u0026rsquo;t inspect. Security: genuinely better than FTP — credentials and data are encrypted in transit, assuming TLS is configured correctly (cert validation, no ancient TLS versions left enabled). Still authenticates with a username and password by default, so you\u0026rsquo;re trusting transport encryption alone unless certificate-based client auth is layered on top. When to use it: a partner\u0026rsquo;s infrastructure standardized on FTPS specifically (common in some industries where it\u0026rsquo;s a compliance default) and won\u0026rsquo;t move to SFTP. It\u0026rsquo;s a legitimate, secure-enough choice when configured properly. Why I still default to SFTP over it: the two-connection model doesn\u0026rsquo;t go away just because it\u0026rsquo;s encrypted — you\u0026rsquo;re still fighting passive-mode port ranges and NAT/firewall interaction, just now with TLS in the mix too. SFTP sidesteps the entire category of problem. What is SFTP / SSH / SCP # This is the one that actually matters most for B2Bi, so it gets the rest of this post. First, the naming has to be untangled, because \u0026ldquo;SFTP is FTP over SSH\u0026rdquo; is the single most common thing people get wrong about it — and it isn\u0026rsquo;t true. SFTP — the SSH File Transfer Protocol — is a subsystem of SSH itself, not FTP wrapped in anything. It shares nothing with FTP\u0026rsquo;s command set or connection model. One TCP connection, one negotiated encrypted channel, file operations defined as part of the SSH protocol family from the ground up.\nsequenceDiagram participant Client participant Server Client-\u003e\u003eServer: TCP connect, port 22 Client-\u003e\u003eServer: SSH protocol version exchange Note over Client,Server: Algorithm negotiation:key exchange method, ciphers, MACs Client-\u003e\u003eServer: Key exchange (e.g. curve25519-sha256) Server-\u003e\u003eClient: Host key presented Note over Client,Server: Client checks host key against known_hosts —fails closed on mismatch Client-\u003e\u003eServer: Authenticate (public key or password) Server-\u003e\u003eClient: Authentication result Note over Client,Server: Single encrypted channel now established Client-\u003e\u003eServer: Request \"sftp\" subsystem Note over Client,Server: All file operations (open, read, write,stat, rename, delete) run as binarypackets inside this one channel Ports: one. Port 22, same as any SSH connection. No second data connection, no passive-mode range, nothing extra to open on a firewall. Security: strong by design — every packet, control and data alike, rides the same encrypted, integrity-checked channel established during the SSH handshake. Authentication supports both passwords and public-key auth (more on that below), and the server proves its own identity via its host key, which the client is supposed to verify against a trusted known_hosts entry before trusting anything that follows. When to use it: this is the default choice for new partner connections unless a partner\u0026rsquo;s own security or compliance requirements specifically dictate something else. It\u0026rsquo;s what I reach for first, and it\u0026rsquo;s the overwhelming majority of what B2Bi partner traffic runs over in practice. Why not FTP or FTPS instead: no plaintext option to accidentally misconfigure into (FTP), and no second connection fighting your firewall (FTPS) — SFTP\u0026rsquo;s single-channel model is just structurally simpler to secure correctly. SCP deserves a mention here because it\u0026rsquo;s SSH\u0026rsquo;s other file-transfer subsystem and gets confused with SFTP constantly. scp(1) is older and much simpler than SFTP — effectively cp with an SSH transport, no directory listing, no resume support, no atomic rename. Modern OpenSSH has been quietly reimplementing SCP\u0026rsquo;s client on top of SFTP internals for years, specifically because SFTP\u0026rsquo;s protocol design is better in almost every respect. If you have a choice between the two today, choose SFTP — it\u0026rsquo;s the actively maintained, more capable protocol, and it\u0026rsquo;s what Sterling\u0026rsquo;s client and server adapters implement.\nReference material worth having bookmarked rather than trusting secondhand explanations: ssh(1) and sftp(1), the canonical OpenBSD/OpenSSH man pages.\nQuick comparison # FTP FTPS SFTP Connections 2 (control + data) 2, TLS-wrapped 1 Port(s) 21 + dynamic/20 21 or 990 + dynamic 22 Encryption None TLS SSH transport encryption Auth Username/password, plaintext Username/password (+ optional client certs) Password or public key Firewall/NAT friendliness Poor Poor (TLS-wrapped data channel) Good — single connection Sterling adapter FTP Adapter FTP Adapter (SSL enabled) SFTP Client/Server Adapter SSH key pairs # Public-key authentication is the one you actually want for anything automated or partner-facing — no credential sitting in a script or scheduled job, no password rotation argument with a partner\u0026rsquo;s security team, and it\u0026rsquo;s what most SFTP Server Adapter trading partner configurations in B2Bi are built around.\nWhat it is: a mathematically linked pair of keys generated together. The private key stays exactly where it was generated and is never transmitted anywhere, by design — if it leaves that machine, the key pair is considered compromised. The public key is the half meant to be shared freely; it gets dropped into an authorized_keys file on a plain OpenSSH server, or registered as the partner\u0026rsquo;s known public key inside Sterling\u0026rsquo;s trading partner configuration. Authentication works because the client can prove possession of the private key (by signing a challenge) without ever sending it anywhere — the server only ever needs the public half to verify that signature.\nssh-keygen(1) is the tool that generates both halves.\nKey types and lengths:\nRSA — the old reliable, and still what most legacy MFT stacks and older mainframe-adjacent tooling expect. 2048-bit is the practical floor today (modern OpenSSH refuses anything smaller by default); 3072- or 4096-bit is the safer choice for anything long-lived. ssh-keygen -t rsa -b 4096. ed25519 — the modern default. Fixed key size (no length knob to get wrong), faster to generate and verify, and considered at least as strong as RSA-3072/4096 with far less key material. ssh-keygen -t ed25519. This is what I reach for first for any new key pair unless a partner\u0026rsquo;s tooling genuinely can\u0026rsquo;t parse it — which, with older systems, happens more often than you\u0026rsquo;d like. ECDSA — supported, occasionally seen, rarely my first pick given the NIST-curve concerns some security teams raise; ed25519 covers the same ground with less baggage. DSA — deprecated and disabled by default in current OpenSSH entirely. A partner insisting on it is really a conversation about how old their system is. Key file formats — the part that causes real friction during partner key exchange:\nOpenSSH\u0026rsquo;s own private key format (-----BEGIN OPENSSH PRIVATE KEY-----) has been the default since OpenSSH 7.8, and it\u0026rsquo;s what ssh-keygen produces unless told otherwise. PEM / PKCS#1 is the older private key format, still what plenty of non-OpenSSH tooling and older libraries expect. ssh-keygen -m PEM forces it when the other end can\u0026rsquo;t parse the newer format. SECSH public key format, defined in RFC 4716, is a public-key interchange format some non-OpenSSH SFTP servers and legacy MFT platforms expect instead of OpenSSH\u0026rsquo;s single-line authorized_keys-style format. ssh-keygen -e exports an OpenSSH-format public key into RFC 4716 form; -i imports one back. In practice: a partner hands you a public key in whatever format their system produced, it doesn\u0026rsquo;t match what your side wants, and the fix is a ssh-keygen -e/-i round-trip, not a re-generated key pair. Knowing these three formats exist turns a stuck partner onboarding into a two-minute fix.\nCiphers and MACs # What they are: during the SSH key exchange step in the handshake diagram above, client and server each advertise an ordered list of supported algorithms and agree on the strongest one both sides support — a cipher for encrypting the data stream, and a MAC (message authentication code) for verifying that packets haven\u0026rsquo;t been tampered with in transit. This negotiation is exactly what the SFTP Server Adapter\u0026rsquo;s cipher and MAC preference fields (visible in the Part 2 screenshots) are configuring — not something Sterling-specific, it\u0026rsquo;s SSH\u0026rsquo;s own algorithm negotiation surfaced through an admin console.\nWhy it matters: SSH has been around long enough to accumulate algorithms that were reasonable choices a decade ago and are now considered weak or broken. A server that still offers them isn\u0026rsquo;t necessarily compromised, but it\u0026rsquo;s carrying avoidable risk, and it\u0026rsquo;s routinely what security scans flag on an MFT server.\nGood, current choices (what modern OpenSSH defaults to and what I\u0026rsquo;d want a partner connection actually using):\nCiphers: chacha20-poly1305@openssh.com, aes256-gcm@openssh.com, aes128-gcm@openssh.com MACs: the -etm (encrypt-then-MAC) variants — hmac-sha2-256-etm@openssh.com, hmac-sha2-512-etm@openssh.com — preferred over their non-ETM equivalents because encrypt-then-MAC avoids some cryptographic pitfalls that MAC-then-encrypt is exposed to. Weak or deprecated — should not appear in an active configuration:\nCiphers: 3des-cbc (slow and cryptographically tired), arcfour/arcfour128/arcfour256 (RC4-based, broken), any plain -cbc mode cipher where a GCM or ChaCha20 alternative is available. MACs: hmac-md5 and hmac-sha1 (MD5 and SHA-1 are both considered too weak for this use), and non-ETM MACs generally, if the ETM variant is supported by both ends. The authoritative, current list of what OpenSSH supports — and how to set explicit preference order — lives in ssh_config(5) and sshd_config(5). The practical rule I follow: default to current OpenSSH recommended defaults, and only add an older cipher or MAC to the allowed list for the one specific partner connection that genuinely needs it — never globally, and never permanently without a ticket to revisit and remove it later.\nOperations that trip people up # Partial file reads. A partner\u0026rsquo;s automated job starts polling a mailbox the instant a file starts uploading, and picks up a half-written file. The fix is operational, not protocol-level: upload to a temp filename, then rename atomically once the transfer completes. SFTP supports atomic rename as a native operation; use it.\n\u0026ldquo;It works in FileZilla but not from our system.\u0026rdquo; Almost always an authentication method mismatch (the GUI client remembered a saved password; the automated job is trying key auth with the wrong key) or a host key that changed and the automated client is failing closed on a known_hosts mismatch while the GUI client just clicked through a warning dialog. Check both before assuming it\u0026rsquo;s a network issue.\nThread and connection limits. The SFTP Client Adapter config from Part 2 has explicit thread limits for a reason — a partner running a burst of parallel transfers against a shared adapter can exhaust connection slots for every other partner sharing it. Worth knowing your adapter\u0026rsquo;s limits before a partner asks \u0026ldquo;can we push 200 files at once.\u0026rdquo;\nHost key changes without warning. Partners rebuild servers and rotate keys without telling you in advance. A strict known_hosts policy is the right default, but it means every unannounced rotation is a failed connection until someone manually verifies and accepts the new key — worth a documented, fast verification path rather than reaching for \u0026ldquo;just disable strict checking,\u0026rdquo; which defeats the entire point. This happens often enough, and has enough nuance, that it gets its own post: SSH known_hosts: How Host Key Verification Actually Works.\nWhere this fits in Sterling # Everything above is protocol-level and applies to any FTP, FTPS, or SFTP server or client — IBM or otherwise. What Sterling adds is an admin-console UI over exactly these concepts: the SFTP Server Adapter\u0026rsquo;s host identity key field is the server\u0026rsquo;s SSH host key pair; its cipher and MAC preference lists are the ssh_config/sshd_config negotiation lists described above; a trading partner\u0026rsquo;s registered public key is an authorized_keys entry, just stored in Sterling\u0026rsquo;s trading partner configuration instead of a flat file; and the plain FTP Adapter with SSL enabled is exactly the FTPS handshake diagrammed above. None of it is Sterling reinventing these protocols — it\u0026rsquo;s Sterling exposing their native configuration surface through a console, which is why understanding the protocols underneath makes the adapter screens from Part 2 make a lot more sense on a second look.\nSources \u0026amp; further reading # RFC 959 — File Transfer Protocol OpenSSH ssh(1) sftp(1) scp(1) ssh-keygen(1) ssh_config(5) sshd_config(5) RFC 4716 — The Secure Shell (SSH) Public Key File Format IBM Documentation: Services \u0026amp; Adapters As with the rest of this series: the protocol definitions, RFCs, and man page content are the authoritative sources linked above, the framing, the comparisons, and the operational advice are mine.\nWhat\u0026rsquo;s next # Next up: Mailboxes and File Gateway — untangling the confusion flagged back in Part 1, with a closer look at how File Gateway\u0026rsquo;s routing actually sits on top of the mailbox and adapter machinery underneath it. Read it here: Part 5.\n","date":"9 September 2026","externalUrl":null,"permalink":"/posts/sterling-b2bi-07-sftp-protocol-fundamentals/","section":"Posts","summary":"Three protocols, one job, very different guts # FTP, FTPS, and SFTP all claim to do the same thing — move a file from one place to another — and partners use the names almost interchangeably, which is exactly the problem. They are three genuinely different protocols with different port models, different security properties, and different failure modes, and the SFTP Server Adapter and SFTP Client Adapter you configure in Sterling only make sense once you know which one you’re actually running. This post goes through each one on its own terms, then spends the back half on SFTP specifically, since that’s what carries the overwhelming majority of partner traffic in B2Bi.\n","title":"SFTP, FTP, FTPS: Protocol Behind the Adapters","type":"posts"},{"content":"","date":"9 September 2026","externalUrl":null,"permalink":"/series/sterling-b2bi-architecture/","section":"Series","summary":"","title":"Sterling-B2bi-Architecture","type":"series"},{"content":"","date":"8 September 2026","externalUrl":null,"permalink":"/tags/architecture/","section":"Tags","summary":"","title":"Architecture","type":"tags"},{"content":"","date":"8 September 2026","externalUrl":null,"permalink":"/tags/b2bi/","section":"Tags","summary":"","title":"B2bi","type":"tags"},{"content":"","date":"8 September 2026","externalUrl":null,"permalink":"/tags/dmz/","section":"Tags","summary":"","title":"Dmz","type":"tags"},{"content":"","date":"8 September 2026","externalUrl":null,"permalink":"/tags/network-security/","section":"Tags","summary":"","title":"Network-Security","type":"tags"},{"content":" The connection runs backward from what you\u0026rsquo;d guess # Most people\u0026rsquo;s first assumption about a box sitting in the DMZ is that your trusted, internal network reaches out to it — the secure side initiates, the exposed side listens. A Perimeter Server does the opposite. The core B2Bi engine sitting safely inside your network never opens a connection out into the DMZ at all. Instead, the Perimeter Server — the box actually facing partners and the internet — dials back in to the core engine and holds that connection open. Partner traffic lands on the DMZ box first, and only then gets forwarded inward over a channel the DMZ side itself established.\nI called this component out in Part 1 and promised to come back to it, because most intro material skips it entirely — which is a shame, since it\u0026rsquo;s the actual reason a Sterling deployment diagram has boxes sitting outside the firewall in the first place, and it\u0026rsquo;s the detail that makes the whole DMZ story click once you understand which direction the wire actually runs. Side by side, the assumption and the reality look like this:\nflowchart TB subgraph Assumed[\"What you'd assume\"] direction LR C1[\"Core Engine\\n(trusted zone)\"] FW1{{\"Inner Firewall\"}} PS1[\"Perimeter Server\\n(DMZ)\"] C1 -- \"Core opens a new\\nconnection into the DMZ\" --\u003e FW1 FW1 -- \"requires an inbound\\nallow rule from the DMZ\" --\u003e PS1 end subgraph Actual[\"What actually happens\"] direction LR PS2[\"Perimeter Server\\n(DMZ)\"] FW2{{\"Inner Firewall\"}} C2[\"Core Engine\\n(trusted zone)\"] PS2 -- \"PS dials out\\n(reverseConnect)\" --\u003e FW2 FW2 -- \"outbound-only rule —\\nno inbound hole needed\" --\u003e C2 end style FW1 fill:#4a1a1a,stroke:#c0392b style FW2 fill:#12331a,stroke:#27ae60 The top half is the rule your inner firewall would need if the core engine reached outward into the DMZ — an inbound allow rule that lets a DMZ host initiate traffic into the trusted zone, which is precisely the kind of hole a DMZ exists to prevent. The bottom half is what a Perimeter Server actually requires: an outbound-only rule, and nothing listening for connections from the DMZ side at all.\nWhat a Perimeter Server is # A Perimeter Server is a lightweight, standalone process that sits in the DMZ and terminates the protocol handshake with the outside world — SFTP, FTP/FTPS, HTTP/S, AS2, Connect:Direct, OdetteFTP, SOAP — on B2Bi\u0026rsquo;s behalf. It doesn\u0026rsquo;t run Business Processes, doesn\u0026rsquo;t touch mailboxes, and doesn\u0026rsquo;t hold trading partner configuration. Its entire job is socket management: accept the connection, manage the session and thread, and hand the traffic off to the real engine over a secure channel, so the engine itself — with the database, the document tracking history, every partner\u0026rsquo;s file — never has to sit anywhere near a public-facing interface (IBM Documentation).\nThat\u0026rsquo;s the whole value proposition in one sentence: it lets you expose partner-facing endpoints without ever putting the core engine within reach of the public internet. Beyond the security boundary, IBM also documents a performance angle — session and thread management on the DMZ box reduces the load the core engine has to carry directly, which matters more than it sounds like once you\u0026rsquo;re running dozens of partners with very different traffic profiles through the same node.\nEmbedded vs. remote: two very different deployments hiding behind one name # \u0026ldquo;Perimeter Server\u0026rdquo; refers to two distinct setups, and conflating them is a common source of confusion:\nEmbedded (local) Perimeter Server. Bundled directly inside B2Bi itself — no separate install, no DMZ placement. It exists so adapters that expect a perimeter server assignment have something to point at in a lab, a dev environment, or any deployment where you genuinely don\u0026rsquo;t need a DMZ boundary. It provides none of the actual security separation a remote one does.\nRemote (installed) Perimeter Server. A separate installation, deployed on its own host physically or logically inside the DMZ, independent of the B2Bi installation itself. This is the one doing real work in any production topology — the one partner traffic actually hits.\nMultiple remote Perimeter Servers can run against a single B2Bi node at once, which is what lets you segment traffic deliberately: one DMZ box handling high-volume SFTP from your largest trading partners, a separate one for a partner whose security team insists on physically isolated infrastructure, without touching the core engine\u0026rsquo;s configuration to add either. That per-adapter assignment is exactly the field you\u0026rsquo;d have glossed over in Part 2\u0026rsquo;s SFTP Client Adapter screenshot — \u0026ldquo;system name, environment, a perimeter server assignment, and thread limits\u0026rdquo; was doing a lot of quiet work in that one line.\nThe reverseConnect mechanic # Here\u0026rsquo;s the part that surprises people who\u0026rsquo;ve worked with reverse proxies before and expect the usual direction of trust: the remote Perimeter Server initiates the connection to the core engine, not the other way around. IBM\u0026rsquo;s own support documentation for the remote_perimeter.properties file that configures this lists exactly the parameters you\u0026rsquo;d expect for that model — reverseConnect, remoteAddress, remotePort, and a local port (IBM Support) — and community documentation of the same mechanism describes the remote Perimeter Server establishing a persistent connection back to the core system, commonly on port 9999 (Pronteff).\nWhy build it this way instead of letting the core engine reach out to the DMZ? Because it means your inner firewall never needs an inbound rule that lets a DMZ host initiate traffic into your trusted network\u0026rsquo;s listening ports — the DMZ box only ever originates the one connection it needs, and everything after that rides inside it. That single design decision is the reason the topology works at all without opening the exact kind of hole a DMZ exists to prevent.\nsequenceDiagram participant Partner participant PS as Perimeter Server (DMZ) participant Core as B2Bi Core Engine (trusted zone) Note over PS,Core: Persistent connection established first —PS dials Core, not the other way around PS-\u003e\u003eCore: Outbound connect (reverseConnect, typically port 9999) Core--\u003e\u003ePS: Connection accepted, held open Partner-\u003e\u003ePS: Connect (SFTP / AS2 / HTTP) PS-\u003e\u003ePS: Terminate protocol handshake PS-\u003e\u003eCore: Forward session over the existing channel Core-\u003e\u003eCore: Hand off to Adapter → Business Process Note over Partner,Core: Inner firewall never has to acceptan inbound connection initiated from the DMZ That sequence hides an important detail: at the network layer, there are really two separate connections doing two separate jobs, not one. Laid out as a topology instead of a timeline, it looks like this:\nflowchart LR subgraph Internet[\"Internet\"] Partner[\"Trading Partner\"] end subgraph DMZ[\"DMZ\"] PS[\"Perimeter Server\"] end subgraph Trusted[\"Trusted Zone\"] Core[\"B2Bi Core Engine\"] end PS == \"1 — outbound, PS-initiated\\npersistent control channel\\n(reverseConnect, port 9999)\" ==\u003e Core Partner -- \"2 — inbound to PS only\\n(SFTP / AS2 / HTTP)\" --\u003e PS PS -. \"3 — partner session tunneled\\nover the channel opened in step 1\" .-\u003e Core Step 1 has to happen first and stays up continuously — it\u0026rsquo;s infrastructure, not per-session traffic. Step 2 is the only connection a partner ever makes, and it terminates at the Perimeter Server; it never becomes a second, independent connection reaching into the trusted zone. Step 3 isn\u0026rsquo;t a new connection at all — it\u0026rsquo;s the partner\u0026rsquo;s session riding inside the channel that already exists from step 1. From the inner firewall\u0026rsquo;s point of view, exactly one connection ever crosses the boundary, and the DMZ box is the one that opened it.\n(Screenshot placeholder: the \u0026ldquo;Add Perimeter Server\u0026rdquo; screen in the admin console — Deployment \u0026gt; Perimeter Servers \u0026gt; Add — showing the name, description, and the local/embedded vs. remote type selector. Worth a second screenshot of a configured remote Perimeter Server\u0026rsquo;s detail view if the remote_perimeter.properties values are visible there.)\nPerimeter Server vs. Sterling Secure Proxy — not the same product # This is the other recurring source of confusion, and it\u0026rsquo;s worth being precise about it: Sterling Secure Proxy (SSP) is a separate IBM product, a full reverse-proxy and DMZ security gateway with its own session-breaking, protocol filtering, and credential-mapping capabilities well beyond what a Perimeter Server does. They get conflated constantly because SSP deployments also involve a \u0026ldquo;Parameter Server\u0026rdquo; component installed in front of it and because both products live in the same DMZ-facing part of a Sterling architecture diagram (IBM Support). If a job posting or a colleague says \u0026ldquo;perimeter server\u0026rdquo; and means session-breaking proxy behavior, full protocol inspection, or credential mapping between an external and internal identity, they\u0026rsquo;re almost certainly describing SSP, not the plain Perimeter Server this post covers. The plain Perimeter Server is a much narrower, much simpler component — it moves bytes securely across the DMZ boundary; it doesn\u0026rsquo;t inspect, transform, or authenticate anything on its own.\nOperational scenarios # \u0026ldquo;Partners can connect but files never show up.\u0026rdquo; Check which Perimeter Server the failing adapter is actually assigned to before anything else — with multiple remote Perimeter Servers on one node, a partner landing on the wrong one (or one that\u0026rsquo;s down) looks identical to a network problem from the partner\u0026rsquo;s side, but it\u0026rsquo;s a configuration mismatch on yours.\nCloseCode.NO_AVAILABLE_PORT in perimeter.log. This one shows up as a bind failure — java.net.BindException: Cannot assign requested address — when the Perimeter Server can\u0026rsquo;t allocate a port for a new session (IBM Support). In practice this is almost always port exhaustion under load or a local firewall/OS rule capping the ephemeral port range on the DMZ host — check the DMZ host\u0026rsquo;s own port range and any host-level firewall rules before assuming it\u0026rsquo;s a B2Bi-side problem. Worth remembering this is genuinely separate from the mailbox and Business Process world — it\u0026rsquo;s a lower-level, network-layer failure.\nTwo log files, two different failure classes. Perimeter connection and session issues live in perimeter.log, on the Perimeter Server host itself. Issues on the core engine side of the handoff — the Perimeter Services Manager registering or losing a connected Perimeter Server — show up in the core engine\u0026rsquo;s own logs instead. Chasing a connectivity issue in the wrong log is a fast way to lose twenty minutes for nothing; if a partner-facing protocol adapter is failing to receive connections at all, perimeter.log on the DMZ box is the first stop, not the core engine\u0026rsquo;s application log.\nA Perimeter Server \u0026ldquo;goes missing\u0026rdquo; after a restart. Because the DMZ side owns the connection, a restart order matters: if the core engine comes back up before the remote Perimeter Server reconnects, adapters assigned to that Perimeter Server will show it as unavailable until the DMZ-side process re-establishes its outbound connection. This is expected behavior, not corruption — it just means restart runbooks for a B2Bi environment with remote Perimeter Servers need to account for both sides coming back, not just the core engine.\nWhere this fits in the series # Perimeter Server is the piece from Part 1\u0026rsquo;s topology diagram that got a one-paragraph mention and nothing else until now. It\u0026rsquo;s the first thing a partner\u0026rsquo;s connection touches — before the Adapter, before the Business Process, before the file ever reaches a Mailbox. Every piece from that original diagram now genuinely has its own post behind it.\nSources \u0026amp; further reading # Perimeter servers in Sterling B2B Integrator — IBM Documentation Perimeter Server overview — IBM Documentation (6.1.2) Need more information about remote_perimeter.properties parameters — IBM Support Perimeter Server connection fails with CloseCode.NO_AVAILABLE_PORT — IBM Support What Parameter Server needs to be installed with IBM Sterling Secure Proxy? — IBM Support What is IBM Sterling Perimeter Server? — Pronteff As with the rest of this series: the definitions and the documented parameters are IBM\u0026rsquo;s (and IBM Support\u0026rsquo;s), the framing, the diagram, and the operational scenarios are mine.\nWhat\u0026rsquo;s next # Next up: The Map Editor — the translation layer flagged back in Part 1, and the source of some of the gnarliest bugs I\u0026rsquo;ve chased in production.\n","date":"8 September 2026","externalUrl":null,"permalink":"/posts/sterling-b2bi-06-perimeter-servers/","section":"Posts","summary":"The connection runs backward from what you’d guess # Most people’s first assumption about a box sitting in the DMZ is that your trusted, internal network reaches out to it — the secure side initiates, the exposed side listens. A Perimeter Server does the opposite. The core B2Bi engine sitting safely inside your network never opens a connection out into the DMZ at all. Instead, the Perimeter Server — the box actually facing partners and the internet — dials back in to the core engine and holds that connection open. Partner traffic lands on the DMZ box first, and only then gets forwarded inward over a channel the DMZ side itself established.\n","title":"Perimeter Servers in IBM Sterling B2B Integrator: Why the DMZ Box Calls Home Instead of the Other Way Around","type":"posts"},{"content":"","date":"8 September 2026","externalUrl":null,"permalink":"/tags/perimeter-server/","section":"Tags","summary":"","title":"Perimeter-Server","type":"tags"},{"content":"","date":"7 September 2026","externalUrl":null,"permalink":"/tags/file-gateway/","section":"Tags","summary":"","title":"File-Gateway","type":"tags"},{"content":" The confusion I flagged back in Part 1 # I called this out in Part 1 and promised to come back to it: File Gateway is not a separate product competing with B2Bi. It\u0026rsquo;s a purpose-built UI and routing layer sitting directly on top of B2Bi\u0026rsquo;s mailbox and adapter machinery, built specifically so partner file exchange can be managed without anyone touching BPML directly. I still see people who\u0026rsquo;ve run Sterling for years talk about the two as if they\u0026rsquo;re alternatives you choose between. They\u0026rsquo;re not — one is the foundation, the other is a way of working with that foundation without writing a Business Process by hand.\nOne naming note before anything else, because it causes real confusion in job postings, tickets, and casual conversation alike: File Gateway is almost always referred to as \u0026ldquo;SFG\u0026rdquo; — Sterling File Gateway — its actual product name, distinct from \u0026ldquo;B2Bi\u0026rdquo; (Sterling B2B Integrator) even though SFG runs as a component installed on top of a B2Bi environment rather than a standalone system. When someone says \u0026ldquo;we run SFG,\u0026rdquo; they mean this layer specifically: the Routes/Participants/Tools admin console shown throughout this post, not the core B2Bi admin console from the earlier parts of this series. I\u0026rsquo;ll use \u0026ldquo;File Gateway\u0026rdquo; and \u0026ldquo;SFG\u0026rdquo; interchangeably from here on, since you\u0026rsquo;ll see both in the wild — IBM\u0026rsquo;s own documentation, partner emails, and job requisitions all mix the two.\nThis post covers the mailbox foundation first, then what SFG actually adds on top of it.\nWhat is a Mailbox # A Mailbox is a secure, permissioned drop box inside B2Bi — a virtual folder structure that exists as metadata and database records, not literal files sitting in a directory, even though it behaves like one to anything interacting with it over SFTP, HTTP, or the Mailbox APIs. Files land in a mailbox, get picked up from one, and every operation against it is permission-checked and logged the same way any other document movement in the platform is.\nTwo things about that \u0026ldquo;virtual\u0026rdquo; framing matter in practice:\nMailbox hierarchy is organizational, not physical. You build a tree — a root mailbox, shared collection points, per-partner mailboxes underneath — and that structure is what partners and internal processes see when they list or navigate mailboxes. The actual bytes live wherever B2Bi\u0026rsquo;s document storage is configured to put them; the hierarchy you build has nothing to do with that. Permissions are assigned per mailbox, and they\u0026rsquo;re genuinely per-user/per-group, not just per-adapter. A trading partner\u0026rsquo;s SFTP credentials can be scoped to see exactly one mailbox and nothing else in the tree above or beside it — which is the entire mechanism that lets one shared SFTP Server Adapter safely serve dozens of unrelated partners at once, distinguished by mailbox and credentials rather than a dedicated adapter per partner. A typical hierarchy looks like this:\nflowchart TD ROOT[\"Root Mailbox\"] ROOT --\u003e DL[\"Dead Letter Mailbox\"] ROOT --\u003e EDIIN[\"EDI Inbound Collection\"] ROOT --\u003e EDIOUT[\"EDI Outbound Collection\"] ROOT --\u003e PARTNERS[\"Trading Partners\"] PARTNERS --\u003e PA[\"Partner A Mailbox\"] PARTNERS --\u003e PB[\"Partner B Mailbox\"] PARTNERS --\u003e PC[\"Partner C Mailbox\"] PA --\u003e PAIN[\"inbound/\"] PA --\u003e PAOUT[\"outbound/\"] style DL fill:#4a1a1a,stroke:#c0392b The Dead Letter Mailbox deserves a callout on its own: it\u0026rsquo;s where files land when they can\u0026rsquo;t be routed anywhere else — a malformed filename, a routing rule with no match, a permission failure mid-process. I check it before I check almost anything else when a partner says \u0026ldquo;I sent the file but nothing happened,\u0026rdquo; because more often than not, it\u0026rsquo;s sitting right there.\nHow a file actually gets into and out of a mailbox # Nothing about mailbox delivery is protocol-specific — the same mailbox can be written to by an SFTP Server Adapter receiving a partner\u0026rsquo;s upload, read from by a Business Process picking up a file to translate, or exposed through File Gateway\u0026rsquo;s own routing, all without the mailbox itself knowing or caring which path is being used:\nsequenceDiagram participant Partner participant AD as SFTP Server Adapter participant MB as Mailbox participant BP as Business Process participant DB as Database Partner-\u003e\u003eAD: Upload file (SFTP PUT) AD-\u003e\u003eMB: Deliver to partner's mailbox MB-\u003e\u003eDB: Record arrival, permissions check Note over MB,BP: Mailbox event or scheduled poll triggers pickup MB-\u003e\u003eBP: File available for processing BP-\u003e\u003eBP: Route, map, validate BP-\u003e\u003eMB: Deliver result to destination mailbox MB-\u003e\u003eDB: Record delivery status What File Gateway (SFG) actually is # Strip away the marketing name and SFG is: a routing engine, a partner-management UI, and a set of pre-built Business Processes that IBM ships so you don\u0026rsquo;t have to hand-build the same \u0026ldquo;receive, validate, route, delivery-confirm\u0026rdquo; pattern from scratch for every partner relationship. It runs on B2Bi — same engine, same adapters, same mailboxes — it just gives you a different, higher-level way to configure partner file exchange, through its own dedicated console organized around three tabs: Routes, Participants, and Tools.\nConcretely, SFG adds:\nPartners and Communities (the Participants tab) — a structured way to define trading partners and group them into communities, rather than mailbox permissions and trading partner records managed independently of each other. Here\u0026rsquo;s the Groups management screen — note \u0026ldquo;All Partners\u0026rdquo; as the default group, with the ability to create additional groups and assign partners into them: SFG\u0026rsquo;s Participants tab — grouping partners into communities instead of managing raw trading partner records one at a time Routing Channel Templates (the Routes tab) — reusable definitions of \u0026ldquo;when a file matching this pattern arrives from this partner, validate it this way, then deliver it here\u0026rdquo; — configured through a UI instead of drawn in the Graphical Process Modeler or written as raw BPML. Arrived Files / consumption tracking (the Tools tab) — a partner-facing (and admin-facing) view of what\u0026rsquo;s shown up, what\u0026rsquo;s been picked up, and what\u0026rsquo;s still pending, without anyone needing to query the document tracking database directly. The search screen under Tools lets you query by mailbox type, producer, consumer, filename, status, protocol, and date/time range: The Arrived File search under Tools — this is what \u0026lsquo;consumption tracking without querying the database directly\u0026rsquo; looks like in practice Running that search against real activity returns a result list like this — each arrived file with its status, producer, original filename, and discovery time:\nTwo arrived files, both Failed — exactly the kind of thing a partner\u0026rsquo;s \u0026quot;I sent it, did you get it\u0026quot; question resolves against That same Tools tab also has a Reports sub-tab for generating a formatted PDF or similar output across a date range, filtered by producer/consumer group and status (Started, Succeeded, Failed, Ignored) — useful for a recurring partner-facing or internal SLA report rather than one-off lookups:\nScheduled or on-demand reporting across arrived file activity — this is the tool for \u0026quot;how many files failed for this partner last month,\u0026quot; not a one-off search The routing itself still ultimately moves through mailboxes and still ultimately triggers Business Processes — File Gateway is the layer that generates and manages those for you based on the routing channels you configure:\nflowchart LR subgraph FG[\"File Gateway Layer\"] RC[\"Routing Channel\\nTemplates\"] PM[\"Partner \u0026\\nCommunity Management\"] AF[\"Arrived Files\\nTracking\"] end subgraph Core[\"B2Bi Core (unchanged)\"] AD[\"Adapters\"] MB[\"Mailboxes\"] BP[\"Business Processes\"] end Partner[\"Trading Partner\"] --\u003e AD AD --\u003e MB RC -.configures.-\u003e BP MB \u003c--\u003e BP BP --\u003e AF PM -.governs.-\u003e RC That dotted-line relationship is the whole point of this post: SFG configures and manages the same underlying pieces from Parts 1–4, it doesn\u0026rsquo;t replace or bypass them. When something breaks in an SFG-managed exchange, you\u0026rsquo;re still debugging an adapter, a mailbox, and a Business Process underneath — the SFG UI is just a friendlier front door to get there, and it even shows you that underlying machinery directly when you drill into a single arrived file\u0026rsquo;s event log:\nEvery box in the flowchart above, traced as one real event log — partner identification, mailbox delivery, routing channel matching, and the exact point where this one failed Read top to bottom, that log is the flowchart: the file arrives (FG_0408), gets delivered to a mailbox (FG_0425), the producer partner is identified (FG_0404), route determination runs against the matching Routing Channel Template (FG_0501–FG_0504), and — in this case — validation against the partner fails (FG_0455, in red) before routing can complete. When SFG documentation or a colleague says \u0026ldquo;check the arrived file events,\u0026rdquo; this is exactly what they mean, and it\u0026rsquo;s usually the fastest way to find out which step in the pipeline actually broke instead of guessing.\nWhen to reach for File Gateway vs. a raw mailbox # Use File Gateway when: partner onboarding needs to be repeatable and largely self-service for whoever\u0026rsquo;s doing it, when you want built-in delivery confirmation and a partner-visible arrived-files view without custom-building one, or when the exchange pattern is genuinely \u0026ldquo;receive from A, validate, deliver to B\u0026rdquo; without complex conditional branching that the routing channel template can\u0026rsquo;t express cleanly.\nGo straight to a raw mailbox and a hand-built (or existing) Business Process when: the routing logic is complex enough that a routing channel template becomes more awkward than just writing the BPML directly, when you\u0026rsquo;re integrating with existing Business Processes that already do bespoke validation/mapping that doesn\u0026rsquo;t fit File Gateway\u0026rsquo;s pattern, or for internal-only mailbox usage that was never partner-facing to begin with (an EDI Outbound Collection point being read by a scheduled internal process, for instance).\nIn practice, most new external partner onboarding at the SFTP-in, deliver-somewhere-out pattern goes through File Gateway now, specifically because the Arrived Files tracking alone saves a meaningful amount of \u0026ldquo;did they get it\u0026rdquo; support back-and-forth. Anything with real conditional logic or legacy history still lives as a direct Business Process against mailboxes.\nOperational scenarios # \u0026ldquo;The partner says they uploaded, but nothing happened.\u0026rdquo; Check the Dead Letter Mailbox first — a filename that doesn\u0026rsquo;t match the expected pattern, or a routing channel with no matching rule, sends a file there silently rather than failing loudly. Second stop: the Tools tab\u0026rsquo;s Arrived File search — filtered by that producer and a Failed status, it\u0026rsquo;ll usually surface exactly this kind of stuck file in seconds, the same way the two Failed results shown earlier did. From there, drilling into the arrived file\u0026rsquo;s event log (as above) tells you why — a validation failure, a routing channel with no match, or something further upstream.\nPermission scoping mistakes. Because mailbox permissions are genuinely fine-grained, it\u0026rsquo;s easy to grant a partner\u0026rsquo;s SFTP credentials broader mailbox visibility than intended — especially on a shared SFTP Server Adapter serving many partners. Worth periodically auditing mailbox permissions against the trading partner list rather than assuming they stayed correctly scoped as the partner list grew.\nRouting channel template changes affecting live traffic. Editing a routing channel template that\u0026rsquo;s actively in use is not the same as editing a Business Process offline — routing channels can affect in-flight and newly-arriving files immediately. Treat template changes with the same change-control discipline you\u0026rsquo;d apply to a production BPML edit, not as a casual admin-console tweak.\nRecurring partner SLA reporting. Rather than manually searching Arrived Files every time a partner asks \u0026ldquo;how many of our files failed last month,\u0026rdquo; the Reports sub-tab under Tools generates exactly that as a formatted PDF, filtered by producer/consumer group and status — worth setting up as a scheduled habit for high-volume partners rather than reactive one-off lookups.\nWhere this fits in the series # This closes the loop from Part 1\u0026rsquo;s component overview: the Perimeter Server and Adapters get the file in, Business Processes and BPML move and transform it (Part 3), SFTP is the protocol most of those adapters actually speak (Part 4), and Mailboxes — with File Gateway as an optional, higher-level way of managing them — are where the file lands and gets picked up from. One piece from the Part 1 topology diagram is still owed its own deep dive: the Perimeter Server itself, next.\nSources \u0026amp; further reading # Sterling File Gateway — Overview Creating a Sterling B2B Integrator Mailbox Sterling B2B Integrator — Overview As with the rest of this series: the definitions are IBM\u0026rsquo;s, the framing, the routing diagram, and the operational scenarios are mine.\nWhat\u0026rsquo;s next # Next up: Perimeter Servers — the DMZ component every partner connection touches first, mentioned back in Part 1 and never fully explained until now. Read it here: Part 6. The Map Editor follows after that.\n","date":"7 September 2026","externalUrl":null,"permalink":"/posts/sterling-b2bi-05-mailboxes-file-gateway/","section":"Posts","summary":"The confusion I flagged back in Part 1 # I called this out in Part 1 and promised to come back to it: File Gateway is not a separate product competing with B2Bi. It’s a purpose-built UI and routing layer sitting directly on top of B2Bi’s mailbox and adapter machinery, built specifically so partner file exchange can be managed without anyone touching BPML directly. I still see people who’ve run Sterling for years talk about the two as if they’re alternatives you choose between. They’re not — one is the foundation, the other is a way of working with that foundation without writing a Business Process by hand.\n","title":"Mailboxes and File Gateway in IBM Sterling B2B Integrator: One Layer, Not Two Products","type":"posts"},{"content":"","date":"7 September 2026","externalUrl":null,"permalink":"/tags/sfg/","section":"Tags","summary":"","title":"Sfg","type":"tags"},{"content":"","date":"6 September 2026","externalUrl":null,"permalink":"/tags/bpml/","section":"Tags","summary":"","title":"Bpml","type":"tags"},{"content":" What is a Business Process # A Business Process is the workflow that strings adapters and services together into something that actually does a job: receive a file, validate it, map it, encrypt it, hand it to an adapter for delivery, log every step along the way. It\u0026rsquo;s the thing Part 1 called \u0026ldquo;the closest thing the platform has to a heart\u0026rdquo; — because almost nothing meaningful happens in Sterling B2B Integrator outside of one running.\nStructurally, a Business Process is just a sequence of steps with branching logic: call this service, check this condition, call that adapter, handle it differently if something goes wrong. Nothing about that description requires a diagram. Which is exactly the point.\nWhat is BPML # BPML — Business Process Markup Language — is the XML-based language a Business Process is actually written in underneath. Every box you drag in the visual designer becomes an element in this markup; every arrow becomes the nesting and sequencing of those elements. It\u0026rsquo;s not a simplified summary of the process — it\u0026rsquo;s the literal, complete definition the Business Process Engine executes. Nothing runs that isn\u0026rsquo;t in the BPML, including anything the visual designer generated for you without asking.\nGPM and BPML are the same thing, viewed differently # The Graphical Process Modeler (GPM) is the tool most people learn first: drag a service icon onto the canvas, connect it to the next step, and the tool builds the process visually. What\u0026rsquo;s easy to miss starting out is that the GPM isn\u0026rsquo;t a separate, simplified way of building a Business Process — it\u0026rsquo;s a real-time translator. IBM\u0026rsquo;s own documentation describes it as a Web-deployed graphical interface tool used to create and modify Business Processes (IBM Documentation), and under the hood it converts every graphical model you build directly into BPML — and just as easily converts existing BPML back into the diagram, letting you toggle between the two views of the exact same process at any point.\nThat reversibility is the part worth internalizing: nothing is lost going from diagram to code or back. A Business Process built entirely by dragging icons and a Business Process typed by hand in a text editor are functionally identical once saved — the engine doesn\u0026rsquo;t know or care which one you used.\nThe BPML elements you\u0026rsquo;ll actually use # BPML has a fairly large vocabulary, but a handful of elements cover the overwhelming majority of what you\u0026rsquo;ll read and write:\nOPERATION. The workhorse element — this is the BPML component used to call a service or adapter from within a Business Process (IBM Documentation). Every icon you drag in the GPM that represents a service or adapter compiles down to an OPERATION underneath. If you\u0026rsquo;re hunting for where a specific service gets invoked, you\u0026rsquo;re hunting for an OPERATION block.\nSEQUENCE. The structural element that says \u0026ldquo;these steps happen in this order.\u0026rdquo; Most of a Business Process is one big SEQUENCE with other elements nested inside it — it\u0026rsquo;s the skeleton everything else hangs off.\nCHOICE. Conditional branching — do this if a condition is true, do something else if it isn\u0026rsquo;t. This is where partner-specific routing logic usually lives: \u0026ldquo;if trading partner is X, use map A; otherwise use map B.\u0026rdquo;\nASSIGN. Moves data between the Business Process\u0026rsquo;s working memory and a service\u0026rsquo;s input or output parameters. Unglamorous, but this is where a huge share of \u0026ldquo;the map got the wrong field\u0026rdquo; bugs actually originate — not in the map itself, but in an ASSIGN that pointed it at the wrong piece of data.\nONFAULT. Error handling. When a step inside a SEQUENCE fails, an ONFAULT block lets you catch that failure and do something deliberate about it — retry, notify, route to a dead-letter mailbox — instead of letting the process die silently. A Business Process with no ONFAULT handling isn\u0026rsquo;t wrong, exactly, but it\u0026rsquo;s the single most common reason \u0026ldquo;the file just disappeared\u0026rdquo; turns into a long investigation.\nScenarios: reading and writing BPML in practice # Scenario 1 — Building a new inbound Business Process from scratch. This is GPM\u0026rsquo;s home turf: drag an adapter icon, drag a validation service, drag a mapping service, connect them, save. For a first draft, the visual tool is faster than typing BPML by hand, and it\u0026rsquo;s much harder to produce invalid XML by accident.\nScenario 2 — The GPM is slow or unavailable, and a process needs a small fix right now. This is exactly the moment that senior engineer was demonstrating. Opening the .bpml file directly in a text editor, finding the OPERATION or ASSIGN block in question, and editing it by hand is entirely valid — the engine doesn\u0026rsquo;t care how the file was produced. Being comfortable reading raw BPML turns \u0026ldquo;I need the GPM to load\u0026rdquo; into \u0026ldquo;I need a text editor,\u0026rdquo; which matters more than it sounds like during an actual incident.\nScenario 3 — The same small change needs to go into fifty Business Processes. Clicking through fifty processes in the GPM one at a time is a bad afternoon. Scripting a find-and-replace across fifty .bpml files is not. This is the scenario where knowing BPML isn\u0026rsquo;t just a debugging skill — it\u0026rsquo;s the difference between an hour of work and a week of it.\nScenario 4 — A process is failing and nobody knows where. Start with the ONFAULT blocks — or the lack of them. If a SEQUENCE has no error handling around the step that\u0026rsquo;s failing, that\u0026rsquo;s usually the fastest fix available: wrap it, log what actually failed, and the next failure explains itself instead of requiring another investigation from scratch.\nWhy the distinction actually matters # The GPM is the better tool for building and understanding a process\u0026rsquo;s shape — the boxes-and-arrows view makes the overall flow obvious in a way that nested XML tags don\u0026rsquo;t. Raw BPML is the better tool for precision, bulk changes, and anything that has to happen when the visual tool is slow, unavailable, or simply overkill for a two-line fix.\nNeither one is the \u0026ldquo;real\u0026rdquo; Business Process and the other a shortcut. They\u0026rsquo;re the same definition, and the right one to use depends entirely on what you\u0026rsquo;re trying to do at that moment — build something new, or fix something specific, fast.\nWhere this sits in the bigger picture # Every adapter and service call from Part 1 and Part 2 happens because a Business Process\u0026rsquo;s BPML told the engine to make it happen, in that order, with that error handling. The GPM and the raw BPML are just two doors into editing the same file:\nflowchart TB subgraph Authoring[\"Two Ways In\"] GPM[\"Graphical Process Modeler(drag, connect, toggle view)\"] TXT[\"Text Editor(edit .bpml directly)\"] end BPML[(\"BPML(the actual definition)\")] ENGINE[\"Business Process Engine\"] GPM \u003c--\u003e|generates / renders| BPML TXT \u003c--\u003e|reads / writes| BPML BPML --\u003e ENGINE ENGINE --\u003e OP1[\"OPERATION(call an Adapter)\"] ENGINE --\u003e OP2[\"OPERATION(call a Service)\"] ENGINE --\u003e CH[\"CHOICE(branch)\"] ENGINE --\u003e OF[\"ONFAULT(handle failure)\"] Both authoring paths converge on the exact same BPML, and the engine that actually runs it has no idea — and no reason to care — which door you used.\nSources \u0026amp; further reading # Graphical Process Modeler BPML Business Process Components Business Processes Add error handling to a Business Process IBM Support: Business Process does not invoke any OnFault when a service fails with error As with the rest of this series, the framing, the scenarios, and the war stories are mine — the definitions and the BPML element behavior are IBM\u0026rsquo;s.\nWhat\u0026rsquo;s next # Next up: SFTP: The Protocol Behind the Adapter — a closer look at the transport, authentication, and key mechanics underneath the SFTP Server Adapter configured back in Part 2.\n","date":"6 September 2026","externalUrl":null,"permalink":"/posts/sterling-b2bi-03-business-processes-bpml/","section":"Posts","summary":"What is a Business Process # A Business Process is the workflow that strings adapters and services together into something that actually does a job: receive a file, validate it, map it, encrypt it, hand it to an adapter for delivery, log every step along the way. It’s the thing Part 1 called “the closest thing the platform has to a heart” — because almost nothing meaningful happens in Sterling B2B Integrator outside of one running.\n","title":"Business Processes and BPML in IBM Sterling B2B Integrator: Two Views of the Same Engine","type":"posts"},{"content":" What is an Adapter # An Adapter is a service whose entire job is reaching outside Sterling B2B Integrator — connecting the Business Process Engine to \u0026ldquo;dissimilar systems and applications\u0026rdquo; that live outside the environment (IBM Documentation). An SFTP adapter opens a connection to a partner\u0026rsquo;s SFTP server. An AS2 adapter speaks the AS2 protocol to a trading partner\u0026rsquo;s gateway. Same underlying mechanism as any other service — the Business Process Engine calls it, it runs, it returns a result — but the work itself happens somewhere else, over a network, against a system you don\u0026rsquo;t control.\nWhat is a Service # A Service is the broad category: any set of instructions the Business Process Engine uses to carry out an activity inside a Business Process. That\u0026rsquo;s deliberately broad — services cover mapping a document from one format to another, validating a field against a schema, encrypting a payload, checking a condition and branching, even pausing a process to wait for a human to click \u0026ldquo;approve\u0026rdquo; in a web form.\nThe thread connecting all of that is that a service does its work using data the Business Process already has, or produces data the Business Process will use next. It doesn\u0026rsquo;t need to reach outside the system to do its job.\nPut the two together and you get the whole distinction in one line: every adapter is a service, but not every service is an adapter. That\u0026rsquo;s worth sitting with, because it explains almost every confusing conversation you\u0026rsquo;ll have about this platform.\nThere\u0026rsquo;s a useful three-way split worth knowing, because it comes up constantly once you start reading Business Process logs: internal services process parameters and produce results without ever leaving the system; input and output adapters are the ones that reach outward; and a separate category, human interaction services, exist purely to pause a process until a person acts, typically through a web browser approving or rejecting a step. That last category trips people up the most, because it\u0026rsquo;s technically \u0026ldquo;just a service,\u0026rdquo; but it behaves nothing like the mapping-and-validation services people picture by default.\nA single node in a real environment can easily run into the hundreds of registered services once you count every adapter, translator, and utility service installed — this is one node in a production-sized deployment:\n444 services on a single node — most of them you\u0026rsquo;ll never touch directly The adapters you\u0026rsquo;ll actually use # Sterling ships dozens of adapters, but in practice most deployments lean on a handful of them, over and over, because most trading-partner requirements boil down to a handful of protocols:\nSFTP Adapter (Client and Server). The default choice for new partner connections when nobody\u0026rsquo;s dictating otherwise. It\u0026rsquo;s encrypted, nearly every partner\u0026rsquo;s IT team already knows how to stand one up, and the setup overhead is low compared to AS2. I reach for SFTP first unless a partner\u0026rsquo;s own security or compliance team specifically requires something else. Here\u0026rsquo;s a real SFTP Client Adapter configuration — notice how little there actually is to it: a system name, an environment, a perimeter server assignment, and thread limits:\nSFTP Client Adapter 2.0 — a minimal, mostly-defaults configuration The Server-side adapter carries a lot more surface area, because now you\u0026rsquo;re the one being connected to: listen port, host identity key, cipher and MAC preferences, authentication requirements, and mailbox routing all live here:\nSFTP Server Adapter 2.0 — this is the side of the connection partners actually authenticate against AS2 Adapter. The one you don\u0026rsquo;t get to choose — it\u0026rsquo;s the one a partner mandates. AS2 is built around signed, encrypted messages with Message Disposition Notifications (MDNs) that give both sides a cryptographic receipt proving a file arrived intact. That receipt is exactly why large retailers, logistics networks, and anyone running EDI at scale tends to require it: when a dispute happens over whether a purchase order was actually delivered, the MDN settles it. The tradeoff is setup cost — certificates, partner profiles, and MDN configuration all have to match exactly on both ends, and a mismatched cert is the single most common AS2 onboarding headache I\u0026rsquo;ve dealt with.\nConnect:Direct Adapter. This is the one people underestimate until they need it. Connect:Direct is built for guaranteed, checkpoint-restartable delivery of large files between systems that can\u0026rsquo;t tolerate a failed transfer needing to restart from byte zero — think end-of-day batch files between banks, or multi-gigabyte files in logistics and manufacturing. If a transfer drops at 80%, Connect:Direct resumes from 80%, not from scratch. That single feature is why it\u0026rsquo;s still standard in finance and other high-volume enterprise environments, license cost and all.\nHTTP/HTTPS Client Adapter. The adapter for modern, API-style integrations — calling a partner\u0026rsquo;s REST endpoint, receiving a webhook-style callback, or talking to internal microservices instead of a legacy mainframe. This is the one that\u0026rsquo;s grown the most in relevance as more trading-partner ecosystems move away from pure batch file exchange toward request/response APIs.\nFTP Adapter. Still out there, still working, and generally the adapter I try to migrate partners away from when I get the chance — plain FTP sends credentials and data unencrypted unless it\u0026rsquo;s tunneled through something else. It survives mostly on legacy inertia, not because anyone would choose it today.\nCommand Line Adapter 2 (CLA2). The escape hatch. When a Business Process needs to hand off to an actual script or a legacy executable that predates the platform, CLA2 is the bridge — genuinely useful, but also usually a sign that something upstream never got properly re-platformed.\nThe services you\u0026rsquo;ll actually use # Fewer categories here, but they show up in nearly every Business Process regardless of which adapters are involved:\nTranslation / EDI services (X12, EDIFACT, and similar). These convert a partner\u0026rsquo;s raw EDI envelope into something the rest of the process — and your downstream systems — can actually work with, and back again on the way out. If your organization does any EDI at all, one of these runs on almost every inbound and outbound document.\nMapping services, built in the Map Editor. Where the actual field-by-field translation happens: partner format to your internal format, or the reverse. This is where most of the \u0026ldquo;why did this document fail\u0026rdquo; investigations end up, because a map only handles the shapes of data it was built and tested against — an unexpected field, a new code value, or a partner silently changing their format is a map problem, not a connectivity one.\nValidation services. Check a document against a schema or a set of business rules before anything downstream trusts it. Cheap insurance: catching a malformed document here is far less painful than catching it three systems downstream.\nEncryption/decryption services, most commonly PGP. Plenty of partners require PGP-encrypted files regardless of which transport carries them, since transport encryption (like SFTP or AS2\u0026rsquo;s own TLS) only protects data in transit — PGP protects the file itself, including while it\u0026rsquo;s sitting in a mailbox waiting to be picked up.\nHuman interaction services. The odd one out, and worth normalizing rather than being confused by. They\u0026rsquo;re genuinely a service by the platform\u0026rsquo;s own definition, but their entire job is pausing a process until a person clicks approve or reject in a web form — useful for anything that needs a manual review step, like an unusually large invoice or a first-time partner document.\nOperational services worth knowing about # Not every service touches a trading partner\u0026rsquo;s document. A chunk of that 444-service list is pure platform housekeeping — services that keep the system itself healthy rather than moving anyone\u0026rsquo;s file. Two worth knowing by name:\nAlert Service. Deliberately minimal — its entire job is checking your workflows and raising an alert when something needs attention. This is usually one of the first things wired up in a new environment, because \u0026ldquo;did anything break overnight\u0026rdquo; needs an answer that doesn\u0026rsquo;t depend on someone manually checking logs.\nAlert Service — small on purpose, and usually one of the first services configured in a new environment BackupService. Runs on a schedule (2:00 AM in most environments I\u0026rsquo;ve seen) to archive completed or terminated Business Process data in chunks, so the database in Part 1 doesn\u0026rsquo;t grow forever. If you\u0026rsquo;ve ever wondered how document tracking history stays queryable for months without the database falling over, this service — and the archive/purge/index numbers on that Database Usage dashboard — is the answer.\nBackupService — the reason your Business Process history doesn\u0026rsquo;t grow forever Scenarios: adapters in the wild # Definitions only get you so far. Here\u0026rsquo;s how the adapter choice actually plays out across a few real situations:\nScenario 1 — A new partner wants to send you flat files, no special requirements. Default to SFTP. Stand up an SFTP Server Adapter (or reuse an existing one — most environments run a shared server adapter across many partners, distinguished by mailbox and credentials rather than one adapter each), issue the partner a key or password, and route their inbound files to a dedicated mailbox. This is the fastest partner onboarding path in the whole platform, usually a same-day turnaround.\nScenario 2 — A retail partner requires AS2 with MDN receipts in their trading partner agreement. No choice here — configure an AS2 adapter, exchange certificates with the partner (theirs and yours, both directions), and make sure MDN settings (synchronous vs. asynchronous, signed vs. unsigned) match exactly what\u0026rsquo;s in the agreement. Budget real time for this one; certificate mismatches are the most common reason AS2 onboarding drags past its estimate.\nScenario 3 — A bank needs guaranteed delivery of a multi-gigabyte nightly settlement file, and a failed transfer can\u0026rsquo;t restart from zero. This is Connect:Direct\u0026rsquo;s exact reason for existing. Configure the Connect:Direct adapter with checkpoint restart enabled, and a transfer that drops at 2GB into a 5GB file resumes from 2GB rather than starting over — which matters a lot when the file has to land before a batch window closes.\nScenario 4 — Partners keep asking \u0026ldquo;did my file arrive,\u0026rdquo; and you\u0026rsquo;re tired of manually checking. This isn\u0026rsquo;t a new adapter — it\u0026rsquo;s wiring the Alert Service into the Business Processes that matter, so a failure state triggers a notification instead of sitting silently until someone goes looking. Combine it with document tracking (from Part 1) and most \u0026ldquo;did it arrive\u0026rdquo; questions get answered before anyone has to ask.\nWhy the distinction actually matters # Here\u0026rsquo;s the part that\u0026rsquo;s easy to miss until it costs you time: adapters and services fail differently, and they get diagnosed in different places.\nAn adapter failure is almost always about the outside world — a partner\u0026rsquo;s server is down, a certificate expired, a firewall rule changed, a network path got blocked. You fix it by checking connectivity, credentials, and the partner\u0026rsquo;s side of the handshake. The Business Process itself is usually innocent; it\u0026rsquo;s just waiting on a door that won\u0026rsquo;t open.\nA service failure is almost always about the data. A map choked on an unexpected field. A validation rule rejected something that used to pass. A condition branched somewhere nobody expected. You fix it by looking at the actual document moving through the process, not at connectivity settings.\nConfuse the two and you end up doing exactly what I did on that first project: checking network settings for a data problem, or picking apart a map for a problem that was actually a partner\u0026rsquo;s server timing out. The fastest diagnostic question I know for Sterling incidents is simply: \u0026ldquo;did this fail trying to reach something outside the system, or while working on data already inside it?\u0026rdquo; That question alone routes you to the right half of the Business Process almost every time.\nWhere this sits in the bigger picture # Adapters sit at the two edges of the flow from Part 1 — receiving a file from a Perimeter Server on the way in, or handing a file off to a partner on the way out. Services sit in the middle, doing everything that happens to a file once it\u0026rsquo;s inside the walls: mapping, validating, routing, occasionally waiting on a human. A Business Process is really just a sequence of calls to both, with branching logic stitching them together.\nflowchart LR subgraph Outside[\"Outside the System\"] Partner[\"Trading Partner\"] end subgraph BP[\"Business Process\"] direction TB A1[\"Input Adapter(SFTP / AS2 / HTTP)\"] S1[\"ServiceValidate\"] S2[\"ServiceMap\"] S3[\"Human Interaction Service(optional approval step)\"] A2[\"Output Adapter(SFTP / AS2 / Connect:Direct)\"] A1 --\u003e S1 --\u003e S2 --\u003e S3 --\u003e A2 end Partner --\u003e|inbound file| A1 A2 --\u003e|outbound file| Partner classDef adapter fill:#0f62fe,color:#fff,stroke:#0f62fe classDef service fill:#393939,color:#fff,stroke:#393939 class A1,A2 adapter class S1,S2,S3 service Blue is \u0026ldquo;leaves the system.\u0026rdquo; Gray is \u0026ldquo;stays inside.\u0026rdquo; When something breaks, that color is the first thing I check.\nSources \u0026amp; further reading # Sterling B2B Integrator — Services and Adapters Sterling B2B Integrator — Services and Adapters (A–L) Sterling B2B Integrator — Services and Adapters (M–Z) Business Processes Command Line Adapter 2 (CLA2) overview File transfer capabilities and integration with IBM Sterling B2B Integrator As with Part 1, the framing, the recommendations, and the war stories are mine — the definitions are IBM\u0026rsquo;s, and the screenshots are from my own environment.\nWhat\u0026rsquo;s next # Next up: Business Processes and BPML — the actual workflow engine tying every adapter and service call together, and why the visual Graphical Process Modeler and the raw BPML underneath it are worth understanding as two views of the same thing, not two separate tools.\n","date":"5 September 2026","externalUrl":null,"permalink":"/posts/sterling-b2bi-02-adapters-vs-services/","section":"Posts","summary":"What is an Adapter # An Adapter is a service whose entire job is reaching outside Sterling B2B Integrator — connecting the Business Process Engine to “dissimilar systems and applications” that live outside the environment (IBM Documentation). An SFTP adapter opens a connection to a partner’s SFTP server. An AS2 adapter speaks the AS2 protocol to a trading partner’s gateway. Same underlying mechanism as any other service — the Business Process Engine calls it, it runs, it returns a result — but the work itself happens somewhere else, over a network, against a system you don’t control.\n","title":"IBM Sterling B2B Integrator: Adapters vs. Services - The Distinction That Actually Matters","type":"posts"},{"content":"The admin console home page — where every session starts What is IBM B2Bi # IBM Sterling B2B Integrator does one job: move files between your business and your trading partners — banks, suppliers, logistics providers, whoever needs EDI documents, flat files, or XML exchanged reliably and traceably — and know exactly what happened to every file at every step. That\u0026rsquo;s it. Everything else exists to support that one job.\nIBM\u0026rsquo;s own overview puts it plainly: B2Bi is built to manage \u0026ldquo;the technical and human dynamics of business-to-business partner relationships\u0026rdquo; (IBM Documentation). In practice, \u0026ldquo;technical and human dynamics\u0026rdquo; means the software has to be forgiving of partners who send malformed files, change their connection details without warning, and occasionally vanish for a week over the holidays — while your audit trail still needs to hold up.\nIBM B2Bi Components # Memorizing a components list never worked, but tracing one file end to end did. For scale, here\u0026rsquo;s the full admin menu tree — everything below is one branch of it:\nThe complete admin menu — Business Processes, Trading Partner, Deployment, EBICS, and Operations Perimeter Server # A partner connection doesn\u0026rsquo;t hit the core engine directly. It lands on a Perimeter Server sitting out in the DMZ, which handles the actual protocol handshake (SFTP, AS2, HTTP) and forwards traffic inward over a secure channel. Most intro material skips this entirely, which is a shame, because it\u0026rsquo;s the whole reason you can expose partner-facing endpoints without ever putting your core engine anywhere near the public internet. If you\u0026rsquo;ve ever wondered why a Sterling deployment diagram has boxes sitting outside the firewall, this is why — and it deserves its own post later in this series: Part 6 covers exactly how that DMZ box talks to the core engine.\nAdapters # From there, an Adapter picks it up. Adapters are narrow by design — SFTP, AS2, Connect:Direct, HTTP/S, JDBC, and a few dozen others — and each one does exactly one thing: receive or send a file over its specific protocol, then hand it to a Business Process.\nA real adapter list — this is what \u0026rsquo;narrow by design\u0026rsquo; looks like in practice Business Process # That handoff is where things get interesting. A Business Process is a workflow — modeled visually in the Graphical Process Modeler, stored underneath as BPML (Business Process Markup Language) — that strings together steps: validate this, map that, encrypt this, route it, page someone if it fails. Practically everything meaningful in B2Bi happens inside a Business Process. It\u0026rsquo;s the closest thing the platform has to a heart.\n807 Business Processes in one environment — and that\u0026rsquo;s a modest one Services # Inside that process, Services do the internal work — mapping, validation, extraction, compression, custom logic — while Adapters keep handling the outside world. A Business Process, stripped down, is mostly just Adapter and Service calls in sequence, with branches for when things go wrong (and in production, something always eventually goes wrong).\nServices are organized into categories like this — EDI, Translation, and Transport cover most of what a Business Process actually does Map # Somewhere in that sequence, a Map usually runs. Partners almost never send data in the shape you actually need — EDI to XML, flat file to JSON, whatever the downstream system expects — and that translation happens in the Map Editor, which is deep enough to deserve its own post later in this series. I\u0026rsquo;m not exaggerating when I say some of the gnarliest bugs I\u0026rsquo;ve chased started as \u0026ldquo;the map did something weird with a null field.\u0026rdquo;\nA real maps library — this environment alone has close to a thousand of them Mailbox # The file usually lands in a Mailbox — a secure, permissioned drop box inside B2Bi. This is where I see the most confusion, even among people who\u0026rsquo;ve used Sterling for years: File Gateway is not a separate product competing with B2Bi. It\u0026rsquo;s a purpose-built UI and routing layer sitting on top of B2Bi\u0026rsquo;s mailbox and adapter machinery, built specifically so partner file exchange can be managed without anyone having to touch BPML directly (IBM\u0026rsquo;s File Gateway overview is worth reading if this is new to you).\nA typical mailbox tree — shared EDI collection points plus one mailbox per trading partner Database # And underneath all of it sits the Database — every Business Process\u0026rsquo;s state, every document\u0026rsquo;s tracking history, the full audit trail. Easy to take for granted until your first real outage, when document tracking data becomes the only honest record of what actually happened to a file. I\u0026rsquo;ve reconstructed more than one incident timeline purely from that table.\nThe Database Usage dashboard — capacity, backlog, and connection pool health in one place For production environments that can\u0026rsquo;t tolerate downtime, B2Bi also supports multi-node Clustering — worth knowing it exists, not something you need on day one.\nTopology design # Here\u0026rsquo;s the architecture as one picture:\nflowchart TB subgraph Partners[\"Trading Partners\"] P1[\"Partner A\"] P2[\"Partner B\"] end subgraph DMZ[\"DMZ\"] PS[\"Perimeter Server\"] end subgraph Core[\"B2B Integrator Core\"] AD[\"AdaptersSFTP / AS2 / Connect:Direct / HTTP\"] BP[\"Business Processes(BPML Engine)\"] SV[\"ServicesMapping / Validation / Routing\"] MB[\"Mailboxes\"] FG[\"File Gateway(UI layer over Mailboxes)\"] end DB[(\"DatabaseDocument Tracking \u0026 State\")] P1 --\u003e PS P2 --\u003e PS PS --\u003e AD AD --\u003e BP BP --\u003e SV SV --\u003e MB FG -.manages.-\u003e MB BP \u003c--\u003e DB MB \u003c--\u003e DB And here\u0026rsquo;s the same idea as a timeline, since a static diagram doesn\u0026rsquo;t quite capture that this all happens as a sequence of discrete handoffs — useful when you\u0026rsquo;re trying to figure out which log to check first:\nsequenceDiagram participant Partner participant PS as Perimeter Server participant AD as Adapter participant BP as Business Process participant MB as Mailbox participant DB as Database Partner-\u003e\u003ePS: Connect (SFTP/AS2/HTTP) PS-\u003e\u003eAD: Forward file over secure channel AD-\u003e\u003eBP: Trigger Business Process BP-\u003e\u003eBP: Run Services (map, validate, route) BP-\u003e\u003eDB: Log document tracking state BP-\u003e\u003eMB: Deliver file MB-\u003e\u003eDB: Record delivery status Note over Partner,DB: Every arrow above is a pointwhere the file can fail — and a placedocument tracking will show you why That note at the bottom is really the point of this whole post: once you can picture the file\u0026rsquo;s actual path, troubleshooting stops being guesswork. You just walk the diagram backward from where the file stopped.\nSources # I\u0026rsquo;d rather link you to IBM\u0026rsquo;s own documentation than paraphrase it badly, so here\u0026rsquo;s what I drew on for this post — all official IBM Documentation pages, worth bookmarking regardless of whether you read this series:\nSterling B2B Integrator — Overview Architectural Overview Perimeter servers in Sterling B2B Integrator Business Processes Sterling File Gateway — Overview Creating a Sterling B2B Integrator Mailbox Everything else in this post — the framing, the \u0026ldquo;which log to check first\u0026rdquo; advice, the war stories — comes from actually running this stuff in production for the last several years, not from a manual.\nWhat\u0026rsquo;s next # Next up in this series: Adapters vs. Services — the distinction that trips up almost everyone in their first few weeks with Sterling, and the one that actually matters most when you\u0026rsquo;re troubleshooting at 2am.\n","date":"4 September 2026","externalUrl":null,"permalink":"/posts/sterling-b2bi-01-overview/","section":"Posts","summary":"The admin console home page — where every session starts What is IBM B2Bi # IBM Sterling B2B Integrator does one job: move files between your business and your trading partners — banks, suppliers, logistics providers, whoever needs EDI documents, flat files, or XML exchanged reliably and traceably — and know exactly what happened to every file at every step. That’s it. Everything else exists to support that one job.\n","title":"IBM Sterling B2B Integrator: A Quick Architecture Overview","type":"posts"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"Senior Middleware \u0026amp; Infrastructure Engineer with 15+ years in enterprise IT, specializing in IBM Sterling Managed File Transfer (File Gateway, B2B Integrator, Connect:Direct), Linux systems administration, and AWS/Azure cloud infrastructure. Over the last five-plus years, hands-on supporting business-critical MFT environments for a Fortune 500 telecommunications provider, in 24x7 and follow-the-sun production models.\nMy Linkedin Professional Experience # Senior Middleware Engineer May 2024 – Present DXC Technology dxc.com\nLead middleware support for a business-critical Managed File Transfer platform serving a Fortune 500 telecom provider\u0026rsquo;s US customer base, on IBM Sterling File Gateway, B2B Integrator, and Connect:Direct for UNIX. Act as team lead — coordinating priorities, escalations, and incident response, and driving root cause analysis for critical outages within SLA. Manage partner onboarding, ServiceNow change/incident processes, and disaster recovery. Automated Linux health checks with Bash, saving roughly 5 hours/week of manual effort and cutting query latency 20%. Built Power BI dashboards on ticket volume, on-call load, and overtime for leadership visibility, and work directly with IBM Support on product-level investigations.\nMiddleware System Administrator Dec 2021 – May 2024 Kyndryl kyndryl.com\nAdministered the same IBM Sterling File Gateway / B2B Integrator / Connect:Direct stack for the same telecom client, plus Azure infrastructure (Virtual Machines, Storage Accounts, Backup, Network Security Groups, Bastion hosts). Investigated file-transfer failures via Sterling logs and protocol diagnostics, ran root cause analysis on production incidents, and maintained 99.9% availability through DR exercises and 24x7 on-call coverage. Authored runbooks and led knowledge-transfer sessions that cut new-engineer onboarding time by 30%.\nSenior Data Center Technician Jul 2018 – Jul 2021 Amazon Web Services aws.amazon.com\nLed a hardware decommissioning team retiring 1,000+ legacy racks across all company units under strict safety and data-security procedures, contributing to the buildout of Amazon\u0026rsquo;s global cloud infrastructure. Delivered data center rollout projects end to end, conducted technical interviews, and built the interview-question bank and new-hire training program used for hiring.\nData Center Technician Jun 2016 – Jul 2018 Amazon Web Services aws.amazon.com\nInstalled, maintained, and repaired high-density server and network hardware; installed and tested fiber-optic and copper cabling; diagnosed hardware issues on Red Hat Enterprise Linux and Amazon Linux; resolved operational tickets against strict SLA priorities.\nNetwork Administrator Jun 2013 – May 2016 Acrisure Brasil acrisure.com.br\nManaged on-premises and AWS infrastructure (EC2, RDS, S3, Route 53, VPC, Security Groups, CloudWatch, CloudFront) across 10 corporate locations in Brazil. Led a team of four support analysts and the migration of corporate email to Google Workspace, improving average ticket resolution time by 25%.\nSenior Support Analyst Jun 2011 – Jun 2013 Acrisure Brasil acrisure.com.br\nProvided level-2 infrastructure support, administered Active Directory accounts and permissions, supported Windows Server environments, and mentored junior analysts.\nTechnical Support Analyst Nov 2009 – Jun 2011 Hypera hypera.com.br\nSupported office networks, switches, print servers, and ITIL-based incident and service-request processes.\nCertifications # AWS Certified Cloud Practitioner Microsoft Certified: Azure Fundamentals Claude Certified Associate – Foundations (CCAF), Anthropic — Issued Sep 2026 My Credly Education # Postgraduate Certificate in Project Management — Gran Faculdade (Oct 2024 – Mar 2026) Postgraduate Certificate in Cloud Computing — Centro Universitário Senac (Jan 2018 – Dec 2019) Associate Degree in Computer Networks — Centro Universitário UniSant\u0026rsquo;Anna (Feb 2008 – Dec 2010) Languages # Portuguese (native) · English (fluent) · Spanish (intermediate)\n","externalUrl":null,"permalink":"/resume/","section":"Newton Rocha","summary":"Senior Middleware \u0026 Infrastructure Engineer with 15+ years in enterprise IT, specializing in IBM Sterling Managed File Transfer (File Gateway, B2B Integrator, Connect:Direct), Linux systems administration, and AWS/Azure cloud infrastructure. Over the last five-plus years, hands-on supporting business-critical MFT environments for a Fortune 500 telecommunications provider, in 24x7 and follow-the-sun production models.\n","title":"Resume","type":"page"}]