1982年の春頃、早坂から書き出しの10枚の脚本が送られてきて、これを読んだ吉永は企画書ほどの嫌悪感がなく、早坂らしい温かみが滲み出て、殺人を犯した者の哀しみが胸に響いた。岡田以外にも早坂も出演を勧め、また「『細雪』で自分にも魔性みたいなモノがあるのかな」と感じたこともあり、人間の本質的な欲望に触れたドラマはやったことがないし、年齢的にも役の幅を広げて、多少毒のある役にも挑みたいと考えていたこと、日活時代を思い出させてくれる活気のある東映のスタッフとまた仕事をしたいという思いもあり出演を承諾した。出目も吉永の出演を受け「最近、映画監督は恵まれませんから、守備範囲を広げておきませんとね」と監督を引き受けた。「別の女優さんで、いくらでも役に当てはまる人はいると思いますが、吉永さんがやらなければイヤな話になってしまう。割と普通のきれいな女性が辿る薄幸の道。女の闇の欲望やそこから出てくる魔性を描いてみたい。戦後いろんな改革が進んで、女性も強くなり始めて我慢しなくなった。それが昭和30年頃だと思います。今は女性の犯罪も増えていますけど、いろんな意味でモデルになった女性は現代の女性の先駆的な人だと思います」などと抱負を述べた。出目は東映での初演出。
早坂に脚本が移った段階でタイトルが『天国の駅』になったが、タイトル命名は岡田茂東映社長と書かれた文献もある。最初から「HEAVEN STATION」の横文字も副題として付いていたが、当時の文献でもほとんど『天国の駅』のみで「HEAVEN STATION」の無い表記であった。また、2018年現在の日本映画製作者連盟、文化庁日本映画情報システム、東映ビデオのサイトや東映の社史（2016年発行）でも『天国の駅』表記である。しかし2018年のデータベースや文献では『天国の駅 HEAVEN STATION』表記の物もあり混在している。
現・東映会長・岡田裕介が吉永小百合主演で温めていた三年越しの企画。1981年の秋頃、岡田が日本閣事件のモデルとなった小林カウ死刑囚を主人公とする脚本を書き、監督の出目昌伸に「吉永さんの主演で映画化したい」と伝えた。出目は岡田が東宝の俳優時代に世話になった人で、当時はテレビ中心の活動で、東宝時代の黒澤明のセカンドイメージが強い人であった。出目は脚本を読み、「吉永さんの持っているイメージとはあまりにかけ離れていて、出演を受けないだろうし、自分も自信がない」と伝えた。岡田は「脚本は吉永さんから信頼されている早坂暁さんに脚本を頼みます」と言うと出目は「それなら考えさせて欲しい」と返事した。岡田は吉永に『細雪』の撮影の前に、自身の脚本を渡さず、小林カウの資料を含む『ひとりぼっちの死刑台』という題名の企画書を渡した。カウは金の亡者で食事も切り詰め、身体の調子が悪くなってもどした時、それも取っておいて後でおじやにして食べた、警察での取り調べ中、机の下から手を伸ばし刑事の一物を握った等、吉永の理解が出来る、出来ないの範囲を大きく逸脱する女性像に空いた口がふさがらず、岡田に「気分が悪くなった」と伝えた。当時、同じ温泉場を舞台にして人気を博していた『夢千代日記』とはあまりにかけ離れているため、「脚本を読んで答えさせて下さい」と返事を保留した。早坂の脚本が遅いという問題もあり、また1980年代に入り日本映画界を取り巻く状況もどんどん変わり、実現する企画か不透な状況であった。出目も企画は成立しないんじゃないかと考えていたが、岡田は「吉永さんの主演、出目さんの監督で絶対にやりたい」と執念を燃やし早坂に脚本を発注、早坂は二人と違って乗り気だったといわれる。
なおこの概念は、物理的な機構を持つハードウェアに限らない。初期のマイコンではユーザー自身がソフトウェアを作成していたが、今日のパソコンなどのコンピュータのユーザーは既成のソフトウェアを使用するのが普通であり、使用するソフトウェアの内部を理解していることはまれである。つまり、ソフトウェアに関してもブラックボックス化が進んでいると言える。これはソフトウェアの開発者についても言える。特に商用のOSやミドルウェアがアプリケーションソフトウェアに機能を提供するために用意しているAPI群は、開発者に対して仕様は公開しているが内部は公開していないのが普通である。ソースコードを公開していないソフトウェアの内部構造は、逆アセンブルという、非常に高度なスキルを持つエンジニアが膨大な手間と労力をかけてのみ達成できる作業によってしか知ることはできない。Windowsのような巨大なソフトウェアの全貌を逆アセンブルすることは到底不可能であるし、商用ソフトウェアは使用契約によって逆アセンブルを禁止していることが普通である。一方でLinuxのようなオープンソースのソフトウェアでは内部構造も公開しているが、その内容は膨大であるためアプリケーションソフトウェアの開発者が理解することは時間的に困難である。そもそもAPIを介してソフトウェアの機能を利用するだけならば、わざわざ内部の詳細を知る必要はない。結局、商用・非商用を問わず、上位のソフトウェアの開発者は、下位のソフトウェアをブラックボックスとして扱っていることに違いはない。このようなAPI群は、公開された仕様通りに機能する限りは、優れたブラックボックスであると言える。下位のソフトウェアがAPIを介してブラックボックス化されることによって、上位のソフトウェアの開発者は下位のソフトウェアやハードウェアの詳細を理解し、それらを自らの設計に折り込む労苦から解放されるのである。ソフトウェアの発展の歴史とは、このような抽象化の積み重ねの歴史である、と言うこともできる。逆にそのようなOSやライブラリのAPIが仕様と異なる動作をすると、利用しているソフトウェアにとって非常に根の深いバグの原因になりうる。このようなケースは稀なものではなく、また市場で広く利用されているOSやライブラリのバグを修正することは困難であるから、アプリケーションソフトウェアの開発者はバグを回避してAPIを利用する必要に迫られることもある。一方でオープンソースのソフトウェアの場合は、アプリケーションソフトウェアの開発者がソースコードを読んで内部構造を理解してバグを修正するという最終手段を取ることは不可能ではない。もっとも現実には、それができるスキルを持つ技術者や、それに必要な時間を割くことのできる開発組織は限られている。