Instances

One page per client. Each page has the same sections, in the same order, so you can compare two instances side by side: who the client is, which Jira project and repositories belong to it, how it is deployed, which database it runs on, and how its code differs from master.

The big five is the default set a fix is ported to: master, Jadestone, Medco, JOTRE and Prima Energy. Timas, Tomori and KTP get a fix only when their own work item asks for it.

The name has been reused as the set changed, so an old note can mean a different set. Resolve it by the note's date:

Label	In use	Members
big four	before 2026-09-02	master, Jadestone, Medco, JOTRE
big five (old)	2026-09-02 to 2026-09-13	+ Timas
big six	2026-09-08 to 2026-09-13	+ Prima Energy
big five (current)	from 2026-09-14	master, Jadestone, Medco, JOTRE, Prima Energy — Timas dropped to on-request

So a verification note dated on or before 2026-09-13 that says "big five" means the old five (with Timas, without Prima). "big five" written from 2026-09-14 on means the current five (with Prima, without Timas). Prima Energy joined the default set on 2026-09-08; a page checked before that was not verified on it. Timas left the default set on 2026-09-14; it is still a maintained instance, it just no longer gets a fix unless its own ticket asks.

Comparison

Instance	Jira	Repository	Encrypted twin	Branches on origin	Database	Big five
Jadestone	INA27	ina-jadestone	yes	main, staging, development	MySQL	yes
Medco	INA28	ina-medco-v3	yes	main, staging, development	SQL Server	yes
JOTRE	INA36	ina-jotre	yes	main, staging, development	MySQL	yes
Prima Energy	INA15	ina-primaenergy	no	main, staging, development	MySQL	yes
Timas	INA14	ina-timas	yes	main, development	MySQL	no — left 2026-09-14
Tomori	INA12	ina-tomori	yes	main, development	SQL Server	no
KTP	INA10	ina-ktp	no	main, staging, development	MySQL	no

Which module group each one runs

Commercially INACT is sold as four modules: DMS (document management), ADMS (asset document management), Procurement, and Cost Control & Budgeting. ADMS sits structurally under the DMS (Project) menu, but it is enabled on its own, so an instance can run DMS without ADMS.

In the code every row of ts_modules carries a modules_parent of dms, adms, procurement or budget, and a module shows in the menu only when its own modules_is_installed, its type and its parent are all installed — getModuleList() in reference_function.inc.php. The Reporting menu has three headings (DMS, Procurement, Cost Control & Budgeting); ADMS has no separate report group.

The table below is what each instance's own database actually has enabled, read from the local dev databases (production snapshots) on 2026-09-10.

Instance	Modules enabled
Master	DMS + ADMS + Procurement + Cost Control & Budgeting — all four kept on for QA
Jadestone	DMS + ADMS
Medco	DMS + ADMS
JOTRE	DMS + Procurement
Timas	DMS
Prima Energy	DMS
Tomori	DMS + ADMS
KTP	DMS

ADMS is enabled on master, Medco, Tomori and Jadestone. Tomori is the ADMS implementation itself; the ADMS work had its own one-time change-request space, INA34, but Tomori's project is INA12. On the Jadestone snapshot the adms browse module row is flagged off while ADMS Settings and its asset data (ts_assets) are both present, so only ADMS Settings shows in the menu — this looks like a data slip worth confirming on the live instance. Every other fork carries the ADMS code as fork drift, but it is not enabled and has no asset data.

The Procurement pages therefore describe master and JOTRE, and Cost Control & Budgeting runs on master only. A procurement or budgeting ticket on any other instance starts with switching the modules on.

Where each one runs

Instance	Dev (QA) consumer	Staging deploy	Production
Jadestone	Rumah box, inact-jadestone-encrypted.bdt.dev	jadestone.inactsoft.com, plain repo	Client pulls encrypted main from INARTS themselves
Medco	Lab box, inact-medco-v3-encrypted.bdt.dev and inact-medco-v3-encrypted-testable.bdt.dev	none	Release zip, applied by hand on a box with no internet
JOTRE	Rumah box, inact-jotre-encrypted.bdt.dev	none	Eris pulls encrypted main from INARTS over VPN, by hand
Timas	Rumah box, inact-timas-encrypted.bdt.dev	none	Consumer ssh's edms.timas.com, pulls from INARTS, migrates
Prima Energy	none known	none known	TODO; the repository has no deploy scripts and no workflow
Tomori	Windows Server box, inact-tomori-encrypted.bdt.dev	none	Release zip cut from a tag, applied by hand
KTP	Rumah box, inact-ktp.bdt.dev, updated by hand	none	INARTS server

Three machines carry a self-hosted GitHub Actions runner: the Rumah box, the Lab box on the office LAN, and the Windows Server box, a Windows Server 2022 machine on the office LAN. Every instance except KTP and Prima Energy deploys through GitHub Actions on one of them. The plain repository is the producer: on a push it syncs the code into the encrypted twin and pushes that to GitHub and to the INARTS GitLab. The encrypted twin is the consumer: its own workflow pulls the served checkout and runs phinx migrate. Production is different for every client, see the table.

QA hostnames follow one rule: an instance that ships as an encrypted build gets -encrypted in its QA hostname. The master has one QA site per database driver: inact-mysql.bdt.dev and inact-psql.bdt.dev on the Rumah box, inact-sqlsrv.bdt.dev on the Lab box. All hostnames were read from baseurl in each QA database's inweb_config on 2026-09-06, except Tomori's, which comes from its consumer's deploy README.

How far each fork is from master

Measured on 2026-09-05 against inact at its newest migration, 20260826.

Instance	Module files that differ	Files only in the fork	Migrations only in the fork	Migrations in master the fork lacks	Newest migration
Jadestone	96	6	35	21	2026-08-26
Medco	93	14	39	20	2026-07-16
JOTRE	141	24	27	25	2026-08
Timas	116	4	5	45	2025-12-26
Prima Energy	115	2	5	43	2024-11-28
Tomori	178	10	42	45	2026-08-20
KTP	116	3	0	46	2024-05-02

Read the last two columns together. Timas, KTP and Prima Energy have taken almost nothing from master for a long time, so a port to those two needs more care than the numbers alone suggest.

inweb_config keys against the master seed

Keys in db/seeds/DefaultInwebConfig.php. Master has 107. No fork changes a default value; the differences are keys added or keys never taken.

Instance	Keys	Only in the fork	Missing from the fork
Jadestone	104	2	5
Medco	111	6	2
JOTRE	96	0	11
Timas	92	2	17
Prima Energy	92	0	15
Tomori	99	1	9
KTP	90	2	19

The key names are on each instance page.

What every instance has in common

• Same 54 module folders as master.
• main.php is the ionCube-encoded file in the encrypted twin. The sync never overwrites it and stops if the source changes it, so a change to main.php needs a human to re-encode.
• deploy/ and .github/ are never synced into the encrypted twin. A push that changes only those paths reaches GitHub and INARTS but makes no encrypted commit.
• All access to the database goes through $pdo. The legacy iw_mysql_query throws on every call.