Air-Gapped Automation Delivery Playbook: Lessons from Traditional SI Methods

Automation projects in closed networks tend to fail in a predictable way. The team learns late that a tool cannot do what the business assumed, and the security review rules out options that nobody considered during design. Traditional system integration (SI) methods addressed this class of problem decades ago with analysis-stage deliverables: a requirements specification, an acceptance test standard, a requirements traceability matrix, and a current-system analysis that inventories constraints. This article reconstructs that approach as a short delivery playbook for n8n-based projects. It draws on Korean public procurement guidance and the current National Network Security Framework (N2SF). You will get a four-gate sequence, the deliverable that proves each gate, and the reasoning behind each step.

One-Line Summary

The two recurring problems in these projects are discovering late what a tool can and cannot do, and failing to imagine design options under security constraints. Traditional SI solved both with analysis-stage gates: a requirements specification, a requirements traceability matrix, an acceptance test standard, and a constraint inventory. The Korean public-sector equivalent of a single source of truth (SSOT) for requirements is the NIPA guide on public software project requirements. The current reference for security constraints is the National Intelligence Service (NIS) N2SF Guideline 1.0.

Core Diagram

📐 Original HTML

Key Data

1. Deliverables and Requirements Definition: Korea’s Public SI Procedure (accessed June 10, 2026)

The formal starting point is the National IT Industry Promotion Agency (NIPA) guide titled Software Project Requirements Analysis and Application Guide. It is based on Ministry of Knowledge Economy notice No. 2012-288, which sets general standards for supervising software projects. The full PDF is publicly available for free.

When public software projects prepare a request for proposal (RFP), the guidance requires requirements to be detailed in five categories: functional, performance, system equipment configuration, interface, and data. Visible deliverables such as web pages and front ends fall under functional and interface requirements. That means they are written into the contract before work begins. This matters for automation projects because a front end that is never specified in the contract will surface as a surprise during implementation.

Two further references support the same approach. In 2024, the Ministry of Science and ICT published a guide listing 18 laws and institutional items that public software RFPs must observe. NIPA also published a phased procurement guide based on case studies, which recommends separating the analysis and design phase from the implementation phase. The core pattern is to define the work under a separate contract before building it.

2. Analysis-Stage Deliverables in Traditional SI

The standard analysis-stage deliverables in traditional SI are listed below. Each one exposes a different category of tool limitation early, when changing course is still cheap.

Deliverable	Role	What it would have caught in the Doosan case
Requirements specification	Documents hidden customer requirements from the RFP	“The output is a web front end” documented in week one
Requirements traceability matrix	Maps requirements to implementing functions	The “front-end requirement ↔ n8n implementation not possible” cell is left empty and exposed
Task comparison sheet	Compares contracted tasks with tasks actually performed	Basis for negotiating scope changes
Acceptance test standard	Agrees on acceptance tests in advance	A verifiable definition of done instead of “it works”
Current-system analysis	Surveys the existing environment and constraints	Security policies and an inventory of installable software

3. Security Constraints: Where Korea’s Network Separation Rules Stand Now

The N2SF Guideline 1.0 was released in its full form by the National Intelligence Service at the CSK 2025 event. It replaces the uniform physical and logical network separation approach with a more differentiated framework. The original text is published by the National Cyber Security Center (NCSC), and the NIS press release covers the release.

Under N2SF, networks are classified into three grades: Classified, Sensitive, and Open. Security controls are applied according to grade. The control items span six areas: authorization, authentication, separation and isolation, control, data, and information assets. The number of control items is roughly 260, expanded from the earlier 176.

For project teams, the important point is that the framework is organized around data grade. The question it poses is not whether something is allowed in general. It asks which controls are required for data of a given grade. A conversation framed this way can lead to a workable design where a flat ban would have blocked it.

4. Practical Status of n8n in Closed Networks

n8n supports air-gapped deployment. The usual pattern is to save the Docker image as a tar file outside the network and import it inside. A community write-up documents the same process on an air-gapped Red Hat Enterprise Linux server.

Community nodes are a limitation. In self-hosted deployments they are installed through npm. In a closed network where the npm registry is blocked, they are effectively unusable.

The conclusion is that n8n works in a closed network as a backend workflow engine but not as a complete application stack. Visible web output requires a separate internal web server or static page layer. This separation should appear in the analysis-stage system diagram from the start, not be discovered during implementation.

5. Practitioner Books

The books below are mostly written by practitioners. Korean editions are noted where they exist.

Book	Author	Why it fits this problem
Software Requirements, 3rd ed. (Korean edition)	Karl Wiegers and Joy Beatty	A standard practitioner guide to requirements engineering. Includes a checklist for verifying whether requirements are feasible. Wikibook · Kyobo Book Centre
Software Requirements Essentials (Korean edition)	Karl Wiegers and Candase Hokanson	A condensed version of the book above, built around 20 practical cases. Recommended first for busy practitioners. Kyobo Book Centre
Tongtongtong Project Management (Korean-language book; title romanized)	Kim Byeong-ho (30 years at Samsung SDS; SI project manager at Hana Bank and Industrial Bank of Korea, IBK)	A project management guide written in the vocabulary of Korean SI practice. Covers deliverables and scope negotiation in the Korean context. Kyobo Book Centre
Just Enough Software Architecture (English original; no Korean edition)	George Fairbanks	Risk-driven design. Design and verify the riskiest parts first, which here means tool limits and security constraints. This is the direct prescription for the Doosan case. Amazon
Waltzing with Bears (English original)	Tom DeMarco and Timothy Lister	Register and track tool limits as risk items. A Korean edition, roughly titled Waltzing with Bears, is likely out of print, and no sales link was confirmed in this review. Check secondhand sources. Amazon
Exploring Requirements: Quality Before Design (English original)	Donald Gause and Gerald Weinberg	A classic on interview and workshop techniques for drawing out expectations the customer has not stated, such as visible output, before design starts.

A free supplementary resource is the Inflearn (Korean online learning platform) course Learn the Full SI Project Process for PMs. It is a fast way to review the sequence of SI deliverables in Korea.

Insights

1. Both gaps are symptoms of skipping the analysis stage. The first gap, undefined outputs, corresponds to a missing requirements specification and acceptance test standard. The second gap, weak security imagination, corresponds to a missing current-system analysis, which is the constraint inventory. AI automation did not create this problem. Every SI project that skipped the analysis stage has run into it.

2. The requirements traceability matrix is the early warning system for tool limits. If the matrix mapping requirements to implementation means is filled in during analysis, the moment the cell for “web front-end requirement ↔ n8n” stays empty is the feasibility alarm. It rings in week one of analysis, not in week three of implementation.

3. Treat security constraints as grade-based control negotiation, not a list of prohibitions. Borrowing the N2SF framework of Classified, Sensitive, and Open grades plus the six control areas changes the question. “All external APIs are prohibited” becomes “What grade is this data, and which controls, such as a proxy, an approved gateway, or an import procedure, make it permissible?” The vocabulary used with the security team changes accordingly.

4. The correct architecture for an n8n project separates the engine from the presentation layer. In a closed network, n8n can serve as the workflow engine and nothing more. If visible output is a requirement, a separate presentation layer such as an internal web server, a static page host, or an internal portal widget must appear in the system diagram from the analysis stage.

5. A minimal four-gate playbook for the next project. The gates run in order.

   • G1, define the output. Agree on acceptance criteria at the level of an acceptance test standard.
   • G2, inventory constraints. List installable software, blocking policies, and import procedures.
   • G3, run a feasibility spike. For each empty cell in the requirements traceability matrix, run a one-to-two-day proof of concept to decide whether it is feasible.
   • G4, start implementation after the architecture is fixed.

   Each gate is proven by a single one-page deliverable.

Bottom Line

The evidence supports one conclusion. Feasibility failures in closed-network automation are analysis-stage failures, and traditional SI already has the tools to prevent them. A requirements specification and acceptance test standard make the expected output explicit. A requirements traceability matrix exposes tool limits as empty cells. A current-system analysis turns security constraints into an inventory that can be negotiated by data grade. Applying these four gates before implementation turns the most expensive surprises into cheap week-one findings. The n8n case shows the practical consequence: the workflow engine and the visible front end are separate layers, and both need to be designed on purpose from the start.

Sources

All sources were accessed June 10, 2026.

Primary sources (official)

• NIPA, Software Project Requirements Analysis and Application Guide (based on notice No. 2012-288): https://www.nipa.kr/home/2-8/5437
• NIPA, case-based phased procurement guide for software projects: https://www.nipa.kr/home/2-7-1-1/7089
• NIPA, legal and institutional compliance items for public agency software projects: https://www.nipa.kr/home/2-8/5448
• National Intelligence Service, press release on the full N2SF Guideline 1.0: https://www.nis.go.kr/CM/1_4/view.do?seq=373
• NCSC, N2SF Guideline 1.0 original text: https://www.ncsc.go.kr:4018/main/cop/bbs/selectBoardArticle.do?bbsId=Notification_main&nttId=218022&menuNo=010000&subMenuNo=010300&thirdMenuNo=
• n8n documentation, Hosting: https://docs.n8n.io/hosting/
• n8n documentation, Community Nodes Installation: https://docs.n8n.io/integrations/community-nodes/installation/

Secondary sources (press, community, and practical guides)

• The Electronic Times, guide on legal and institutional items for public software projects (January 2024): https://www.etnews.com/20240103000160
• FESI, 2021 practical guide to writing requirements in public software RFPs: https://www.fesi.or.kr/post/2021-%EA%B3%B5%EA%B3%B5sw%EC%82%AC%EC%97%85-%EC%A0%9C%EC%95%88%EC%9A%94%EC%B2%AD%EC%84%9C-%EC%9E%91%EC%84%B1%EC%9D%84-%EC%9C%84%ED%95%9C-%EC%9A%94%EA%B5%AC%EC%82%AC%ED%95%AD-%EC%8B%A4%EB%AC%B4-%EA%B0%80%EC%9D%B4%EB%93%9C
• ZDNet Korea, N2SF control items expanded from 176 to about 260 (September 2025): https://zdnet.co.kr/view/?no=20250909182304
• Byline Network, national network security framework replacing public network separation (January 2025): https://byline.network/2025/01/30-371/
• Incodom, SI deliverables: https://incodom.kr/%EC%82%B0%EC%B6%9C%EB%AC%BC
• Incodom, analysis-stage deliverables: https://incodom.kr/%EB%B6%84%EC%84%9D%EB%8B%A8%EA%B3%84%EC%82%B0%EC%B6%9C%EB%AC%BC
• DEV Community, installing n8n on an air-gapped RHEL server: https://dev.to/kaustubhyerkade/how-to-install-and-configure-n8n-on-an-air-gapped-rhel-server-47hh
• Google Books, author entry for Kim Byeong-ho: https://books.google.com/books/about/%EA%B3%A0%EA%B0%9D_%EC%A4%91%EC%8B%AC%EC%9D%98_%EC%83%81%ED%92%88%EA%B8%B0%ED%9A%8D%EA%B3%BC_%ED%94%84%EB%A1%9C.html?id=iphUzwEACAAJ
• Amazon, Software Requirements, 3rd ed.: https://www.amazon.com/Software-Requirements-Developer-Best-Practices/dp/0735679665
• Inflearn, free course on the full SI project process for PMs: https://www.inflearn.com/course/pm-si-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EC%95%8C%EC%95%84%EA%B0%80%EA%B8%B0

Note: Exploring Requirements, Waltzing with Bears, and Just Enough Software Architecture are established classics, included in the reading recommendations above. Their individual URLs were not verified in this review. Bibliographic details are stable.