GoFM — Functional Specification, Phase 1

Jalan Besar Town Council · Estate Management System · v1.3 — 20 August 2026

Covers the 47 Phase 1 functions of the Functions List. The twelve Phase 2 functions — the Estate Inspection (EIS) module and the related items the Functions List places in Phase 2 — are out of scope here and are not specified.

What this document is. It records what the four supplied source documents, the Town Council's own written answers, the material supplied on 4 August 2026, the two contractor screen recordings supplied on 18 August 2026, and the Town Council's written note of changes of 20 August 2026 state about the existing GO FM system and the Phase 1 requirement. It is written for Town Council officers, managers and procurement staff.

What changed in v1.3. The Town Council issued a written note of changes on 20 August 2026, and it is the first source in this project that is the Town Council speaking directly about the system it wants rather than the system it has. It therefore overrides every earlier inference, and it changes eight rules. The largest are: the contractor gets a web portal and creates its own schedule (R1); an overdue job sends an e-mail to the manager or officer in charge, which closes the contradiction that had been open since the first Q&A List (R4); the QR code leaves Phase 1 and is replaced by a GPS comparison against the address, at an administrator-configurable distance defaulting to 100 m, with an NFC tap taking its place in Phase 2 (R8, R9); a photograph whose timestamp precedes the start of work is rejected (R21); video becomes a mandatory evidence type on some checklists (R20); and the contractor's own organisation is defined as three levels with stated permissions (R18). The Town Council also set the priority: contractor management first.

What changed in v1.2. The 18 August recordings are the first sight of the contractor side of the mobile application, which every earlier version had to leave blank. They close screenshot request 1, close the photograph-counter contradiction, and add four rules, R14 to R17. Three functions moved up a grade: L02 to Full, M06 to Full, L04 to Partial. The one thing they change in substance rather than in detail is that the steps of a job are configured per Job Type (R16), which widens what M10 has to deliver.

What it is not. It is a record of requirements, not a system design, not a build plan and not a contract. Nothing in it is a commitment.

0. How to read this document

0.1 The one rule

Every statement carries a source tag. Nothing in this document is inferred, proposed or designed. Where no source states something, the document says so with [NOT STATED] rather than filling the gap.

Two tags are used without a number where the statement rests on the sources collectively rather than on one: [GOFM] for the screenshot set as a whole, including the navigation and the client's own captions, and [REQ] for the requirement document as a whole.

Naming. GO FM is the existing system, as the requirement document names it. GOfm is the name printed on its screens. GoFM is the replacement specified in this document. The tag [GOFM imgN] always refers to a screenshot of the existing system.

Nature of the 4 August material. [IMG_0211] and [IMG_0212] are photographs of a monitor taken with a phone, and [VIDEO] is a phone recording of a monitor, rotated 90 degrees. That is why some values are noted as not legible, or as obscured by a dialog: the limitation is in the capture, not in the system.

Nature of the 20 August material. [TCN] is a short written note, not a transcript, and it is unambiguous — it is quoted verbatim wherever it settles a rule. The three [MEET n] transcripts are Google Meet machine captions of calls conducted in English by non-native speakers; whole sentences in them are garbled. They are used here only where the note already establishes the point, or for dates and commercial context, and never on their own.

Nature of the 18 August material. [CVID1] and [CVID2] are screen recordings made on the device itself, so every label is legible. They are the first and only sight of the contractor side of the mobile application, and they close screenshot request 1 (8.2). Between them they cover sign-in, the Overview, the hamburger menu, the town-council chooser, App settings, the to-do list with its filters, one routine job driven from NEW to the point of submission, the QR scanner and its bypass dialog, the photograph screens, the checklist, the New Issue form, and an issue record.

Values. Text in code style is verbatim from a screen or a document, including any spelling on the screen — a screen typo is marked (sic) so it is not read as an error in this document. Where a screen truncated a value, the truncation is kept (535 UPPER CRO…) rather than completed. Numbers such as 27 or 89.38% are the live values captured, quoted so that Town Council staff can recognise their own system; they are sample data, not requirements. The web and mobile captures were taken on different dates, so the same tile carries different figures in A01 and L01.

Personal data. Town Council operational values are quoted as captured. The contractor company name and contractor personnel identifiers are masked — Contractor A, Worker 1, Worker 2, Contractor A admin — because they are a third party's data and nothing in this specification depends on their identity.

0.2 What this document deliberately does not contain

None of the four original sources, none of the five sources added on 4 August in six files, and neither of the two recordings added on 18 August, contains an API, a database, a data dictionary, a validation rule or a permission matrix. The existing system belongs to a third party and none of its internals was disclosed. Therefore this specification contains no:

• API endpoints, request or response shapes
• database tables, columns, keys or types
• field data types, lengths, formats or validation rules
• state machines beyond the status values actually observed on a screen
• permission matrix per role

Any of those written here would be invented. They can only be settled once the open items in section 8 are answered.

0.3 How much of Phase 1 can be specified from source

Of the 18 marked Full, 16 are captured screens and two — M05 and M07 — are rules the Town Council stated outright rather than screens. The 18 August recordings moved two functions up: L02 from Partial to Full, because the contractor flow is now captured end to end, and M06 from Partial to Full, because the photograph counter is settled (R7). L04 moved from Name only to Partial: the New Issue form and an issue record are captured, the rest of the loop is not.

All 47 functions are identified, phased and traced (section 9). For the 17 marked Name only, what is missing is screen-level detail, and the reason is that no screenshot of them was supplied: of the 16 screenshot requests, one is now fully answered — request 1, the contractor side of the mobile application [CVID1] [CVID2] — and two were partly answered by the 4 August material. Section 8.2 lists what is still needed, against the functions it affects.

Two functions cannot be completed until one contradiction between the sources is resolved: M04 and L05 (question 13 of the Q&A List). Both are specified as far as the sources allow, and are graded in section 9 accordingly. The second contradiction, on the photograph counter, is closed by [CVID1] and [CVID2] — see R7.

1. System context

What the system is for. [REQ §2.1] "The GO FM system is used by both Town Council officers and contractors/vendors." "Contractors use a mobile application to perform scheduled maintenance works." "Jobs include conservancy, horticulture, fire protection, pump maintenance and environmental inspections." "The system records date, time, GPS/location, QR code, photos, checklist and submitted reports."

Why it is being rebuilt. [REQ §3] "Current systems belong to the previous Managing Agent and cannot continue under the new direct management model." · "Enhancements are slow due to third-party dependency." · "Existing systems have workflow and usability limitations." · "Town Council wants flexibility to enhance the systems over time." · "Future AI capabilities can be introduced after the new platform is established."

What Phase 1 is. [REQ §4] "Vendor Management System (contractor workflow only)." · "Officer Estate Inspection (EIS) deferred to Phase 2." · "Vendor mobile application." · "Web portal for Town Council staff and vendors."

Scale. [REQ §5] "Approximately 10+ contractors across conservancy, horticulture, fire protection, pump maintenance and environmental services." [REVIEW] about 60 to 70 users per town council (Property Officers plus managers); five divisions; about seven Property Officers per division; about 19 contractor types, one contractor per job type. [REVIEW] the number of users per contractor company is unknown.

Tenancy. [QA1] "Yes" · "Future possible for other town councils". The system serves Jalan Besar Town Council only; other Town Councils are named as a future possibility and are not in this scope.

The multi-tenant controls present in GO FM are therefore not required in Phase 1: the Town Council report filter and result column [GOFM img2, img4-5], the Town Council / Agency column on Job Types [GOFM img15], the Affected Company column and the Company filter on Public Holidays [GOFM img32], and the Town Council selector on the mobile Overview [MOB img1]. [NOT STATED] Whether they are retained in the data model against the future possibility.

The contractor application carries the same controls, and more of them: a Change TC item in the hamburger menu, and a Choose company partner dialog listing Tanjong Pagar Town Council, EAST COAST TOWN COUNCIL and Jalan Besar Town Council, each with a Set as default radio and an Enter action [CVID2]. The existing application is therefore one application serving several town councils, and a contractor holding contracts with more than one switches between them inside it. Per R15 GoFM is built for Jalan Besar Town Council only: it carries no town-council chooser and no Change TC. A contractor who also works for another town council keeps using that town council's own system for that work.

Retention and security. [REQ §5] "Full audit trail with minimum 7-year retention." [REQ §7] "Secure authentication and audit logging." · "Minimum 7-year data retention." · "Automatic photo/video compression recommended." · "Support both on-premise and cloud deployment." · "Penetration testing required before production." The last two are hosting requirements, not functions, and are not specified here.

2. Actors

[NOT STATED] The complete role list, and the permission of each role on each screen. [QA3] names roles without defining them. Only three role codes appear on any screen: PO [GOFM img31], caAdmin and CT_WK [GOFM img17-21].

[TCN] names the contractor's own three levels — Manager, Supervisor, Worker — and states what each may do (R18). That is the first permission statement of any kind in this project. It also establishes that a contractor allocates its people to zones, so the contractor holds an organisation structure of its own, mapped onto the Town Council's location hierarchy. The Town Council's own staff roles remain [NOT STATED] beyond [QA3].

What [CVID2] adds about the contractor side: a contractor company has more than one user, and routine work is held against an individual worker. The to-do list carries a user filter whose default is a named worker and whose other value is All Users, and the job list header names that worker. [REVIEW] had recorded the number of users per contractor company as unknown; it is now established that there is more than one. [NOT STATED] still, whether the Town Council or the contractor company administers those users — see M02.

3. Rules settled by the Town Council

These are the Town Council's written answers to the Q&A List, and the changes it issued in writing on 20 August 2026. They apply across sections 5 to 7.

Eight rules were changed by [TCN]. R1, R4, R8, R9, R10, R11 and R14 are superseded in whole or in part, and R18 to R23 are new. Each says so in its own row, and the superseded text is kept rather than deleted so that the reason for the change stays visible.

3.1 What the existing system does not enforce — the evidence

The requirement [REQ §5] names "Mandatory checklists and photos are not enforced before submission" as a pain point. Five captures show it, and the fifth is from inside the contractor application itself.

1. [GOFM img17-21] A job reached status Completed with checklist item 5.1 left unticked.

The same job shows section 2. MONITORING STATION with its counter reading 1/0, and section 3. BATTERY CONDITION reading 1/1 — and each of the two carries exactly one photograph, timestamped 26/06/2026 16:52. The sections reading 0/0 carry none. Read as held / required per R7 this is consistent: one photograph held against nil required, and one held against one required. It also means 2. MONITORING STATION required no photograph at all, while section 1. SIMULATED TEST required one and got one. 2. [VIDEO] A second job of Contract Type FIRE reached status Completed with the whole of section 1. QUALIFIED PERSON (items 1.1, 1.2, 1.3) unticked. 3. [REVIEW] "Checklist items are predefined per job type; system does not block submission if items are unchecked" · "No prompt or warning for incomplete checklist items: inspector must self-check". 4. [CVID1] The contractor application offers END while its own mandatory markers are unsatisfied. On the captured Block Washing job the worker ticked one of seven child items, left the parent item * BLOCK WASHING — the one carrying the red mandatory marker — unticked, saved, and took no photograph at all, leaving PHOTOS reading Before 0/1 ,After 0/1 under its own red *. The stepper then showed CHECKLIST & REMARKS as complete and END as available. The recording stops before END is pressed, so it is not proven that the submission would be accepted — what is proven is that the application raises no obstacle and gives no warning up to that point, which is exactly what [REVIEW] describes. 5. [CVID2] Photograph evidence may be chosen from the device gallery (R14): Photo Options offers Camera and Photo Gallery alike. A photograph in the record therefore does not of itself establish that anyone was on site.

And the bypass is easier than a scan (R9): BYPASS sits on the scanner screen, its dialog opens with Invalid QR Code error already selected, so two taps satisfy the QR step [CVID1].

A fourth observation, from the same job [GOFM img17-21]: start recorded LOCATION DETECTED: 54 CHIN SWEE ROAD 160054, matching the job's Area and Property, while Complete recorded LOCATION DETECTED: 33 PARK CRESCENT MULTI STOREY CAR PARK 050033 — a different road and postal code. The existing system provides filters named Correct Start Location and Correct Completed Location on the EIS list [GOFM img25] — a Phase 2 screen. [NOT STATED] whether the routine job list carries the same filters.

[VIDEO] The Town Council also reports the export function is unreliable: "if I click download… this prompt appears then open then you can't see much errors", and [REVIEW] "Download/export function exists but reportedly broken".

4. Domain objects, as observed on screens

Only what appears on a captured screen. No types, no keys, no relations beyond those a screen shows.

4.1 Location hierarchy — five location levels, plus Property and Asset

[GOFM img6, img17-21, img23]

Constituency  →  Division  →  Zone  →  Precinct  →  Area        ‖   Property  →  Asset
└────────────── the five location levels ──────────────┘            └── below Area ──┘

Reports abstract the middle three as Location Level 1, Location Level 2, Location Level 3 [GOFM img2]. Both vocabularies exist in the product, and both appear on the same screen: the Compliance report filters on Constituency, Location Level 1/2/3 and Area, and its result table has a Division column [GOFM img2].

[REVIEW] Blocks are assigned to each Property Officer, who groups them by proximity — "Group 1,2 etc". This is recorded of the officer's EIS inspections, which are Phase 2. [NOT STATED] whether that grouping is a stored object.

[NOT STATED] The number of rows at each level; whether an Area may hold more than one Property; whether an Asset belongs to a Property or to an Area.

4.2 Contract Type — 5 values

CONSERVANCY · HORTICULTURE · ELECTRICAL · PUMP · FIRE [GOFM img15, img17-21]

4.3 Job Type — the contract term

[GOFM img15] [IMG_0211] Columns on the Job Types row, in order:

Job Type · Contract Type · Town Council / Agency (dropped, see section 1) · Job Classification · Frequency · Job Time · Grace Period · Verify Grace Period · Cycle Start By

[REQ §2.1] "Each maintenance activity contains predefined checklists based on contractual frequency (daily, weekly, monthly, bi-monthly, annual, etc.)." A Job Type therefore also carries a checklist — see 4.5.

The Job Type master list holds at least 48 entries [GOFM img7-14] — the slash-separated groups below are separate rows in the list, not single entries: Block Washing · Flush Refuse Chute · Polish Lift Panel · Roof · Grass Cutting · Maintenance Work · Tree Pruning · Arborist Tree Inspection · Electrical Work · Booster Pump · Ejector Pump · Refuse Chute Flushing System · Sump Pump · Transfer Pump · Annual Water Tank Cleaning · Annually - Water Mist System / Sprinkler System / Hosereel System / Generator Sets / Fire Extinguisher / Dry Riser / Hosereel Pump / Sprinkler Pump / Fire Alarm System · Half-yearly - Mech Ventil Sys · Half-Yearly - Generator Sets / Dry Riser · Quarterly - Intercom Handset / Intercom Control / Sprinkler System / Wet Riser / Public Addr System / Generator Sets / Wet Riser Pump / Sprinkler Pump · Weekly - Sprinkler System / Generator Sets / Sprinkler Pump / Fire Alarm System · Monthly - Water Mist System / Wet Riser / Hosereel System / DECAM system / Mech Ventil Sys / Fire Extinguisher / Wet Riser Pump / Hosereel Pump / Fire Alarm System. The dropdown scrolled past the end of the last capture, so the list may be longer.

[NOT STATED] What Verify Grace Period and Cycle Start By hold, and what they affect. [NOT STATED] What Frequency is used for now that R1 removes automatic generation. [NOT STATED] What determines a row's Grace Period, given that it varies within one Contract Type.

4.4 Routine job

[GOFM img17-21] Fields on the job record, by section.

ROUTINE JOB OVERVIEW

LOCATION / FACILITY / ASSET — Division · Zone · Precinct · Area · Property · Asset

The internal identifier appears in the breadcrumb: Jobs > Routines > To Do > Routine Job:4682318 [GOFM img17-21].

Status values observed: New → Started → Completed [GOFM img17-21]. The dashboard counts the same population with a different vocabulary — Outstanding, Schedule, To-Inspect, Verified [GOFM img1]. [NOT STATED] the mapping between the two vocabularies, and whether a status exists between Completed and verified.

[NOT STATED] Where the target completion date of R2 comes from. Job Plan Date, Job Duration and Grace Period are all present as fields, but no source says which one, or which combination, produces it. R2 turns on this.

[NOT STATED] The full status list, including any status for a job graded Unsatisfactory (R10).

4.5 Checklist

[REVIEW] "Checklist items are predefined per job type", so a checklist belongs to a Job Type. [GOFM img17-21] Structure: a heading Facility Name, then numbered sections, each holding numbered items, each item a checkbox; then REMARKS : with a free-text area.

The action history renders the same checklist twice, in two different expansions, and they differ: the Checklist expansion shows the sections numbered (4. SWITCHES) with a checkbox per item [GOFM img21], while the Photos expansion shows one bar per section carrying two numbers and, beneath it, the photographs (SWITCHES, unnumbered) [GOFM img20]. The two blocks below are reproduced from those two expansions separately. Per R7 the two numbers read photographs held / photographs required.

A second checklist shape, from the contractor application [CVID1]. The Block Washing job of Contract Type CONSERVANCY carries a checklist that is two levels, not numbered, on one screen headed Checklist & Remarks:

[ ] * BLOCK WASHING          <- parent item, red mandatory marker
      [ ] VOID DECK
      [ ] APRONS
      [ ] LOBBY AREA
      [ ] COMMON CORRIDORS
      [ ] CORRIDORS
      [ ] MSCP-DECK
      [ ] CARPARK WASHING
REMARKS :
[ free text ]                                              [ SAVE ]

So the structure the editor (M10) has to produce is: a parent that is itself tickable and can be marked mandatory, its children, and one REMARKS field for the whole checklist rather than one per section. The mandatory flag of R6 is visible on a screen for the first time here — a red * against the item — which answers where it shows, though not where it is set.

Photographs hang off the checklist items, not off sections [CVID1] (R17). The Photos screen of the same job lists a job-level total and then every checklist item twice:

*
BEFORE (0/1)  AFTER (0/1)          <- job level, mandatory
VOID DECK          before (0/0)  [camera]   after (0/0)  [camera]
APRONS             before (0/0)  [camera]   after (0/0)  [camera]
LOBBY AREA         before (0/0)  [camera]   after (0/0)  [camera]
COMMON CORRIDORS   before (0/0)  [camera]   after (0/0)  [camera]
CORRIDORS          before (0/0)  [camera]   after (0/0)  [camera]
MSCP-DECK          before (0/0)  [camera]   after (0/0)  [camera]

A job type with no checklist has one bucket instead, Work Done Photo/s (0/0) under TOTAL (0/1) [CVID2]. In both shapes the required count may be nil at item level while the job level still requires one, which is what the captured job showed.

The checklist for Weekly - Fire Alarm System, from the Checklist expansion, with the counters from the Photos expansion shown against each section [GOFM img17-21]:

Facility Name
1. SIMULATED TEST                                              1/1
   1.1  Carry out a stimulated fire alarm call
   1.2  Operate any Alarm Zone
   1.3  Transmit a Fire Alarm Signal to the monitoring station and reset the system
2. MONITORING STATION                                          1/0
   2.1  Contact the monitoring system prior to the transmitting of the fire alarm signal
   2.2  To warn them of the simulated fire condition to be tested
   2.3  Check with them after completion of test to ensure the fire alarm signal was received
   2.4  Advise the monitoring station that the system has been reset
3. BATTERY CONDITION                                           1/1
   3.1  Check the battery voltage
   3.2  Check the battery conditions
4. SWITCHES                                                    0/0
   4.1  Ensure that all switches are in the correct operating condition after completion of tests
   4.2  Take immediate steps to rectify the fault(s) should they exist
5. DEFECTS                                                     0/0
   5.1  Record in the log any fault(s) identified and that the above test has been carried out
REMARKS :

A second checklist, for a FIRE job. Section 1 and section 2 are legible in full in the screen recording [VIDEO]; the same job appears in [IMG_0212], where the right of each line is obscured by the INSPECT dialog:

1. QUALIFIED PERSON
   1.1  All servicing and recharging of fire extinguishers shall only be performed by qualified person
   1.2  Qualified person must belong to companies approved by Singapore Civil Defence Force
   1.3  Carry out maintenance as specified in CP 55:1991
2. FIRE EXTINGUISHERS
   2.1  All fire extinguishers are in their designated & proper places as specified by code of practice
   2.2  All fire extinguishers have not been discharged or lost pressure
   2.3  Access to and visibility of each extinguishers is not obstructed
   2.4  Operating instructions on each extinguishers surface shall be legible and faced outward
   2.5  Pressure gauge readings if any shall be in the operable range
   2.6  Any seals, safety clip or tamper indicators that are broken or missing shall be replaced
   2.7  Any physical damage, corrosion, leakage or clogged nozzle shall be rectified
   2.8  Damaged, broken or rusty fire extinguishers shall be repaired or replaced
   2.9  Keep inspection records for those extinguishers that are found to require corrective actions
   2.10 Submit inspection records to Superintending Officer
   2.11 All extinguishers are to be properly hung
   2.12 Date of service is shown and has not expired
   2.13 The extinguishers shall bear a PSB label
REMARKS:

Per R6 each item carries a mandatory-or-optional flag, and [CVID1] shows how it reads on the phone: a red * beside the item. [NOT STATED] where that flag is set — no capture of the checklist editor has been supplied — and [NOT STATED] whether the items of the two web checklists above are mandatory or optional; on the contractor checklist only the parent BLOCK WASHING carries the marker.

[REVIEW] "Checklist items are predefined per job type". [VIDEO] The recording covers the same ground in conversation — "All these are predefined, right? predefined then basically they will have to check whatever that's been for the check", and "some you don't have access just on the list". [NOT STATED] what access a Property Officer has to change a checklist today. [REQ §5] requires "Town Council self-administration of assignments and checklists" and "Flexible editable checklists" — see M09 and M10.

4.6 Action history

[GOFM img17-21] A log on the captured job, headed Action History, with a Collapse All toggle. [NOT STATED] whether it is append-only, and whether it is visible to the contractor as well as the officer.

Columns: S/No · User Name · Role · Company Name · Action Date/Time · Status · Actions · Details (a chevron; every row expands).

Rows captured, in order, for one real job:

A second job [IMG_0212] shows row 6, user Worker 1, role CT_WK, company Contractor A, 23/07/2026 22:11, status Completed, and LOCATION DETECTED: 205 HENDERSON ROAD HENDERSON INDUSTRIAL PARK 159549. A photograph in the first job's history carries the timestamp 20/07/2026 15:00 [VIDEO].

Two facts the captured history establishes: the job was started by one worker and completed by another — rows 2 to 5 are one user, row 6 Complete is a second user, who is the one named in Job Performed By [GOFM img17-21] — and the QR code was bypassed with a stated reason.

[NOT STATED] The complete list of action names. Five are observed across the six rows — row 1 carries no action, showing ---.

4.7 Issue

No screenshot of the Issue module has been supplied [GOFM]. What other screens and the review establish:

The New Issue form, captured in full [CVID2]. Fields in screen order, with * marking the ones the screen marks mandatory:

*Company · *Address · Level · *Contract Type · *Issue Category · Sub Category · *Property/Asset · *Severity · Response Due Date · Resolution Due Date · Closure Due Date · *Description · Photos

Address is a searchable picker, not a free-text field: typing 83 narrowed a list of full addresses with postal codes. Photos uses the same Camera / Photo Gallery chooser as everywhere else (R14). Values captured: CONSERVANCY · Conservancy · Graffiti / Stains · 83 WHAMPOA DRIVE · Low · Letter box.

An issue record, captured [CVID2]. Description · Issue No (value 566674, six digits, system-assigned) · Contract Type · Level (empty) · Issue Category · Issue Sub-Category · Severity · Created By · Created On. Created By held a contractor worker, confirming the contractor as an originator.

So Issue Category / Sub Category on the form are the same two levels the reports call Defect Category / Defect Subcategory; the record screen calls them Issue Category / Issue Sub-Category. [NOT STATED] which name the new system should use.

[NOT STATED] How the three due dates are arrived at — whether Severity derives them, whether they are editable, and what each one means against the Response and Resolve clocks the reports measure. [NOT STATED] The Response and Resolve targets, in hours or days, and whether the two clocks run independently. [NOT STATED] The Defect Category list. [NOT STATED] The officer-side screens of the loop — assignment, response, resolution and closure — and every state transition. Screenshot request 2 is narrowed, not closed: the contractor's half is captured, the officer's half is not.

4.8 Property and Property Type

[GOFM img23] The Property List table has the columns Name · Type · Serial Code · Serial Type · Referring Attributes · Location, and the screen has a Property Status filter (value Active). The result area reads No Data, so no property record was captured; the columns are all that is known.

[GOFM img24] Property Types — 12 rows, each with Property Type · Type Code · Attributes · Description:

PAVILION / PAV / 0 · SHOP / SHOP / 0 · COMMERCIAL / COMMERCIAL / 0 · ROOF / ROOF / 0 · TOILET / TOILET / 0 · MULTI-STOREY CAR PARK / MSCP / 3 · MULTI-PURPOSE HALL / MPH / 0 · LINK BUILDING / LB / 0 · HAWKER CENTER / HC / 0 · FUNCTION HALL / FH / 0 · CAR PARK / CP / 2 · BLOCK / BLK / 8

The three types carrying attributes — MULTI-STOREY CAR PARK, CAR PARK, BLOCK — are expandable in the tree. [NOT STATED] what those attributes are.

4.9 Public holiday

[GOFM img32] Name · Description · Date · Type of Holiday (value Public on every row) · Affected Company (value JBTC, not required per section 1) · Created On · Created By (value system admin). 90 rows. Replacement days are held as their own rows: Christmas Day 25/12/2026 · Deepavali Replacement 09/11/2026 · Deepavali 08/11/2026 · National Day Replace… 10/08/2026 · National Day 09/08/2026 · Vesk Day Replacement 01/06/2026 (sic — the screen reads Vesk, the row below reads Vesak Day) · Vesak Day 31/05/2026 · Hari Raya Haji 27/05/2026 · Labour Day 01/05/2026 · Good Friday 03/04/2026.

Per R2 this table does not feed the overdue calculation. [NOT STATED] what it is used for in the new system.

4.10 User

[GOFM img31] Name · Login · Position · Role (value PO) · Created (value 15:07 18/08/2021) · Status (value Activated) · Department · Office No. · Company (value Jalan Besar Town Council) · Mobile · Email · Social · Job Group(s) · User Group(s) · Bind Account(s) — the last three empty in the capture.

[NOT STATED] What Job Group(s), User Group(s) and Bind Account(s) hold. Bind Account(s) suggests one person may hold more than one account, but no source says so.

5. Web portal

Per R1 and R22 [TCN] the web portal has two audiences, not one. [REQ §4] had always said "Web portal for Town Council staff and vendors", and until 20 August 2026 no source said what a vendor would do on it. [TCN] answers: "Contractors also have access to the GoFM portal to create the schedule", and a contractor Manager creates, edits and deletes that schedule and sees the KPIs and the status of the work (R18). A contractor Supervisor sees the KPIs and his workers' work.

So every screen below has to be read twice — once as an officer sees it and once as a contractor does — and what separates them is role permission, which is the largest [NOT STATED] in this document (M02). The screens [TCN] names for the contractor are the schedule (M03), the KPIs (A01, M11) and the status of the work (F01, F02). [NOT STATED] whether a contractor reaches any other screen, and whether it sees only its own rows on the ones it reaches. No screenshot of the existing portal as a contractor sees it exists — every capture in [GOFM] is an officer's.

5.0 Navigation

[GOFM] The navigation as printed in the existing application, with the Phase 2 items removed:

Dashboard
PO Dashboard
Accounts       → My Profile · My Company · Duty Assignment
Locations      → Location List
Facilities     → Property List · Asset List · Settings → Property Types · Asset Types
Contracts
Jobs           → Routines → To Do · Review RoutineJob
                 Issues
                 Settings → Job Types · Defect Category · Job List
Reports        → Routine → Compliance · Timeliness · PO Verification · Job Checklist · Follow Up List
                 Issues  → KPI Report
Systems        → Public Holidays
Top-right      → the signed-in user's name as a dropdown · a power icon

Out of scope for Phase 1: Jobs › EIS and Reports › EIS, deferred by [REQ §4] "Officer Estate Inspection (EIS) deferred to Phase 2"; and Accounts › Leave Form, Locations › Geo-Position Track and Reports › Location, which the requirement document does not mention at all and which carry the phase agreed with the Town Council (Functions List B04, C02, J10, J11).

[IMG_0211] confirms Jobs › Settings holds exactly three items; [VIDEO] confirms Reports › Routine holds exactly five.

Two spellings exist in the product. The sidebar reads Reports › Routine and Reports › Issues; the on-screen breadcrumb reads Reports > Routines > and Reports > Issue > [GOFM img2, img3, img4-5]. This document uses the sidebar spelling in each function's Path line and quotes the breadcrumb where it is the source.

[NOT STATED] Where the officer creates a routine job (R1) sits in this navigation. No captured screen shows a job being created — screenshot request 3.

A01 · Routine dashboard — Full

Path Dashboard · Source [GOFM img1]

Captions the client put on the screenshots [GOFM]: "Town Council's Dashboard Showing Vendor's Servicing Performance" and "Town Council's Dashboard Displaying Work Scheduled by Vendors".

One of three columns on the Dashboard, headed ROUTINE, with its own filter row and an expand icon.

Both indices are reported against the same KPI: 80% target. [NOT STATED] How COMPLIANCE INDEX and ON-TME INDEX are calculated. [QA12] answered "See video"; the recording shows the report but no formula. Screenshot request 15 asks for a monthly KPI report as issued to management. [NOT STATED] Whether the KPI: 80% target is configurable.

A02 · Issue dashboard — Full

Path Dashboard · Source [GOFM img1]

The second column, headed ISSUE, with its own filter row and expand icon.

The existing Dashboard carries a third column, EIS — Phase 2, not in scope [REQ §4].

[NOT STATED] The Defect Type value list, and how the Issue compliance index is calculated.

A04 · Notice — Partial

Path Dashboard · Source [GOFM img1] [MOB img1]

A panel below the dashboard columns, titled Notice, carrying a ... menu. Empty in the capture. The same panel appears on the mobile Overview, where it reads No notice [MOB img1].

[NOT STATED] What a notice is, who writes one, what the ... menu offers, and whether notices are targeted at particular users. This is screenshot request 16.

A05 · PO Dashboard — Name only

Path PO Dashboard · Source [GOFM img1] navigation

A top-level navigation item, distinct from Dashboard. No screenshot has been supplied.

[NOT STATED] Everything. This is screenshot request 7.

B01 · My Profile — Full

Path Accounts › My Profile · Source [GOFM img31]

Four cards. Fields as listed in 4.10.

[NOT STATED] Which fields the user may edit; only Name shows an edit affordance.

B02 · My Company — Name only

Path Accounts › My Company · Source [GOFM img1] navigation

No screenshot has been supplied. [NOT STATED] Everything. Screenshot request 12.

B03 · Duty Assignment — Name only

Path Accounts › Duty Assignment · Source [GOFM img1] navigation

No screenshot has been supplied. Related requirement [REQ §5]: the pain point "Block/officer assignments require vendor intervention" and the requirement "Town Council self-administration of assignments and checklists". [REVIEW] "Blocks assigned to each PO; PO groups blocks by proximity for efficiency. Group 1,2 etc."

[NOT STATED] The screen, its fields, and whether an assignment is per block, per area or per division. Screenshot request 8.

B05 · User menu and sign out — Partial

Source [GOFM] every web screen · [MOB img1]

Top right of every web screen: the signed-in user's name as a dropdown, and a power icon. On mobile the header carries the avatar, the user name, a bell icon and a hamburger menu.

[NOT STATED] What the name dropdown contains.

C01 · Location List — Name only

Path Locations › Location List · Source [GOFM img1] navigation

No screenshot has been supplied. The hierarchy it maintains is known from other screens — see 4.1. No section of the requirement document describes it.

[NOT STATED] The screen, its fields, and how a level is added or moved. [NOT STATED] How master data first enters the system, and whether it is maintained through the portal thereafter. Screenshot request 14.

D01 · Property List — Full

Path Facilities › Property List · Source [GOFM img23]

The result area reads No Data in this capture.

[NOT STATED] What the scope select own means, and what Referring Attributes holds.

D02 · Asset List — Name only

Path Facilities › Asset List · Source [GOFM img1] navigation

No screenshot has been supplied. What is known: an asset is the object a routine job is performed against, and the job detail carries an Asset field with the value 54_CSR_FIRE_FAS [GOFM img17-21]. [NOT STATED] how an asset code is composed.

[NOT STATED] The screen, and every field on an asset. Screenshot request 14.

D03 · Property Types — Full

Path Facilities › Settings › Property Types · Source [GOFM img24]

A left tree listing each type, and a table with Property Type · Type Code · Attributes · Description. The 12 rows are in 4.8.

[NOT STATED] The attributes behind the three expandable types, and how an attribute is defined.

D04 · Asset Types — Name only

Path Facilities › Settings › Asset Types · Source [GOFM img1] navigation

No screenshot has been supplied, though it sits beside Property Types in the same Settings group. [NOT STATED] Everything. Screenshot request 14.

E01 · Contracts — Name only

Path Contracts · Source [GOFM img1] navigation

A top-level navigation item. No screenshot of the submenu has been supplied, so its contents are unknown.

What is known: Contract Type is a field on every Job Type [GOFM img15] and on every routine job [GOFM img17-21], with five values (4.2). [REQ §5] "Approximately 10+ contractors across conservancy, horticulture, fire protection, pump maintenance and environmental services." [REVIEW] about 19 contractor types, one contractor per job type (R13).

Per R5 there are no Liquidated Damages terms to hold.

[NOT STATED] What a contract record contains, whether it has a period, and how a contractor company is registered. Screenshot request 5.

F01 · To Do — routine job list — Full

Path Jobs › Routines › To Do · Source [GOFM img6] [VIDEO]

One tab, labelled My Routine.

Rows captured [GOFM img6]: CONSERVANCY / Flush Refuse Chute / KRETA AYER - KI… / ZONE 9 / KKR3P1 / 51 CHIN SWEE R…; the same job type at ZONE 9 / KKR9P1 / 535 UPPER CRO…; CONSERVANCY / Polish Lift Panel / ZONE 10 / KKR1P2 / 96 HAVELOCK R…. [VIDEO] shows the same screen filtered to Status: Complete and Contract Type FIRE across ZONE 5 and ZONE 6.

[NOT STATED] The Date Type value list — only Scheduled Date is observed. [NOT STATED] The full Status value list. [NOT STATED] What the checkbox column enables; no bulk action was captured. [NOT STATED] Whether the tab label My Routine implies other tabs. [NOT STATED] How the Contractor of a routine job is set — see R13.

F02 · Routine job detail — Full

Path Jobs › Routines › To Do › Routine Job:<id> · Source [GOFM img17-21]

Breadcrumb reads Jobs > Routines > To Do > Routine Job:4682318. A print action. Two field sections plus the action history (F03). Fields are in 4.4.

[NOT STATED] What the comment affordance beside Routine Job No does. [NOT STATED] Whether the sections are editable, and by whom.

F03 · Action history — QR, GPS, photo and checklist evidence — Full

Path within F02 · Source [GOFM img17-21] [IMG_0212] [REQ §2.1]

[REQ §2.1] "The system records date, time, GPS/location, QR code, photos, checklist and submitted reports." Structure, columns, rows and expanded details are in 4.6.

Two conditions occurred on the one captured job (3.1): a QR code bypassed with a reason, and a completion location that differs from the start location. The existing system provides filters named Correct Start Location and Correct Completed Location on the EIS list [GOFM img25], a Phase 2 screen. [NOT STATED] whether the routine job list carries the same filters, and [NOT STATED] how either condition is surfaced to the verifying officer.

F04 · Officer verification of a routine job — Full

Path within F02, on a completed job · Source [IMG_0212] [GOFM img17-21] [QA10] [REVIEW]

[REQ §5] requires an "Officer verification workflow with approval/rejection". What the system actually does:

1. On a job at status Completed, the action history's Complete row carries a Remarks field and a green INSPECT button [GOFM img17-21].
2. INSPECT opens a modal titled INSPECT [IMG_0212] containing: - * Grading : — a required radio pair. The existing system reads Satisfactory and Unsatisfactory; per R10 [TCN] the new system reads passed and failed — "officers can validate the work on web portal and give passed/failed" - Remarks : — a free-text area, placeholder Enter remarks... - Cancel and Submit
3. On the captured job, which has not been inspected, Job Inspected and Job Inspected By read --- [GOFM img17-21]. No capture of an inspected job has been supplied, so [NOT STATED] what those two fields hold afterwards.
4. Per R10 the system does not notify the contractor: [QA10] "if PO found defects, PO will call contractor to inform to fix. No push notification or LD". [REVIEW] "No in-system rejection flow: if work is unsatisfactory, PO contacts contractor directly via WhatsApp."

The dashboard counts the two sides of this separately — By PO / TO-INSPECT and VERIFIED [GOFM img1].

[TCN] places this function in the first delivery. Its closing instruction reads "Focus first on Contractor management" and names three things: the contractor's mobile application, the contractor's web portal, and — this function — "When contractor finished the work, officers can validate the work on web portal and give passed/failed". So the loop the Town Council wants working first is: contractor does the work on the phone, officer passes or fails it on the web.

[NOT STATED] What happens to a job after a grading of Unsatisfactory — whether it reopens, holds a distinct status, or closes. [REVIEW] records that this is unclear in the existing system too: "Unsatisfactory option exists but behavior after selection is unclear" · "Unsatisfactory job outcome: no clear workflow after flagging". [NOT STATED] Whether raising an Issue is linked to the grading or is a separate act.

F05 · Review RoutineJob — Name only

Path Jobs › Routines › Review RoutineJob · Source [GOFM img1] navigation

No screenshot has been supplied. Its position beside To Do, and the dashboard tile By PO / TO-INSPECT [GOFM img1], suggest an officer verification queue, but no source states that.

[NOT STATED] Everything. Screenshot request 6.

G01 · Issue and defect handling — Partial

Path Jobs › Issues · Source [GOFM img1, img4-5] [REVIEW] [REQ §2.1] [MOB]

No screenshot of the Issue module has been supplied. Everything known is in 4.7.

Its Phase 1 position rests on [REQ §2.1], where Town Council officers "raise defects", and on [MOB], where the contractor is notified when work is found to have defects. [NOT STATED] — [REQ §5] does not name an Issue module, and no source states how an Issue relates to a routine job graded Unsatisfactory.

[NOT STATED] Every screen and every field of the issue loop; the Response and Resolve targets; the Severity and Issue Status value lists. This is screenshot request 2, a Must.

I01 · Job Types — Full

Path Jobs › Settings › Job Types · Source [GOFM img15] [IMG_0211] [GOFM img7-14]

A Contract Type filter (value All Types), row selection by checkbox, and the columns listed in 4.3 — nine as captured, of which Town Council / Agency is not required per section 1, so eight plus the selection checkbox. Values observed and the master list are both in 4.3.

[NOT STATED] The checklist editor behind a Job Type — see M10, screenshot request 4. [NOT STATED] Verify Grace Period and Cycle Start By.

I02 · Defect Category — Name only

Path Jobs › Settings › Defect Category · Source [GOFM img1] navigation, [VIDEO]

No screenshot has been supplied. Known to be two levels deep, because both Defect Category and Defect Subcategory are filters and result columns on the Issue KPI report [GOFM img4-5].

[NOT STATED] The category list and the screen. Screenshot request 13.

I03 · Job List — Name only

Path Jobs › Settings › Job List · Source [GOFM img1] navigation, [VIDEO]

No screenshot has been supplied. [IMG_0211] confirms it is the third item in Jobs › Settings, beside Job Types and Defect Category.

[NOT STATED] Everything, including how it differs from Job Types. Screenshot request 13.

J01 · Compliance — Full

Path Reports › Routines › Compliance Report · Source [GOFM img2] [VIDEO]

[VIDEO] The Job Type filter is a multi-select whose options are prefixed with the Town Council code: JBTC Block Washing, JBTC Flush Refuse Chute, JBTC Polish Lift Panel, JBTC Roof.

[NOT STATED] The columns of the second block. [NOT STATED] How Completed % and Not Completed % are calculated.

J02 · Timeliness — Name only

Path Reports › Routine › Timeliness · Source [GOFM img1] navigation, [VIDEO]

No screenshot has been supplied — neither filters nor result columns. The Dashboard carries a gauge labelled ON-TME INDEX (sic) [GOFM img1]; [NOT STATED] whether the two are related.

[NOT STATED] Everything. Screenshot request 10.

J03 · PO Verification — Partial

Path Reports › Routines › PO Verification Report · Source [GOFM img3]

Filters: the same block as J01, plus PO Name. Action List — no export icon was shown. The result table was not rendered in the capture.

[NOT STATED] The result columns. Screenshot request 10.

J04 · Job Checklist — Name only

Path Reports › Routine › Job Checklist · Source [GOFM img1] navigation, [VIDEO]

No screenshot has been supplied. [NOT STATED] Everything. Screenshot request 10.

J05 · Follow Up List — Name only

Path Reports › Routine › Follow Up List · Source [GOFM img1] navigation, [VIDEO]

No screenshot has been supplied. [NOT STATED] Everything, including what is being followed up. Screenshot request 10.

J06 · KPI Report — Full

Path Reports › Issue › KPI Report · Source [GOFM img4-5]

The result area reads No Data in the capture.

[NOT STATED] The columns past the right edge. [NOT STATED] The Response and Resolve targets these percentages are measured against. Screenshot request 10.

K01 · Public Holidays — Full

Path Systems › Public Holidays · Source [GOFM img32]

Filters Start Date to End Date, a Company select — not required per section 1 — and a search button. Columns and rows in 4.9. Row and bulk selection by checkbox. Pagination reads Total 90, 10/page, pages 1 to 9, with a Go to control.

Per R2 this table does not feed the overdue calculation. [NOT STATED] What it is used for in the new system.

6. Mobile application

[MOB] "This is used by vendors/contractors & Town Council inspectors." · "There should be login using email address and password."

Two sets of captures exist, one per persona.

The officer side: three screenshots. One is the Overview [MOB img1], which both personas share and which is specified below as L01; the other two are the officer's EIS flow [MOB img2-3], which is Phase 2. [MOB] had stated the gap outright — "The following screenshots are from inspectors's perspective. Screenshots are from vendor's perspective are not available yet."

The contractor side: two screen recordings supplied on 18 August 2026, [CVID1] and [CVID2], which close that gap and screenshot request 1. They are the source for L02 and for the contractor half of L04, and they raised R14 to R17. [REVIEW] had added that in practice "Mobile app used almost exclusively for EIS inspections by PO and contractors".

Two conventions the contractor recordings establish across every screen [CVID1] [CVID2]:

• A red * marks a mandatory step or field, and it appears on the Photos screen, the Work Done Photos screen and the checklist parent item.
• The stepper circle carries the state: hollow means not reachable yet, filled blue means available now, filled green means done. That is how a worker knows what is left — there is no text status per step.

Per R11 GoFM's application is online only, although the existing one is not.

Per R15 there is no town-council chooser and no Change TC; the hamburger menu of the existing application holds New Issue, Change TC and Settings [CVID2], of which the middle one is not built.

L01 · Overview dashboard — Full

Source [MOB img1] [MOB]

[MOB] "Dashboard will show the list of to-do, status & completed" — stated for both the contractor and the inspector.

The EIS card on this screen and the EIS tab in the bottom bar are Phase 2 [REQ §4].

The figures on this capture differ from those on the web Dashboard (A01) because the two captures were taken on different dates.

The contractor's version of the same screen [CVID1] [CVID2]. It is the same layout with the officer's half removed and the EIS card gone:

So the middle tab is the persona switch: Routine for the contractor, EIS for the officer. The contractor's Completed figure is a gauge showing a percentage, where the officer's is a count. The hamburger menu holds New Issue · Change TC · Settings [CVID2].

[NOT STATED] Whether an officer's Routine tab exists alongside the EIS tab, since the officer must also reach routine jobs to verify them (L03). Neither capture shows a four-tab bar.

L02 · Contractor job execution — Full

Source [CVID1] [CVID2] — the contractor flow, captured end to end · [REQ §2.1] [MOB] [GOFM img17-21]

[REQ §2.1] "Contractors use a mobile application to perform scheduled maintenance works." · "Contractors scan a QR code to start work, complete the checklist, upload photographs and reports, then scan again to complete the job." [MOB] "They use this to update their work, take photo for evidence."

One statement in [REQ §2.1] is not borne out by the recordings: the worker does not scan again to complete the job. There is one QR step, near the start. END carries no scan [CVID1].

The screens, in the order a worker meets them

1 · Sign in [CVID1] — the GOfm wordmark, a user field, a password field with a reveal action, Forgot Password ?, and Sign In. A username, not an email address, and no one-time password: the account signed in with a plain username and password. [MOB] had asked for "login using email address and password" and R12 adds a one-time password from an authenticator — so both are new requirements against what the existing application does, not descriptions of it. See M01.

2 · Overview — L01, contractor variant.

3 · To-do Routines [CVID1] [CVID2] — reached from the Routine tab. Three tabs, and they are not the officer's two:

Under the tabs one filter row, all on one line: Total: N · a Job Type picker (All Job Type, and the values Block Washing, Flush Refuse Chute, Polish Lift Panel, Roof) · a user picker (All Users, or a named worker, which is the default). Both pickers are bottom sheets closed with DONE.

The list is grouped by location, not flat. Each row is a location carrying a job count and a download action:

81 WHAMPOA DRIVE          1 Jobs     [download]
97 WHAMPOA DRIVE          1 Jobs     [download]

Per R11 the download action is not built. [NOT STATED] what it downloads today.

4 · The location's jobs [CVID1] — tapping a location opens a card headed by the location and its job count, then one block per job:

81 WHAMPOA DRIVE                                    1 Jobs
Block Washing                                  13 Aug 2026
Facility: 81 WHAMPOA DRIVE                        Execute
Status: New

So the action that opens the job is labelled Execute, and the job line carries Job Type, date, facility and status.

5 · The job [CVID1] — header: back · Job · an add action. Then a top card:

Inspection state is the same label the officer's EIS job uses [MOB img3], so the two personas share the field. [NOT STATED] what the comment affordance opens, and the full value list of Inspection state.

Beneath the card, the vertical stepper. For Block Washing:

That last column is the evidence in 3.1 item 4: END became available while PHOTOS still read 0/1 under a mandatory * and the mandatory checklist parent was unticked.

6 · START — stamps the step with a date and time to the second, and moves Inspection state from NEW to START [CVID1]. Per [GOFM img17-21] the web action history records LOCATION DETECTED: <address> against it.

7 · UNLOCK VIA QR CODE [CVID1] — a full-screen camera with a torch toggle and a BYPASS button centred beneath it. BYPASS opens Bypass reason: — Invalid QR Code error (pre-selected) · Missing QR Code · Damage QR Code · Others, a free-text box, CANCEL / SUBMIT. On submission the step turns green, indistinguishable in the stepper from a real scan. See R9.

8 · PHOTOS [CVID1] — per R17: a job-level BEFORE (0/1) AFTER(0/1) under a red *, then every checklist item with a before and an after control, each with its own counter. Reproduced in 4.5. Photographs come from Camera or Photo Gallery (R14).

9 · CHECKLIST & REMARKS [CVID1] — the two-level checklist of 4.5, one REMARKS : free-text area for the whole job, and a full-width SAVE. Saving turns the step green and does not validate the mandatory marker.

10 · END — not pressed in either recording. Per [GOFM img17-21] the completion writes LOCATION DETECTED: <address> and a Remarks field, and hands the job to the officer for verification (F04). [NOT STATED] what END asks for on the phone — whether it takes its own remark, its own photograph, or a confirmation.

What [TCN] changes in this flow

So the captured UNLOCK VIA QR CODE step and its bypass dialog are not built. They remain in this document because they are the evidence in 3.1 for why the Town Council is replacing the product, and because Phase 2 puts a presence check back in the same position in the stepper.

[TCN] also names this application first in the delivery order: "Focus first on Contractor management : Mobile app for contractors, Web portal for contractors, When contractor finished the work, officers can validate the work on web portal and give passed/failed."

The stepper is configured, not fixed

Per R16, a second job type in [CVID2] runs a different stepper on the same screen:

This is the single most consequential thing the recordings establish: the job execution screen is a renderer over a per-Job-Type definition. What that definition has to hold — which steps, whether QR is required, the checklist tree, and the required photograph count at job and item level — is what M10 and I01 must let the Town Council maintain, and it is why R16 and R17 exist.

[NOT STATED] The full list of step types available, beyond the six observed (START, UNLOCK VIA QR CODE, PHOTOS, CHECKLIST & REMARKS, REMARKS, WORK DONE PHOTOS, END).

Carried over from the web evidence

What the web action history records for the same flow [GOFM img17-21]:

The captured job was started by one worker and completed by another (4.6), and [CVID2] establishes that a contractor company has several users and that work is held against a named one. [NOT STATED] whether the application constrains a job to one device or one user; nothing in either recording addresses it.

Per R11 the application is online only, with photograph upload deferred until the phone has signal, so a pending-upload state exists on this flow. [NOT STATED] how it is presented — neither recording was made without signal.

L03 · Officer verification of contractor work — Name only

Source [REQ §2.1] [MOB]

[REQ §2.1] "Town Council officers use the same mobile application to … verify contractor work." [MOB] "They use this to check the work of vendors/contractors to determine whether the work is properly completed or any defects. Notify the vendors/contractors any open issues." The Overview carries the officer side as the Routine card's PO: TO-DO block, counting Completed and Verified [MOB img1].

No screenshot of an officer verifying a routine job exists; the two officer screenshots are the EIS flow.

[NOT STATED] The screen. Whether the grading of F04 / R10 appears identically on mobile is not stated by any source.

L04 · Issue — Partial

Source [CVID2] · [MOB img1] [MOB img3]

Four appearances: the Issue item in the bottom tab bar [MOB img1] [CVID1], the Issue card on the Overview [MOB img1] [CVID1], an Issue tab on the officer's job screen [MOB img3], and New Issue as the first item of the contractor's hamburger menu [CVID2].

What is captured [CVID2]. The contractor raises an issue from the phone. Two screens exist in full and both are reproduced in 4.7: the New Issue form, with its thirteen fields, its searchable Address picker, its three due dates and its Photos control; and an issue record, with Issue No, the two category levels, Severity, Created By and Created On.

Two things follow. The contractor is an originator of issues, not only a recipient of them — [REQ §2.1] names only the officer raising defects, and [REVIEW] describes the loop as "PO raises defect, contractor rectifies, PO closes after verification". And New Issue is a menu action, not a tab action: it is reached from the hamburger, while the Issue tab shows the list.

[NOT STATED] The issue list screen behind the Issue tab, and every officer-side screen of the loop — assignment, response, resolution, closure — and every state transition between them. Screenshot request 2 is narrowed to the officer's half.

L05 · Notifications — Name only

Source [MOB] [QA2]

[MOB] For the contractor: "They will get notification from the town council — if the work is found to have defects — reminder of deadline or target work date & time." For the inspector: "They will get notification from the town council — reminder of open to-do or deadlines." A bell icon sits in the mobile header [MOB img1]. No notification screen was captured.

Per R3 device push is out of scope. [NOT STATED] what remains — whether the bell opens an in-application list, and what that list holds.

R4 is now resolved and it does not resolve this function. [TCN] settles that an overdue job sends an e-mail to the manager or officer in charge (M04). E-mail is not this screen. So the question this function turns on has narrowed rather than closed: the bell exists in the header [MOB img1] [CVID1], and [NOT STATED] whether it opens an in-application list at all, or whether e-mail is the only channel and the bell is decorative. Device push stays out of scope per R3.

7. Functions stated only in the requirement document

No screen exists for any of these. Each is a line of [REQ] text, plus whatever the Town Council has since answered.

M01 · Sign in with email address and password — Partial

[MOB] "There should be login using email address and password." [REQ §7] "Secure authentication and audit logging." The mobile sign-in screen is now captured [CVID1]; no web sign-in screen is — screenshot request 11 is narrowed to the web.

What the mobile screen holds [CVID1]: the GOfm wordmark, a user field, a password field with a reveal action, Forgot Password ?, and Sign In. Two gaps against the requirement follow:

• The field takes a username, not an email address. [MOB] asks for email; the existing application does not use it.
• There is no one-time password step. The captured sign-in went straight from password to the Overview.

So R12 — one-time password, 14-day session lock, administrator reset — describes what the Town Council asked for, not what exists. It is new build on both channels, and Forgot Password ? is the only account-recovery affordance the existing application shows.

Per R19 [TCN] there are two sign-in paths, and nobody self-registers.

Per R12 [REVIEW] a session locks automatically after 14 days of inactivity and an administrator can reset a user's one-time password. [NOT STATED] how the password and the authenticator code are sequenced, and on how many screens. [NOT STATED] whether the Microsoft path is a true single sign-on or the e-mail address is merely the user name.

[NOT STATED] Which authenticator application, whether OTP applies to contractor users as well as Town Council users, password policy, and what the locked-session state looks like.

M02 · User and role administration — Partial

Implied by the fields on My Profile — Login, Role, Status: Activated, and the three panels Job Group(s), User Group(s), Bind Account(s) [GOFM img31] — for which no administration screen was captured. Screenshot request 9.

[QA3] "See video. Admin, PO, PM, manager etc". Role codes on screen: PO, caAdmin, CT_WK. Scale from [REVIEW]: 60 to 70 users, five divisions, about seven POs per division, about 19 contractor types. Per R12 this screen also resets a user's one-time password.

Per R18 [TCN] the contractor half of the role model is now settled — Manager, Supervisor and Worker, with the permissions listed in section 2. Two consequences for this function. It administers two populations with different sign-in paths (R19): staff on a Microsoft e-mail created by an administrator, contractor users on their own password plus an authenticator, also created by an administrator. And it must let a contractor Manager allocate supervisors and workers to a zone — so permission here is location-scoped, not a flat role, and it is delegated: a contractor administers its own people within its own contract.

[NOT STATED] The Town Council's own staff role list and the permission of each one — now the single largest gap in this specification, since the contractor half is answered. [QA3] gave only "Admin, PO, PM, manager etc", and role codes on screen are PO, caAdmin and CT_WK. [NOT STATED] Whether a Town Council administrator creates a contractor Manager, or the contractor does.

M03 · Calendar-based contractor scheduling — Partial

[REQ §5] requirement: "Calendar-based contractor scheduling." Pain points: "No proper calendar to proactively monitor scheduled and overdue work" · "Scheduling is rigid and difficult to manage."

Per R1 [QA6] "Jobs are generated by PO, not automatic" — the Property Officer creates each routine job. [NOT STATED] on what screen, whether a calendar is involved in creating it, and how the contractor is set; [REVIEW] states one contractor per job type but describes automatic assignment only for an issue (R13), and the routine job list carries a Contractor filter (F01).

Per R1 and R22 [TCN] there are two schedules, and the contractor owns one of them. [TCN] lists Officer Schedule and Contractor Schedule as separate items, and states "Contractors also have access to the GoFM portal to create the schedule". A contractor Manager may create, edit and delete a schedule (R18). Visibility is by role. So this function is now two screens on two portals — the officer's and the contractor's — rather than one officer screen, and [MEET 11] and [MEET 18] record why: the officer has routine work of his own on a weekly, monthly or quarterly cycle, distinct from the contractor's. [NOT STATED] whether an officer may edit a contractor's schedule, and whether the two schedules are one object with two views or two objects.

No contractor calendar exists to replicate. The only calendar in any source is EIS Planning [GOFM img16], which is the officer's Phase 2 screen. What it shows, for reference only: two tabs Job Selection & Define Group and Calendar; a left panel with PO-In-Charge, EIS Cycle (value Wed Jul 01 2026 to Wed Sep 30 2026), Job Type as radio buttons, a Job Automation OFF/ON toggle, and Clone and Save As Template with a name field; a right panel holding a quarter calendar headed 2026 Q3, columns WEEK and Monday to Sunday with the weekend columns shaded, a Print action and Submit; day cells carrying an area and its job-type codes, for example 34 WHAMPOA WEST G(D),B(D),B(G).

[REVIEW] warns about the clone pattern: "Clone and save as template functions exist but rarely used: risk of stale schedules affecting KPIs" and "Clone function creates maintenance burden if schedules change".

[NOT STATED] The screen where a routine job is created — screenshot request 3, a Must. [NOT STATED] What Frequency on the Job Type is used for now that job creation is manual. [NOT STATED] Whether an officer can create many jobs at once, and how — [REVIEW] records about seven Property Officers per division, so volume matters.

M04 · Automatic reminders and overdue alerts — Partial

[REQ §5] "Automatic reminders and overdue alerts." No reminder or alert configuration screen was captured.

Settled, per R2 [QA7a]: a job is overdue once "current date is more than target completion date". This replaced the proposition put to the Town Council, which counted Grace Period in working days excluding public holidays. [NOT STATED] what the target completion date is composed of — see 4.4.

Resolved by R4 [TCN]. "If the contractors do not do the work that they scheduled (overdue), the manager/officer in charge of their work will get email notification."

So this function stays in Phase 1, and so does L05. The contradiction between [QA2] and [QA7b] is closed and question 13 of the Q&A List is answered. [REVIEW] had recorded the existing position as "No automated reminders for overdue issues or missed EIS schedules", so this is new build rather than a like-for-like replacement.

[NOT STATED] Whether the e-mail is sent once or repeats, whether the contractor is copied, whether the recipient is derived from the job or configured, and whether anything other than an overdue job sends an e-mail. [NOT STATED] The mail transport — [MEET 20] discusses using the Town Council's Microsoft tenant and an administrator API key, but settles nothing.

M05 · Mandatory checklist completion before submission — Full

[REQ §5] "Mandatory checklist completion before submission." Per R6 [QA8]: each checklist item is flagged mandatory or optional when defined, and every mandatory item must be ticked before Complete is accepted.

The existing system does not enforce this — the five pieces of evidence are in 3.1, of which item 4 is from inside the contractor application: it offered END with the mandatory parent item * BLOCK WASHING unticked [CVID1].

[CVID1] also settles how the flag reads on the phone — a red * beside the item — and that the checklist is a two-level tree whose parent is itself tickable and is the level carrying the marker (4.5). Enforcement therefore has to answer a question the web checklist never raised: whether ticking a parent requires its children first.

[NOT STATED] Where the mandatory flag is set — no capture of the checklist editor has been supplied (M10). [NOT STATED] Whether the items of the two web checklists are mandatory or optional. [NOT STATED] Whether a parent and its children are independently tickable.

M06 · Mandatory photo upload before submission — Full

[REQ §5] "Mandatory photo upload before submission."

Resolved by [CVID1] and [CVID2]. Per R7 the counter reads photographs held / photographs required, and per R17 the requirement is set at two levels:

So this function has something to enforce: a required count exists, it is configurable, and it can be nil. [REVIEW] "Photos taken only when defects found; no photo required if no issues" is consistent with that rather than contrary to it — it describes a configuration where the required count is nil, and it describes the officer's EIS inspections, which are Phase 2.

What has to be enforced, which the existing application does not (3.1 item 4): the job may not be submitted while a required count is unmet. On the captured job the requirement was one before and one after, none was taken, and END was offered anyway.

Two things this function must handle that the web evidence alone did not reveal:

• The requirement is per checklist item and per axis, not per section (R17), so the enforcement message has to name the item and the axis.
• A photograph may come from the device gallery (R14), so meeting the count does not establish attendance. [NOT STATED] whether the source of each photograph is recorded, which is what would let a report tell the two apart.

Two things [TCN] adds, and they change this function from counting to validating.

1. Per R21 a photograph is rejected outright if its timestamp is not after the start of work, and its geotag is compared with the address. [MEET 20] records the reason: one photograph was being re-used across many days. This is the first rule in the project that refuses a submission rather than warning about it, so this function needs a rejection state and a message that says which check failed.
2. Per R20 video joins the photograph as required evidence. "There will be mandatory requirement to upload video for some checklists" — so the required-count model of R7 and R17 has to carry a second medium, and a checklist item may require a video, a photograph, both or neither.

[NOT STATED] Whether the required count may exceed one, and whether a maximum exists. [NOT STATED] What happens when a photograph carries no timestamp or no geotag at all — the note says reject when the timestamp is wrong, not when it is absent. [NOT STATED] How far the geotag may differ from the address before it counts as a mismatch; R8 configures a distance for the start of work, and no source says the same number governs a photograph.

M07 · GPS, timestamp and QR code validation — Full

[REQ §5] "GPS, timestamp and QR code validation."

The three rows above are why this function is more than plumbing: every one of GPS, timestamp and QR is present in the existing application and every one of them is satisfiable without being at the site. What GoFM adds is not the capture but the validation — and validation needs thresholds and a record of which path was taken.

[TCN] rewrites this function. What is built in Phase 1 is no longer QR validation at all:

So the bypass path of [QA11], its four-reason dialog [CVID1], and the 1 km tolerance of [QA9] all describe the existing system. They stay in 3.1 as evidence of why the Town Council is replacing it, and none of them is built.

[NOT STATED] Whether a start outside the configured distance is blocked or merely flagged — the note says compare, not block. [NOT STATED] Where the GPS of an address comes from: no captured screen holds a coordinate against a property, so either the master data gains coordinates or they are geocoded. This is a dependency, not a detail. [NOT STATED] Whether an out-of-tolerance start or a rejected photograph is recorded in a way a report can count. [NOT STATED] Whether the NFC tags of Phase 2 exist yet — [MEET 20] says the Town Council will supply samples.

M09 · Town Council self-administration of assignments and checklists — Name only

[REQ §5] requirement "Town Council self-administration of assignments and checklists", against the pain point "Block/officer assignments require vendor intervention". No assignment screen was captured — screenshot request 8.

[VIDEO] The recording touches the same point in conversation — the checklists are "predefined", and "some you don't have access just on the list". [NOT STATED] what access a Property Officer has today.

[NOT STATED] The screen and the unit of assignment. See B03.

M10 · Flexible editable checklists — Partial

[REQ §5] "Flexible editable checklists." Only the filled-in result of a checklist has been supplied, never the editor — screenshot request 4, a Must.

The structure to be edited is known from two captured results, and they are not the same shape:

So the editor has to produce a tree whose parent is itself an item, with a mandatory flag per node and a required photograph count per node per axis.

And per R16 the editor's scope is wider than a checklist. Two job types run two different steppers, one of which has no checklist and no QR step at all (L02). What is configured against a Job Type is therefore: which steps the job presents, whether a QR unlock is among them, the checklist tree if there is one, and the required photograph counts. [REQ §5] calls this "Flexible editable checklists"; the recordings show the flexible thing is the whole job definition, and this function is where the Town Council gets it — which is the point of the pain point it answers, "Block/officer assignments require vendor intervention".

Three additions from [TCN].

1. Two sets of checklists, not one — Checklist for Officer and Checklist for Contractor (R22). The officer's own routine work has its own checklists.
2. Checklists arrive as Excel and must be importable. [MEET 20]: the Town Council will supply them in Excel, they will be large, and the instruction was to "make it easy to upload". So this function needs an import, not only a form. [MEET 11] asks for the same on property data. [NOT STATED] the column layout of that Excel — it has not been supplied.
3. A checklist item may require a video (R20), with a length the administrator configures, so the editor sets required counts for two media, not one.

[NOT STATED] The editor screen. [NOT STATED] The full list of step types (L02 lists the six observed). [NOT STATED] How sections and items are ordered, whether a checklist is versioned, and what happens to jobs already created when a checklist changes. [NOT STATED] Whether a job type may carry more than one checklist.

M11 · Comprehensive dashboards and KPI reports — Partial

[REQ §5] "Comprehensive dashboards and KPI reports", against the pain points "Report generation is cumbersome" and "Difficult for officers to verify work progress". [REQ §2.1] "Monthly KPI reports are generated."

The figures the existing system displays: COMPLIANCE INDEX, ON-TME INDEX (sic), the target KPI: 80%, and the percentage columns on the reports (A01, A02, J01, J06). No formula appears anywhere.

[QA12] answered "See video"; the recording shows the Compliance report but no arithmetic. [REVIEW] and [VIDEO] add that the current export is unreliable (3.1).

[NOT STATED] Every KPI formula. [NOT STATED] What the monthly KPI report to management contains — screenshot request 15.

M12 · Full audit trail with minimum 7-year retention — Partial

[REQ §5] "Full audit trail with minimum 7-year retention." [REQ §7] "Minimum 7-year data retention." · "Secure authentication and audit logging."

Action History (F03) is a per-job trail and is the only trail captured. No system-wide audit log viewer and no retention screen were captured.

[NOT STATED] What events beyond job actions are audited, who may read the audit log, and how retention is enforced or archived.

M13 · Automatic photo and video compression — Partial

[REQ §7] "Automatic photo/video compression recommended." [TCN] turns that recommendation into a requirement with numbers, per R20:

Per R11 the application does not run offline at all, so there is no deferred-upload queue to compress into.

[NOT STATED] The photograph compression target — only video carries one. [NOT STATED] Whether the original is kept alongside the compressed copy, which matters because R21 validates the timestamp and geotag and compression can strip both. That is a real conflict between two [TCN] rules and it has to be settled before either is built.

8. Consolidated open items

Everything this specification could not state, in one list. Each row blocks the item named against it.

8.1 Contradictions — these decide whether a function exists

No contradiction remains. Both are closed — the photograph counter by the 18 August recordings, the overdue notification by the 20 August note.

One new conflict is created by [TCN] itself, and it is recorded here rather than buried: R20 requires video to be compressed to 1080p, and R21 validates a photograph's timestamp and geotag. Compression commonly strips both. Which wins has to be settled before either is built. It blocks M06, M13.

8.2 Screens with no visual reference

Sixteen screenshot requests were raised, and [TCN] adds two more, numbered 17 and 18 to keep the earlier numbering stable. One is fully provided — request 1, by the two contractor recordings of 18 August — and three are partly provided. The numbering of 1 to 16 matches section 2 of the Q&A List.

The route [REVIEW] recorded to the first of these — "Town council to arrange us to meet contractor to show on flow from contractor side" — has been taken, and the two recordings are its result.

8.3 Rules and data no source states

9. Traceability — 47 Phase 1 functions

Function names in this table are taken verbatim from the Functions List. Twelve IDs are absent from it — A03, B04, C02, H01, H02, J07, J08, J09, J10, J11, L06 and L07 — because they are the twelve Phase 2 functions, which this document does not specify. M08 is absent because Liquidated Damages is out of scope (R5).

47 functions. Full 18 · Partial 13 · Name only 16.

Movement in v1.2, from [CVID1] and [CVID2]: L02 Partial → Full · M06 Partial → Full · L04 Name only → Partial.

Movement in v1.3, from [TCN]: M13 Name only → Partial, because video now carries a required flag, a configurable maximum length and a compression target.

The function count does not change. Everything [TCN] adds lands inside an existing function: the contractor's web portal and its schedule in M03 and section 5; the overdue e-mail in M04; the three contractor levels and the two sign-in paths in M02 and M01; zone allocation in B03; the two checklist sets, the Excel import and the video flag in M10; video length and compression in M13; photograph rejection in M06 and M07; pass or fail in F04; search by ID in F01 and G01. So the Functions List still holds 47 Phase 1 functions and 59 in total.

10. Related documents