Development
FirecodeOS is being developed through use.
This is a record of what we have built, tested and learned.
FirecodeOS is emerging from the application of technologies that already exist, assembled and used in ways we are still learning how to describe.
The work is moving faster than the language around it.
Rather than force it into familiar categories, we are documenting what we can demonstrate: what we tried, what worked, what failed, what we built, and what we learned.
As the system develops, more of it will become visible.
And, eventually, so will where it is leading.
Chronological record / earliest to current
What happened.
01QR penetration registerSuperseded / View +
Superseded
A QR label connected each physical asset to a live penetration register. The register proved to be the wrong product abstraction; persistent asset identity and continuity survived.
02Document / register-centric architectureSuperseded / View +
Superseded
Development initially centred on maintaining registers and reports. It moved to an authoritative operational record from which those documents are generated.
03Early field inspection platformPartially successful / View +
Partially successful
An authenticated field implementation connected buildings, inspections, camera capture, penetration records, evidence upload and audit writes. It worked far enough to expose where the architecture was not yet trustworthy.
04Camera / authentication service abstractionsAbandoned / View +
Abandoned
Service layers were implemented, found to duplicate behaviour or add no architectural value, and removed.
05Right-aligned Firecode interfaceRejected / View +
Rejected
A right-aligned desktop and mobile interface was prototyped and used. Its reading and interaction model fought normal visual behaviour, informing the simpler direction that followed.
06Public AidanBuilt · Retired / View +
Built · Retired
A public observer environment operated through firecode observe --public, with Aidan as an architectural and engineering guide. It was retired when personifying FirecodeOS began to obscure the system itself.
07Public observer / command-driven organisational interfaceBuilt · Superseded / View +
Built · Superseded
Commands, role assignment, execution, evidence states and a live organisational tour were implemented. The observer model was superseded by clearer representations of the actual system.
08Industrial / 3D organisational worldPrototype · Abandoned / View +
Prototype · Abandoned
An explorable interface combined modules, cubes, terminal interaction, organisational visualisation and observer state. It was technically interesting and unnecessarily complicated.
09Generated organisational world / large panoramaExperimental · Abandoned / View +
Experimental · Abandoned
A large generated representation was explored as a navigable public interface. A static image of a changing organisation became stale and was not the organisation itself.
10Procedural constitutional rendererPrototype · Superseded / View +
Prototype · Superseded
Reusable primitives, deterministic generation, authority flows and browser rendering addressed the static-world problem. The approach was superseded by demonstrating actual FirecodeOS behaviour.
11Camera-first field workflowBuilt / View +
Built
Building → Area / Work Package → Field Session → camera capture → review → structured evidence. It became the first strong demonstration of the actual system rather than a metaphor for it.
12Field Sessions V2Built / View +
Built
Controlled active-session ownership gives field evidence explicit building, area and work-package context instead of treating photographs as detached files.
13Governed software delivery / Mission ControlOperating / View +
Operating
Defined organisational roles and governance boundaries are used across Mission Control, engineering, architecture and review to commission and implement FirecodeOS development.
14Cross-role delegationExperimental · Demonstrated / View +
Experimental · Demonstrated
Work has moved between defined organisational roles without every step requiring manual human orchestration. The capability continues to evolve.
15Constitutional operator modelDeveloped / View +
Developed
Acquire, Store, Retrieve, Communicate, Create, Modify, Relate, Retire, Measure, Compare, Infer, Authorise and Delegate form the constitutional operator set.
16Repository-backed organisational governanceOperating / View +
Operating
Organisational instructions and governance moved into canonical repository-controlled sources rather than depending entirely on transient conversation state.
17Evidence / asset-centric architectureDeveloped · Evolving / View +
Developed · Evolving
Persistent buildings, assets and evidence replaced document-centric records, with provenance, relationships, revision, revocation and durable operational history.
18Deterministic register / report modelDeveloped / View +
Developed
Registers and reports became generated views of canonical operational records rather than independent sources of truth.
19Profession 001 — Fire ComplianceIn development / View +
In development
The first Profession is being developed through real commercial work across inspection, evidence, assessment, registers, reporting, commercial workflows and professional-authority boundaries.
20Professional practice governanceOperating / View +
Operating
Controlled professional-practice documentation, standards and procedures are used in commercial work and provide governed requirements for Profession 001.
21Commercial commissioning / proposal systemOperating outside OS / View +
Operating outside OS
RFQ and commissioning structures, proposals, client appendices, scope rules and commercial treatment operate in practice and are progressively moving into FirecodeOS.
22Production Unit pricingOperating / View +
Operating
A Production Unit model translates operational scope, time and travel into consistent commercial pricing.
23No-access workflowDeveloped / View +
Developed
A failed site-access event produced a workflow for access evidence, responsibility, return attendance and charging—real work generating a new capability requirement.
24Evidence Provenance & AuthenticityIN DEVELOPMENT / View +
IN DEVELOPMENT
Generative imaging demonstrated that visual appearance alone can no longer establish whether field evidence originated within Firecode. FirecodeOS is developing provenance controls to distinguish native capture, imported evidence, derivatives and generated or modified media while preserving the integrity and lineage of original evidence.