FALCON Software Requirements Specification

Full-scope review draft — 9 October 2026. Proposed for TM review; not an approved baseline.

• This is the single editable SRS.
• It consolidates the previous detailed draft, all 199 numbered TM requirement rows, 28 narrative obligations, existing local requirements and the subsequent drafting decisions.
• Each requirement has an observable verification check.
• A written response is not evidence of implementation or acceptance: all verification results remain Not Run.

Open values and interpretations are identified in section 5.4. Proposed additions and detailed refinements are identified separately from TM obligations. The active coverage record maps requirement IDs and source locators. The previous full draft (internal reference) remains an unchanged reference.

Document control	Value
Prepared for	TM FALCON POC and Pilot
Working edition	Full-scope review draft, 9 October 2026
Formal version, document owner and named reviewers	To Confirm
TM approval authority, approval date and approved revision	To Confirm; no approval recorded by this document
Requirement authority	Original TM modality and conditions remain in the source register; solution responses remain Proposed unless explicitly stated otherwise
Verification	Not Run; criteria below are proposed checks, not test results

Reading guide

• 1. Introduction: purpose, boundaries and requirement conventions.
• 2. Solution Overview: users, responsibilities, module catalogue and operational flows.
• 3. Requirements: interfaces; functional modules and submodules; quality; compliance; engineering; AI/ML.
• 4. Verification: methods, evidence, milestone gates and acceptance handling.
• 5. Appendixes: data dictionary, recorded decisions, proposed states, parameter/decision register, glossary and narrative-source responses.

Suggested joint Team/TM review order

Review step	Question to resolve	Record against
1. Scope and authority	Is the interpretation within the TM source and agreed delivery boundary?	Requirement status/source; OPEN or Q reference.
2. Expected behaviour	Are the rules, information and exception handling clear and complete?	Requirement ID and local B clause.
3. Verification	Can the expected result be observed under the stated conditions?	Requirement ID and local AC criterion.
4. Outstanding agreement	Which value, policy or interpretation is still needed?	Section 5.4 decision or PAR reference.
5. Review record	What was agreed, by whom and against which revision?	Decision/review record with authority, date and evidence.

Drafting agreement, test execution and TM acceptance remain separate records. Local B/AC references restart within each requirement; always include the parent requirement ID.

1. Introduction

1.1 Purpose

• This SRS specifies the FALCON capabilities to be developed and verified for the POC and Pilot.

• It defines user actions, system responses, business rules, data, interfaces, operating constraints and acceptance criteria.

• TM reviewers, developers, integrators, field engineers and testers will use it to agree what FALCON must deliver and determine whether each requirement has been met.

• The customer baseline is TM’s URG (internal reference), supplied as URG_FALCON (1).docx on 9 October 2026.

• It is identical to the previously referenced URG_FALCON.docx: SHA-256 706b597f7756e1d467f1f4fe109f98009c66f2f92f6a35d646446b13903426ab.

• Although its cover says Software Requirements Specification, this project uses it as the TM requirements baseline from which this detailed SRS is developed.

1.2 Solution scope

FALCON supports the detection, assessment, prediction, prevention and handling of threats to fibre infrastructure from construction, theft or vandalism, and animal or rodent activity.

The full solution scope comprises:

• Importing and validating approved asset and incident data, and receiving observations from deployed devices.
• Displaying assets, devices, events, alerts and risk information on operational maps and dashboards.
• Detecting and classifying supported threats and assessing historical and predicted risk.
• Applying configured rules to generate alerts, request approval and initiate authorised responses.
• Recording investigation, assignment, field actions, preventive interventions and outcomes.
• Reporting operational results and retaining the records needed to explain system and user actions.
• Providing access control, data protection, monitoring, recovery and model lifecycle controls.
• Meeting the field equipment, deployment, integration, commissioning and support requirements applicable to the selected solution.

Legal proceedings and prosecution, and financial reconciliation or fraud investigation, are outside the scope stated by TM.

1.3 POC and Pilot boundary

• FALCON will operate in an isolated POC/Pilot environment.

• TM asset and incident/docket data will be supplied as files for offline import.

• Actual field devices will communicate with the FALCON platform through the FALCON IoT service.

• Live connections to TM production systems are not included in the current delivery direction.

• TM’s definition of the production environment permits an isolated POC/Pilot without production integration unless otherwise agreed.

• The URG also requires documented integration capabilities and marks enterprise integration as an initial-phase area.

• These are separate considerations: an isolated deployment does not remove the requirement to specify supported interfaces.

• The required POC/Pilot interface demonstration and the meaning of initial-phase integration need clarification with TM.

The Pilot covers two designated sites in different states. Site identities, equipment quantities and deployment conditions require TM and engineering input.

1.4 Requirement authority and status

The source register preserves TM’s original identifiers, wording and shall/should/may conditions. This SRS turns those requirements into testable rules and links each rule to its source. Additional functionality identifies its separate source.

Status	Meaning
Proposed	Draft behaviour or criterion for review.
Confirmed	Agreed at the authority and scope identified in its decision record. User drafting agreement is distinct from TM approval.
To Confirm	A specific decision or value is unresolved.
Deferred	Explicitly postponed with its reason and allocation recorded.

• Requirement wording and acceptance criteria in this rewrite remain Proposed for TM review.
• User-confirmed drafting decisions are identified in section 5.2 and the decision log; they do not establish TM approval.
• The Confirmed status of HW-PWR-001 is retained at its recorded authority; its acceptance conditions remain To Confirm.

1.5 Document structure

Chapter	Contents
1. Introduction	Purpose, scope, source baseline and requirement conventions.
2. Solution Overview	System boundary, users, operational flows, dependencies and release allocation.
3. Requirements	Detailed interfaces, functional behaviour, quality attributes, compliance, engineering obligations and AI/ML requirements.
4. Verification	Acceptance criteria, verification methods, evidence and requirement traceability.
5. Appendixes	Shared definitions, data dictionary, state models, parameter register and supporting references.

The linked design documents specify the detailed topology, source-code structure, API payloads and reasons for technology choices. This SRS retains the mandatory technical constraints and requirements to produce those documents.

1.6 Requirement and change conventions

Review topic	Convention
Customer authority	The original URG remains the baseline. Preserve each shall, should, may, condition and “where technically feasible” qualification.
Source identity	Each source response records the exact TM ID, unique URG table/row locator, source modality and response disposition.
Duplicate source ID	Keep both REQ-MLOP-004 rows separate by locator and title.
Proposed responses	Numbered source responses describe proposed solution behaviour for TM agreement.
Retained identities	Existing PL, SH, HW, FE and MD IDs retain their identity and recorded status. SRS-EVT-001–018 retain the accepted drafting structure.
Additional refinements	Other SRS IDs represent consolidated source responses or explicitly labelled BA refinements. An addition does not establish a new TM obligation or delivery commitment.
Detailed review references	Use the requirement ID plus local clause/criterion, for example SRS-GIS-104/B05 or SRS-GIS-104/AC04.
Open decisions	Read the brief reference beside a requirement with the full question/status in section 5.4. A missing value is not an agreed default.
Baselined changes	Record source/rationale, affected requirements/interfaces/data/tests, impact assessment and approving authority.
History and approval	Retain superseded versions and decision evidence. Neither repository code nor a prototype establishes requirement approval.

2. Solution Overview

2.1 System context

The platform maintains operational records and applies business rules. The IoT service manages device communication, translates device messages, delivers commands and returns their results. Field devices provide the sensing and intervention capabilities supported by the selected equipment.

flowchart LR
    TM[TM asset and incident files] -->|Offline import| P[FALCON platform]
    D[Field devices] <-->|Observations, health, commands and results| I[FALCON IoT service]
    I <--> P
    U[Authorised users] <-->|Web interface| P

TM assets and FALCON devices are separate records. Each deployed device is linked to the location or infrastructure it monitors. Deployment history preserves the location associated with earlier events when a device moves.

2.2 Users

Role	Main responsibilities
Superadmin	Manage platform security settings, system monitoring, performance settings, backups, recovery and technical maintenance.
Administrator	Manage application users, sites, devices, data imports, rules and closure outcomes.
Operator	Review alerts, own cases, assign field work, approve permitted actions, review field results and close cases.
Field Team	From M3, sign in to view assigned work, record progress, upload evidence and submit completion details.
Viewer	View permitted maps, dashboards and reports.

• Administrators, Operators and Viewers can view records across sites within their permissions.
• Field Team members can access only their assigned work and the records needed for that work.
• Superadmins need a separately assigned operational role to use operational functions.
• Restricted records and evidence require the relevant access permission.
• Public self-registration is not available.

TM’s SMEs, data/AI specialists and management may also review the solution. Their job titles do not grant application access.

Functional permission matrix

Operational access

Action	Superadmin	Administrator	Operator	Field Team	Viewer
View maps and operational records	Not allowed	Allowed	Allowed	Assigned work only	Allowed
View operational dashboards and reports	Not allowed	Allowed	Allowed	To confirm	Allowed
Create and manage application accounts	To confirm	Allowed within approved account scope	Not allowed	Not allowed	Not allowed
Import TM files	Not allowed	Allowed	Not allowed	Not allowed	Not allowed
Manage sites, devices and deployment records	Not allowed	Allowed	To confirm	Not allowed	Not allowed
Configure rules and closure outcomes	Not allowed	Allowed	Not allowed	Not allowed	Not allowed
Review and acknowledge alerts; create cases	Not allowed	To confirm	Allowed	Not allowed	Not allowed
Assign field work and review submitted results	Not allowed	To confirm	Allowed	Not allowed	Not allowed
Record field progress, evidence and completion details	Not allowed	To confirm	Allowed	Assigned work only	Not allowed
Close a case	Not allowed	To confirm	Allowed	Not allowed	Not allowed
Approve an action or pause automatic action	Not allowed	To confirm	Allowed for approved actions	Not allowed	Not allowed
Issue a manual deterrent command	Not allowed	To confirm	Allowed for approved devices and actions	Not allowed	Not allowed
View live cameras	Not allowed	Allowed	Allowed	Not allowed	Not allowed
Download Excel/PDF operational reports	Not allowed	To confirm	To confirm	Not allowed	To confirm
Review operational audit records	Not allowed	To confirm	To confirm	Not allowed	Not allowed

These permissions apply to each role on its own. An additional assigned role provides only the permissions listed for that role. Actions must also meet approval, maintenance, device availability and cooldown rules.

Technical access

Action	Superadmin	Other application roles
Manage platform security settings	Allowed	Not allowed
View system health, performance and technical diagnostic records	Allowed	Not allowed
Configure agreed performance settings and monitoring limits	Allowed	Not allowed
Manage backups and execute approved recovery procedures	Allowed	Not allowed
Perform approved platform maintenance	Allowed	Not allowed
Create or assign Superadmin access	To confirm	To confirm for Administrator; not allowed for other roles
Approve or deploy a model release	Separate release approval required	Separate release approval required

• Superadmin access does not approve a model release or a physical device action.
• Superadmins apply agreed technical settings. Changes to acceptance targets require the recorded review and approval process.
• Account types, role-grant permissions and Superadmin provisioning are listed in section 5.4, DET-076.
• The server checks permissions for every protected request, including direct API, media and export requests.
• Disabled accounts and revoked credentials cannot make new protected requests. Active-session revocation timing remains in DET-002.

2.3 Main operational flows

Flow	Step	Expected progression
Detection and response	1	Receive, record and validate the observation/event.
Detection and response	2	Evaluate rules; create or update an alert where required.
Detection and response	3	Obtain required approval and perform the permitted response.
Detection and response	4	Record execution evidence and operational outcome separately.
Historical and predictive risk	1	Import and validate TM data; associate usable records with locations/assets.
Historical and predictive risk	2	Calculate historical indicators and the agreed future-risk prediction separately.
Historical and predictive risk	3	Display results and contributing information; use qualifying risk results to support preventive decisions.
Investigation and field intervention	1	Create a linked case when investigation, assignment or field intervention is needed.
Investigation and field intervention	2	Assign a responsible Operator and record reported field actions.
Investigation and field intervention	3	Close with outcome and note; attachments remain optional. Case states are Open, In Progress and Closed.

Outcome distinction: Command dispatch, confirmed device execution, case closure and threat resolution are separate recorded facts.

2.4 Delivery allocation

Stage	Review item	Specification
M1 requirements and solution baseline	Deliverable boundary	Master SRS and source-level design RTM; logical architecture/operational scenarios; shared data/interface contracts; device/site approach; delivery dependencies; verification and acceptance plan.
M1 requirements and solution baseline	Review / acceptance evidence	Named TM review of the identified revision, source ambiguities/deviations and criteria.
M1 requirements and solution baseline	Review / acceptance evidence	Unresolved source interpretations/targets/owners are explicit, not silently accepted.
M2 controlled actual-device POC	Deliverable boundary	Initial access, imports/registration, map/dashboard/events and actual Capability1 detection/manual deterrent with basic live camera, as in the checklist.
M2 controlled actual-device POC	Review / acceptance evidence	Real equipment/configuration records, controlled-location demonstration and traceable permission/interface/component tests.
M2 controlled actual-device POC	Review / acceptance evidence	Physical execution evidence distinct from UI or service receipt.
M3 integrated first increment	Deliverable boundary	Agreed field detection/response, internal alerts/cases/workflows, initial historical and predictive risk, audit/safeguards and basic reporting/exports.
M3 integrated first increment	Review / acceptance evidence	Integrated field trace, model/data evaluation, control/failure cases, regression results and outstanding-item disposition.
M3 integrated first increment	Review / acceptance evidence	Case/closure and threat outcome remain separate from device result.
M4 expanded capability and prevention	Deliverable boundary	Second agreed threat capability, rule-based preventive recommendations/intervention tracking and effectiveness review; proposed read-only AI assistant; start agreed mobilisation increment.
M4 expanded capability and prevention	Review / acceptance evidence	Capability-specific evaluation, prediction/operational limitations, preventive decision/outcome records, bilingual assistant/read-only tests if adopted, and regression evidence.
M4 expanded capability and prevention	Review / acceptance evidence	Capability2 identity and assistant allocation need TM agreement.
M5 complete agreed MVP and readiness	Deliverable boundary	Third agreed capability and remaining agreed full-solution functions; remaining agreed equipment/asset records; completed agreed mobilisation increment; formal validation/UAT, documentation and initial training.
M5 complete agreed MVP and readiness	Review / acceptance evidence	All three threat-family responses exercised under agreed conditions, installation inventory, system/integration/regression evidence, performance/load/stress and vulnerability-assessment/penetration-testing (VAPT) reports with remediation/retest evidence as source-listed proposals, UAT and explicit outstanding-item disposition.
M5 complete agreed MVP and readiness	Review / acceptance evidence	Exact completion/readiness boundary and date remain unresolved.
Pilot readiness transition	Deliverable boundary	Complete approved corrections/tuning, deployment/commissioning preparation, support arrangements and updated training/documentation before pilot start.
Pilot readiness transition	Review / acceptance evidence	Readiness review of site/configuration, dependencies and regression/security/performance evidence for changed functions.
Pilot readiness transition	Review / acceptance evidence	Whether this is included in M5 or a separate December stage remains To Confirm.
M6 pilot	Deliverable boundary	Install/commission and validate at two TM-approved sites in different states; assess detection, prevention/response, AI/risk, operational KPIs and reliability under representative conditions.
M6 pilot	Review / acceptance evidence	Site/as-built records, operational run/effectiveness/model reports, failures/support records and pilot acceptance decision.
M6 pilot	Review / acceptance evidence	Locations, monitoring period and measures require agreement.
M7 support and handover	Deliverable boundary	Agreed maintenance/support, corrective actions, final findings/recommendations, configuration and inventory, technical/operating documents, applicable source deliverables and knowledge transfer.
M7 support and handover	Review / acceptance evidence	Service/defect history, verified handover inventory, final report/training evidence and clear remaining responsibilities.
M7 support and handover	Review / acceptance evidence	Support duration, licensing/source-access obligations and closure date require explicit agreement.

All three threat families remain in full-solution scope. Animal/rodent is the first capability; the order and detailed coverage of construction and theft/vandalism require a decision. Detailed workforce rostering and equipment scheduling remain additional proposals.

2.5 Dependencies

Input	Required to specify or verify
TM asset and incident samples	Import fields, identifiers, geometry, matching rules and usable historical information.
Selected device capabilities	Observation fields, evidence, command catalogue, execution confirmation, buffering and operating limits.
Site survey and access	Sensing coverage, installation, connectivity, power and representative test conditions.
TM operational input	Threat criteria, response procedures, approval responsibilities and escalation.
Applicable TM policies	Hosting, authentication, protected data, retention and security acceptance.

Named owners and delivery dates are maintained in the dependency register.

2.6 Module and submodule catalogue

A module owns the stated behaviour even when it calls a shared service. Submodules below define review and implementation boundaries; they do not require separate deployable services.

Section	Module	Submodules
3.1	External Interfaces	Device observations and health; command dispatch and results; offline imports; application APIs; media and live video; report downloads; optional AI API.
3.2.1	User Access and Administration	Account provisioning; authentication; role permissions; account suspension; session control.
3.2.2	Data Intake and Validation	Import preview and commit; validation and quarantine; source mappings; deduplication; asset/incident matching; data quality and provenance.
3.2.3	GIS Assets and Operational Map	Asset and route registry; map layers; spatial association; dashboard filters; historical hotspots; risk overlays.
3.2.4	Device Registration and Deployment	Device inventory; registration and authorisation; deployment history; relocation; connectivity and health; configuration portability.
3.2.5	Risk Assessment and Prediction	Threat taxonomy; historical scoring; future prediction; ranking and confidence; explanations; insufficient-data handling.
3.2.6	Workflow and Rule Management	Rule configuration and versions; priorities; approval tasks; manual/automatic/hybrid paths; pauses; cooldowns; command restrictions.
3.2.7	Events and Alerts	Event ingestion; event evidence; classification; grouping; shared queue; acknowledgement; priority; escalation; lifecycle and closure.
3.2.8	Active Deterrent Control	Command catalogue; authorised activation; device confirmation; retry and expiry; operating limits; stop and fault handling.
3.2.9	Case Management	Case creation and links; responsible Operator; field mobilisation; action/evidence records; outcomes; closure; feedback.
3.2.10	Preventive Actions and Mobilisation	Recommendation rules; supporting evidence; accept/dismiss/defer; mobilisation; intervention history; before/after review.
3.2.11	Reporting and Performance Review	Event/alert summaries; case outcomes; device availability; trends and hotspots; management view; Excel/PDF exports.
3.2.12	Audit History	User/action audit; import/configuration history; event-to-outcome trace; model/decision trace; authorised review.
3.2.13	AI Assistant	Read-only questions; bilingual on-demand summaries; permission-filtered retrieval; supporting-record citations; missing information; API failure.
3.2.14	Evidence and Media Management	Evidence identity; upload/linking; retrieval permissions; unavailable-media handling; preservation and expiry; live-view separation.
3.2.15	Notification and Escalation Management	Internal recipient selection; delivery versus acknowledgement; escalation timers; repeat handling; exceptions and audit.
3.2.16	Reference Data and Operational Configuration	Sites and zones; event mappings; closure outcomes; parameter versions; configuration validation and retirement.
3.3.1	Reliability Recovery and Retention	Fault isolation; recovery; backup and restoration; retention; interrupted communication; AI fallback.
3.3.2	Performance and Capacity	Event throughput; alert latency; monitored capacity; dashboard response; scaling and resource cost.
3.3.3	Maintenance and Diagnostics	Service monitoring; health diagnosis; planned maintenance; component replacement; controlled update and rollback.
3.4	Compliance Security and Privacy	TM policies; data protection; authentication/authorisation/accounting; third-party dependencies; threat assessment; security evidence.
3.5.1	Architecture Deployment and Portability	Component boundaries; deployment model; resource sizing; interfaces; site replication; configuration; licensing.
3.5.2	Edge Controller	Workload assessment; hardware/software dependencies; local processing; compute/storage/interface sizing.
3.5.3	Sensors Camera and Live View	Threat-to-sensor mapping; coverage and placement; calibration; animal/tamper detection; health; event media; live viewing.
3.5.4	Edge Software	Acquisition and timestamping; permitted local processing; buffering; restart recovery; synchronisation.
3.5.5	Connectivity	Site communications assessment; protocol adaptation; connection loss; acknowledgements; store-and-forward.
3.5.6	Solar and Power	Load budget; overnight operation; solar/battery sizing; power monitoring; interruption and recovery.
3.5.7	Enclosure and Mounting	Weather and thermal protection; mounting; physical security; cable entry; service access; installation drawings.
3.5.8	Hardware Assembly	Bill of materials; wiring; unit identity; assembly instructions; inspection and functional checks.
3.5.9	Testing and Commissioning	Installation method; site checks; integration and sustained-operation tests; as-built evidence; commissioning decision.
3.5.10	Passive Protection	Candidate protection design; ground-level prototype; installation records; inspection; bypass/failure observations; effectiveness evaluation.
3.5.11	Delivery Documentation and Handover	Delivery increments; dependencies and risk; deployment completion; lifecycle costs; manuals; support ownership and handover evidence.
3.6.1	Predictive Model Lifecycle	Dataset lineage; target/horizon; reproducible training; held-out evaluation; baseline comparison; registry; deployment; drift; rollback and feedback.
3.6.2	Detection Model Lifecycle	Construction/theft/animal use cases; labelling; representative data; detection evaluation; runtime compatibility; monitoring and responsible use.

2.7 End-to-end operating scenarios

Scenario	Trigger and main path	Result and exception handling
Import TM assets and incidents	Administrator selects source and mapping, previews validation/matching, reviews proposed inserts/updates and commits permitted records.	Reconcile accepted/rejected/unmatched counts; retain source provenance. Invalid fields do not become zero values; unmatched usable locations remain visible.
Animal/rodent response	Authorised device supplies an observation; FALCON records it, evaluates classification/risk and applies the configured rule.	Qualifying risk produces an alert; any actual deterrent requires the approved action policy and restrictions. A low-confidence or missing-input result does not justify physical action.
Construction near fibre	Detect supported activity and assess location/proximity against usable asset geometry and configured risk criteria.	Retain distance/zone basis and evidence where available; qualifying risk enters alert handling. Missing geometry creates an unresolved assessment rather than a fabricated distance.
Theft/vandalism/tampering	A deployed source detects a supported access/tamper/activity scenario; the platform evaluates its configured risk criteria.	Record suspicion, evidence and response separately from verified findings. The system does not establish criminal guilt; prosecution remains excluded.
Operator handling	New alert enters a shared queue; an Operator acknowledges and reviews it. Investigation, assignment or field intervention uses a linked case.	No-case closure is allowed for reviewed No threat found, Duplicate or Unable to verify with outcome/note. Assignment is held on the case, not duplicated on the alert.
Device action	Permitted automatic/manual/hybrid workflow requests a correlated command through IoT after restrictions and required approval.	Requested, Sent and Confirmed are distinct. Missing physical confirmation remains Unconfirmed; retry does not create a new logical action. Execution does not prove threat resolution.
Historical and predictive risk	Import usable history/context; build a traceable dataset; calculate historical factors and score an approved prediction separately.	Present period, geography, horizon, supporting factors and uncertainty. Insufficient prediction data is disclosed; historical counts are not renamed predictions.
Preventive intervention	A recommendation identifies action, location, reason, supporting evidence and priority; Operator accepts, dismisses or defers with reason.	Accepted work may link to a case; record mobilisation, actions and outcomes. Before/after observations include confounders and do not prove causation.
Device relocation	Plan a move while retaining current placement; complete the move with reason and dates under the same device identity.	At most one active deployment; prior events retain their event-time placement. Late data with ambiguous deployment is flagged for review.
Interrupted service or communications	IoT/device connectivity or power fails; retain available records and mark last-known/unverifiable state.	Buffer/recover where the selected equipment supports it. Reconnection does not replay stale physical actions. IoT service failure is not proof that every device is offline.

2.8 Allocation and source conflicts

M1–M7 are proposed delivery stages; their labels do not establish approval dates. M2 requires a controlled demonstration using actual devices. A UI prototype alone is insufficient. M3 adds the integrated field workflow, cases, internal notifications, historical and initial predictive risk and Excel/PDF reports. M4 preventive recommendation and intervention review are distinct from basic mobilisation across M4–M5. Detailed rostering, workforce schedules and equipment allocation remain separate proposals.

The read-only bilingual assistant is proposed for M4. TM must still agree delivery timing for enterprise integration, AI agents, knowledge retrieval and advanced prediction, which the source marks as initial-phase capabilities. Offline imports cannot count as a passed live-system interface test. Section 5.4 records these open decisions; the capabilities remain neither Deferred nor complete unless that status is explicitly agreed or verified, respectively.

2.9 URG initial and future allocation

TM’s original table10 marks the following capabilities as initial or future/deferred. The proposed delivery stage is shown separately. TM must confirm what “initial” means before the delivery plan can be judged against that table; Q09 remains open.

URG area	Source marking	Proposed SRS treatment
Data ingestion	Initial	M2 reviewed offline intake and field ingestion; extend per selected sources.
Enterprise system integration	Initial	Project lacks live TM production integration. Proposed offline boundary/deviation with future interface capability; TM must decide the disposition.
Knowledge retrieval	Initial	Read-only FALCON-record retrieval proposed M4 with permission/source controls; reconcile timing and intended knowledge scope.
AI-assisted analysis	Initial	M3 prediction/risk and later agreed analytics; M4 summaries are separate. Applicable data/quality/oversight requirements remain.
AI Agent	Initial	Initial assistant is read-only. Wider authorised task-executing agents are not assumed; applicability and allocation need TM decision.
Workflow orchestration	Initial	Initial integrated rules/workflows M3; controlled M2 manual action does not replace this obligation.
Human approval	Initial	Enforce designated action approval in delivered workflows; complete policy/authority details before operational activation.
Automated system action	Initial	Only approved, bounded action policies and supported device controls; M2 manual sufficiency is a milestone boundary, not removal of the source capability.
Advanced predictive models	Initial	M3 initial future-risk assessment remains required in the proposal; method, data and “advanced” acceptance interpretation remain To Confirm.
Cross-domain reuse	Future/deferred	Preserve component/interface portability; a cross-domain rollout is not a current unapproved delivery commitment.
Full vs Focused predictive model based on areas	Future/deferred	Retain source wording; model coverage strategy and intended distinction require TM clarification.
Enterprise-wide deployment	Future/deferred	Design for justified expansion and document dependencies; no enterprise-wide production rollout is included without agreement.

3. Requirements

The six groups below follow TM’s requirement structure. Requirements share the data and state definitions in chapter 5 and verification rules in chapter 4. Their acceptance checks must be executed with the agreed parameters, permitted actors and relevant negative/error cases. All new response and refinement statuses are Proposed unless their entry records another status.

3.1 External Interfaces

Purpose: Define the logical exchange contracts and evidence required to distinguish accepted data, completed processing and confirmed physical execution.

Actors: Administrators supply approved imports; registered devices/adapters exchange observations and commands through the IoT service; authenticated users consume permitted application, media and reporting functions.

Submodules: Device observations and health; command dispatch and results; offline imports; application APIs; media and live video; report downloads; optional AI API.

Boundaries: I labels are local references, not additional TM requirement IDs or commitments to separate services. The platform may remain one modular application and use background processing where needed. The IoT service keeps its stated responsibilities regardless of where it is hosted. Exact routes, keys, topics and transport choices belong in the technical interface release before integration.

Interface catalogue

Interface	Producer → consumer	Proposed contract and success boundary	Principal unresolved detail
I-IMPORT	Authorised Administrator/source export → platform ingestion	Submit source file and mapping for preview; reconcile per-row validation/matching, then apply reviewed changes. Successful receipt alone is not successful import.	TM files/schema, accepted formats, matching keys, size/encoding and data permissions.
I-OBS	Registered device/adapter → IoT service → platform	Carry a normalised versioned event envelope, preserving original identity/time/evidence. Acceptance indicates durable validation/ingestion outcome, not threat validity.	Native protocol, capability, taxonomy and exact payload schema.
I-HEALTH	Device/adapter → IoT service → platform	Report contact and available health readings with observation time; platform derives current/stale/unverifiable presentation under agreed thresholds.	Heartbeat, fields/units, source clock and status thresholds.
I-CMD	Platform → IoT service → selected device	Submit one uniquely identified, authorised and time-bounded action; service owns dispatch and limited eligible retries.	Action catalogue, adapter, device safety/duplicate controls and exact parameters.
I-RESULT	Device/adapter → IoT service → platform	Correlate receipt/dispatch/execution/failure evidence to the logical command, with occurrence and receipt times.	Native acknowledgement semantics and physical confirmation evidence.
I-MEDIA	Camera/device or import processor → controlled bucket reference → authorised consumer	Register/upload permitted media and link evidence ID to the event; retrieve only after permission check.	Storage provider, upload mechanism, formats, integrity check and retention policy.
I-LIVE	Authorised Administrator/Operator → platform/IoT-mediated camera session	Explicit request/start/stop, camera authorisation, inactivity termination and session audit. Session opened is separate from a usable video stream.	Camera streaming protocol, quality, bandwidth and session/concurrency limits.
I-APP	Authenticated web client → platform service API	Read or change only permitted records/actions; return a traceable result or machine-readable error.	Authentication technology, routes, schemas and UI response targets.
I-REPORT	Authorised request → reporting service → controlled Excel/PDF download	Preserve filters, period, data cutoff and permission checks in generated output. Generation success is separate from download access.	Detailed layouts, export access, row/size limits and synchronous/asynchronous execution.
I-AI	Permission-filtered FALCON context → selected LLM API → requesting user	Proposed M4 read-only request/summary; attach source/period context and validation/limitations; no operational write or command tool.	Provider/model, processing/data approval, retention, cost and evaluation.
I-TM	FALCON ↔ TM enterprise systems	No live connection in the proposed project delivery. Retain interface obligations and a proposed disposition under Q09; offline exports are I-IMPORT, not a claim of equivalent live integration.	TM approval of the deviation and future interface scope.

Normalised message envelope

Proposed platform–IoT business messages use JSON. Reviewed adapters may translate different native payloads while preserving source lineage. Images and video use I-MEDIA/I-LIVE references; inline binary data is not mandatory.

Field group	Required information	Processing rule
Identity/version	Message ID, schema version, producer/device identity and message type.	Authenticate producer; reject unsupported versions/types with a traceable reason. Application identity persists across transport retransmission.
Times	Source occurrence time where available, service receipt time, platform receipt time; source offset/clock-quality information.	Apply Data Dictionary time semantics. If occurrence time is missing or untrusted, flag the limitation when checking action age or selecting the event’s deployment. Do not silently substitute another time.
Correlation	Event/command ID, causal evaluation/request ID and deployment reference when reliable.	Validate relationship and device identity; never attach a result to another device’s command solely because its native sequence number matches.
Payload	Type-specific validated fields, units, classification/confidence only when supplied, status/result and error detail as appropriate.	Unknown optional fields may be retained when the documented version rules allow it. Do not activate a physical action if the meaning of any required field is unknown.
Evidence	Controlled evidence IDs and capture metadata where supplied.	Validate ownership/linkage and access; an arbitrary device-provided URL is not trusted as an unrestricted fetch instruction.

Evolution condition	Proposed compatibility rule
Additive optional field	May be accepted under the documented compatible-version policy.
Field removal, changed meaning/unit or new mandatory field	Require an incompatible schema version and an explicit adapter/service compatibility check.
Migration and historical data	Record each event/result’s schema version; never silently reinterpret historical content.
Product boundary	This policy does not select a schema-registry product.

Import transaction and reconciliation

Stage	Required behaviour	Failure / repeat handling
Identify input	Authenticate the Administrator; identify source namespace, file/version, import type and approved mapping.	Inspect format, encoding, required columns and source-use restrictions before calculation eligibility.
Preview	Show valid rows, errors, unmatched associations and proposed record changes; retain source-row locators.	File-level errors leave business records unchanged; reviewed partial-import handling permits independent valid rows after row errors.
Match	Use stable source keys where available.	If the same key contains conflicting data, flag it for review instead of creating two records. If suitable keys are unavailable, propose possible matches and obtain an agreed matching rule. Similar names or coordinates alone must not cause an automatic merge.
Apply	Check target revisions against the preview; record every applied/failed row and reconcile totals.	Proposed concurrency handling rejects stale updates for renewed preview. Retrying the same batch/application does not duplicate completed changes.
Preserve usable information	Keep original usable incident location when asset matching fails.	Exclude only calculations needing the missing link. Import does not automatically command devices or replay historical events as live threats.

Acceptance scenario	Required evidence
Identical re-import or changed source row	Correct duplicate/update outcome and source-row lineage.
Conflicting target revision or duplicate docket ID	Reviewable conflict without silent overwrite/merge.
Mixed valid/invalid rows or interrupted partial progress	Reconciled totals and no duplicated completed change after retry.

Decisions still required: Section 5.4, OPEN-07/Q14; numerical register “Retention, backup and reporting scale (PAR-12)”.

Delivery identity and command safety boundary

MQTT and HTTP remain the chosen protocol families under ARC-D03. The OASIS MQTT specification addresses transport delivery; packet identifiers, DUP flags and HTTP success do not establish unique application processing or physical execution.

Exchange condition	Proposed contract
Same event identity and accepted content	Return the original ingestion result without creating another event.
Same event identity with conflicting content	Quarantine/flag for review; preserve received evidence and authoritative record without silent overwrite.
Genuine separate detections	Require separate identities even when type, time or imagery are similar.
Device lacks stable event identity	Test the adapter’s rule for assigning event identities against actual device behaviour. Do not assume that hashing data within a time window distinguishes every detection.
New command	Record requester, target, permitted action/parameters, reason or triggering evaluation, validity and required approval/restrictions.
Command acceptance	Accept only a supported, authorised action for a registered device.
Repeated command ID	Retrieve or continue the same logical delivery under the allowed retry policy; do not create a new physical action.
Changed payload under an existing command ID	Return a conflict.
Eligible dispatch or retry	IoT service rechecks restrictions and follows the platform’s action policy; it cannot independently redefine that policy.
Device lacks safe action correlation/deduplication	Restrict or disable retries; a device-specific safety review determines whether late/unconfirmed execution permits another action.
Late evidence or timeout	Append late evidence and reconcile under the Data Dictionary proposal. Timeout is not definitive evidence of non-execution.
Reconnection	Do not replay expired/withheld actions or automatically close cases.

Evidence level	Meaning
Service accepted	The service accepted the logical request.
Dispatched	The request was dispatched.
Device acknowledged	The selected device acknowledged, if supported.
Execution confirmed	Selected evidence confirms execution; API/broker acknowledgement alone is insufficient.
Final operational outcome	The operational result is recorded separately from command delivery/execution.

Verification: Reproduce response loss, duplicate delivery, out-of-order/late acknowledgement, stale validity and service restart using a non-hazardous controlled method and selected-device confirmation.

Decisions still required: Section 5.4, OPEN-03/OPEN-04; numerical register “Commands and connectivity recovery (PAR-09)” and “Workflow and alert timing (PAR-08)”.

Availability ordering and error contract

Error category	Required response
Unauthenticated; forbidden; unknown/unregistered device	Stable machine-readable code, safe explanation and request/correlation reference.
Unsupported schema/type/action; invalid/missing input	Same structured response; no blind retry.
Identity conflict; stale revision; action restricted; expired	Same structured response and retry eligibility where meaningful.
Service unavailable; resource limit reached	Same structured response with bounded retry guidance where applicable.
Sensitive implementation information	Never return credentials, raw stack traces or unrelated records.

HTTP interfaces may adopt RFC9457 problem details; this remains a recommended representation, not a selected endpoint implementation.

Condition	Required handling
Ordering	Order records using the source and receipt times appropriate to the operation. Do not assume that the order messages arrive is the order events occurred.
Older heartbeat/result	Retain observations without silently overwriting newer validated state.
Ambiguous/conflicting chronology	Surface timestamps and ambiguity; do not invent ordering. Qualify sequence/clock behaviour with the adapter.
IoT-service outage	Show last-known information and inability to verify current device state.
Individual contact timeout	Show device-specific Offline only when valid source observations support that conclusion.
Supported edge/device buffering	Retain observations; qualify capacity, overflow/drop reporting and recovery behaviour.
Device lacks a required offline capability	Keep the full URG offline/recovery obligation in the RTM.
Retry of a mutation	Reuse its logical identity under a bounded policy; do not blindly retry invalid, forbidden or unsupported work.
Resource configuration	Set limits, timeouts and backoff from measured device/network/application constraints; no numeric value is approved here.

Decisions still required: Section 5.4, OPEN-03/OPEN-04/OPEN-07 and the “Commands and connectivity recovery (PAR-09)” numerical entry.

Authentication authorisation and protected media

Protected asset / boundary	Proposed enforcement	Failure handling
User versus device/service identity	Use separate identities and check function plus requested object/action at the server, including evidence access and live start/stop.	Changed request IDs cannot bypass permissions.
Record access	Apply the role permissions in section 2.2.	Field Team access is limited to assigned work; Viewer access excludes live video and operational changes.
Credentials	Provision/revoke by a controlled administrator procedure; exclude credentials from ordinary logs, reports and model prompts.	Compromised credentials are revoked under the selected procedure.
Sensitive flows and storage	Apply TM-approved encryption and data controls.	No assumed cryptographic profile or compliance claim.
Media retrieval	Authorise underlying record/camera and evidence type. Proposed private bucket uses service retrieval or provider-supported expiring scoped links.	A link is not a permanent grant and is not included in public reports by default.
Live camera capability	Issue only capability permitted for the current user.	Stop, timeout or revocation closes the authorised session through the supported media path.

The object checks follow OWASP object-level authorisation guidance; they do not add a site-restriction feature.

Decisions still required: Section 5.4, OPEN-10/Q14 and OPEN-14.

LLM and external integration boundaries

Interface	Permitted contract	Failure / scope boundary
I-AI input	Send only permission-filtered context needed for the selected read-only question/summary to an approved provider.	No TM data transmission before processing approval; retrieved content cannot expand permissions.
I-AI output	Separate source-backed facts from interpretation; retain record links/period and uncertainty.	API outage affects the assistant, while maps, alerts, cases and reports continue.
I-TM	Document future capability and error/version/security obligations.	Standalone delivery remains a proposed deviation; an offline adapter is not live enterprise integration.
Initial-phase allocation	Preserve source marks for enterprise integration, AI Agent, knowledge retrieval and advanced prediction in Delivery Allocation and the RTM.	Do not treat timing/interpretation as resolved before TM agreement.

Decisions still required: Section 5.4, OPEN-01/Q09 and OPEN-11.

Interface acceptance evidence

Test scope	Evidence required
Every I label	Success, invalid/missing input, permission denial and relevant failure/recovery paths.
Actual event and permitted command	Correlation IDs trace each through the selected end-to-end path.
Identity and compatibility	Duplicate/conflicting IDs, incompatible schemas, location/time ambiguity and stale import previews have stable outcomes.
Availability and access	Distinguish service/device outages; test media expiry, denied live roles and LLM outage.
Selected adapter	Demonstrate actual confirmation and duplicate controls; simulated API replies alone are insufficient.

Decisions still required: Section 5.4, OPEN-03/OPEN-07/OPEN-10/OPEN-16 and applicable numerical entries.

SRS-INT-101 — API Integration

Attribute	Specification
Status	Proposed deviation.
TM source	REQ-INTSW-001; URG-T13-R02.
Source modality	shall; all source conditions remain applicable.

The platform shall retain documented integration boundaries while identifying the proposed live-TM-integration deviation.

Contract element	Specification
Documented contract	Purpose/direction, schema version and identifiers.
Data and access	Required/optional fields, authentication and supported media.
Failure semantics	Validation, errors, timeout and duplicate handling.

Clause	Interface behaviour
B01	Document platform–IoT service exchange and approved offline source import boundaries.
B02	Route device data and commands through the IoT service using the retained MQTT/HTTP direction.
B03	Keep application identities distinct from supplied source identities and preserve mappings/traceability.
B04	Provide controlled positive, invalid and timeout examples for each implemented interface.
B05	Retain an adapter boundary for a future designated TM interface without claiming an implemented external connection.
B06	The user has stated that live TM production integration is unavailable; offline import does not prove an enterprise API or cancel the source obligation.
B07	Obtain TM disposition of the deviation and section 2.6 initial-phase allocation conflict before baseline sign-off.

Verification:

Criterion	Scenario / method	Expected result
AC01	Implemented interface review and actual selected IoT path	Purpose, contracts and schema/authentication/duplicate/unavailable-service tests match implementation.
AC02	Unimplemented TM interface review	The interface is recorded as a deviation with no passing external test claimed; Q09 disposition is required.

Decisions still required: Section 5.4, OPEN-01/Q09; OPEN-07.

SRS-INT-102 — Event Exchange

Attribute	Specification
Status	Proposed deviation.
TM source	REQ-INTSW-003; URG-T13-R04.
Source modality	shall; all source conditions remain applicable.

Where integration with a designated operational system is required, the platform shall preserve the external event-exchange obligation and its proposed standalone deviation.

Contract element	Specification
Proposed envelope	Event/alert identity, schema version and original/receipt times.
Operational context	Category, location/asset references and state.
Traceability	Available evidence references and update/version identity.

Clause	Interface behaviour
B01	Current device-event exchange uses the FALCON IoT service and operational reports are downloadable; neither proves compliance with an external operational event interface.
B02	Future adapters map authorised fields and exchange direction to the designated recipient contract.
B03	Define delivery acknowledgement, retries and duplicate/update semantics for that recipient.
B04	Exclude secrets and unrestricted media links from exported content.
B05	Do not enable an external endpoint through this proposal.

Verification:

Criterion	Scenario / method	Expected result
AC01	Representative internal events including state updates and unavailable evidence	The proposed envelope represents each case without implying live external exchange.
AC02	External system/contract/access absent	External verification is blocked/not executed.
AC03	Approved designated receiver available	Test acknowledged, duplicate and failed deliveries against its contract.

Decisions still required: Section 5.4, OPEN-01/Q09: designated systems and standalone deviation; OPEN-07.

SRS-INT-103 — Interface Error Handling

Attribute	Specification
Status	Proposed response.
TM source	REQ-INTSW-004; URG-T13-R05.
Source modality	shall; all source conditions remain applicable.

Interfaces shall reject invalid or unauthorised input and recover through traceable, bounded, safe delivery handling.

Clause	Interface behaviour
B01	Validate schema and authorisation before operational use; return structured reason and source/correlation reference for invalid input.
B02	Exclude invalid input from affected calculations/commands while allowing independent valid import records to proceed.
B03	Distinguish validation/authentication failure, unavailable dependency, transport timeout and explicit device failure.
B04	Show actionable internal status without credentials or raw secret-bearing payloads; timeout does not prove physical non-execution.
B05	IoT service owns bounded retries under the same command identity, only for devices/actions with verified duplicate-execution controls.
B06	Platform displays progress and final Failed, Expired or Unconfirmed states without independently retrying physical actions.
B07	Recheck maintenance, pause, approval, cooldown and action-age restrictions before further execution.
B08	If optional AI API fails, show assistant failure while maps, alerts, cases and reports continue.
B09	Document actual adapter limits and transient/permanent classification; no invented numeric TM criteria.
B10	On recovery reconcile acknowledged identities and current status; neither replay expired commands nor overwrite newer records with delayed responses.

Verification:

Criterion	Scenario / method	Expected result
AC01	Malformed input, unauthorised source and duplicates	Correct structured reasons appear; valid independent records remain and duplicates do not cause duplicate execution.
AC02	Unavailable service, timeout and definite failure	States are distinct; retries are bounded and eligible, with preserved command identity and safety checks.
AC03	Late acknowledgement and recovery	History reconciles without stale overwrite or expired replay.
AC04	Correlated logs and optional AI outage	Logs exclude secrets; unrelated functions continue.

Decisions still required: Section 5.4, OPEN-03/OPEN-04; numerical entry “Commands and connectivity recovery (PAR-09)”.

SRS-INT-104 — API Documentation

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-APINT-001; URG-T41-R02.
Source modality	shall; all source conditions remain applicable.

Applicable integration interfaces shall be documented and versioned at the authorised service boundary.

Clause	Interface behaviour
B01	Proposed REST/JSON APIs expose applicable operational data; device-native protocols terminate at the IoT service.
B02	Publish machine-readable OpenAPI, examples and operational constraints.
B03	Separate reads, accepted submissions and permitted commands; apply authenticated scoped identities and audit.
B04	Implement/test external readiness against controlled clients or agreed POC/Pilot stubs.
B05	Keep stub-versus-live evidence explicit; documented interfaces and offline imports do not demonstrate successful live enterprise integration.
B06	The user-confirmed lack of live TM production integration remains a proposed deviation requiring TM agreement.

Verification:

Criterion	Scenario / method	Expected result
AC01	Contract client checks authentication, invalid input, pagination and errors	Documentation matches actual behaviour; retained requests/responses identify stubs versus live counterparts.

Decisions still required: Section 5.4, OPEN-01/Q09; OPEN-07/OPEN-10.

SRS-INT-105 — API Types

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-APINT-002; URG-T41-R03.
Source modality	shall; all source conditions remain applicable.

The platform shall define applicable API resources with consistent access, validation and traceability rules.

Contract element	Specification
Resource categories	Event submission, asset information, risk information and alert information.
Further categories	Workflow status, incident information, device status and operational metrics.

Clause	Interface behaviour
B01	Validate event source identity/schema and retain idempotency/source references.
B02	Preserve provenance and reviewable validation errors for asset and incident imports.
B03	Provide identifiers, site/time filters, pagination, freshness and related-record links for reads.
B04	Include model, period and uncertainty with risk; keep workflow and command states distinct; identify metrics calculation periods.
B05	Reject or explicitly identify unsupported/not-approved external writes instead of silently accepting them.
B06	Return consistent validation, permission, missing-record, rate-limit and unavailable errors without exposing restricted objects.

Verification:

Criterion	Scenario / method	Expected result
AC01	Valid and invalid case for every applicable resource category	Permissions, pagination, links, freshness and duplicate-submission semantics are correct.
AC02	Applicability/evidence review	Excluded categories and controlled test counterparts are explicitly identified.

Decisions still required: Section 5.4, OPEN-01/Q09; OPEN-07.

SRS-INT-106 — API Parameters / payload

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-APINT-003; URG-T41-R04.
Source modality	shall; all source conditions remain applicable.

Each implemented endpoint shall have a complete, testable technical contract.

Clause	Interface behaviour
B01	Document method/path and purpose in the technical release, with required role/service scope and authentication.
B02	For request and response fields, define data types, required fields, when null is allowed, units and the meaning of each timestamp.
B03	Include successful/failing examples, correlation/idempotency fields and error codes.
B04	Distinguish invalid, unauthenticated, forbidden, not-found, conflicting update/duplicate, oversized, rate-limited and unavailable-dependency outcomes.
B05	Define pagination/filter/sort, timeout, payload/file maximums, rate/concurrency bounds and retry safety guidance.
B06	Declare major API/schema versions, backwards compatibility and deprecation rules.
B07	Keep device-native schemas behind the common IoT envelope.
B08	Treat numeric limits as configuration proposals until workload review.

Verification:

Criterion	Scenario / method	Expected result
AC01	Machine-readable contract validation and example execution	Contract is valid and actual success/error status/body semantics match it.
AC02	Negative cases and exceeded configured limits	Rejection and retry handling are clear and bounded.

Decisions still required: Section 5.4, OPEN-07/OPEN-10; applicable section 5.4 numerical entries.

SRS-INT-107 — API Scalability

Attribute	Specification
Status	Proposed response.
TM source	REQ-APINT-004; URG-T41-R05.
Source modality	shall; all source conditions remain applicable.

Integration contracts shall support controlled expansion without exposing database or hardware-specific structures.

Clause	Interface behaviour
B01	Use versioned resources, stable application identities and mapped source references.
B02	Add optional fields compatibly; give breaking changes an explicit migration/version path.
B03	Use adapters to validate new sources and translate their data into the common message envelope.
B04	Use pagination and bounded payloads/rate/concurrency.
B05	Provide asynchronous job status for long imports/reports instead of unbounded synchronous requests.
B06	Keep representative legacy-client contract tests and record capacity limits.
B07	Do not claim limitless scale or compatibility with every proprietary system.

Verification:

Criterion	Scenario / method	Expected result
AC01	New test source/adapter and optional field	Existing representative client contracts still pass.
AC02	Increased request volume	Limits produce bounded failure without lost or duplicated work.

Decisions still required: Section 5.4, OPEN-07; numerical entries “Monitored capacity and dashboard response (PAR-03)” and “Retention, backup and reporting scale (PAR-12)”.

3.2 Functional Requirements

All requirement sections use a common review format. Functional modules provide module purpose, actors and boundaries, followed by individual requirements. Each requirement separates its authority/source, short statement, relevant information or behaviour, exceptions and acceptance criteria. Only relevant tables are included.

Behaviour clauses (B01, B02, etc.) and acceptance criteria (AC01, AC02, etc.) are local to their parent requirement. Cite the full reference in review comments, for example SRS-GIS-104/B05 or SRS-GIS-104/AC04. These clauses clarify the existing requirement; they are not additional top-level requirements. Decisions still required remain open, and all acceptance criteria are Not Run.

3.2.1 User Access and Administration

Purpose: Control access to operational information and sensitive actions while retaining accountability.

Actors: Superadmins manage technical settings. Administrators manage application accounts. Operators manage operational work. Field Team members update assigned work from M3. Viewers read permitted information. Devices and services use separate identities.

Submodules: Account provisioning; authentication; role permissions; account suspension; session control.

Access rules: Apply section 2.2 to all five roles. Field Team members see assigned work only. Superadmin operational access requires an additional role. Physical actions still require their safety and approval checks. TM SSO access remains To Confirm.

SH-ACC-001 — Role and action permissions

Attribute	Specification
Status	Proposed.
Provenance	Baseline Sources#SRC-03
Drafting decision	ROLE-001–003; user agreed, TM review pending.

The platform shall enforce the agreed role and action permission matrix.

Functional behaviour

Clause	Required behaviour
B01	Check role and action permissions for protected operations through both the user interface and direct APIs.
B02	Include import, rule configuration, device commands, live media and exports in the permission matrix.

Exceptions

Condition	Required handling
Permission denied	Refuse the operation without an unauthorised side effect.

Verification:

Criterion	Scenario / method	Expected result
AC01	Allowed action	The permitted operation succeeds for the applicable role.
AC02	Denied UI and direct API action	No unauthorised change occurs, including for import, rules, commands, live media and exports.

Decisions still required: See DET-001.

SRS-ACC-001 — Suspend access

Attribute	Specification
Status	Proposed.
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.
Drafting decision	ROLE-001–003; user agreed, TM review pending.

An Administrator shall be able to suspend accounts within their approved account scope without removing historical actor references.

Functional behaviour

Clause	Required behaviour
B01	Allow an Administrator to suspend an account within their approved account scope.
B02	Deny subsequent protected requests from the suspended account.
B03	Keep previous audit entries and other historical actor references attributable to that account.

Verification:

Criterion	Scenario / method	Expected result
AC01	Suspend an account with recorded activity	Subsequent protected requests are denied and previous activity remains attributable.
AC02	Account has an active session when suspended	Apply the agreed session-revocation policy; acceptance of revocation timing awaits that policy.

Decisions still required: See DET-002 for session revocation and DET-076 for account-management permissions.

SRS-ACC-101 — Authentication

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-SEC-001; URG-T26-R02.
Source modality	shall; all source conditions remain applicable.
Drafting decision	ROLE-001–003; user agreed, TM review pending.

The platform shall authenticate end users, services and registered devices before accepting their protected access or operational data.

Functional behaviour

Clause	Required behaviour
B01	Require authenticated identity at browser, API, media, evidence, export and administration entry points.
B02	Allow Administrators to create accounts within their approved account scope; provide no public self-registration.
B03	Validate session and service credentials at the server.
B04	Require device registration and authorisation before its IoT-service identity may publish accepted operational data or receive commands.
B05	Keep service-to-platform authentication separate from end-user authentication.
B06	Record security-relevant authentication attempts without recording secrets.

Exceptions

Condition	Required handling
Invalid credentials	Reject access without disclosing protected record contents.

Verification:

Criterion	Scenario / method	Expected result
AC01	Valid identity at each protected entry point	Access proceeds subject to authorisation.
AC02	Absent, expired, revoked or wrong-principal credentials	UI, API, evidence, live-view and IoT access are rejected without exposing protected records.
AC03	Unregistered or disabled device; disabled account	Operational publication/command access or account access is denied as applicable.
AC04	Security log inspection	Attempts are traceable and credentials are redacted.

Decisions still required: See DET-003 for authentication and DET-076 for account creation.

SRS-ACC-102 — Authorisation

Attribute	Specification
Status	Proposed response.
TM source	REQ-SEC-002; URG-T26-R03.
Source modality	shall; all source conditions remain applicable.
Drafting decision	ROLE-001–003; user agreed, TM review pending.

The platform shall authorise each protected action in its application or service handler.

Functional behaviour

Clause	Required behaviour
B01	Enforce permissions at the server even when a caller bypasses hidden or disabled UI controls.
B02	Permit Administrators to create accounts, import data and manage rule/outcome configuration under the proposed role model.
B03	Permit Operators to review alerts, manage assigned work, approve designated actions and invoke permitted commands or pauses.
B04	Keep Viewers read-only; Viewer membership alone grants no live-camera access. Retain live access for Administrators and Operators.
B05	Allow Administrators, Operators and Viewers to access records across sites within their permissions. Limit Field Team access to assigned work.
B06	Check action-specific restrictions independently of role membership; permission to configure a rule does not establish field-safe physical-action policy.
B07	Audit security-relevant forbidden-action attempts.
B08	Give Superadmins access to platform security settings, system monitoring, agreed performance settings, backups, recovery and approved technical maintenance.
B09	Require a separately assigned operational role before a Superadmin can access operational records or actions.
B10	Allow Field Team members to view assigned work and submit progress, evidence and completion details from M3. An authorised Operator reviews the results and closes the case; Field Team members cannot close it.
B11	Restrict account and role changes to the approved account types and grantable roles. No user may grant themselves unapproved permissions.

Exceptions

Condition	Required handling
Forbidden operation	Reject with no side effect.

Verification:

Criterion	Scenario / method	Expected result
AC01	Role-by-endpoint allow/deny matrix	Each role receives only its permitted functions, including export, media, rules, approval, pause and case closure.
AC02	Direct forbidden write	Stored state is unchanged and the security-relevant attempt is audited.
AC03	All-site Viewer	Records are visible within read permissions; writes and live-camera access remain denied.
AC04	Superadmin with technical access only	Technical functions are available; operational records and actions are denied through UI and API.
AC05	Superadmin with a separately assigned operational role	Only that role’s operational permissions become available; action restrictions still apply.
AC06	Assigned and unrelated users with only the Field Team role	Only the assigned member can view and update the field work; neither can close the case or issue device commands.
AC07	Administrator-only or Field-Team-only account attempts a technical setting or unapproved role grant	The request is denied without changing settings or permissions.

SRS-ACC-103 — Data Access

Attribute	Specification
Status	Proposed response.
TM source	REQ-SEC-005; URG-T26-R06.
Source modality	shall; all source conditions remain applicable.
Drafting decision	ROLE-001–003; user agreed, TM review pending.

The platform shall apply consistent data-access restrictions across every representation of a record.

Functional behaviour

Clause	Required behaviour
B01	Apply role restrictions to dashboards, search, detail APIs, downloads, live streams and AI retrieval.
B02	Resolve object references through authorised queries and restrict sensitive fields independently of parent-record visibility.
B03	Calculate counts and exports from the same permitted dataset used for display.
B04	Apply role changes and revocation to new protected requests; apply the approved session policy to active sessions.
B05	Check the current field-work assignment before returning its records or evidence to a Field Team member. Remove that access from subsequent requests when the assignment ends or changes.

Exceptions

Condition	Required handling
Restricted object or expired evidence link	Deny retrieval without revealing the object contents.

Verification:

Criterion	Scenario / method	Expected result
AC01	Same record through UI, API, report, evidence URL and assistant	Each path discloses only data permitted to the role.
AC02	Changed object ID or expired evidence link	Restricted information is not returned or revealed by the error.
AC03	Role revoked during a session	New protected requests are restricted and active-session behaviour matches the approved policy.
AC04	Field work reassigned; old assignee requests its case or evidence by copied ID	Subsequent requests from the old assignee are denied; the new assignee can access the assigned work within its permissions.

Decisions still required: See DET-004.

3.2.2 Data Intake and Validation

Purpose: Bring usable source records into FALCON with reproducible lineage, associations and quality decisions.

Actors: Administrators control imports and mapping profiles; Operators use imported information; registered devices provide observations through the IoT service; authorised internal users review limitations.

Submodules: Import preview and commit; validation and quarantine; source mappings; deduplication; asset/incident matching; data quality and provenance.

Boundaries: TM exports and registered field observations are initial source candidates. Connected production access and additional source families require their own approval. A record can remain usable even when one association or calculation is unavailable; import does not prove model readiness.

PL-DAT-001 — Traceable source import

Attribute	Specification
Status	Proposed.
Provenance	Baseline Sources#SRC-01

The platform shall import agreed records and observations with traceable source and capture time.

Functional behaviour

Clause	Required behaviour
B01	Retain source identity and capture time for each imported record or observation.
B02	Reconcile import totals and prevent duplicate records when the same agreed source delivery is repeated.

Verification:

Criterion	Scenario / method	Expected result
AC01	Agreed asset/incident sample imported	Stored records retain source/time lineage and totals reconcile.
AC02	Same sample imported again	No duplicate records are created.

PL-DAT-002 — Invalid and missing input review

Attribute	Specification
Status	Proposed.
Provenance	Baseline Sources#SRC-01

The platform shall expose invalid and missing required input for review while retaining usable information.

Functional behaviour

Clause	Required behaviour
B01	Identify invalid or missing required fields and make the reasons available for review.
B02	Retain usable unmatched incidents.
B03	Exclude an incomplete record only from calculations that require its missing input.

Verification:

Criterion	Scenario / method	Expected result
AC01	Mixed valid, invalid and unmatched sample	Review identifies the affected rows and reasons; usable unmatched incidents remain available.
AC02	Calculation with a missing required input	The record is excluded from that calculation without losing other valid uses.

SRS-DAT-101 — Network Asset Data

Attribute	Specification
Status	Proposed response.
TM source	REQ-INTSW-002; URG-T13-R03.
Source modality	shall; all source conditions remain applicable.

The platform shall import agreed TM network assets through an Administrator-controlled, traceable process.

Information displayed / data fields

Field	Specification
Lineage	Source identity, batch and capture time.
Asset identity and location	Required identifiers and supplied location/geometry; kept separate from device identity.

Functional behaviour

Clause	Required behaviour
B01	Validate required asset identifiers and location/geometry before dependent use; show accepted and rejected records with reasons.
B02	Resolve existing assets by stable source identifiers where available and preview additions or updates before applying them.
B03	Keep TM fibre assets distinct from FALCON devices; associate observations through deployment, location and asset relationships.
B04	Allow Operators to use imported records without granting import authority through Operator membership.
B05	Preserve source/batch lineage and the historical location/context of existing event associations when an asset changes.

Exceptions

Condition	Required handling
Referenced asset absent from a later file	Flag for review; do not delete it solely because of absence.
Ambiguous identity or invalid spatial fields	Reject from association-dependent processing.

Verification:

Criterion	Scenario / method	Expected result
AC01	Approved asset sample and detected event	Assets import and the event association has traceable source/batch/capture time.
AC02	Repeat import and coordinate update preview	No duplicate asset is created; proposed changes and the recorded update decision remain visible.
AC03	Omitted or repeated identifier	Referenced assets are not deleted; missing/ambiguous identities are flagged.
AC04	Changed asset position or unusable geometry	Old events retain their context; invalid geometry cannot support a claimed proximity result.

SRS-DAT-102 — Multi-Source Data Ingestion

Attribute	Specification
Status	Proposed response.
TM source	REQ-FUNC-001; URG-T14-R02.
Source modality	shall/may; all source conditions remain applicable.

The platform shall ingest enabled, approved sources through controlled import or registered IoT observation paths.

Functional behaviour

Clause	Required behaviour
B01	Use Administrator-controlled imports for TM asset and incident/docket exports and the IoT service for registered field observations.
B02	For each enabled input record approval, purpose, source owner role, schema/version, mapping, refresh method and quality rules.
B03	Treat network, environmental, sensor, construction, incident, geographical and operational data as possible source families; add a family only when usable data and an approved mapping exist.
B04	Retain source, capture time, batch/message identity and quality status for each input.
B05	Allow valid independent records to proceed while preserving rejected and unmatched records and their reasons.
B06	Proposed import preview shows accepted, rejected and unmatched counts and changed records before commit.
B07	Retain source files in the agreed bucket and normalised records/lineage in PostgreSQL under approved retention.

Exceptions

Condition	Required handling
Source not supplied or approved	Do not claim that it is an enabled integration.
Rejected/unmatched record	Keep its reason visible without blocking independent valid records.

Verification:

Criterion	Scenario / method	Expected result
AC01	TM asset and incident samples plus an actual device observation	Each arrives through its distinct permitted path with complete lineage.
AC02	Reconcile initial and repeated delivery	Every row/message is accounted for as accepted, rejected, unmatched or duplicate; repeat delivery does not duplicate records.
AC03	Operator import or unregistered source/device	Input is denied.

Decisions still required: See DET-005.

SRS-DAT-103 — Data Correlation

Attribute	Specification
Status	Proposed response.
TM source	REQ-FUNC-002; URG-T14-R03.
Source modality	shall; all source conditions remain applicable.

The platform shall correlate records using approved mapping profiles and preserve the evidence for each association.

Functional behaviour

Clause	Required behaviour
B01	Match using available infrastructure/source identifiers first, followed by applicable asset linkage and geographic/time criteria.
B02	Use location, time, fibre asset, event type, infrastructure identifier and geographical proximity only when valid for the source.
B03	Retain contributing records, matching basis and rule/version.
B04	Keep usable unmatched incidents and their coordinates; mark the asset link unresolved.
B05	Exclude an unmatched incident from asset-dependent calculations with an eligibility reason while permitting valid location-level analysis.
B06	Use stable source IDs for repeat imports and show proposed updates; distinct dockets are not automatically distinct real-world incidents.
B07	Associate field observations with the deployment valid at original event time using retained source time, clock quality and normalised instants from the central data contract.
B08	Allow Administrators to maintain mapping profiles; reviewed corrections retain the prior association and correction reason.

Exceptions

Condition	Required handling
Nearest feature alone	Present a candidate, not proof of the affected asset.
Tie or incompatible identifiers	Leave association unresolved for review.
Invalid/uncertain event time or missing deployment	Prevent automatic historical reassignment.

Verification:

Criterion	Scenario / method	Expected result
AC01	Exact identifier, valid proximity, conflicting ID and equal-distance cases	Exact joins and candidates are traceable; conflicts/ties remain unresolved against a reviewed reference set.
AC02	Unmatched incident and repeated dockets	Usable coordinates remain available, calculation eligibility is explicit and no unapproved distinct-incident assumption is applied.
AC03	Delayed pre-relocation event	It links to the event-time deployment or remains explicitly unresolved when time/deployment is uncertain.
AC04	Reviewed correction	Prior association and reason remain available.

Decisions still required: See DET-006.

SRS-DAT-104 — Historical Data

Attribute	Specification
Status	Proposed response.
TM source	REQ-FUNC-003; URG-T14-R04.
Source modality	should; all source conditions remain applicable.

The proposed M3 capability should ingest and query TM historical fibre fault/incident records for recurring-pattern analysis and predictive dataset preparation.

Information displayed / data fields

Field	Specification
History record	Observation period, source/batch, event/fault identity and available category, location/asset, severity/impact.
Quality context	Known source coverage and quality limitations.

Functional behaviour

Clause	Required behaviour
B01	Label counts and summaries as historical rather than validated future likelihood.
B02	Document included records, exclusions, source coverage and preparation version for each analytical dataset.
B03	Distinguish reported dockets from confirmed distinct incidents or faults.
B04	Preserve update history and reproduce reviewed dataset snapshots.
B05	Apply current operational-record permissions to historical evidence.

Exceptions

Condition	Required handling
Missing history	Show unknown coverage, not zero incidents.

Verification:

Criterion	Scenario / method	Expected result
AC01	Historical sample with duplicates, absent severity and unmatched locations	The resulting summary discloses exclusions and limitations and remains traceable to sources.
AC02	Known coverage gap	Coverage is unknown; it is not reported as zero incidents.
AC03	Recreate reviewed snapshot	Source references and preparation version reproduce the dataset and historical summary.
AC04	Simple historical counts	No future-prediction label is presented.

SRS-DAT-105 — Data Flow

Attribute	Specification
Status	Proposed response.
TM source	REQ-AIMLA-002; URG-T38-R03.
Source modality	shall; all source conditions remain applicable.

The platform shall link approved input, model output, decisions, actions and recorded outcomes so each result can be traced to its source.

Functional behaviour

Clause	Required behaviour
B01	Process registered sensing/import through validation, quality/provenance checks and permitted transformation/features.
B02	Submit versioned inference requests and receive typed prediction, classification, confidence and limitations.
B03	Carry event/batch/source, input/version and correlation references through platform risk interpretation and configured decision/approval.
B04	Link actions, Operator changes and verified outcomes to the original prediction for evaluation.
B05	Keep historical incident counts separate from model predictions. A model score alone must not trigger a physical action.

Exceptions

Condition	Required handling
Malformed model output	Reject the output.
Insufficient input	Show insufficiency and retain previous results with their age.

Verification:

Criterion	Scenario / method	Expected result
AC01	Controlled detection and historical-to-predictive sample	Source, feature, model, risk, workflow and output references form a traceable chain.
AC02	Required input removed or malformed model output	The result is constrained/unavailable or rejected; no invented current score appears.
AC03	Operator intervention and outcome	Each links back to the original prediction.

SRS-DAT-106 — Additional Data Sources

Attribute	Specification
Status	Proposed response.
TM source	REQ-REX-004; URG-T47-R05.
Source modality	shall; all source conditions remain applicable.

The platform shall onboard additional offline or approved connected sources through validated source profiles.

Functional behaviour

Clause	Required behaviour
B01	Create a profile recording owner, access/rights, format/schema/version, cadence, source IDs, location/time/unit mapping, quality rules and retention.
B02	Validate and stage input before dependent use; report accepted, rejected and unmatched records with reasons.
B03	Preserve lineage and prevent duplication on repeated delivery.
B04	Admit only eligible records/fields into dependent risk or model calculations and keep missing associations explicit.
B05	Review schema compatibility when a source changes.
B06	Keep connected production sources subject to the separate TM integration decision; a file adapter does not grant network or data access.

Exceptions

Condition	Required handling
Schema incompatibility	Require compatibility review before changed input can corrupt established meanings.

Verification:

Criterion	Scenario / method	Expected result
AC01	Representative new source with valid, malformed, duplicate and unmatched rows	Counts, provenance and eligibility reconcile; each unusable row has a reason.
AC02	Repeat delivery	No duplicate records result.
AC03	Schema change and prior-source regression	Incompatible meanings are not silently applied and existing sources retain correct processing.

Decisions still required: See DET-007.

SRS-DAT-107 — Data Quality

Attribute	Specification
Status	Proposed response.
TM source	REQ-MLDM-002; URG-T52-R03.
Source modality	shall/may; all source conditions remain applicable.

The platform shall apply versioned data-quality checks during import, feature preparation and inference.

Functional behaviour

Clause	Required behaviour
B01	Check missing required fields; duplicate IDs/content; invalid formats/ranges; conflicting values; outliers; impossible/future/out-of-order timestamps; sensor fault/health indications; and incomplete/corrupted records.
B02	Record affected source records, check/reason, treatment and potentially impacted models/use cases.
B03	Keep accepted, rejected and unmatched outcomes distinct; allow valid records to proceed.
B04	Exclude incomplete records only from calculations requiring the missing input.
B05	Preserve original and receipt times during normalisation; document imputation/transformation so it can be reproduced.
B06	Constrain or block an affected automated decision when required fields, freshness or health fail the applicable inference guardrail; retain the underlying observation.

Exceptions

Condition	Required handling
Unrecoverable payload	Quarantine and retain an auditable rejection reference.
Outlier	Flag for review; do not automatically delete an unusual threat.

Verification:

Criterion	Scenario / method	Expected result
AC01	At least one example of each of the eight quality classes	Each produces a traceable reason and treatment with the source retained as applicable.
AC02	Mixed valid/incomplete data and repeat import	Partial acceptance is correct and no duplicate scoring occurs.
AC03	Outlier versus corrupted record	The outlier is flagged for review; unrecoverable data is quarantined with a rejection reference.
AC04	Material inference-quality failure	The affected automated decision is prevented under its guardrail.

SRS-DAT-108 — Data Quality Guardrail

Attribute	Specification
Status	Proposed response.
TM source	REQ-MLGRL-001; URG-T53-R02.
Source modality	shall; all source conditions remain applicable.

The platform shall evaluate versioned input-quality guardrails before inference and before releasing inference into an action workflow.

Functional behaviour

Clause	Required behaviour
B01	Check the model-required quality, completeness, freshness and source-health rules and retain outcomes with inference/decision records.
B02	Proposed handling withholds the affected automatic action when a mandatory input, validity/freshness bound or required health condition fails.
B03	Mark an available advisory result as constrained and explain its missing or stale inputs.
B04	Preserve raw observations and notify authorised internal users of the limitation.
B05	Allow historical analysis for its stated period when its model inputs do not depend on the offline live sensor.
B06	On recovery allow new valid evaluations; do not replay stale or previously withheld deterrent actions.
B07	Apply each independent approved workflow’s own input and safety checks.

Exceptions

Condition	Required handling
Evidence unavailable	Never substitute an assumed safe or low-risk value.

Verification:

Criterion	Scenario / method	Expected result
AC01	Valid, missing, incomplete, stale and unhealthy inputs	The configured guardrail outcome is retained; constrained/unavailable results are explicit and prohibited commands are withheld.
AC02	Source recovery	New valid evaluations proceed without replaying previously withheld or stale deterrence.
AC03	Independent historical/reporting function	It remains usable where its required inputs are available.

3.2.3 GIS Assets and Operational Map

Purpose: Present supplied infrastructure, observations and assessment results in linked geographical and list views.

Actors: Authorised users inspect permitted records; Viewers remain read-only; Administrators manage reviewed spatial configuration. Field surveyors provide placement and site evidence.

Submodules: Asset and route registry; map layers; spatial association; dashboard filters; historical hotspots; risk overlays.

Boundaries: Display only supported geometry and approved assessment units. Historical hotspots, future predictions, device positions and sensor coverage remain distinct. Spatial display does not establish field suitability or authorise physical actions.

PL-GIS-001 — Asset and route registry

Attribute	Specification
Status	Proposed.
Provenance	Baseline Sources#SRC-01

The platform shall maintain agreed asset and route records with identifiers and locations.

Functional behaviour

Clause	Required behaviour
B01	Store asset/route identifiers, supplied geometry and site associations.
B02	Keep infrastructure asset records separate from FALCON device records.

Verification:

Criterion	Scenario / method	Expected result
AC01	Approved asset/route sample	Identifiers, geometry and site associations match the sample; device identities remain separate.

PL-GIS-002 — Linked operational map

Attribute	Specification
Status	Proposed.
Provenance	Baseline Sources#SRC-01

The platform shall display linked events, devices and available evidence on the asset map.

Functional behaviour

Clause	Required behaviour
B01	Link mapped devices and events to their source records, status and available evidence.
B02	Show the applicable site and preserve historical event location when presenting past events.

Verification:

Criterion	Scenario / method	Expected result
AC01	Select a mapped device and event	Status and evidence trace to the source records and the displayed site/location matches the applicable deployment history.

SRS-GIS-101 — Operational Dashboard

Attribute	Specification
Status	Proposed response.
TM source	REQ-INTUI-001; URG-T11-R02.
Source modality	shall; all source conditions remain applicable.

The dashboard shall present the operational information available at the applicable delivery milestone.

Functional behaviour

Clause	Required behaviour
B01	In M2 show monitored asset/location status, device status and detections.
B02	In M3 add active alerts, cases and separately identified historical/predictive risk; in M4 add risk-linked preventive recommendations.
B03	Apply the authorised user’s site and period selection to panel results.
B04	Open the linked asset, event, alert, assessment or recommendation from a populated panel.
B05	Identify each panel’s data period or last update and distinguish loading, no records, unavailable and stale states.
B06	Permit Viewers to inspect information; require the applicable operational permission for action controls and APIs.

Exceptions

Condition	Required handling
Capability awaiting its milestone	Label unavailable in this release; do not represent it as zero risk.
Service failure	Retain labelled last-known values.

Verification:

Criterion	Scenario / method	Expected result
AC01	Populated panels filtered by site/period	Every displayed result reconciles to its linked record.
AC02	No-record period and unavailable-data period	Different labels distinguish the two states.
AC03	IoT-service interruption	Last-known values are labelled stale; all devices are not automatically shown Offline.
AC04	Viewer via UI and direct API	Inspection is allowed and operational actions are denied.

SRS-GIS-102 — Fibre Network Visualisation

Attribute	Specification
Status	Proposed response.
TM source	REQ-INTUI-002; URG-T11-R03.
Source modality	shall/should; all source conditions remain applicable.

The platform shall provide a geographical view of relevant supplied fibre infrastructure and risk locations.

Functional behaviour

Clause	Required behaviour
B01	Layer support should include usable supplied fibre routes, distribution cabinets, manholes, poles, monitored infrastructure, construction areas, detected threats, historical incidents and risk levels.
B02	Retain each feature’s source identity and geometry type; distinguish an unavailable layer from a supplied layer containing no features.
B03	Open feature identifiers, source and related records on selection.
B04	Use filters and a legend that distinguish assets, devices, observations and risk outputs.
B05	Display usable unmatched incidents at supplied coordinates with unresolved asset associations.
B06	After relocation, update current device placement while retaining historical markers at their event-time deployment and coordinates.

Exceptions

Condition	Required handling
Invalid geometry	Flag the feature and exclude it from spatial calculations until corrected.

Verification:

Criterion	Scenario / method	Expected result
AC01	Available layers, point and route in an approved reference sample	Positions match the approved coordinate transformation; record unavailable optional layers separately.
AC02	Invalid geometry and located unmatched incident	Invalid geometry is flagged and excluded from spatial calculations; the usable incident remains mapped with an unresolved asset link.
AC03	Device relocation	Current placement changes and previous event markers remain at their original locations.

Decisions still required: See DET-008.

SRS-GIS-103 — Fibre Proximity Assessment

Attribute	Specification
Status	Proposed response.
TM source	REQ-FUNC-021; URG-T16-R03.
Source modality	shall; all source conditions remain applicable.

The platform shall establish construction-to-fibre proximity only from usable geometry and an approved spatial method.

Information displayed / data fields

Field	Specification
Calculation basis	Activity geometry/version and asset geometry/version.
Result	Calculation time, units, nearest relevant feature or zone relationship, and positional limitations.

Functional behaviour

Clause	Required behaviour
B01	Calculate the relationship between a construction point/area and relevant imported route/asset geometry using the approved coordinate system and distance method.
B02	Proposed point observations use shortest point-to-route distance; proposed area observations use intersection or nearest separation.
B03	Keep a sensor coverage zone distinct from the precise activity location.
B04	Use distance or protection-zone membership as inputs to approved risk rules; neither independently establishes an alarm threshold.
B05	Preserve the geometry/context used by each historical assessment.
B06	Allow Administrators to manage reviewed spatial configuration; deny Viewer changes.

Exceptions

Condition	Required handling
Missing/incompatible geometry, unknown coordinate system or insufficient precision	Return Proximity not established with reasons and Operator review.

Verification:

Criterion	Scenario / method	Expected result
AC01	Reviewed on-route, intersecting, near and distant geometries	Units and distances reconcile within the agreed tolerance.
AC02	Area observations and uncertain coverage zone	The applicable relationship/limitation is displayed without inventing a precise activity point.
AC03	Invalid coordinates, unknown CRS or insufficient precision	Proximity is not established; no zero-distance or safe-result substitution occurs.
AC04	Historical assessment and Viewer configuration attempt	The stored geometry context is retained and configuration changes are denied.

Decisions still required: See DET-009.

SRS-GIS-104 — Risk Visualisation

Attribute	Specification
Status	Proposed response.
TM source	REQ-FUNC-053; URG-T19-R05.
Source modality	shall; all source conditions remain applicable.

The platform shall show available risk assessments by monitored asset or location on a map and in a ranked dashboard list.

Information displayed / data fields

Field	Specification
Asset/location	The monitored asset or location to which the assessment applies.
Assessment type	Historical or predictive, explicitly labelled.
Threat category and risk	Category, level and applicable legend/scale; readable labels accompany colour.
Time context	Historical data period or future prediction horizon, plus last assessment time.
Availability and freshness	Insufficient-data or stale indicator; age and failure/unknown-current-state information where applicable.
Supporting information	Drill-down links to contributing factors and source records subject to permission.

Functional behaviour

Clause	Required behaviour
B01	Use the same assessment snapshot and selected filters for the map and ranked list.
B02	Keep historical assessments and predictive assessments identifiable in both views.
B03	Apply the displayed legend/scale and include readable risk labels; colour alone must not convey risk level or missingness.
B04	Allow an authorised user to open an assessment and inspect its factors and supporting records.
B05	Represent risk only within the approved spatial unit; do not interpolate precise risk at unobserved points.
B06	Keep unlocated and unassessed records visible in the appropriate list state without inventing a map position or numeric risk.
B07	Enforce read permissions on assessment details and downloads.
B08	Keep asset, device and event views accessible when the risk calculation/model service fails.

Exceptions

Condition	Required handling
Calculation or model failure with a prior result	Retain the last labelled assessment, show its age and disclose failure/unknown current state.
No usable assessment	Show insufficient-data/unavailable state rather than an inferred risk level.
No usable location	Retain the record in the list; do not fabricate spatial precision.

Verification:

Criterion	Scenario / method	Expected result
AC01	Same snapshot with selected filters	Map features and ranked list reconcile to the same eligible assessment set; unlocated records remain identifiable in the list.
AC02	Historical and predictive examples	Type, category, level, data period or future horizon, assessment time and legend are correct.
AC03	Select an assessment	Permitted factors and supporting records open; restricted details/downloads remain denied.
AC04	Unassessed, stale and spatially bounded results	Readable states distinguish missingness and age; the view does not imply risk beyond the approved unit.
AC05	Scoring/model-service failure	The previous assessment remains labelled with age and unknown current state; asset/device/event views remain accessible.

SRS-GIS-105 — Hotspot Identification

Attribute	Specification
Status	Proposed response.
TM source	REQ-FUNC-092; URG-T23-R04.
Source modality	shall; all source conditions remain applicable.

The platform shall identify historical hotspots by aggregating eligible distinct fibre-related incidents under an approved recurrence method.

Information displayed / data fields

Field	Specification
Hotspot summary	Incident count, threat mix, period, supporting records and available severity/impact.

Functional behaviour

Clause	Required behaviour
B01	Group incidents by the agreed infrastructure unit, location/zone or segment and period.
B02	Apply the approved distinct-incident policy before aggregation; do not count every docket or detection as a separate fault.
B03	Identify and rank recurring hotspots using the approved criterion.
B04	Allow located unmatched incidents in eligible location-level calculations while excluding them from asset-specific calculations.
B05	Save grouping/method version and source snapshot or equivalent reproducible input reference.
B06	Label a hotspot as historical concentration; do not claim that it is future probability or proof of unsafe infrastructure.

Exceptions

Condition	Required handling
Unlocated, duplicate-review or insufficient-coverage records	Show outside the hotspot map/count where appropriate so omissions remain visible.

Verification:

Criterion	Scenario / method	Expected result
AC01	Repeated segment incidents, single event, duplicate dockets and located-unmatched records	Grouping, ranking and counts match the reviewed sample and distinct-incident policy.
AC02	Unlocated or insufficient-coverage data	Excluded records remain visible with their limitations; no unsupported hotspot count is claimed.
AC03	Changed spatial unit	The result identifies its applied method/grouping version and supporting records.

Decisions still required: See DET-010.

SRS-GIS-106 — Deployment Location

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-PHY-002; URG-T32-R03.
Source modality	shall; all source conditions remain applicable.

Each proposed device position shall have a documented placement and coverage rationale.

Information displayed / data fields

Field	Specification
Position	Coordinates/reference datum, associated asset and risk zone.
Installation proposal	Elevation/orientation where relevant, proposed mounting and placement rationale.

Functional behaviour

Clause	Required behaviour
B01	Evaluate proximity, visibility and access in relation to fibre routes, FDCs, manholes, poles, construction areas, road crossings, high-risk locations and other relevant infrastructure.
B02	Explain the threat approach or measurement zone covered, potential occlusion/interference, network/power availability and maintenance/physical-security constraints.
B03	Keep the device point location distinct from its coverage extent.
B04	If access or geometry prevents adequate coverage, identify the uncovered area and redesign placement or seek explicit acceptance of the limitation.

Verification:

Criterion	Scenario / method	Expected result
AC01	Survey/drawing reviewed against site photos and mapped assets	Coordinates, placement rationale and coverage overlays are traceable to the placement decision.
AC02	Representative threat approaches	Coverage and blind spots are recorded; inadequate coverage triggers redesign or explicit limitation acceptance.

SRS-GIS-107 — Centralised Dashboard

Attribute	Specification
Status	Proposed response.
TM source	REQ-APP-001; URG-T39-R02.
Source modality	shall; all source conditions remain applicable.

The platform shall provide one authenticated operational web interface with common navigation and linked records.

Functional behaviour

Clause	Required behaviour
B01	Provide site/asset/device status, detections, alerts, risk and case/workflow review with common site/date filters.
B02	In M2 show imported assets, manually registered device locations/status and received events.
B03	In M3 add historical/predictive risk, initial workflows/cases and basic downloadable summaries.
B04	Display last-update, source and quality information; distinguish empty, stale, unavailable and assessed low-risk states.
B05	Keep record-only detections searchable even when no alert exists.
B06	Open on-demand live view separately for permitted roles through the IoT service, with explicit start/stop and session audit.

Verification:

Criterion	Scenario / method	Expected result
AC01	Each role follows a device event	Navigation connects dashboard/map, evidence and permitted action/case without bypassing role restrictions.
AC02	Site/date selection across views	Results consistently respect selected filters.
AC03	Empty, stale and service-failure examples	States remain distinguishable with linked source records.
AC04	Record-only event and permitted live session	Event remains searchable; live start/stop is explicit and audited.

SRS-GIS-108 — Parameters

Attribute	Specification
Status	Proposed response.
TM source	REQ-APP-002; URG-T39-R03.
Source modality	shall; all source conditions remain applicable.

The platform shall display the required operational record categories without merging their distinct identities.

Information displayed / data fields

Field	Specification
Fibre infrastructure	Asset/route records and geometry where supplied.
Sensors	Locations from active and historical deployments.
Detected events	Source, time and evidence.
Predicted risks	Period, model, reasons and uncertainty; distinct from historical hotspots.
Alerts	Acknowledgement and priority.
Incidents/cases	Owner, status and outcome.
Workflows	Decision, approval, action and result.
Historical information	Explicit date scope.

Functional behaviour

Clause	Required behaviour
B01	Link each representation to its source detail and related records.
B02	Preserve separate event, alert and incident/case identities.
B03	Apply time/role filters consistently to display and export.
B04	Keep otherwise valid records in list views when geometry or risk is missing.

Exceptions

Condition	Required handling
Missing geometry or risk	Show unavailable/unresolved; do not suppress an otherwise valid list record.

Verification:

Criterion	Scenario / method	Expected result
AC01	Examples of all eight categories	Displayed parameters and linked details match source records.
AC02	Delayed event and relocated sensor	Historical deployment/time context remains correct.
AC03	Missing geometry/risk	The state is unavailable/unresolved while the valid record remains listed.
AC04	Filtered display and export	Both contain the same permitted, time-scoped data and distinguish history from prediction.

SRS-GIS-109 — Geographical View

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-APP-003; URG-T39-R04.
Source modality	should; all source conditions remain applicable.

The proposed geographical view should display supplied fibre geometry, registered sensor positions and validated risk spatial units.

Functional behaviour

Clause	Required behaviour
B01	Provide selectable layers, a legend, source period and detail links for points, areas or segments.
B02	Calculate proximity only when coordinate reference, geometry and an appropriate spatial method are known.
B03	Show observed sensor coverage separately from the area estimated to be at risk. State any location uncertainty that affects how the result should be interpreted.
B04	Keep unsupported or missing locations in a non-map list with an unresolved marker.

Verification:

Criterion	Scenario / method	Expected result
AC01	Known points, routes and risk areas	Map placement and overlays match the agreed reference dataset at relevant zoom levels.
AC02	Reference proximity cases	Distances match the agreed method and reference data.
AC03	Missing or invalid coordinates	Records remain in the non-map list with unresolved location; no unsupported distance is produced.

Decisions still required: See DET-011.

SRS-GIS-110 — Architecture

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-SITE-001; URG-T44-R02.
Source modality	shall; all source conditions remain applicable.

Each field site shall undergo a documented physical and infrastructure assessment before deployment.

Information displayed / data fields

Field	Specification
Survey record	Date, surveyor, site/map/photos, measurements and assumptions.
Open follow-up	Unavailable information and responsible follow-ups.

Functional behaviour

Clause	Required behaviour
B01	Assess fibre infrastructure and authoritative asset references.
B02	Assess physical setting, access and nearby activity.
B03	Assess candidate sensor placement and coverage.
B04	Assess available power and distribution.
B05	Measure or validate connectivity.
B06	Assess environmental exposure.
B07	Assess theft, tamper, privacy and safety risks.
B08	Assess mounting, structural, electrical, permission and installation constraints.
B09	Record unavailable information and responsible follow-ups; controlled M2 observations do not replace the field-site assessment.

Exceptions

Condition	Required handling
Critical assessment gap	Prevent dependent installation decisions until resolved.

Verification:

Criterion	Scenario / method	Expected result
AC01	Survey reviewed across all eight categories	Evidence includes observations/measurements and identifies assumptions or unknowns.
AC02	Material physical condition remains unknown	Desktop-map evidence alone does not approve the site; dependent installation decisions wait for critical gaps to be resolved.

3.2.4 Device Registration and Deployment

Purpose: Maintain device identity, deployment history, equipment traceability and evidence-based operational health.

Actors: Administrators manage device registration, relocation and operational health settings. Superadmins manage platform monitoring and technical diagnostics. Operators and Viewers inspect permitted records. Field Team members view device information needed for assigned work.

Submodules: Device inventory; registration and authorisation; deployment history; relocation; connectivity and health; configuration portability.

Boundaries: Connectivity is Online, Offline or Unknown with last-contact time and independently timed health readings. An IoT-service outage makes current state unverifiable, not automatically Offline. Initial location comes from registration; per-event GPS is not required. Inventory tracking does not imply an unapproved theft tracker or offline deterrence.

PL-DEV-001 — Device registration

Attribute	Specification
Status	Proposed.
Provenance	Baseline Sources#SRC-01

The platform shall register devices separately from infrastructure assets and associate them with a location or asset.

Functional behaviour

Clause	Required behaviour
B01	Create a distinct identity for an authorised device.
B02	Record its site and asset/location association for map placement.

Verification:

Criterion	Scenario / method	Expected result
AC01	Register an authorised device	Its separate device identity, linked asset/location/site and map position are correct.

PL-DEV-002 — Connectivity and health status

Attribute	Specification
Status	Proposed.
Provenance	Baseline Sources#SRC-01

The platform shall show connectivity and health with explicit freshness and availability.

Functional behaviour

Clause	Required behaviour
B01	Distinguish initial Unknown, current-contact Online and timeout-driven Offline states.
B02	Show stale or unavailable health readings independently of connectivity.
B03	During IoT-service interruption preserve last-known device information and mark current status unverifiable.

Verification:

Criterion	Scenario / method	Expected result
AC01	Unknown, current contact and contact timeout	The correct connectivity state is displayed.
AC02	IoT-service interruption	Last-known/unverifiable state appears without declaring all devices Offline.

PL-DEV-003 — Device relocation history

Attribute	Specification
Status	Proposed.
Provenance	User discussion, 2026-10-02 — relocation may follow successful deterrence or be planned for another reason.

The platform shall support planned relocation for any reason and preserve completed deployment history under the same device identity.

Information displayed / data fields

Field	Specification
Deployment history	Location/asset, coordinates, start/end dates.
Move record	Destination, reason, planned date, recording actor and any recorded outcome.

Functional behaviour

Clause	Required behaviour
B01	Record intended destination, reason and planned date without changing the current deployment.
B02	On completion close the previous deployment and create the new deployment under the existing device identity.
B03	Allow at most one active deployment for a device.
B04	Preserve each previous deployment’s coordinates and associated events.
B05	Keep each event’s original deployment and event-time coordinates unchanged.
B06	Permit planning and completion without requiring successful deterrence.

Verification:

Criterion	Scenario / method	Expected result
AC01	Plan A-to-B relocation unrelated to deterrence	Destination, reason and date are saved while A remains current.
AC02	Complete the move	A closes, B becomes the sole active deployment, and device identity remains unchanged.
AC03	Inspect history and previous events	A’s coordinates/events, deployment dates, reason, actor and any recorded outcome remain available.

SRS-DEV-101 — Device Identification

Attribute	Specification
Status	Proposed response.
TM source	REQ-INTHW-002; URG-T12-R03.
Source modality	shall; all source conditions remain applicable.

The platform shall register each device with a unique identity and an auditable deployment history.

Functional behaviour

Clause	Required behaviour
B01	Manually register the unique FALCON identity and relevant supplied hardware identity separately from TM asset records.
B02	Record site, location/coordinates, monitored-infrastructure link and explicit adapter mapping to the device-side identifier.
B03	Require registration before joining; unknown devices cannot join automatically.
B04	Implement planned/completed relocation under PL-DEV-003, retaining coordinates, events, dates, actor, reason and any outcome.
B05	Administrators control device registration and relocation. Record each change in the audit history.
B06	Associate delayed observations with the deployment containing original event time.
B07	Neither planning nor completing relocation implies successful deterrence.

Exceptions

Condition	Required handling
Duplicate identity or conflicting active deployment	Reject the conflicting registration/deployment.
Uncertain clock or event-time boundary	Flag the deployment link as uncertain instead of automatically linking the event to a different deployment.

Verification:

Criterion	Scenario / method	Expected result
AC01	Registration and duplicate attempt	The device registers once; duplicate identities are rejected.
AC02	Plan and complete A-to-B move for another reason	A remains current until completion; then B is the sole active placement with the same identity and preserved A history.
AC03	Late A observation after relocation	It links to A where event time supports the match; uncertain clock/boundary cases are explicitly flagged.

Decisions still required: See DET-012.

SRS-DEV-102 — Device Health

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-INTHW-003; URG-T12-R04.
Source modality	shall; all source conditions remain applicable.

Where device information is available, the platform shall show connectivity and health as separately evidenced states.

Functional behaviour

Clause	Required behaviour
B01	Show Online, Offline or Unknown with last-contact time.
B02	Retain device-supplied health values and measurement times; distinguish unavailable and stale readings.
B03	Proposed state rules are Unknown before valid contact, Online after authenticated contact within the freshness interval, and Offline after the agreed contact timeout while monitoring remains available.
B04	During an IoT-service outage retain last observed state as last-known and mark current status unverifiable.
B05	After recovery reconcile fresh contacts before presenting current device state.
B06	Allow Administrators to configure supported fields/thresholds and Operators/Viewers to inspect under read permissions.

Exceptions

Condition	Required handling
Online connectivity	Do not infer good battery, power or sensor health.
Unsupported field	Show a capability limitation, not a healthy value.

Verification:

Criterion	Scenario / method	Expected result
AC01	Initial state, authenticated contact and timeout boundary	Unknown, Online and Offline follow the agreed configuration.
AC02	Current contact with stale battery reading	Connectivity is current while battery freshness remains stale.
AC03	IoT-service outage and recovery	No blanket Offline transition occurs; current state returns only after fresh contact reconciliation.
AC04	Unsupported health field	Capability is shown as unsupported/unavailable without an invented healthy reading.

Decisions still required: See DET-013.

SRS-DEV-103 — Loss of Connectivity

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-INTHW-004; URG-T12-R05.
Source modality	shall; all source conditions remain applicable.

Where connectivity information is available, the platform shall record contact-loss episodes and recovery for each monitored device.

Functional behaviour

Clause	Required behaviour
B01	Compare valid contact with the configured timeout while monitoring remains available.
B02	Record device, last contact, detection time and monitoring basis for the loss condition; show an internal operational indication.
B03	Update one episode during repeated outage polls instead of generating an alert flood.
B04	Record restoration time after authenticated current contact.
B05	Distinguish historical communication gaps from confirmed device-side failure.
B06	Where selected edge/device capability supports buffering, forward retained original-time observations after reconnection and label delayed events.
B07	Apply configured permitted event age to prevent automatic stale deterrence.

Exceptions

Condition	Required handling
Central IoT-service outage	Mark current status unverifiable, preserving last-known data.

Verification:

Criterion	Scenario / method	Expected result
AC01	Device stops communicating while service remains healthy	One correctly timed loss episode appears.
AC02	Authenticated contact restored	The episode records recovery.
AC03	IoT service stopped separately	Last-known information remains and current status is unverifiable; no individual-device outages are fabricated.
AC04	Supported buffering delivers delayed observations	Records reconcile with original times; stale events do not issue automatic deterrent commands.

Decisions still required: See DET-014.

SRS-DEV-104 — System Monitoring

Attribute	Specification
Status	Proposed response.
TM source	REQ-OBS-001; URG-T29-R02.
Source modality	shall; all source conditions remain applicable.

The platform shall expose component health and freshness sufficient to identify actionable operational faults.

Information displayed / data fields

Field	Specification
Proposed monitoring signals	Last successful check/contact, observed status, queue age/backlog, error counts, storage pressure and component version.

Functional behaviour

Clause	Required behaviour
B01	Monitor the IoT service/broker, device contacts, platform/API, ingest/workflow queues, database, bucket access, background jobs, analytics and live-media service where present.
B02	Distinguish healthy, degraded/unavailable and unknown observations.
B03	Keep device Online/Offline/Unknown separate from central-service health.
B04	Route actionable monitoring faults to authorised maintainers with the affected component and evidence.
B05	Advance freshness only from actual observations; do not claim unmeasured sensors are healthy.

Verification:

Criterion	Scenario / method	Expected result
AC01	Representative component stopped	The relevant component condition and fault timestamp are visible.
AC02	Test queue/storage limit exhausted	A specific backlog/storage condition appears.
AC03	Component restored	Recovery is visible and monitoring freshness reflects actual checks.

SRS-DEV-105 — Physical Monitoring & Tracking

Attribute	Specification
Status	Proposed response.
TM source	REQ-PHY-006; URG-T32-R07.
Source modality	shall; all source conditions remain applicable.

The platform shall maintain physical equipment, deployment and maintenance traceability.

Information displayed / data fields

Field	Specification
Equipment	Identity, owner/custodian, serial/model/version and purchase/warranty reference where available.
Lifecycle	State, active placement, installed accessories and maintenance/replacement history.

Functional behaviour

Clause	Required behaviour
B01	Keep inventory ownership/location separate from Online/Offline/Unknown, last-contact and supplied health/power readings.
B02	Implement PL-DEV-003 planning without changing active placement until completion.
B03	On completed relocation close the old interval and create the new deployment under the same device ID, retaining reason, actor, destination and any outcome.
B04	Preserve original event placement/coordinates and source links.
B05	Treat tracking as inventory, deployment and health traceability without assuming GPS or an unapproved theft-tracker purchase.

Verification:

Criterion	Scenario / method	Expected result
AC01	Register/install and maintain a unit	Inventory reconciles with the equipment and maintenance/cost references.
AC02	Plan and complete relocation unrelated to deterrence	Only one active deployment remains; identity and historical event locations are preserved.

SRS-DEV-106 — Sensor Health

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-SENS-006; URG-T33-R07.
Source modality	shall; all source conditions remain applicable.

Where sensor information is available, the platform shall distinguish sensor health from contact and central-service availability.

Functional behaviour

Clause	Required behaviour
B01	Receive available heartbeat/contact and health fields through the IoT service with last-contact and reading times.
B02	Use configured contact timeout for Offline, initial/no trustworthy observation for Unknown and valid current contact for Online.
B03	Validate supplied readings against the selected sensor range/status.
B04	Flag abnormal, stuck or error-coded signals where data supports that check.
B05	Distinguish sensor failure, communication loss, stale measurement and central-service uncertainty.
B06	Retain unavailable status for missing or unsupported fields; Online does not prove every sensor channel valid.

Verification:

Criterion	Scenario / method	Expected result
AC01	Disconnect device or suppress heartbeat	Configured connectivity transitions and last-contact times are correct.
AC02	Invalid, stuck or error-coded sensor values	Distinct health reasons appear where the selected sensor supports validation.
AC03	IoT-service interruption and recovery	Last-known values, central uncertainty and recovery remain distinct from sensor failure.
AC04	Unsupported field	No fabricated normal reading appears.

SRS-DEV-107 — Inventory

Attribute	Specification
Status	Proposed response.
TM source	REQ-INST-003; URG-T43-R04.
Source modality	shall; all source conditions remain applicable.

Each installed equipment item shall have a unique inventory identity that preserves its lifecycle history.

Information displayed / data fields

Field	Specification
Item identity	Component, serial, manufacturer and version.
Ownership and installation	Owner, site/placement, installation date and installer.
Assembly/configuration	Configuration reference and parent assembly.

Functional behaviour

Clause	Required behaviour
B01	Include applicable sensors/cameras, controller/gateway, deterrent, power/battery/solar equipment, enclosure and passive protection.
B02	Keep TM infrastructure assets distinct from FALCON devices/equipment.
B03	Preserve identity and historical associations during replacement and relocation; do not reuse identifiers in a way that confuses history.
B04	Record spare, replaced and retired states and physical labels where feasible.
B05	Exclude credentials from inventory records.

Verification:

Criterion	Scenario / method	Expected result
AC01	Installed items and labels reconciled to BOM	Each applicable physical item has a unique inventory record.
AC02	Component replacement and device relocation	Current and historical associations/serials remain traceable without identity reuse.
AC03	Inventory inspection	No credentials are stored.

SRS-DEV-108 — Documentation

Attribute	Specification
Status	Proposed response.
TM source	REQ-INST-004; URG-T43-R05.
Source modality	shall; all source conditions remain applicable.

After installation, an as-built package shall document the actual deployed configuration and handover evidence.

Information displayed / data fields

Field	Specification
Placement	Actual coordinates/locations and deployment intervals.
Arrangement	Final drawings and cable, power and network arrangement.
Installed configuration	BOM/serials; firmware, software, model and configuration versions.
Interfaces	Endpoint/configuration references without secrets.
Sensor setup	Settings, calibration and coverage.
Assurance	Accepted changes/deviations and commissioning/test results.
Handover	Operations, maintenance and backup references.

Functional behaviour

Clause	Required behaviour
B01	Record the package checker, revision and completion date.
B02	Reconcile actual deviations against the approved design without silently replacing that baseline.
B03	Update the package after material relocation, replacement or configuration change.
B04	Retain checked package and unresolved exceptions.

Verification:

Criterion	Scenario / method	Expected result
AC01	As-built walkdown and configuration export comparison	Every installed item and observed deviation is traceable to the package.
AC02	Representative replacement/recovery	The operation can be reproduced from the package.
AC03	Material deployment change	The package revision reflects the changed installation and retained baseline deviations.

SRS-DEV-109 — Full Diagnostics

Attribute	Specification
Status	Proposed response.
TM source	REQ-O&M-002; URG-T46-R03.
Source modality	shall; all source conditions remain applicable.

The platform shall provide authorised diagnostics that distinguish evidence of failures across the field-to-platform path.

Information displayed / data fields

Field	Specification
Diagnostic context	Component/version, last successful observation and error/reason.
Supporting evidence	Correlation IDs, queue/backlog and relevant redacted configuration/health readings.

Functional behaviour

Clause	Required behaviour
B01	Distinguish device acquisition/health, power, bearer/contact, authentication/adapter, upload/queue, IoT service, application/workflow, database/bucket and model-service layers.
B02	Provide a next permitted check or runbook reference.
B03	Limit bundles to authorised operational evidence, redact credentials/personal content and audit access/export.
B04	Retain the relevant failure interval under the agreed retention policy so diagnostics remain useful after recovery.

Exceptions

Condition	Required handling
Only contact loss is known	Preserve unknown cause rather than inferring power or hardware failure.

Verification:

Criterion	Scenario / method	Expected result
AC01	Representative device, communication and central-service faults	Diagnostics identify the evidenced failed layer, correlate to logs and show recovery.
AC02	Contact loss without device-side evidence	Cause remains unknown; no unsupported power/device diagnosis appears.
AC03	Exported diagnostic bundle	Relevant failure evidence is retained, secrets/personal content are redacted and export is audited.

Decisions still required: See DET-015.

SRS-DEV-110 — Configuration Portability

Attribute	Specification
Status	Proposed response.
TM source	REQ-PORT-003; URG-T48-R04.
Source modality	shall; all source conditions remain applicable.

Where technically applicable, the platform shall transfer versioned site configuration through validated, staged bundles.

Functional behaviour

Clause	Required behaviour
B01	Export/import assets/reference mappings, location/geometry, sensor/channel/capability mappings, validated thresholds, rule/workflow versions and internal notification settings.
B02	Validate schema, identifier collisions, required capabilities and parameter ranges before staged application.
B03	Show proposed changes and audit who approved and applied them.
B04	Rebind environment-specific endpoint/credential references through secure provisioning; do not export secrets.
B05	Preserve configuration history and existing event/deployment associations.
B06	Apply new configuration prospectively without replaying withheld historical deterrent commands.

Exceptions

Condition	Required handling
Unsupported setting or unsafe hardware mismatch	Block activation and report the error.

Verification:

Criterion	Scenario / method	Expected result
AC01	Round-trip into a clean test site	Semantic settings and permissions match the approved configuration.
AC02	Missing capability, conflicting ID or unsafe hardware mismatch	Activation is blocked with explicit errors and rejected partial activation leaves history intact.
AC03	New configuration activated	Existing associations are unchanged and historical withheld commands are not replayed.

3.2.5 Risk Assessment and Prediction

Purpose: Produce explainable historical and predictive risk assessments to support reviewed preventive decisions.

Actors: Authorised users inspect assessments and evidence; Operators review uncertain results and intervention decisions; Administrators publish reviewed risk-threshold configurations; TM agrees assessment definitions and acceptance measures.

Submodules: Threat taxonomy; historical scoring; future prediction; ranking and confidence; explanations; insufficient-data handling.

Boundaries: Historical exposure is separate from future prediction. M3 frequency, recency and severity/impact factors remain provisional assumptions dependent on supplied data. Missing evidence is not low risk. Scores, ranks and confidence never independently authorise physical action; unresolved source wording and model acceptance remain explicit.

PL-RSK-001 — Explainable risk priorities

Attribute	Specification
Status	Proposed.
Provenance	Baseline Sources#SRC-01

The platform shall produce risk priorities with reasons and explicit uncertainty.

Functional behaviour

Clause	Required behaviour
B01	Link historical priorities to supporting records.
B02	Keep future prediction separately labelled from historical risk.
B03	Evaluate prediction against an agreed dataset, horizon and baseline.

Verification:

Criterion	Scenario / method	Expected result
AC01	Ranked historical result	The priority reconciles to supporting records and shows uncertainty.
AC02	Future prediction evaluation	Its label, horizon, dataset and baseline are separate from historical scoring.

Decisions still required: See DET-016.

SRS-RSK-101 — Risk Identification

Attribute	Specification
Status	Proposed response.
TM source	REQ-FUNC-010; URG-T15-R02.
Source modality	shall; all source conditions remain applicable.

For each eligible monitored asset or location, the platform shall calculate an assessment using its approved input profile.

Information displayed / data fields

Field	Specification
Assessment identity	Assessment ID, spatial unit, category and assessment time.
Calculation basis	Data period, method/model version and contributing records.
Outcome	Risk result and eligibility state.

Functional behaviour

Clause	Required behaviour
B01	Calculate the applicable historical indicator or predictive assessment for each eligible unit in a risk run.
B02	Rank and display potentially exposed locations with reasons and supporting records.
B03	For M3 begin with TM incident/docket and asset data and provisional frequency, recency and severity/impact factors where available.
B04	Assess input-field suitability and disclose calculation exclusions; do not invent weights, thresholds or missing severity.
B05	Keep historical exposure separate from prediction.
B06	Escalate predictive data insufficiency for a decision instead of silently replacing prediction with historical counts.

Exceptions

Condition	Required handling
No usable input	Show Not assessed/Insufficient data, never an inferred low risk.

Verification:

Criterion	Scenario / method	Expected result
AC01	Recurring incidents, quiet observed location and missing-coverage location	Reasons/source links reconcile; assessed low risk remains distinct from insufficient data.
AC02	Repeat run from stored input/method versions	The assessment can be reproduced.

Decisions still required: See DET-017.

SRS-RSK-102 — Risk Classification

Attribute	Specification
Status	Clarification required.
TM source	REQ-FUNC-011; URG-T15-R03.
Source modality	shall; all source conditions remain applicable.

The platform shall classify identified risks, while the complete minimum category obligation remains subject to TM clarification.

Functional behaviour

Clause	Required behaviour
B01	Preserve the source omission: REQ-FUNC-011 ends after “At minimum, the solution shall support:” without its list.
B02	Pending clarification, use Construction, Theft/vandalism and Animal/rodent as a proposed interpretation drawn from URG-T11-R04 and the explicitly covered threat scenarios.
B03	Retain classification source/method and category mapping with each result.
B04	Keep the unresolved source list in the review register; do not mark the complete source obligation satisfied by inference.
B05	Test any additional categories when TM supplies the missing list.

Exceptions

Condition	Required handling
Unmapped/uncertain classification	Show the limitation and require review before category-specific physical action.

Verification:

Criterion	Scenario / method	Expected result
AC01	One assessment for each independently required threat family	Shared labels, mapping and source/method are retained.
AC02	Unmapped or uncertain input	Classification is visibly unresolved and cannot trigger category-specific physical action without review.
AC03	Review of source-row completion	The missing list remains open; full completion awaits TM clarification and any additional-category tests.

Decisions still required: See DET-018.

SRS-RSK-103 — Risk Level

Attribute	Specification
Status	Proposed response.
TM source	REQ-FUNC-012; URG-T15-R04.
Source modality	shall; all source conditions remain applicable.

The platform shall assign eligible threat assessments to versioned risk levels under an approved configuration.

Information displayed / data fields

Field	Specification
Assessment result	Raw measure where meaningful, applied category/threshold version and resulting level.
Context	Evidence period and available uncertainty/limitations.

Functional behaviour

Clause	Required behaviour
B01	Propose configurable ordered levels with labels and boundaries approved during POC.
B02	Keep unassessed data outside the risk-level scale.
B03	Allow Administrators to publish reviewed threshold configurations.
B04	Apply changed thresholds to new assessments without silently relabelling historical results.
B05	Validate usefulness for intended response decisions as well as arithmetic correctness.
B06	Store validation evidence and approval state with the configuration; identify unvalidated trial levels as provisional.

Verification:

Criterion	Scenario / method	Expected result
AC01	Below, equal to and above each approved boundary	Risk levels follow the agreed comparison and can be reproduced from the stored version.
AC02	Missing input or invalid scale	No unsupported assessed level is presented.
AC03	Threshold changed	New assessments use the new configuration and old results remain traceable.
AC04	POC validation review	Evidence records decision usefulness, approval state and unresolved limitations.

Decisions still required: See DET-019.

SRS-RSK-104 — Rodent Risk Identification

Attribute	Specification
Status	Proposed response.
TM source	REQ-FUNC-042; URG-T18-R04.
Source modality	shall; all source conditions remain applicable.

The platform shall assess rodent risk for eligible fibre assets or locations using supplied evidence and a reviewed method.

Functional behaviour

Clause	Required behaviour
B01	Consider rodent-related incident history, repeated observed activity and relevant supplied site/infrastructure characteristics.
B02	Use initial historical frequency, recency and severity/impact factors where agreed; include other characteristics only when supplied and validated.
B03	Preserve factor values, source periods, method version, supporting events/incidents and outcome.
B04	Show eligible locations with rodent-risk level/ranking and reasons.
B05	Distinguish location characteristics and historical exposure from future-fault prediction.
B06	Use POC-agreed factors/thresholds for elevated-risk decisions; label unvalidated trials provisional.
B07	Do not treat a rodent-risk assessment alone as authority for deterrence.

Exceptions

Condition	Required handling
Unavailable site/environmental characteristics	Do not invent values or imply use.
Insufficient evidence	Show missing/insufficient data, not low risk.

Verification:

Criterion	Scenario / method	Expected result
AC01	Recurring rodent location and non-rodent animal location	Classification and factors reproduce from evidence without treating every animal event as a rodent.
AC02	Missing observation coverage	Insufficient data remains separate from low risk.
AC03	Historical versus future output	Labels and reasons distinguish exposure from future prediction.

Decisions still required: See DET-020.

SRS-RSK-105 — Preventive Alert

Attribute	Specification
Status	Proposed response.
TM source	REQ-FUNC-043; URG-T18-R05.
Source modality	shall; all source conditions remain applicable.

The platform shall evaluate validated animal/rodent risk against its configured intervention threshold and produce the qualifying preventive alert.

Functional behaviour

Clause	Required behaviour
B01	Retain the assessment, rule/version and threshold decision.
B02	At a qualifying threshold create or update the alert with supporting reasons, location and evidence.
B03	Retain a below-threshold assessment without requiring an alert.
B04	The proposed rule triggers when risk equals or exceeds the threshold. Confirm this comparison when approving the configuration.
B05	Route the alert to the configured Operator, automatic or hybrid workflow without treating the alert itself as deterrent authorisation.
B06	Apply permission, designated approval, maintenance prohibition, pause, cooldown, availability and permitted event age before action.
B07	Keep M2 manual operation sufficient; M3 automatic activation requires the specific action policy to be agreed.
B08	Record command result separately from the Operator’s threat outcome.

Exceptions

Condition	Required handling
Missing mandatory input	Flag for review rather than treating the assessment as a valid threshold decision.

Verification:

Criterion	Scenario / method	Expected result
AC01	Below, equal and above approved threshold	Alert behaviour matches the approved comparison and threshold provenance is retained.
AC02	Incomplete input and repeated qualifying detections	Missing mandatory data is flagged; alert creation/update/grouping follows the configured rule.
AC03	Maintenance, pause, cooldown or stale replay	Alerts can remain visible while prohibited automatic deterrence is withheld.
AC04	Permitted command completed	Command result and threat outcome are separately recorded.

Decisions still required: See DET-021.

SRS-RSK-106 — Fibre Fault Risk Prediction

Attribute	Specification
Status	Proposed response.
TM source	REQ-FUNC-050; URG-T19-R02.
Source modality	shall; all source conditions remain applicable.

The platform shall predict a defined fibre fault or fibre-related incident for an approved spatial unit and future monitoring period.

Information displayed / data fields

Field	Specification
Prediction definition	Target, approved unit/geometry and future horizon.
Run basis	As-of time, input cutoff and method/model version.
Output	Likelihood output and scale, available uncertainty and limitations.

Functional behaviour

Clause	Required behaviour
B01	Use only eligible input available by the prediction run’s cutoff.
B02	Label the output Prediction and keep it separate from historical frequency/hotspot indicators.
B03	Prepare candidate model and baseline results against reviewed outcomes and held-out time/location conditions under MD-PRED-001–008.
B04	Evaluate against TM-agreed acceptance measures and retain per-category errors and limitations.
B05	Do not describe an uncalibrated score as probability.
B06	Preserve the required prediction deliverable when evidence is insufficient; raise a scope decision instead of silently substituting counts.

Exceptions

Condition	Required handling
Insufficient labelled history or unsuccessful validation	Show an explicit limited/not-ready result and raise a scope decision.

Verification:

Criterion	Scenario / method	Expected result
AC01	Frozen inputs and model version	The run reproduces and records target, horizon, as-of time and cutoff; later outcomes do not leak into inputs.
AC02	Held-out cases against approved baseline	Acceptance evidence includes agreed measures, per-category errors and limitations.
AC03	Insufficient labelled history or failed validation/model path	The result is limited/not-ready with an explicit decision need; historical counts are not relabelled as accepted prediction.

Decisions still required: See DET-022.

SRS-RSK-107 — Risk Ranking

Attribute	Specification
Status	Proposed response.
TM source	REQ-FUNC-052; URG-T19-R04.
Source modality	shall; all source conditions remain applicable.

The platform shall rank eligible locations only when their approved risk measures can be compared.

Information displayed / data fields

Field	Specification
Ranked item	Rank, risk level/score, reason and assessment freshness.

Functional behaviour

Clause	Required behaviour
B01	Apply selected site/area, threat family, assessment type and period/horizon.
B02	Compare only compatible units and method versions; otherwise display separate labelled groups.
B03	Keep historical frequency scores separate from predictive probabilities.
B04	Give equal measures the same risk rank; use a stable identifier only to order display within a tie.
B05	Keep unassessed locations visible outside numeric ranking.
B06	Open contributing incidents/factors and any recommendation when a ranked location is selected.
B07	Refresh the current view for new assessments while retaining the assessment referenced by an Operator decision/intervention.
B08	Treat rank as decision support; it neither issues a physical command nor establishes urgency outside agreed policy.

Verification:

Criterion	Scenario / method	Expected result
AC01	Ordered risks, ties and insufficient-data locations	Ordering, equal ranks, stable tie display and unranked states are correct.
AC02	Incompatible horizons or methods	Separate groups prevent misleading cross-comparison.
AC03	New assessment after a preventive decision	Current ranking refreshes while the decision still traces to the assessment originally shown.

SRS-RSK-108 — Prediction Confidence

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-AIML-005; URG-T51-R06.
Source modality	shall; all source conditions remain applicable.

Where technically applicable, the platform shall retain and display the model-supplied confidence, probability or equivalent indicator with its interpretation.

Functional behaviour

Clause	Required behaviour
B01	Distinguish probability of the target outcome, detector confidence and operational risk priority.
B02	Identify indicator meaning, scale, model/version and applicable future horizon or observation period.
B03	Restrict prediction details and supporting records to authorised users.
B04	Prevent missing confidence from passing a decision rule that requires confidence.
B05	Do not fabricate numerical probabilities for historical rankings, deterministic rules or assistant answers.

Exceptions

Condition	Required handling
Source supplies no confidence	Show Not available and the known limitation; do not substitute zero.

Verification:

Criterion	Scenario / method	Expected result
AC01	Applicable prediction with authorised and denied users	Indicator/scale/version/time context is correct; protected details remain restricted.
AC02	Missing, boundary and invalid confidence values	Missing is distinct from zero and cannot satisfy a required confidence threshold.
AC03	Probability claim	A defined outcome and validation evidence support the interpretation rather than its numeric format alone.

Decisions still required: See DET-023.

SRS-RSK-109 — Risk Scoring

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-AIML-006; URG-T51-R07.
Source modality	shall; all source conditions remain applicable.

For applicable threats, the platform shall calculate a documented score or category for an identified spatial unit and assessment time.

Information displayed / data fields

Field	Specification
Assessment unit	Identified asset, location or segment and assessment time.
Scoring explanation	Method/version, period, used/missing factors and source records.

Functional behaviour

Clause	Required behaviour
B01	Publish the scoring method/version, input period, used and missing factors, and supporting source records.
B02	Evaluate relevance and availability of historical faults, location, environment, construction activity, prior theft/vandalism, animal/rodent activity, sensor observations, network/fibre characteristics, temporal patterns and other justified sources.
B03	Disclose unavailable factors rather than claiming their use.
B04	Initially consider frequency, recency and severity/impact as user-confirmed provisional M3 historical assumptions.
B05	Exclude missing severity or unresolved asset association only from calculations requiring that input; retain usable location-based records.
B06	For future-risk outputs identify the target and horizon.
B07	Keep unknown/insufficient evidence distinct from assessed low risk; a score alone does not authorise deterrence.

Verification:

Criterion	Scenario / method	Expected result
AC01	Sample score/category and ranked result	The output reconciles to the method/version and underlying records.
AC02	Missing impact, unresolved asset, duplicate dockets and no history	Omitted factors/coverage and calculation eligibility remain explicit without unsupported low-risk substitution.
AC03	Historical and future-risk outputs	Labels, target/horizon where applicable and evidence distinguish them.
AC04	Risk result without action authority	No unauthorised action follows.

Decisions still required: See DET-024.

SRS-RSK-110 — Model Explainability

Attribute	Specification
Status	Proposed response.
TM source	REQ-AIML-007; URG-T51-R08.
Source modality	shall; all source conditions remain applicable.

The platform shall present an operationally readable explanation with each prediction or risk assessment.

Functional behaviour

Clause	Required behaviour
B01	Identify principal contributing factors and the result’s meaning and limitations.
B02	Where technically applicable include contributing features, detected patterns, risk factors, confidence, prediction timestamp and relevant historical/contextual records.
B03	For historical risk show actual source counts, recency and impact inputs used.
B04	For prediction show the model-supported explanation method, target, horizon and data coverage.
B05	Apply normal permissions to supporting record links.
B06	Do not treat feature association or before/after change as proof of causation.
B07	If the proposed assistant is delivered, ground its explanation in linked results; it must not invent factors, confidence values or observations.

Exceptions

Condition	Required handling
Explanation item unavailable from the method	Mark it unavailable with a reason; an unexplained number is not sufficient operational justification.

Verification:

Criterion	Scenario / method	Expected result
AC01	Representative operational users review known examples	Principal factors, timestamps, context and applicable confidence trace to scoring/model records.
AC02	Unsupported factor or missing context	The explanation states a limitation and reason.
AC03	Assistant explanation, if delivered	Narrative matches underlying records without invented claims.

SRS-RSK-111 — Confidence Guardrail

Attribute	Specification
Status	Proposed response.
TM source	REQ-MLGRL-002; URG-T53-R03.
Source modality	shall; all source conditions remain applicable.

The platform shall apply versioned model/use-case-specific confidence or prediction thresholds to dependent decisions.

Functional behaviour

Clause	Required behaviour
B01	Allow authorised configuration of the indicator/scale, comparison operator and below-threshold behaviour.
B02	Retain the threshold version with every decision.
B03	Proposed default uncertain-result handling presents the result for review without its dependent automatic physical action; retain result and reason.
B04	Keep missing/invalid confidence distinct from a genuine low value; neither may pass a confidence-required rule.
B05	Apply evidence, approval, maintenance, cooldown and event-age controls even above the threshold.
B06	Keep classification confidence, predicted likelihood and risk-category thresholds distinct.
B07	Validate the relevant decision boundary when thresholds change; apply new evaluations without replaying historical predictions.

Verification:

Criterion	Scenario / method	Expected result
AC01	Below, equal and above configured boundary	Disposition follows the configured comparison and retains configuration audit/version.
AC02	Null, out-of-range or wrong-scale input	No confidence-required action passes; missing/invalid state remains distinct from low confidence.
AC03	Review-only disposition	Result and reason are visible without the dependent automatic action.
AC04	Above threshold with an independent restriction	Evidence/approval/maintenance/cooldown/event-age restrictions remain enforced.
AC05	Threshold changed	Boundary validation is recorded and new evaluations use the change without historical replay.

3.2.6 Workflow and Rule Management

Purpose: Evaluate validated events and model outputs, select permitted responses and retain the decision-to-outcome history.

Actors: Administrators configure rules and guardrails; authorised Operators review, approve and control operational responses; the IoT service delivers device commands.

Submodules: Rule configuration and versions; priorities; approval tasks; manual/automatic/hybrid paths; pauses; cooldowns; command restrictions.

Boundaries: Platform owns rule evaluation, priorities, approval, cases and closure. IoT service owns device connection/authentication, payload translation, delivery and bounded eligible command retries. The platform does not independently repeat an action during IoT delivery retry. Automatic deterrent policy and device-specific operating parameters remain subject to agreement.

PL-WFO-001 — Event rule evaluation

Attribute	Specification
Status	Proposed
Delivery / open scope	Initial M3
Provenance	URG-derived with user refinement; REQ-WFO-001, URG-T40-R02; REQ-FUNC-070, URG-T21-R02.

The solution shall evaluate validated events against configured conditions and select the configured response, including recording without operator notification or routing to an operator.

Verification:

Criterion	Scenario / method	Expected result
AC01	Record-only match	Event is retained without an Operator notification.
AC02	Operator-routing match	The configured Operator item/notification is produced.

PL-WFO-002 — Rule conditions

Attribute	Specification
Status	Proposed
Delivery / open scope	Initial M3
Provenance	Supporting refinement of REQ-WFO-001; user animal-at-midnight example and assistant condition proposal.

Rules shall support event type and time-window conditions.

Clause	Required behaviour
B01	Site/device and detection-confidence conditions are proposed initial refinements, subject to available event fields and agreement.

Verification:

Criterion	Scenario / method	Expected result
AC01	Matching and non-matching types and time boundaries, including a midnight-crossing window	Evaluation follows the agreed type and time conditions.
AC02	Optional conditions after the meaning of each field is agreed	Site/device and confidence conditions produce their agreed results.

Decisions still required: See DET-025.

PL-WFO-003 — Manual automatic and hybrid execution

Attribute	Specification
Status	Proposed
Delivery / open scope	Initial M3; action policy To Confirm
Provenance	REQ-FUNC-071/072, URG-T21-R03/R04; REQ-WFO-003, URG-T40-R04; user workflow direction.

Workflows shall support manual, automatic and hybrid handling.

Clause	Required behaviour
B01	Actions designated as requiring human approval shall not execute before approval.
B02	Automated steps shall execute only where approved.

Verification:

Criterion	Scenario / method	Expected result
AC01	Approval pending or rejected	The human-approval action does not execute.
AC02	Approved automatic and hybrid paths	Execution follows configured permissions.

Decisions still required: See DET-026.

PL-WFO-004 — Traceable response sequence

Attribute	Specification
Status	Proposed
Delivery / open scope	Initial M3; detailed lifecycle To Confirm
Provenance	REQ-WFO-002/004, URG-T40-R03/R05.

The workflow shall support Event → Validation → Risk Assessment → Decision → Action → Confirmation → Closure.

Clause	Required behaviour
B01	Execution and outcomes shall be traceable and auditable.

Verification:

Criterion	Scenario / method	Expected result
AC01	Qualifying response sequence	Evidence links validation, assessment, decision, action, confirmation and closure.
AC02	Failed or unconfirmed action	Its outcome is distinguishable from success.

Decisions still required: See DET-027.

SRS-WFO-001 — Rule versions

Attribute	Specification
Status	Proposed
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.

Administrators shall configure and enable rules.

Clause	Required behaviour
B01	Condition/action changes shall create a new version used for new evaluations.
B02	Existing decisions shall retain the version applied.
B03	Publishing a rule shall not replay historical events.

Verification:

Criterion	Scenario / method	Expected result
AC01	Enabled rule changed; new and historical events submitted	New evaluations reference the new version; existing decisions retain their applied version, with no unsolicited historical replay.

SRS-WFO-002 — Action restrictions

Attribute	Specification
Status	Proposed
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.

Before an automatic or manual device command, FALCON shall enforce authorisation, required approval, maintenance prohibition, device availability, command validity and cooldown.

Clause	Required behaviour
B01	Automatic actions shall also respect pauses and permitted event age.
B02	Maintenance prohibitions take precedence.
B03	Unresolved conflicting actions shall be held for Operator review.

Exception / condition	Required handling
Any command restriction fails	Withhold the command and record the reason; initial M3 manual action cannot override cooldown.
Unresolved conflicting actions	Hold for Operator review; maintenance prohibition takes precedence.

Verification:

Criterion	Scenario / method	Expected result
AC01	Otherwise matching rule combined with each command restriction	The prohibited action is withheld with its reason.
AC02	Manual command during cooldown in initial M3	Cooldown cannot be overridden.

SRS-WFO-003 — Pause and resume

Attribute	Specification
Status	Proposed
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.

An authorised Operator shall be able to pause automatic action for a permitted site/device with a reason and expiry.

Clause	Required behaviour
B01	After expiry, new events shall be evaluated under remaining restrictions.
B02	Withheld commands shall not be replayed automatically.

Exception / condition	Required handling
Pause expires	Evaluate new events under remaining restrictions; do not replay withheld commands.

Verification:

Criterion	Scenario / method	Expected result
AC01	Event received during an authorised pause, then a new event after expiry	Pause history is retained; the new event is evaluated under remaining restrictions and the withheld command is not replayed.

SRS-WFO-004 — Missing inputs

Attribute	Specification
Status	Proposed
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.

An unmatched event shall be retained without automatic physical action.

Clause	Required behaviour
B01	A rule evaluation missing a required input shall record the missing field and be made available for internal review.

Exception / condition	Required handling
Unmatched event	Retain without automatic physical action.
Required input missing	Record the missing field and make the evaluation available for internal review.

Verification:

Criterion	Scenario / method	Expected result
AC01	Unmatched event and event missing required context	Both are retained without physical commands; the missing field and internal-review reason are recorded.

SRS-WFO-101 — Response Workflow

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-070; URG-T21-R02
Source modality	shall; all source conditions remain applicable

A qualifying validated event selects its configured rule/workflow version and progresses through validation, risk assessment, decision, action, confirmation and closure as applicable.

Clause	Required behaviour
B01	Record each selected or withheld step and reason.
B02	The platform owns rules, priorities, approval, cases and closure.
B03	The IoT service owns device delivery/results.
B04	A record-only event does not require a case.
B05	Investigation, assignment or field intervention requires a linked case with one responsible operator.
B06	Selected high-severity rules may create a case automatically only where configured and agreed.
B07	Create one execution record per accepted qualifying decision, linking input events/alert, version, step state and results.
B08	A step waiting for approval or external result remains pending.
B09	Failure, cancellation and unconfirmed command result are explicit.
B10	Dependent steps do not run before successful prerequisite completion.
B11	Independent record/notification steps may continue when a physical action is withheld.
B12	Resume after restart from stored state without repeating completed physical steps.
B13	This is a minimal persisted workflow contract, not a requirement for a separate workflow-engine product.

Verification:

Criterion	Scenario / method	Expected result
AC01	Record-only, manual and hybrid flows, including waiting approval, failed device action and successful command with unresolved threat	Applicable stages, pending/failure states, selected version and outcomes are linked; command success remains distinct from threat resolution.
AC02	Processing restarted mid-flow	Stored version/step history remains intact without duplicate case creation or physical action.

SRS-WFO-102 — Automated Workflow

Attribute	Specification
Status	Proposed conditional response
TM source	REQ-FUNC-071; URG-T21-R03
Source modality	shall; all source conditions remain applicable

An Administrator enables a reviewed rule; only steps explicitly approved for automatic execution run without an operator decision.

Clause	Required behaviour
B01	Before a device action check valid inputs, applicable priority, maintenance prohibition, automatic-action pause, approval policy, device/service availability, permitted event age and cooldown.
B02	Unresolved conflicts are held for operator review.
B03	The IoT service alone performs bounded eligible command-delivery retries with the same command identity and verified duplicate-execution control.
B04	An operator can pause automatic actions for an authorised site/device with reason and expiry while recording/alert handling continues.
B05	Expiry restores evaluation for new events only, subject to remaining restrictions.
B06	Withheld commands are not replayed.
B07	A rule change applies to new evaluations.
B08	Manual commands continue to require their own authority and respect maintenance, availability and cooldown.
B09	Initial M3 includes no manual cooldown override.
B10	No automatic deterrent policy is selected by this SRS response.

Exception / condition	Required handling
Duplicate-execution control is unproven	Disable delivery retry under the selected policy.
Offline deterrence	Remain To Confirm pending device selection.

Verification:

Criterion	Scenario / method	Expected result
AC01	Approved automatic step with each guard independently activated	Eligible execution proceeds; each blocking guard retains the event/alert and records the withheld reason.
AC02	Pause expiry and rule change	New evaluations use applicable restrictions/version without historical replay.
AC03	Lost acknowledgement	IoT retries are bounded and retain command identity without duplicate physical execution; retry is disabled when this safety property is unproven.

Decisions still required: See DET-028.

SRS-WFO-103 — Human Approval

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-072; URG-T21-R04
Source modality	shall; all source conditions remain applicable

For a designated human-intervention action create a pending approval showing event/alert, target device/asset, requested action, supporting evidence/risk, rule/version, restrictions and expiry where configured.

Field / record	Specification
Context	Event/alert, target device/asset, requested action.
Decision basis	Supporting evidence/risk, rule/version and restrictions.
Expiry	Show where configured.
Approval record	Actor/time; reason where required; specific action identity and material parameters.

Clause	Required behaviour
B01	An authorised operator approves or rejects with recorded actor/time and reason where required.
B02	While pending or rejected no associated physical execution occurs.
B03	Approval is bound to the specific action identity and material parameters.
B04	Changed target/action or expired request requires renewed approval.
B05	Before dispatch verify the approved request remains current and maintenance, pause where applicable, cooldown, device availability and action-age conditions still permit it.
B06	Approval does not override a prohibition.
B07	Concurrent approve/reject attempts yield one recorded decision.
B08	Subsequent attempts receive current status.
B09	A withheld, expired or cancelled approved request remains visible with reason and does not become an implied failed threat response.

Exception / condition	Required handling
Target/action changes or request expires	Require renewed approval.
A restriction blocks an approved request	Withhold dispatch and retain visible reason; approval does not override prohibition.

Verification:

Criterion	Scenario / method	Expected result
AC01	Pending, approved, rejected, expired and changed-target requests	Only a current permitted approval for the exact action/target can reach execution; changed target or expired request requires renewed approval.
AC02	Concurrent approval/rejection attempts	One decision is recorded; later attempts receive current status.
AC03	Maintenance or cooldown imposed after approval before dispatch	No prohibited command is dispatched.
AC04	Viewer approval attempt and approved identity tracing	Viewer approval is denied; the authorised action identity remains linked through IoT command/result.

SRS-WFO-104 — Workflow Engine

Attribute	Specification
Status	Proposed response
TM source	REQ-WFO-001; URG-T40-R02
Source modality	shall; all source conditions remain applicable

Persist validated events and evaluate the applicable enabled rule version against agreed event type/time and other approved available inputs.

Clause	Required behaviour
B01	Apply priorities and restrictions, then record only, route internally, request human approval or request an authorised action.
B02	Unmatched events are retained without automatic physical action.
B03	Incomplete inputs and unresolved conflicts are held for review.
B04	Group qualifying detections under one active alert without deleting individual events.
B05	The platform owns rules/decisions/cases.
B06	The IoT service delivers identified commands and owns eligible bounded retries.
B07	Rule changes apply to new evaluations, not automatic historical replay.

Verification:

Criterion	Scenario / method	Expected result
AC01	Matched record-only, review and approved-action fixtures	Selected rule version, event/alert links and action or withheld reasons match the configured route.
AC02	Unmatched, incomplete and conflicting fixtures	Events remain retained; no automatic physical action occurs for unmatched input and incomplete/conflicting inputs are available for review.
AC03	Maintenance and duplicate-event cases, using actual selected-device integration where applicable	Maintenance prohibits activation and duplicate controls preserve the agreed event/action identities.

SRS-WFO-105 — Structural Process

Attribute	Specification
Status	Proposed response
TM source	REQ-WFO-002; URG-T40-R03
Source modality	shall; all source conditions remain applicable

Persist the chain Event → Validation → Risk Assessment → Decision → Action → Confirmation → Closure with identities and status/reason/time at each applicable stage.

Clause	Required behaviour
B01	Validation may reject/quarantine incomplete input.
B02	Assessment may show insufficient data.
B03	Decision may be record-only, pending approval, withheld or authorised.
B04	Device commands retain Requested, Sent, Confirmed, Failed, Expired or Unconfirmed distinct from case Open/In Progress/Closed.
B05	Confirmation uses defined device-specific execution evidence.
B06	Successful dispatch or execution does not establish threat resolution.
B07	M3 operators close a case with configured outcome and note, optional evidence.
B08	Record-only events need no artificial physical action or case solely to complete a diagram.

Verification:

Criterion	Scenario / method	Expected result
AC01	Successful, rejected, pending-approval, failed/unconfirmed and record-only paths	Applicable stage identities, states, reasons and times reconstruct each path without artificial actions/cases.
AC02	Successful command with unresolved threat	Command success neither closes the case by itself nor labels the threat resolved.

SRS-WFO-106 — Automation and Human-in-the-loop.

Attribute	Specification
Status	Proposed conditional response
TM source	REQ-WFO-003; URG-T40-R04
Source modality	shall; all source conditions remain applicable

Support automated, human-approved and hybrid workflow steps using configured action permissions.

Clause	Required behaviour
B01	An approval-required action remains pending until an authorised approval of the specific request.
B02	Rejection/expiry does not execute it.
B03	Automatic steps run only when the rule/action has been explicitly authorised and all required inputs, device availability, event-age, maintenance, pause and cooldown checks pass.
B04	Recheck restrictions at delivery/retry.
B05	Manual commands also respect cooldown, with no initial M3 manual override.
B06	Pause expiry resumes new evaluations without replaying withheld commands.
B07	This architecture does not choose deterrent type, operating hours/limits or an offline/field-safe action policy.
B08	Those remain approval gates for actual actuation.

Verification:

Criterion	Scenario / method	Expected result
AC01	Automatic, pending/approved/rejected, hybrid, expired, paused, maintenance-blocked and cooldown-blocked cases	Each path respects its configured permissions and restrictions.
AC02	Restriction changed between approval and dispatch	The changed restriction is honoured; no prohibited command executes.
AC03	Actual device outcome observation	Evidence is collected only under the agreed controlled test policy.

SRS-WFO-107 — Decision Guardrail

Attribute	Specification
Status	Proposed response
TM source	REQ-MLGRL-003; URG-T53-R04
Source modality	shall; all source conditions remain applicable

Route AI/ML outputs into platform-owned decision rules.

Clause	Required behaviour
B01	A prediction may create an advisory display or review item.
B02	An operational action is eligible only when its action type, conditions, target scope and mode have been explicitly authorised and enabled.
B03	Retain prediction and rule/version identifiers with the decision, including a blocked/no-action reason.
B04	Apply the existing workflow priorities: maintenance restrictions prohibit activation, unresolved conflicts go to operator review, designated actions require approval, and pauses, cooldowns, device availability and permitted event age continue to apply.
B05	Manual commands also respect cooldowns in initial M3.
B06	The platform requests permitted device actions through the IoT service, which owns delivery retries.
B07	The model never calls devices directly.
B08	The M4 chatbot remains read-only even for an otherwise authorised operator.
B09	New automatic uses require a recorded decision, not merely a high confidence score.

Verification:

Criterion	Scenario / method	Expected result
AC01	Same prediction with advisory-only, enabled automatic and approval-required rules	Each decision follows the authorised mode and retains prediction/rule-version references.
AC02	Disabled/unconfigured action; maintenance, conflict, pause, cooldown, stale-data or unavailable-device condition	No prohibited command issues and the blocked/no-action reason is retained.
AC03	Permitted device action and chatbot execution attempt	The action passes through platform and IoT service; the read-only chatbot cannot execute it.

SRS-WFO-108 — Guardrail Configuration

Attribute	Specification
Status	Proposed response
TM source	REQ-MLGRL-008; URG-T53-R09
Source modality	shall; all source conditions remain applicable

Expose guardrail thresholds, decision/corroboration rules and approval requirements only to users with the relevant configuration permission.

Clause	Required behaviour
B01	Proposed initial allocation follows existing rule administration: Administrators configure/enable.
B02	Operators review and exercise authorised operational decisions without acquiring rule-edit permission.
B03	Viewers cannot change controls.
B04	Specialist model-release authority is separately assigned and is not inferred from a job title.
B05	Validate required fields, scales/ranges, references and conflicts before enabling a configuration.
B06	Store the previous and new values, version, actor/time and reason.
B07	Every evaluation retains the version it used.
B08	Changes apply to new evaluations and do not retroactively replay actions.
B09	A configuration with unresolved safety conflicts cannot enable automatic execution.
B10	Ordinary verification checks are required, but this does not add the user-rejected in-product rule-testing feature.

Exception / condition	Required handling
Unresolved safety conflict	Do not enable automatic execution.

Verification:

Criterion	Scenario / method	Expected result
AC01	Administrator, Operator and Viewer configuration attempts	Permission-appropriate changes succeed or are denied, with audit evidence.
AC02	Invalid scale/range, missing approval role or conflicting actions	Invalid configuration is not enabled; unresolved conflicts receive the required review treatment.
AC03	Evaluation before and after an authorised change	Each result retains its version; historical decisions stay unchanged and actions are not replayed.

SRS-WFO-109 — Human Override

Attribute	Specification
Status	Proposed response
TM source	REQ-HITL-004; URG-T55-R05
Source modality	shall; all source conditions remain applicable

Permit an appropriately authorised user to reject, defer or replace an AI/ML recommendation within the allowed operational workflow and record the original recommendation, chosen treatment, reason, actor/time and linked outcome.

Clause	Required behaviour
B01	Preserve model output and the override as separate records.
B02	Proposed M3 overrides apply to review/classification and permitted response choices.
B03	M4 operators may accept/dismiss/defer preventive recommendations with reasons.
B04	An override does not confer new permissions or bypass maintenance prohibitions, unsupported device operations, action-age validity or other mandatory restrictions.
B05	Initial M3 manual commands still respect cooldowns.
B06	If the desired response is outside the user’s permission or currently blocked, retain the request/reason for authorised review without executing it.
B07	Overridden recommendations can inform evaluation but do not automatically become ground truth or cause model retraining.

Exception / condition	Required handling
Requested response lacks permission or is blocked	Retain request/reason for authorised review without executing it.

Verification:

Criterion	Scenario / method	Expected result
AC01	Permitted rejection/replacement and Viewer or otherwise unauthorised attempt	Allowed treatment retains original and revised decisions/reasons; unauthorised treatment is denied.
AC02	Override requesting a maintenance-blocked or cooldown-blocked command	No command executes.
AC03	Permitted response followed to outcome	Workflow/outcome remains traceable separately from prediction correctness.

SRS-WFO-110 — Automated Preventive Action

Attribute	Specification
Status	Proposed conditional response
TM source	REQ-MLIN-002; URG-T57-R03
Source modality	shall; all source conditions remain applicable

Where explicitly configured and authorised, a qualifying model result can initiate the relevant preventive/mitigation workflow.

Clause	Required behaviour
B01	Persist links for the full Prediction → Risk Assessment → Decision → Action → Outcome chain, including no-action, rejected, failed or unconfirmed branches.
B02	If the model result already contains the risk assessment, link to that assessment; do not create a second one solely to represent the same result.
B03	Initial preventive logic uses configured risk-to-approved-action rules.
B04	A workflow can present a recommendation/create a permitted follow-up case or request a designated approval.
B05	It does not imply unattended physical execution.
B06	Before any allowed action, recheck rule version, evidence/confidence, authorisation, maintenance, pause, cooldown, age and availability constraints.
B07	Execute device commands only through the IoT service.
B08	The read-only chatbot is not an action trigger and does not gain tool execution through this row.

Verification:

Criterion	Scenario / method	Expected result
AC01	Configured authorised route; automation disabled; approval denied; safety restriction active	Only the permitted route proceeds, with explicit pending/no-action or blocked treatment for the others.
AC02	Prediction-to-outcome trace	The record links all five stages and identifies any stage that is pending or requires no action. Device commands still follow the required controls. The final outcome is recorded separately from service or device acknowledgement.

3.2.7 Events and Alerts

Purpose: Retain genuine detections, group qualifying activity into alerts and support traceable Operator handling.

Actors: Operators use the shared queue, acknowledge and review alerts; authorised users inspect evidence; Administrators maintain permitted configuration.

Submodules: Event ingestion; event evidence; classification; grouping; shared queue; acknowledgement; priority; escalation; lifecycle and closure.

Boundaries: Acknowledgement is separate from case ownership. Investigation, assignment or field intervention uses a linked case; a reviewed No threat found, Duplicate or Unable to verify alert may close without one, with outcome and note. RWD-001–006 are confirmed for drafting only; all requirements remain Proposed for TM review. Alert state representation and remaining transition/grouping details are subject to section 5.3.

PL-EVT-001 — Event records

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-01

Register events with location, time, source, and supporting evidence.

Verification:

Criterion	Scenario / method	Expected result
AC01	Known detections received and one retransmitted	Source, time, location and available evidence match the detections; retransmission creates no duplicate event.

PL-EVT-002 — Alert handling

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-01

Support duplicate review, prioritisation, notification, and acknowledgement.

Verification:

Criterion	Scenario / method	Expected result
AC01	Configured grouping, priority, notification, acknowledgement and internal escalation	Handling follows configuration and retains every underlying detection.

SRS-EVT-001 — Individual detection records

Attribute	Specification
Status	Proposed
Provenance	PL-EVT-001; REQ-INTHW-001/002; REQ-FUNC-090.

FALCON shall retain each accepted genuine detection as an individually identifiable event with its originating device, event time and location association.

Verification:

Criterion	Scenario / method	Expected result
AC01	Two distinct detections from one device	Two event records are retrievable, each with its originating device, time and location association.

SRS-EVT-002 — Original and receipt timestamps

Attribute	Specification
Status	Proposed
Provenance	PL-EVT-001; existing delayed-event drafting decision; REQ-SENS-007.

FALCON shall retain the original event time separately from the IoT service receipt time.

Verification:

Criterion	Scenario / method	Expected result
AC01	Delayed event delivery	Original event time and IoT receipt time retain their separate respective values.

SRS-EVT-003 — Source-event retransmission

Attribute	Specification
Status	Proposed
Provenance	PL-EVT-001/002; supporting refinement of REQ-FUNC-064.

Retransmission of the same accepted source event shall not create an additional event record.

Exception / condition	Required handling
Repeated source identity and payload	Retain one event under the adapter-specific identity rule.

Verification:

Criterion	Scenario / method	Expected result
AC01	Same source identity and payload submitted twice	Only one event record exists, using the identity rules specified per adapter.

SRS-EVT-004 — Record-only event retention

Attribute	Specification
Status	Proposed
Provenance	PL-EVT-001/002; PL-WFO-001; existing drafting decision.

For an event evaluated as record-only, FALCON shall retain the event without creating an operator alert notification.

Verification:

Criterion	Scenario / method	Expected result
AC01	Record-only rule applied	The event remains available and no Operator alert notification is created for it.

SRS-EVT-005 — New alert creation

Attribute	Specification
Status	Proposed
Provenance	PL-EVT-002; REQ-FUNC-060.

FALCON shall create an alert when an event meets a configured alert rule and does not qualify for an existing active alert’s grouping rule.

Verification:

Criterion	Scenario / method	Expected result
AC01	Alert-rule match with no eligible active alert	One alert is created and linked to the event.

SRS-EVT-006 — Cross-device alert grouping

Attribute	Specification
Status	Proposed
Provenance	PL-EVT-002; existing grouping decision; proposed treatment of REQ-FUNC-064, whose source modality is should.
Source modality	REQ-FUNC-064: should; detailed grouping treatment remains Proposed.

FALCON shall link genuine detections with the same configured event type and location/zone within the grouping window to one eligible active alert, including detections from different devices.

Verification:

Criterion	Scenario / method	Expected result
AC01	Qualifying detections from two devices	One eligible active alert links both separately retained events under SRS-EVT-015; exact boundary, late-arrival and competing-alert rules remain in section 5.3.

Decisions still required: See DET-029.

SRS-EVT-007 — Alert details and evidence access

Attribute	Specification
Status	Proposed
Provenance	PL-EVT-001/002; REQ-INTUI-004.

An authorised user shall be able to open an alert and access its linked event details and available evidence.

Verification:

Criterion	Scenario / method	Expected result
AC01	Authorised user opens a known alert	Device, location, time, category and available evidence links match the originating records.

SRS-EVT-008 — Acknowledgement audit

Attribute	Specification
Status	Proposed
Provenance	PL-EVT-002; REQ-INTUI-005; REQ-FUNC-063.

FALCON shall record acknowledgement of an alert with the acknowledging Operator and acknowledgement time.

Verification:

Criterion	Scenario / method	Expected result
AC01	Operator acknowledgement; Viewer-only acknowledgement attempt	Operator actor/time is recorded; Viewer acknowledgement is denied.

SRS-EVT-009 — Shared Operator queue

Attribute	Specification
Status	Proposed
Provenance	PL-EVT-002; REQ-FUNC-062; user decision RWD-002.

FALCON shall present new qualifying M3 alerts in a shared in-application Operator queue.

Verification:

Criterion	Scenario / method	Expected result
AC01	Qualifying new M3 alert before case assignment	Two Operator accounts can find and open the same alert in the shared in-application queue.

SRS-EVT-010 — Acknowledgement independent of ownership

Attribute	Specification
Status	Proposed
Provenance	PL-EVT-002; REQ-INTUI-005; user decision RWD-002.

Acknowledging an alert shall record acknowledgement independently of case assignment.

Verification:

Criterion	Scenario / method	Expected result
AC01	Acknowledgement without a case and with an assigned case	Actor/time is recorded independently; existing case ownership does not change.

SRS-EVT-011 — Reviewed closure without a case

Attribute	Specification
Status	Proposed
Provenance	PL-EVT-002; REQ-INTUI-005; REQ-FUNC-063; user decision RWD-001.

An authorised Operator shall be able to close a reviewed alert without a case when the recorded outcome is No threat found, Duplicate or Unable to verify.

Clause	Required behaviour
B01	Closure shall require an outcome and note.

Exception / condition	Required handling
Outcome or note missing	Reject closure and preserve previous state.

Verification:

Criterion	Scenario / method	Expected result
AC01	Reviewed alert without a case closed with each permitted outcome and a note	No threat found, Duplicate and Unable to verify each produce Closed status with saved outcome/note.
AC02	Missing outcome or closure note	Closure is rejected and previous alert state is preserved.

SRS-EVT-012 — Case-required handling

Attribute	Specification
Status	Proposed
Provenance	PL-CAS-002/005; REQ-FUNC-070; user decision RWD-001.

Alert handling that requires investigation, assignment or field intervention shall use a linked case.

Verification:

Criterion	Scenario / method	Expected result
AC01	Investigation, assignment and field-intervention examples	Each handling path uses a case linked to the originating alert.

SRS-EVT-013 — Case-derived alert ownership

Attribute	Specification
Status	Proposed
Provenance	PL-CAS-004; REQ-INTUI-005; REQ-FUNC-063; user decision RWD-003.

An alert linked to a case shall display that case’s responsible Operator and shall not maintain a separate editable alert assignee.

Verification:

Criterion	Scenario / method	Expected result
AC01	Case assigned/reassigned; alert ownership inspected through UI and API	The alert shows current case ownership and cannot store a separate conflicting editable assignee.

SRS-EVT-014 — Non-resolution closure outcomes

Attribute	Specification
Status	Proposed
Provenance	PL-CAS-008; REQ-FUNC-063/101; supporting refinement of RWD-001 and the existing outcome distinction.

Closing an alert as No threat found, Duplicate or Unable to verify shall not record the threat as addressed or resolved.

Verification:

Criterion	Scenario / method	Expected result
AC01	Alert closed as No threat found, Duplicate or Unable to verify	No threat-resolved finding or threats-addressed count is created by any of these outcomes.

SRS-EVT-015 — Fixed grouping window

Attribute	Specification
Status	Proposed
Provenance	PL-EVT-002; REQ-FUNC-064; user decision RWD-004.

FALCON shall group qualifying detections within a configurable fixed window starting at the first qualifying detection.

Clause	Required behaviour
B01	Later detections shall not extend that window.

Verification:

Criterion	Scenario / method	Expected result
AC01	Test duration W; first qualifying detection t0; matching detection before t0+W	The later detection joins the alert and the grouping end remains t0+W. W is test configuration, not an approved production value.

SRS-EVT-016 — New detections after closure

Attribute	Specification
Status	Proposed
Provenance	PL-EVT-002; REQ-FUNC-060/063/064; user decision RWD-005.

A new qualifying detection occurring after an alert has closed shall create a new alert rather than reopen or modify the closed alert.

Verification:

Criterion	Scenario / method	Expected result
AC01	New qualifying detection of the same type/zone after alert closure	A new alert identity is created and closed-alert history is unchanged. Existing-event retransmission follows SRS-EVT-003.

SRS-EVT-017 — Optional linked-alert closure

Attribute	Specification
Status	Proposed
Provenance	PL-CAS-006/008; REQ-INTUI-005; REQ-FUNC-063; user decision RWD-006.

When an Operator closes a case with a linked alert, FALCON shall offer “Also close linked alert”.

Clause	Required behaviour
B01	If selected, alert closure shall require the Operator to confirm the alert outcome.

Exception / condition	Required handling
Alert outcome is not confirmed	Do not close the alert; combined-closure transaction policy remains To Confirm.

Verification:

Criterion	Scenario / method	Expected result
AC01	Case closure with Also close linked alert selected and alert outcome confirmed	The linked alert closes with that confirmed outcome.
AC02	Combined closure without confirmed alert outcome	The alert cannot close.

Decisions still required: See DET-030.

SRS-EVT-018 — Independent case closure

Attribute	Specification
Status	Proposed
Provenance	PL-CAS-008; REQ-FUNC-063; user decision RWD-006.

Closing a case without the Operator selecting “Also close linked alert” shall leave the linked alert in its existing state.

Verification:

Criterion	Scenario / method	Expected result
AC01	Case closure without Also close linked alert selected	The case closes and the linked alert retains its prior state.

SRS-EVT-101 — Threat Classification

Attribute	Specification
Status	Proposed response
TM source	REQ-INTUI-003; URG-T11-R04
Source modality	shall; all source conditions remain applicable

Every classified observation, alert and risk result carries a threat-family value: Construction, Theft/vandalism, or Animal/rodent.

Clause	Required behaviour
B01	Display the family as text as well as any visual marker and identify whether the record represents detected activity, assessed historical risk or a future prediction.
B02	Applicable category is derived from approved source mapping or reviewed model/rule output.
B03	An unmapped input remains Unclassified with the raw source label preserved.
B04	Unclassified is a review condition, not a fourth supported threat family.
B05	Administrators may maintain reviewed source-label mappings under configuration control.
B06	Individual operator corrections retain the original value, reason and actor as a proposed audit refinement.
B07	This response does not infer the missing list in REQ-FUNC-011.

Exception / condition	Required handling
Unmapped input	Keep Unclassified and the raw label; do not silently invoke a category-specific automatic action.

Verification:

Criterion	Scenario / method	Expected result
AC01	One accepted example per family, a future-risk result and an unmapped source label	Labels propagate consistently through map, details, alerts and reports; result kind is distinguishable and the raw unmapped label remains visible as Unclassified.
AC02	Unclassified record evaluated for category-specific automatic action	It cannot silently enter that action.

Decisions still required: See DET-031.

SRS-EVT-102 — Event Details

Attribute	Specification
Status	Proposed response
TM source	REQ-INTUI-004; URG-T11-R05
Source modality	shall; all source conditions remain applicable

An event detail view exposes event identity, registered device/source, original event time, IoT-service receipt time, threat/type and available evidence, using the applicable deployment/location rather than a relocated device’s current coordinates.

Field / record	Specification
Identity and source	Event identity and registered device/source.
Time and location	Original event time, IoT receipt time and applicable event-time deployment/location.
Classification and assessment	Threat/category; supplied confidence and risk separately labelled with scale/basis; absent confidence is not zero.
Context and evidence	Affected fibre asset, evidence, recommended action and event status where available; unresolved/unavailable data explicit.
Related records	Alert, action/command and case links, with their separate states.

Clause	Required behaviour
B01	Source-provided confidence is optional and absent confidence is not zero.
B02	Show related alert, action/command and case records separately.
B03	Include location, date/time, threat category, detection source, confidence/risk level, affected fibre asset, evidence, recommended action and event status where available.
B04	Confidence and risk are separately labelled with their scale/basis.
B05	Unresolved asset association and unavailable evidence are explicit.
B06	Event receipt/assessment state, alert lifecycle, command state and case outcome must not be collapsed into one status.
B07	Evidence access follows record permissions.
B08	Unavailable media does not erase the event.

Exception / condition	Required handling
Evidence unavailable or denied	Keep the event; show unavailable evidence explicitly and deny unauthorised access.

Verification:

Criterion	Scenario / method	Expected result
AC01	Full data, absent confidence, absent evidence, unresolved asset and delayed delivery	Fields show their source or explicit absence; confidence is not replaced by zero and record links/states remain distinct.
AC02	Evidence access without permission	Access fails.
AC03	Device relocated after the event	Event detail retains its event-time placement.

SRS-EVT-103 — Alert Acknowledgement

Attribute	Specification
Status	Proposed response
TM source	REQ-INTUI-005; URG-T11-R06
Source modality	shall; all source conditions remain applicable

An Operator shall acknowledge an active alert, escalate it with a reason and record a permitted closure outcome and note.

Clause	Required behaviour
B01	Acknowledgement records the actor/time.
B02	It does not assign ownership.
B03	When investigation, assignment or field intervention is needed, handling shall use a linked case.
B04	The alert shall display the linked case’s responsible Operator without storing a separate alert assignee.
B05	The platform shall reject forbidden or stale concurrent lifecycle updates without overwriting history.
B06	No threat found, Duplicate and Unable to verify permit reviewed closure without a case.
B07	None establishes Threat addressed.
B08	A confirmed command alone shall not resolve or close an alert.
B09	RWD-001–003 and RWD-006 govern the detailed rules below.
B10	This is the proposed case-based interpretation of TM’s alert-assignment obligation and requires TM agreement.

Verification:

Criterion	Scenario / method	Expected result
AC01	Acknowledgement using two Operator accounts; case assignment/reassignment	Actor/time is retained, ownership follows the linked case and no separate alert-assignment field is editable.
AC02	Escalation, no-case closure, Viewer action and stale lifecycle update	Permitted handling succeeds with history; denied or stale updates cannot overwrite it.
AC03	Command completion	The alert does not close solely because the command completed.

SRS-EVT-104 — Construction Risk Alert

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-022; URG-T16-R04
Source modality	shall; all source conditions remain applicable

When a validated construction observation satisfies an enabled rule using applicable activity, proximity/zone, asset context and other approved inputs, create or update the qualifying active alert and record the matched rule/version, risk level, supporting events and affected location/asset.

Clause	Required behaviour
B01	A non-qualifying detection remains recorded.
B02	If required proximity or activity data is missing, flag the assessment for review. Do not automatically classify it as safe or as meeting the alert rule.
B03	Apply agreed type/location/time grouping while preserving individual observations, and route qualifying alerts to internal operator handling.
B04	When investigation, assignment or field intervention is needed, a linked case is required.
B05	Any reuse of an existing case follows the agreed linkage rules.
B06	The source does not authorise a physical intervention.
B07	Any automatic or approved action uses the shared permissions, restrictions and outcome distinctions.
B08	Construction detector availability remains separate from the earlier reusable workflow framework.

Exception / condition	Required handling
Required proximity/activity input missing	Flag review rather than an automatically safe or qualifying result.

Verification:

Criterion	Scenario / method	Expected result
AC01	Approved construction-rule boundaries below/at/above, missing proximity, repeated matches and non-match	Alert count, retained evidence, rule/version and internal queue match the approved rule; missing inputs receive review treatment and no unapproved physical action occurs.

SRS-EVT-105 — Supporting Evidence

Attribute	Specification
Status	Proposed conditional response
TM source	REQ-FUNC-023; URG-T16-R05
Source modality	should; all source conditions remain applicable

Where technically feasible, retain and present image/video, sensor observation, activity location, timestamp, affected fibre route and distance from fibre infrastructure.

Clause	Required behaviour
B01	Record which evidence fields are supplied, calculated, unavailable or failed to retrieve, with source/time and links to the originating event.
B02	A calculated distance carries the spatial basis from URG-T16-R03.
B03	No route or distance is fabricated where geometry is absent.
B04	Event evidence uses the bucket/file reference boundary with authorised access.
B05	Evidence failure is visible on the event and alert and can route an operator to review.
B06	It must not erase the alert or be presented as evidence of no threat.
B07	Preserve original evidence identity and capture time.
B08	Add later evidence as linked material rather than replacing the original silently.
B09	Live viewing is a separate user-requested capability and does not imply retained continuous video.

Exception / condition	Required handling
Evidence failure or absent geometry	Show the limitation, preserve the alert and do not fabricate route/distance or absence of threat.

Verification:

Criterion	Scenario / method	Expected result
AC01	Full evidence, no camera, unavailable media and no usable distance	Availability reasons and original references remain visible; alerts remain traceable and absent geometry produces no fabricated distance.
AC02	Permission-denied evidence access	Access is denied.
AC03	Captured media/time and calculated distance compared with actual sources	Values and spatial basis reconcile with the sources.

SRS-EVT-106 — Theft/Vandalism Alert

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-033; URG-T17-R05
Source modality	shall; all source conditions remain applicable

Assess classified activity using an enabled rule and its approved inputs, such as asset context, supported tamper condition, supplied access context, recurrence or corroborating observations where available.

Clause	Required behaviour
B01	A qualifying result creates/updates a linked alert with severity/risk, rule/version and evidence.
B02	Missing required inputs flag review and do not trigger automatic physical action.
B03	Non-qualifying observations remain accessible.
B04	Consolidate qualifying repeated detections under the approved grouping settings while retaining each device/source observation.
B05	Notify the internal operator queue, support acknowledgement, assignment, escalation and recorded outcome.
B06	Open a case when investigation or field response is required.
B07	Legal/prosecution actions remain outside scope.
B08	No external security/police communication or device action is authorised merely by producing an alert.

Exception / condition	Required handling
Required assessment input missing	Flag review; do not trigger automatic physical action.

Verification:

Criterion	Scenario / method	Expected result
AC01	Qualifying, benign/authorised, incomplete-input and repeated-source scenarios	Approved rules determine severity and alert handling; events are preserved, qualifying items reach the internal queue and required handling uses case links.
AC02	Viewer handling attempt and external transmission inspection	Unauthorised action is denied; producing the alert implies no external transmission.

SRS-EVT-107 — Evidence Capture

Attribute	Specification
Status	Proposed conditional response
TM source	REQ-FUNC-034; URG-T17-R06
Source modality	should; all source conditions remain applicable

Where deployed technology supports capture, retain relevant images/clips, sensor observations and other supplied evidence linked to the originating event, source/device, capture time and available location.

Clause	Required behaviour
B01	Preserve original references and record subsequently added investigation material separately.
B02	Store files in the agreed bucket with metadata/record associations in PostgreSQL.
B03	The source says should and where supported.
B04	No continuous-recording or forensic chain-of-custody certification is implied.
B05	An authorised reviewer can open retained evidence.
B06	Denial, incomplete upload, expired retention or unavailable media is displayed explicitly.
B07	A missing attachment does not delete the event or imply a false alarm.
B08	An operator may close a case using the agreed outcome and note with optional attachments.
B09	Retention/deletion behavior must preserve a traceable record of what evidence is no longer available under approved policy.

Exception / condition	Required handling
Incomplete upload, retention expiry or unavailable media	Show the availability limitation and preserve traceability under approved policy.

Verification:

Criterion	Scenario / method	Expected result
AC01	Supported selected-device evidence captured and retrieved	Identity/time correlates to the originating event.
AC02	Restricted access and failed retrieval	Denial or unavailability is explicit without deleting the event.
AC03	Later investigation evidence added	Original provenance remains available separately.
AC04	Case closed without an attachment	Required outcome/note remain available and closure succeeds.

SRS-EVT-108 — Alert Generation

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-060; URG-T20-R02
Source modality	shall; all source conditions remain applicable

Record every genuine detection and evaluate applicable enabled rule versions against event type/time window and other approved available conditions.

Clause	Required behaviour
B01	An alert-generating match creates or updates the qualifying active alert.
B02	A record-only or unmatched event stays recorded without automatic physical action.
B03	Missing required inputs flags internal review.
B04	Retain the evaluation, matched rules, priority/restrictions and selected/withheld actions.
B05	Rule changes apply to new evaluations without historical replay.
B06	Record a unique decision/result association so retransmission or resumed processing of the same event/rule evaluation cannot create duplicate alerts or duplicate workflow starts.
B07	Genuine repeated detections can join the active alert under the approved grouping policy.
B08	Expose rule-evaluation failure separately from a successful non-match.
B09	Retrying evaluation must not bypass action guards.

Exception / condition	Required handling
Rule evaluation fails	Distinguish failure from a successful non-match; retry does not bypass action guards.

Verification:

Criterion	Scenario / method	Expected result
AC01	Alert-rule, record-only, unmatched and missing-input fixtures	Alert/evaluation results, input retention and review treatment follow the configured route, retaining applied versions.
AC02	Same processing decision replayed after interruption	Only one alert/workflow start results.
AC03	Genuine repeated detections and unauthorised rule edit	Genuine events remain identifiable and group according to policy; unauthorised rule edits are denied.

SRS-EVT-109 — Alert Prioritisation

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-061; URG-T20-R03
Source modality	shall; all source conditions remain applicable

On qualifying alert generation, apply the configured category/scenario severity or assessed-risk mapping and record its version and basis.

Clause	Required behaviour
B01	Display readable priority and support queue ordering/filtering.
B02	If no valid mapping exists, flag Needs review rather than assign a fabricated low priority.
B03	Propose ordering by priority and then oldest unresolved qualifying time within an equal-priority group.
B04	Any operator override requires appropriate permission, reason and recorded old/new values.
B05	When new qualifying evidence joins an active alert, re-evaluate priority under the approved rule and retain the change history.
B06	Notification/re-notification remains governed by the separately agreed channel/escalation policy.
B07	Device-command urgency never bypasses maintenance, approval, age or cooldown restrictions.

Exception / condition	Required handling
No valid priority mapping	Flag Needs review rather than a fabricated low priority.

Verification:

Criterion	Scenario / method	Expected result
AC01	Different/equal priorities and missing severity	Readable priority, ordering and recorded basis follow the proposed/approved mapping; missing mapping is Needs review.
AC02	Grouped evidence changes priority	Change history is retained without an unapproved notification exception.
AC03	Unauthorised priority override	Override is denied.

SRS-EVT-110 — Notification

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-062; URG-T20-R04
Source modality	shall; all source conditions remain applicable

Qualifying alert notifications appear in the internal system alert queue for the approved operational recipients; an authorised operator can open the alert and acknowledge it.

Clause	Required behaviour
B01	Configure internal escalation for unacknowledged items.
B02	Email, SMS and other external channels are not included in the initial M3 proposal, and the URG’s approved-channel requirement remains subject to TM acceptance of that channel choice.
B03	Each notification references its alert, intended role/user audience, creation time and applicable rule.
B04	Show new/acknowledged handling state based on recorded user action.
B05	Creation of a queue item is not proof a user read it.
B06	Failures to create/serve notifications remain visible internally and may be retried idempotently without duplicating the same notification.
B07	Read/acknowledgement permissions are checked server-side.

Exception / condition	Required handling
Notification creation/service failure	Keep failure visible internally; retry idempotently without duplicating the same notification.

Verification:

Criterion	Scenario / method	Expected result
AC01	Alert generated for approved internal audience	Notification reaches the correct queue/audience and opens the right alert.
AC02	Authorised acknowledgement and Viewer attempt	Operator acknowledgement succeeds; Viewer acknowledgement is denied.
AC03	Queue-service failure and recovery	Failure remains visible and recovery creates no duplicate notification.
AC04	Unacknowledged escalation and external-send inspection	Configured internal escalation occurs without unconfigured external sends.

SRS-EVT-111 — Alert Lifecycle

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-063; URG-T20-R05
Source modality	shall; all source conditions remain applicable

FALCON shall retain evidence for the source stages Detected, Assessed, Acknowledged, Assigned, Actioned, Resolved and Closed.

Clause	Required behaviour
B01	These stages describe operational progress and do not establish seven independent editable alert states.
B02	Acknowledged records attention, Assigned derives from the linked case’s responsible Operator, Actioned records an attempted response, and Resolved requires a recorded finding of Threat addressed.
B03	Preserve applicable actor/time/reason for each stage.
B04	An Operator may close a reviewed alert without a case for No threat found, Duplicate or Unable to verify with an outcome and note.
B05	Such closure does not manufacture an Assigned, Actioned or Resolved stage.
B06	Case closure alone leaves the alert unchanged.
B07	When the Operator selects “Also close linked alert”, a confirmed alert outcome is required.
B08	If the Operator selects “Also close linked alert” but does not confirm the alert outcome, do not close that alert.
B09	A new qualifying detection after alert closure shall create a new alert.
B10	Closed history is retained.
B11	Case and command states remain separate.

Verification:

Criterion	Scenario / method	Expected result
AC01	Complete handled path and each permitted no-case closure	Applicable source-stage evidence and case-derived ownership are retained; skipped stages are not fabricated.
AC02	Case closure with and without combined-closure selection	Only selected linked-alert closure with a confirmed outcome closes the alert; absent confirmation cannot close it and no selection leaves it unchanged.
AC03	New qualifying event after closure	A different alert identity is created and closed history remains unchanged.

Decisions still required: See DET-032.

SRS-EVT-112 — Duplicate Events

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-064; URG-T20-R06
Source modality	should; all source conditions remain applicable

Retransmission of the same accepted source event identity shall not create another event record.

Clause	Required behaviour
B01	Separate genuine detections shall remain individually identifiable with device, time and evidence.
B02	Qualifying detections of the same configured event type and location/zone, including across devices, shall join an eligible active alert within a configurable fixed window starting at its first qualifying detection.
B03	Later detections shall not extend that window.
B04	Outside-window detections and new qualifying detections after closure shall create a new alert.
B05	Where a source has no stable identity, approve a source-specific deduplication key.
B06	Uncertain similarity must not merge distinct detections automatically.

Exception / condition	Required handling
Source has no stable event identity	Agree a source-specific deduplication key; uncertain similarity cannot merge distinct detections automatically.

Verification:

Criterion	Scenario / method	Expected result
AC01	One source identity replayed; distinct detections from two devices in configured window	Replay retains one event; genuine detections remain separate and group under one eligible alert without extending its window.
AC02	Outside-window and new post-closure detections	New alerts are created.
AC03	Exact boundary and late-arrival tests before acceptance	Results follow the approved parameter/transition decision; these details are not fixed by this response.

Decisions still required: See DET-033.

SRS-EVT-113 — Escalation

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-074; URG-T21-R06
Source modality	shall; all source conditions remain applicable

Configure escalation conditions for applicable risk/severity and unresolved handling, including an unacknowledged alert or pending operational response past an agreed threshold.

Clause	Required behaviour
B01	Record the triggering condition/time, current alert state, rule/version, intended internal recipient role/user and escalation level.
B02	Create an internal escalation item linked to the same alert.
B03	Do not create a duplicate threat event or mark escalation as resolution.
B04	Acknowledgement alone does not prevent escalation of a still-unresolved high-risk condition if the approved rule requires it.
B05	Propose one escalation record per satisfied stage/alert unless a separately configured repeat condition becomes due.
B06	Re-evaluate closure/resolution before issuing the escalation.
B07	Record cancellation/no-longer-applicable decisions.
B08	Missing or inactive recipients and failed internal notification are visible to an authorised operational administrator.
B09	External email/SMS/security escalation is not enabled by the M3 internal proposal.

Exception / condition	Required handling
Recipient missing/inactive or internal notification fails	Make failure visible to the authorised operational administrator.

Verification:

Criterion	Scenario / method	Expected result
AC01	Unacknowledged, acknowledged-but-unresolved high-risk and resolved alerts	Escalation follows the approved rule/time basis; stage notification/record is not duplicated and escalation does not resolve the threat.
AC02	Missing recipient and repeated scheduler execution	Recipient failure is visible; one applicable stage record/notification remains unless the configured repeat condition is due.
AC03	Authorised manual escalation and Viewer attempt	Permitted escalation succeeds; Viewer action is denied.

Decisions still required: See DET-034.

SRS-EVT-114 — Incident History

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-090; URG-T23-R02
Source modality	shall; all source conditions remain applicable

Retain detected threat events, alert/lifecycle history, interventions and imported/reported fibre faults within the agreed scope.

Clause	Required behaviour
B01	Link events to source devices/deployments, alerts to their contributing events, cases/actions to alerts and interventions to originating risks/recommendations where known.
B02	Distinguish imported dockets, separate incidents, detections, alerts and confirmed faults when counting records. Do not automatically count linked records as separate occurrences.
B03	Include original/receipt/recorded times and source/batch references as applicable.
B04	Keep significant actor/time actions, assignments, configuration, command results and closure changes traceable.
B05	Device relocation preserves prior coordinates, deployment dates and associated events under PL-DEV-003.
B06	Closing a case/alert does not delete its evidence or rewrite outcome.
B07	Corrections retain history.
B08	PostgreSQL stores structured records and the bucket stores associated files.

Verification:

Criterion	Scenario / method	Expected result
AC01	Imported fault/source, detection, alert, case, command and intervention chain; subsequent closure/correction and device relocation	Original associations and actor/time history remain queryable with correct event-time location.
AC02	Counts by record type and permission/retention checks	Counts reconcile without conflating record concepts; access and evidence-availability limitations are explicit.

Decisions still required: See DET-035.

SRS-EVT-115 — Additional Threats

Attribute	Specification
Status	Proposed conditional response
TM source	REQ-REX-002; URG-T47-R03
Source modality	should; all source conditions remain applicable

The architecture should support additional fibre fault causes/threat scenarios through a versioned taxonomy, declared observation/features, model/rule definition, risk explanation and action mapping, with historical unknown/retired types preserved.

Clause	Required behaviour
B01	A new threat must provide representative evidence, ground truth/metrics, required input fields and authorised response conditions before enablement.
B02	Unsupported types may be retained for review rather than silently mapped to a known threat or automatically actuated.
B03	Extensibility is a design capability.
B04	It does not add unrequested threat implementation or waive existing three-family coverage.

Exception / condition	Required handling
Unsupported threat type	May be retained for review rather than silently mapped to a known threat or automatically actuated.

Verification:

Criterion	Scenario / method	Expected result
AC01	Representative test-only threat definition/adapter fixture	Storage, display and routing work without core-schema redesign.
AC02	Unknown or invalid type	Record remains visible and cannot bypass approval controls.

SRS-EVT-116 — Escalation

Attribute	Specification
Status	Proposed response
TM source	REQ-HITL-003; URG-T55-R04
Source modality	shall; all source conditions remain applicable

Configure escalation conditions and recipients for risk level, confidence, threat severity, location criticality, repeated detection and absence of operator acknowledgement, singly or in agreed combinations.

Clause	Required behaviour
B01	For each enabled rule record trigger, time basis, recipient/role, notification method and audit/result.
B02	Proposed M3 delivery uses internal system notifications and links escalated items to the existing alert/case.
B03	Escalation does not itself authorise physical action.
B04	Retain every genuine detection even when an alert is grouped.
B05	Repeated detections may contribute to escalation under the configured policy.
B06	Confidence-based escalation may route uncertain events for review rather than increase risk indiscriminately.
B07	Maintain acknowledgement separately from case resolution.
B08	If an intended recipient is unavailable or notification fails, show the pending/failed status and retain it for authorised operational review.
B09	Notification timings remain To Confirm. External SMS/email channels require separate agreement.

Exception / condition	Required handling
Recipient unavailable or notification fails	Show pending/failed status for authorised review; do not fabricate receipt.

Verification:

Criterion	Scenario / method	Expected result
AC01	All six configured escalation factors, including grouped repeats and missing acknowledgement	Recipient permissions, internal notification and status are traceable under the configured policy.
AC02	Acknowledgement	It neither closes the case nor authorises physical action.
AC03	Notification delivery failure	Pending/failed unresolved status is visible without fabricated receipt.

3.2.8 Active Deterrent Control

Purpose: Request permitted deterrent actions and distinguish device execution evidence from observed intervention outcomes.

Actors: Authorised requesters and Operators initiate permitted actions; the platform checks restrictions; the IoT service and selected hardware deliver commands and feedback.

Submodules: Command catalogue; authorised activation; device confirmation; retry and expiry; operating limits; stop and fault handling.

Boundaries: Selected hardware determines supported commands, stop/fault behaviour and physical confirmation. IoT owns eligible bounded delivery retries. Service receipt, dispatch and physical confirmation do not establish threat resolution. Device-specific limits remain To Confirm.

FE-DET-001 — Supported hardware commands

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Connect the selected intervention hardware and define its supported commands and feedback.

Exception / condition	Required handling
Unsupported command	Reject the command.

Verification:

Criterion	Scenario / method	Expected result
AC01	Every agreed command exercised on selected hardware; unsupported command attempted	Supported feedback reconciles to the interface catalogue and unsupported commands are rejected.

FE-DET-002 — Activation authority

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Define who or what may request activation, and under which conditions.

Verification:

Criterion	Scenario / method	Expected result
AC01	Authorised, denied-actor, pending-approval and prohibited-condition requests	Only an approved permitted request reaches dispatch.

FE-DET-003 — Operating limits and stop controls

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Define permitted operating limits, stop controls, and behaviour when conditions are unsuitable or a fault occurs.

Verification:

Criterion	Scenario / method	Expected result
AC01	Agreed stop, duration, repetition, cooldown and fault boundaries under controlled conditions	Selected limits and observed hardware behaviour are retained for comparison.

FE-DET-004 — Execution and intervention outcomes

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Distinguish requested, executed, failed and observed intervention outcomes.

Verification:

Criterion	Scenario / method	Expected result
AC01	Requested, dispatched, confirmed, failed and unconfirmed commands compared with intervention outcomes	Execution states and observed intervention outcomes remain separate; no automatic effectiveness claim is made.

SRS-DET-001 — Correlated command execution

Attribute	Specification
Status	Proposed
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.

Each authorised action request shall have one logical command ID through platform, IoT service and supported device acknowledgements.

Clause	Required behaviour
B01	IoT shall own bounded delivery retries.
B02	The platform shall not independently retry the same physical action.

Verification:

Criterion	Scenario / method	Expected result
AC01	Acknowledgement interrupted under selected safe retry policy using actual equipment	Dispatch attempts reconcile to one logical command ID, bounded IoT retries and verified duplicate-execution control.

SRS-DET-002 — Execution evidence

Attribute	Specification
Status	Proposed
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.

FALCON shall distinguish Requested, Sent, Confirmed, Failed, Expired and Unconfirmed command outcomes.

Clause	Required behaviour
B01	Service receipt or dispatch shall not be shown as confirmed physical execution.

Exception / condition	Required handling
Physical execution evidence missing	Do not show service receipt/dispatch as Confirmed execution.

Verification:

Criterion	Scenario / method	Expected result
AC01	Accepted, dispatched, physically confirmed, failed, expired and missing-acknowledgement cases	Displayed Requested, Sent, Confirmed, Failed, Expired and Unconfirmed states agree with evidence; receipt/dispatch is not physical confirmation.

SRS-DET-003 — Stop and fault response

Attribute	Specification
Status	Proposed
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.

For each selected deterrent, document and implement the approved stop control, activation duration limits, fault response and unsuitable-condition restrictions before enabling operational use.

Clause	Required behaviour
B01	A remote stop request shall not be shown as executed without the required device evidence.

Exception / condition	Required handling
Remote stop requested without required device evidence	Do not show stop as executed.

Verification:

Criterion	Scenario / method	Expected result
AC01	Approved controlled activation, stop and fault cases on selected device	Command IDs, measured duration and required physical confirmation are retained against approved controls; device-specific limits remain To Confirm.

Decisions still required: See DET-036.

3.2.9 Case Management

Purpose: Manage investigation, assigned response, field reports and closure with a recorded outcome.

Actors: Operators own cases, assign field work, review results and close cases. Field Team members record progress and evidence for assigned work from M3. Administrators manage closure outcomes.

Submodules: Case creation and links; responsible Operator; field mobilisation; action/evidence records; outcomes; closure; feedback.

Boundaries: Initial case states are Open, In Progress and Closed. One responsible Operator is recorded on an assigned case with reassignment history. Closure requires outcome and note, with optional attachments. Case closure leaves a linked alert unchanged unless the Operator selects Also close linked alert and confirms its outcome; transaction details remain To Confirm.

PL-CAS-001 — End-to-end case handling

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-01

Support verification, action assignment, field evidence capture, and case closure with a recorded outcome.

Verification:

Criterion	Scenario / method	Expected result
AC01	End-to-end execution of PL-CAS-002–008	Each child acceptance criterion has retained lifecycle evidence.

PL-CAS-002 — Case creation and alert links

Attribute	Specification
Status	Proposed
Provenance	Decomposition of PL-CAS-001 and its existing refinements, 9 October 2026.

Create a case linked to originating alerts/events when investigation, assignment or field intervention is required; configured agreed high-severity rules may create cases automatically.

Verification:

Criterion	Scenario / method	Expected result
AC01	Record-only event; manually created case; agreed high-severity automatic rule	Record-only handling needs no case; created cases link their originating alerts/events without silently closing an alert.

PL-CAS-003 — Case states

Attribute	Specification
Status	Proposed
Provenance	Decomposition of PL-CAS-001 and its existing refinements, 9 October 2026.

Support Open, In Progress and Closed case states, retaining transition history.

Verification:

Criterion	Scenario / method	Expected result
AC01	Representative Open, In Progress and Closed lifecycle	Transition history is retained; reopening and automatic closure policy remain To Confirm.

Decisions still required: See DET-037.

PL-CAS-004 — Responsible Operator and reassignment

Attribute	Specification
Status	Proposed
Provenance	Decomposition of PL-CAS-001 and its existing refinements, 9 October 2026.
Drafting decision	ROLE-001–003; user agreed, TM review pending.

Maintain one responsible operator per assigned case and retain reassignment history.

Clause	Required behaviour
B01	Keep the responsible Operator separate from the Field Team assigned to carry out work.
B02	Record field assignment and reassignment history without changing the responsible Operator or the owner shown on a linked alert.

Verification:

Criterion	Scenario / method	Expected result
AC01	Case assigned then reassigned	One current responsible Operator is distinguishable from previous assignment history.
AC02	Assign or reassign field work	Field assignment history changes; case ownership and the linked alert owner still identify the responsible Operator.

PL-CAS-005 — Field-response recording

Attribute	Specification
Status	Proposed
Provenance	Decomposition of PL-CAS-001 and its existing refinements, 9 October 2026.
Drafting decision	ROLE-001–003; user agreed, TM review pending.

Allow Field Team members to report assigned work directly from M3. Operators assign the work and review its results.

Clause	Required behaviour
B01	Show Field Team members their assigned work and the information needed to perform it.
B02	Allow assigned members to record progress, work performed, evidence and completion details.
B03	Keep the person who performed the work separate from the user who recorded it. Operators may also record reported field actions.
B04	Submit completion details to the responsible Operator for review. Submission does not close the case or confirm that the threat was addressed.

Verification:

Criterion	Scenario / method	Expected result
AC01	Assigned Field Team member submits progress, evidence and completion details	Records retain the performer, recording user and time; the responsible Operator can review them.
AC02	Operator records work reported by a field responder	The record distinguishes the performer from the Operator who entered it.
AC03	Field Team submits completion or attempts case closure	Completion is available for review. The case retains its current Open or In Progress state; Field Team closure is denied.

PL-CAS-006 — Closure outcome and note

Attribute	Specification
Status	Proposed
Provenance	Decomposition of PL-CAS-001 and its existing refinements, 9 October 2026.
Drafting decision	ROLE-001–003; user agreed, TM review pending.

An authorised Operator reviews submitted field results before closing the case. Closure requires an outcome and note; attachments are optional.

Exception / condition	Required handling
Required closure information missing	Reject closure; attachments remain optional.

Verification:

Criterion	Scenario / method	Expected result
AC01	Closure with outcome/note and no attachment	Closure succeeds.
AC02	Missing outcome/note; optional evidence supplied	Missing required information prevents closure; supplied evidence stays linked.
AC03	Field completion submitted, then reviewed by an authorised Operator	Submission alone does not close the case. The Operator can close it after review with the required outcome and note.

PL-CAS-007 — Closure-outcome configuration

Attribute	Specification
Status	Proposed
Provenance	Decomposition of PL-CAS-001 and its existing refinements, 9 October 2026.

Allow Administrators to maintain closure outcomes and retire unused outcomes while preserving historical records.

Exception / condition	Required handling
Outcome retired	Preserve the meaning of historical case records.

Verification:

Criterion	Scenario / method	Expected result
AC01	Closure outcome retired	Prior closed cases retain their recorded meaning.
AC02	Unprivileged configuration change	Change is denied.

PL-CAS-008 — Command case and threat distinctions

Attribute	Specification
Status	Proposed
Provenance	Decomposition of PL-CAS-001 and its existing refinements, 9 October 2026.

Keep command dispatch, confirmed execution, case closure and threat-resolution outcome distinct.

Verification:

Criterion	Scenario / method	Expected result
AC01	Sent/confirmed commands and Duplicate/Unable to verify closures	Commands do not automatically resolve cases; these closure outcomes do not count as Threat addressed.

SRS-CAS-101 — Operator Feedback

Attribute	Specification
Status	Proposed response
TM source	REQ-HITL-002; URG-T55-R03
Source modality	shall; all source conditions remain applicable

Capture structured feedback and recorded operational outcomes linked to prediction, model/version, alert/case and action where applicable.

Field / record	Specification
Proposed feedback fields	Feedback type; accepted/rejected/corrected assessment; reason; author/time; evidence reference; outcome status.
Links where applicable	Prediction, model/version, alert/case and action.
Initial case outcomes	Threat addressed; No threat found; Duplicate; Unable to verify.
Closure support	Operator note required; attachments optional; classification feedback separate.

Clause	Required behaviour
B01	Proposed fields include feedback type, accepted/rejected/corrected assessment, reason, author/time, evidence reference and outcome status.
B02	Preserve “Unable to verify” and incomplete observation as uncertainty instead of converting them into false alarms or successful prevention.
B03	Use the initial case outcomes Threat addressed, No threat found, Duplicate and Unable to verify with operator notes and optional attachments.
B04	Keep classification feedback separate.
B05	Make reviewed feedback available for error analysis and, where appropriate, a validated retraining dataset.
B06	Initial feedback need not trigger automatic model learning.
B07	Later intervention outcomes also link to recommendations and risk history.
B08	A before/after change is not automatically attributed to the intervention.

Exception / condition	Required handling
Unable to verify or incomplete observation	Preserve uncertainty rather than labelling a false alarm or successful prevention.

Verification:

Criterion	Scenario / method	Expected result
AC01	Feedback with and without optional evidence	Original output/version and author/time remain linked.
AC02	Duplicate and Unable to verify cases	Neither silently becomes a labelled positive/negative.
AC03	Validated correction and unreviewed correction	The validated correction can enter analysis data; unreviewed correction remains excluded from automatic training.

SRS-CAS-102 — Outcome Feedback

Attribute	Specification
Status	Proposed response
TM source	REQ-MLIN-003; URG-T57-R04
Source modality	shall; all source conditions remain applicable

Capture the observed result of a preventive/mitigation action and link it to its original prediction, risk assessment, decision and action.

Field / record	Specification
Action and responsibility	Action/date and responsible party.
Observation	Result/outcome, observation period, reporter/time, uncertainty and available evidence.
Origin	Original prediction, risk assessment, decision and action.

Clause	Required behaviour
B01	Record action/date, responsible party, result/outcome, observation period, reporter/time, uncertainty and available evidence.
B02	M3 operators record field-reported outcomes using the case workflow.
B03	Field staff need no accounts and attachments remain optional.
B04	Make linked records available for performance assessment, false-positive/false-negative analysis, operational effectiveness review and future model improvement.
B05	These analyses apply only when the recorded outcome supports the relevant inference.
B06	“Unable to verify” remains unknown.
B07	A threat prevented by an intervention is not automatically a false-positive prediction because no later incident occurred.
B08	A closed case or command confirmation alone is not proof of prevention.
B09	Include observed incidents with no preceding prediction in missed-event analysis when the monitoring coverage supports that comparison.

Exception / condition	Required handling
Outcome does not support the analytic inference	Exclude unsupported truth labels; Unable to verify remains unknown.

Verification:

Criterion	Scenario / method	Expected result
AC01	Completed, ineffective and Unable to verify action outcomes	Each traces to its prediction, retains reporter/time and optional evidence handling, and distinguishes execution from outcome.
AC02	Outcome analytics and eligible missed incident without prior prediction	Unsupported truth labels are excluded; missed-event analysis includes the incident where monitoring coverage permits comparison.
AC03	Effectiveness comparison	Recorded limitations remain visible.

3.2.10 Preventive Actions and Mobilisation

Purpose: Turn reviewed risks into preventive recommendations, record mobilisation and interventions, and support outcome review.

Actors: Operators accept, dismiss or defer recommendations and record responding parties and reported work; authorised users maintain the relevant rules and action catalogue.

Submodules: Recommendation rules; supporting evidence; accept/dismiss/defer; mobilisation; intervention history; before/after review.

Boundaries: Detailed scheduling, rostering and equipment allocation remain separately Proposed; basic resource mobilisation and recorded intervention outcomes do not imply those functions. Recommendation acceptance, dismissal and deferral retain actor/time/reason. Recorded mobilisation does not prove an external party accepted or was dispatched; before/after change does not establish causation.

PL-PRV-001 — Additional detailed work planning

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-01; additional proposed detailed planning functions, separately assessed below.

Support scheduling inspections or protective work and assigning responsible teams and required resources.

Verification:

Criterion	Scenario / method	Expected result
AC01	Additional planning proposal adopted; representative work scheduled	Team/resource assignments match the entered plan; scope and allocation remain To Confirm until agreed.

Decisions still required: See DET-038.

PL-PRV-002 — Preventive recommendations

Attribute	Specification
Status	Proposed
Provenance	REQ-FUNC-080, URG-T22-R02; user refinement, 8 October 2026.

Recommend preventive actions based on identified risk, with affected asset/location, reason, supporting incidents/risk and priority.

Verification:

Criterion	Scenario / method	Expected result
AC01	Risk condition matches configured recommendation rule	Suggested action, affected location, priority and supporting records are shown.

PL-PRV-003 — Recommendation decisions

Attribute	Specification
Status	Proposed
Provenance	Supporting refinement of REQ-FUNC-080/081; user agreement, 8 October 2026.

Support operator acceptance, dismissal or deferral of recommendations with recorded reasons, and creation of a linked follow-up case on acceptance where needed.

Verification:

Criterion	Scenario / method	Expected result
AC01	Recommendation accepted, dismissed and deferred	Decision/reason history is retained; any created follow-up case links to its accepted recommendation.

PL-PRV-004 — Resource mobilisation records

Attribute	Specification
Status	Proposed
Provenance	REQ-FUNC-073, URG-T21-R05 (source modality should); user refinement, 8 October 2026.
Source modality	should

Support mobilisation records identifying responding team/contact, requested action and mobilisation status.

Verification:

Criterion	Scenario / method	Expected result
AC01	Mobilisation record entered	Team/contact, requested action and mobilisation status link to relevant follow-up work.

PL-PRV-005 — Intervention history

Attribute	Specification
Status	Proposed
Provenance	REQ-FUNC-081, URG-T22-R03; user refinement, 8 October 2026.

Record intervention action, date, responsible party and outcome with links to originating risk/recommendation and optional evidence.

Verification:

Criterion	Scenario / method	Expected result
AC01	Intervention recorded with and without optional evidence	Action, date, responsible party and outcome trace to originating risk/recommendation.

PL-PRV-006 — Before-and-after review

Attribute	Specification
Status	Proposed
Provenance	REQ-FUNC-082, URG-T22-R04 (source modality should); user refinement, 8 October 2026.
Source modality	should

Support operator review of incident/risk history before and after an intervention without assuming causation.

Verification:

Criterion	Scenario / method	Expected result
AC01	Representative before/after periods compared	Values reconcile to source records; coverage and limitations are visible without an automatic causal claim.

SRS-PRV-101 — Resource Mobilisation

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-073; URG-T21-R05
Source modality	should; all source conditions remain applicable
Drafting decision	ROLE-001–003; user agreed, TM review pending.

The solution should support mobilisation based on event type/severity by recording the responding team/contact, requested action and mobilisation status linked to the alert/case/recommendation.

Field / record	Specification
Core record	Responding team/contact, requested action, mobilisation status and link to alert/case/recommendation.
Proposed state record	Requested, Accepted, In progress, Completed or Cancelled; actor/time, responding party, requested work and linked outcome.
Potential resources	Field workforce, patrol teams, drones, security personnel, network operations teams or relevant third parties, as applicable.

Clause	Required behaviour
B01	Operators record mobilisation requests and assign field work. They review submitted results and record the case outcome.
B02	From M3, Field Team members use their accounts to update assigned work and submit evidence and completion details.
B03	Detailed calendars, personnel rostering and equipment allocation remain the separate PL-PRV-001 additional proposal, not implied mandatory scope.
B04	Propose mobilisation states Requested, Accepted, In progress, Completed and Cancelled, with actor/time, responding party, requested work and linked outcome.
B05	Acceptance/completion is recorded only when reported, not inferred from a saved request.
B06	Resource type may represent field workforce, patrol teams, drones, security personnel, network operations teams or relevant third parties as applicable.
B07	These are potential resources and do not mandate procurement, drone control or direct third-party messaging.
B08	A FALCON record of mobilisation is not evidence that an external party was dispatched or accepted a commitment.

Verification:

Criterion	Scenario / method	Expected result
AC01	Qualifying event mobilisation with applicable resource type and reported acceptance/progress/completion	Record history preserves responding party and reported status; requested and accepted/completed counts remain distinct.
AC02	Another mobilisation cancelled; external-send/device inspection	Cancellation is retained without implying external transmission or a drone command.

Decisions still required: See DET-039.

SRS-PRV-102 — Preventive Action Recommendation

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-080; URG-T22-R02
Source modality	shall/may; all source conditions remain applicable

Use configurable rules linking reviewed risk conditions to approved preventive action types.

Field / record	Specification
Recommendation	Asset/location, suggested action, reason, supporting incidents/risk assessment and priority.
Action catalogue	Applicability, prerequisites and permission/approval boundary for each action.
Operator decision	Accept, dismiss or defer with reason; linked follow-up case when needed.

Clause	Required behaviour
B01	Each recommendation shows asset/location, suggested action, reason, supporting incidents/risk assessment and priority.
B02	An operator accepts, dismisses or defers with a reason.
B03	Acceptance can create a linked follow-up case when needed.
B04	Initial recommendations need not be AI-generated and do not authorise physical execution simply by being accepted.
B05	The catalogue can include site inspection, patrol, camera deployment, sensor deployment, rodent deterrent, physical protection, fibre route inspection and other approved preventive measures.
B06	Record each action’s applicability, prerequisites and permission/approval boundary.
B07	Avoid duplicate active recommendations for the same assessment/action.
B08	Preserve prior accepted/dismissed/deferred decisions when a new assessment arrives and show its new basis rather than overwrite the old decision.
B09	Missing risk inputs or no eligible action yields an explained review/no-recommendation result.

Exception / condition	Required handling
Missing risk input or no eligible action	Provide an explained review/no-recommendation result.

Verification:

Criterion	Scenario / method	Expected result
AC01	Reviewed risk condition produces applicable recommendation	Required recommendation fields and supporting source links are present.
AC02	Accept, dismiss and defer with reasons; follow-up case selected	Decisions/reasons are retained and selected case links to the recommendation.
AC03	Same/new assessment refreshed	Active recommendation duplication is controlled and prior decisions/new basis remain distinguishable.
AC04	Unavailable prerequisite and unauthorised catalogue edit	Ineligible action receives an explained review/no-recommendation result; unauthorised edit is denied.

SRS-PRV-103 — Intervention Tracking

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-081; URG-T22-R03
Source modality	shall; all source conditions remain applicable

For preventive work taken in response to risk, an authorised operator records the action actually performed, its date, responsible party, reported outcome and links to the originating risk/recommendation and case where present.

Clause	Required behaviour
B01	Evidence attachments are optional.
B02	Preserve requested/accepted work separately from performed work.
B03	A planned action or sent deterrent command is not automatically a completed intervention or a resolved threat.
B04	Propose retaining creator/time, source of the reported field outcome and change history with correction reason.
B05	Allow a performed action to be recorded even when no earlier recommendation exists, linking the relevant risk/event where known and identifying absent origin.
B06	A completed intervention may reference one or more device-command attempts as evidence, but manual confirmation and physical outcome remain distinguishable.
B07	Administrators/viewers do not acquire operational edit permission solely through read access.

Verification:

Criterion	Scenario / method	Expected result
AC01	Recommended and unplanned reported interventions	Each retains performed action/date/party/outcome and available origin link; absent prior recommendation is identified.
AC02	Optional attachment and correction	Attachment is optional; correction history and reason remain distinguishable from requested work/command status.
AC03	Completed intervention report reconciled	Counts derive from recorded completed interventions.

SRS-PRV-104 — Effectiveness Monitoring

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-082; URG-T22-R04
Source modality	should; all source conditions remain applicable

The solution should support an operator reviewing incident/risk history before and after a recorded intervention, linked to the affected asset/location and intervention date.

Clause	Required behaviour
B01	Show relevant incidents, assessment versions, observation coverage and available outcomes.
B02	Preserve the operator’s conclusion and limitations.
B03	A reduction after work is an observed association, not proof that the work caused it.
B04	Propose selectable before/after periods showing incident counts and, only where monitored exposure duration is known, comparable rates.
B05	Display period lengths, data gaps, changed detector/deployment/model conditions and unavailable evidence.
B06	Do not silently compare unequal observation coverage or treat missing post-intervention data as zero incidents.
B07	A reassessed risk score is labelled separately from observed fault/event outcomes.

Exception / condition	Required handling
Missing post-intervention data	Do not treat it as zero incidents or a confirmed reduction.

Verification:

Criterion	Scenario / method	Expected result
AC01	Complete history, unequal periods, coverage outage and changed device/model conditions	Displayed counts/rates reconcile; coverage, comparison limitations and changed conditions remain visible.
AC02	No data after intervention	No confirmed reduction is shown.
AC03	Operator conclusion recorded	Conclusion and limitations remain attributed to the Operator.

3.2.11 Reporting and Performance Review

This module supports operational and management review of recorded alerts, incidents, responses, outcomes and device availability. Authorised operational users review their permitted site and date scope; management users may use the existing Viewer role to inspect maps, dashboards and reports.

Submodules: Event/alert summaries; case outcomes; device availability; trends and hotspots; management view; Excel/PDF exports.

Boundaries: Reports use traceable source records and distinguish historical facts from predictive results. M3 downloads are Excel and PDF. AI operator summaries are a separate M4 proposal, and preventive-effectiveness components follow their M4 delivery. A closed case, dispatched command or confirmed device activation does not establish that a threat was addressed or an incident prevented.

PL-RPT-001 — Operational summaries and exports

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-01

Report agreed measures of alert quality, response, completed work and recurring incidents from traceable operational records.

Clause	Required behaviour
B01	Present the agreed measures for the selected site and date scope.
B02	Retain traceability from reported measures to contributing events, cases and outcomes.
B03	Provide Excel and PDF output for the selected scope.

Verification:

Criterion	Scenario / method	Expected result
AC01	Filter representative site/date records and produce Excel/PDF output.	Displayed and exported measures reconcile with the contributing events, cases and outcomes.

Decisions still required: See DET-040.

SRS-RPT-101 — Trend Analysis

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-091; URG-T23-R03
Source modality	should; all source conditions remain applicable

The solution should show historical trends by selected period and site/location, including recurring threat categories and high-risk periods.

Clause	Required behaviour
B01	Aggregate eligible historical records by the selected period and site/location.
B02	Provide readable category/location breakdowns and links to contributing records; selectable time buckets suited to the available history are proposed.
B03	Label the measure being counted as detections, distinct incidents, alerts or confirmed faults.
B04	Group occurrence trends by original event/incident occurrence time and disclose delayed-entry and source limitations.
B05	Show the selected time basis, coverage period, missing intervals, unmatched/unclassified counts and material detector, deployment or method changes.
B06	Compare periods using like-for-like definitions.
B07	Present future predictions separately from historical incident records.

Exceptions: Zero means no eligible records within known coverage; it does not demonstrate absence where coverage is unknown. Disclose unknown occurrence times and any exclusions from time buckets.

Verification:

Criterion	Scenario / method	Expected result
AC01	Review known recurring locations, threat types and periods.	Buckets and drill-down reconcile with the raw reviewed dataset.
AC02	Include delayed imports and unknown occurrence times.	Known occurrence times determine occurrence grouping; limitations and exclusions are explicit.
AC03	Include a monitoring gap and changed monitoring methods.	Coverage limitations and material changes remain visible; unknown coverage is not represented as evidence of no incidents.
AC04	Compare periods and include predictive results.	Comparable definitions are used and predictions remain separate from historical counts.

Decisions still required: See DET-041.

SRS-RPT-102 — Operational Reporting

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-100; URG-T24-R02
Source modality	shall; all source conditions remain applicable

The solution shall provide source-based operational reports filtered by date and site, with corresponding Excel and PDF downloads.

Output or definition	Required content
Operational summary	Events/alerts, case statuses/outcomes, device availability and historical hotspots; predictive results identified separately.
Indicator definition	Entity counted, inclusion/exclusion rules, time field, filter semantics and denominator where relevant.
Proposed report metadata	Generation time, data cutoff/period, filters and metric version.
Download scope	Selected site/date scope and the same authorised data scope as the report.

Clause	Required behaviour
B01	Apply the selected date/site filters to the report and its downloads.
B02	Use one consistent snapshot so on-screen, Excel and PDF totals reconcile.
B03	Derive case outcomes from recorded evidence; do not treat every closed case as Threat addressed or imply prevention from closure.
B04	Display unknown values and coverage gaps, including device status that cannot be verified during an IoT-service outage.
B05	Enforce download authorisation and exclude unprotected evidence links from downloads.
B06	Keep the separate M4 AI operator-summary proposal distinct from these source-based reports.

Exceptions: Unknown, zero and unavailable values retain their different meanings. Availability calculations must not conceal unknown/offline states or service outages. No percentage target is established by this requirement.

Verification:

Criterion	Scenario / method	Expected result
AC01	Reconcile each filtered indicator against reviewed source records and export Excel/PDF.	Totals match across the report and exports; headers, scope and applicable metadata are readable.
AC02	Include unknown/zero/unavailable values, case closures and an IoT-service outage.	Calculations and labels preserve those distinctions; closure does not imply Threat addressed or prevention.
AC03	Attempt an unauthorised download and direct-file access.	Access is denied and protected evidence is not exposed through unprotected links.

Decisions still required: See DET-042.

SRS-RPT-103 — Threat Reporting

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-101; URG-T24-R03
Source modality	shall; all source conditions remain applicable

The solution shall allow authorised users to filter and group threat reports across the six specified dimensions while preserving distinct counts and source traceability.

Dimension	Interpretation
Threat category	Preserve category definitions and show unclassified threats.
Geographical location	Preserve location information and show missing locations.
Time period	Retain the selected reporting period.
Severity/risk	Identify the source/method of each measure; do not silently equate the scales.
Affected infrastructure	Retain infrastructure relationships and show unresolved assets.
Outcome	Use recorded findings, closure or interventions; show unavailable outcomes.

Clause	Required behaviour
B01	Support filtering and grouping by all six dimensions without discarding records with missing dimension values.
B02	Preserve category/level definitions and label severity and risk according to their source/method.
B03	Derive outcomes from recorded findings, closure and interventions rather than command dispatch.
B04	State the base measure and use distinct entity identities for totals.
B05	Provide drill-down showing the relationships between contributing records.
B06	Where a record spans multiple dimensions, disclose non-additive groupings as a proposed reporting treatment; overlapping groups must not be summed as a unique incident total.
B07	Retain selected dimensions, filters, period and unknown categories in Excel/PDF exports using the display snapshot.

Exceptions: Missing location, unresolved asset, unclassified threat and unavailable outcome remain explicit report categories. Several linked alerts or actions do not automatically constitute several distinct incidents.

Verification:

Criterion	Scenario / method	Expected result
AC01	Use records covering all six dimensions and missing fields.	Filters/groupings operate as defined and unknown categories remain visible.
AC02	Include linked alerts/actions and an incident affecting multiple infrastructure records.	Distinct totals reconcile with source identities; overlapping groups are disclosed.
AC03	Export the selected report in Excel/PDF and inspect drill-down.	Dimensions, filters, period, unknown categories and totals reconcile with the same source snapshot.

Decisions still required: See DET-043.

SRS-RPT-104 — Management View

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-102; URG-T24-R04
Source modality	should; all source conditions remain applicable

The management view should present six management topics with defined scope, freshness and supporting-record drill-down.

Topic	Proposed initial measure or treatment
Overall risk exposure	Eligible assessed locations by risk level.
Incidents detected	Distinct detected incidents under the agreed counting rule.
Incidents prevented	Not established until TM agrees an evidential definition; separately show recorded Threat addressed outcomes and completed preventive interventions.
Response performance	Acknowledgement, action and closure elapsed times where timestamps exist.
High-risk locations	Ranked hotspots supported by source records.
Emerging threats	Newly observed or increasing categories under an approved comparison rule.

Clause	Required behaviour
B01	Show scope/period, data freshness, source-based breakdowns and supporting-record drill-down.
B02	Label unknown or unavailable metrics rather than estimating unsupported values.
B03	Keep recorded Threat addressed outcomes and completed preventive interventions separate from any claim of incidents prevented.
B04	Assess emerging threats using agreed comparison periods, monitoring coverage and criteria; a newly connected sensor or new classification does not by itself establish an emerging threat.
B05	Allow management users to be assigned the existing Viewer role; job title creates neither a new role nor additional permissions.
B06	Require existing operational permissions for operational actions.
B07	Apply the M3 Excel/PDF download contract and the M4 delivery allocation for preventive-effectiveness components; show incomplete later measures as unavailable in earlier releases.

Exceptions: Device activation and absence of later detections do not prove prevention. Missing timestamps, unverified closure and absent prevention evidence cannot support a prevented-incident count.

Verification:

Criterion	Scenario / method	Expected result
AC01	Review all six topics and reconcile available measures.	Each topic is represented and each available measure traces to its defined source records.
AC02	Include unknown timestamps, unverified closure and no prevention evidence.	Unsupported measures remain unknown/unavailable; no example becomes a prevented incident.
AC03	Access the view as a Viewer and attempt an operational action.	Review access follows the Viewer role and the action is denied.
AC04	Compare genuine changes with changes caused by a new sensor or classification.	Emerging-threat criteria distinguish the changes in monitored threats from changes in monitoring sources.

Decisions still required: See DET-044.

3.2.12 Audit History

This module enables authorised reviewers to reconstruct operational changes, workflow decisions and AI/ML results. Users, services, devices and adapters supply identifiable actions or source references; authorised reviewers search and export the resulting history.

Submodules: User/action audit; import/configuration history; event-to-outcome trace; model/decision trace; authorised review.

Boundaries: Business audit history remains distinct from diagnostic logs. Source, platform, transport and correlation identities retain their separate meanings. A command result, a physical device result and an operator-assessed threat outcome are different stages of evidence. Retention, protected-data handling and critical-action logging-failure policy require agreement.

SH-AUD-001 — Traceable operational changes

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-03

Record who or what performed each significant operational action, when it occurred and which record it affected.

Clause	Required behaviour
B01	Identify the user or service responsible for the significant action.
B02	Record the action time and affected record.
B03	Cover representative import, configuration, approval, command, assignment and closure actions.

Verification:

Criterion	Scenario / method	Expected result
AC01	Perform the listed significant actions.	Actor, time and affected-record audit evidence can be retrieved for each action.

SRS-AUD-101 — Audit Trail

Attribute	Specification
Status	Proposed response
TM source	REQ-SEC-004; URG-T26-R05
Source modality	shall; all source conditions remain applicable

The solution shall retain linked audit entries for significant security and operational actions, including their failed or rejected outcomes.

Audit content	Specification
Covered actions	Account/security administration; imports and disposition; configuration/rule versions; approvals/rejections; commands and each returned status; pauses; assignments/reassignments; closure/outcome changes; live-view start/stop/timeout.
Entry identity	Actor or service, action, affected record and correlation ID.
Entry timing	UTC occurrence time and recording time.
Result and change	Outcome and changed version or redacted change details.

Clause	Required behaviour
B01	Record each covered action and its outcome using the specified audit content.
B02	Link asynchronous command results to the original request.
B03	Restrict audit search/export and preserve historical labels and versions.
B04	Prevent normal application-role update/delete of audit entries through the proposed application permission controls.
B05	Surface logging failures and apply the agreed critical-action policy; do not silently report audit completion.

Exceptions: Failed and rejected actions remain auditable. A logging failure must remain distinguishable from a successfully recorded action.

Verification:

Criterion	Scenario / method	Expected result
AC01	Perform every listed significant action, including rejection/failure and asynchronous command results.	Each action has a retrievable linked entry; returned command statuses link to the request.
AC02	Attempt audit edits with normal application roles and inspect changed rules/outcomes.	Edits are denied and historical meanings remain reconstructable.
AC03	Review audit and permission-test evidence.	Redacted extracts demonstrate the required fields, access controls and historical links.

Decisions still required: See DET-045.

SRS-AUD-102 — Event Logging

Attribute	Specification
Status	Proposed response
TM source	REQ-OBS-002; URG-T29-R03
Source modality	shall; all source conditions remain applicable

The solution shall provide protected structured diagnostic logs for component activity and operational faults without replacing business audit history.

Log content	Specification
Covered events	Component start/stop; input validation; event/alert creation; rule/workflow transition; command dispatch/result; access failures; job completion/failure; recovery.
Required fields	Timestamp, component/version, severity, correlation ID, operation/result and bounded error code/context.
Repeated events	Retained counts and first/last occurrence while repetitive volume is limited.

Clause	Required behaviour
B01	Produce structured logs for the covered events using the required fields.
B02	Keep diagnostic logs separate from audit records so rotation cannot erase required business history.
B03	Limit repetitive log volume while retaining repetition counts and first/last occurrence.
B04	Protect logs and redact credentials, unnecessary personal information and full media payloads.
B05	Expose logging-pipeline failure as an observable operational fault.

Exceptions: Repeated faults must not cause unbounded growth or lose their aggregate occurrence evidence. Logging interruption remains visible as a gap or fault.

Verification:

Criterion	Scenario / method	Expected result
AC01	Trace successful and failed end-to-end flows.	Readable, linked structured records cover the relevant operations without exposing credentials.
AC02	Induce repeated errors and a logging interruption.	Repetition is bounded with counts/first/last occurrence retained, and interruption is observable.
AC03	Inspect redacted examples, rotation configuration and gap indicators.	Diagnostic rotation preserves required business history and protected content remains redacted.

SRS-AUD-103 — Traceability

Attribute	Specification
Status	Proposed response
TM source	REQ-OBS-003; URG-T29-R04
Source modality	shall; all source conditions remain applicable

The solution shall preserve event identities and correlation links across applicable processing stages so reviewers can reconstruct causal chains.

Clause	Required behaviour
B01	Carry an event/correlation identifier through applicable device/adapter intake, platform validation, risk/model request, alert, workflow, command/result and case/outcome records.
B02	Retain source-provided event IDs separately from platform identities and transport message IDs.
B03	Preserve each member event link when an alert or workflow groups multiple genuine events.
B04	Give imported records batch, row and source references.
B05	If the selected device cannot return the command/event correlation ID, use an adapter mapping that consistently identifies the matching record. Otherwise mark the result as uncorrelated/unconfirmed.
B06	Treat correlation identifiers as metadata, not secrets or authorisation tokens.

Exceptions: A result that cannot be matched to its command must not be presented as confirmation of physical execution. Grouping events must preserve each event’s identity.

Verification:

Criterion	Scenario / method	Expected result
AC01	Select one event, one multi-event alert, one import row and one command response.	Each causal chain is reconstructable through the relevant logs/records, with separate identities and member links retained.
AC02	Process an uncorrelatable device result.	A tested adapter mapping supports correlation, or the result remains explicitly uncorrelated/unconfirmed without invented physical confirmation.
AC03	Retain the trace export and adapter mapping test.	The evidence demonstrates the reconstructed chains and the handling of unsupported correlation.

SRS-AUD-104 — Auditability

Attribute	Specification
Status	Proposed response
TM source	REQ-COMP003; URG-T30-R04
Source modality	shall; all source conditions remain applicable

The solution shall retain sufficient linked operational and audit evidence to reconstruct who or what acted, the inputs and versions used, the time and the outcome.

Evidence group	Required content
Source and import	Original source identifiers/timestamps and import disposition.
Supporting evidence	Evidence references/checksums.
Decision context	Configuration/model/version, decision history and human-intervention history.
Execution and outcome	Device-command stages and closure reasons.

Clause	Required behaviour
B01	Preserve linked evidence sufficient to reconstruct the action, input, configuration/model/version, time and outcome.
B02	Provide authorised search/export by time, site, record and correlation ID.
B03	Include an export manifest and audit the export.
B04	Apply the agreed retention/hold policy and explicitly identify missing or expired evidence.
B05	Preserve the literal source identifier REQ-COMP003; this response does not rename it.

Exceptions: Missing or expired evidence is declared as a reconstruction limit rather than silently omitted.

Verification:

Criterion	Scenario / method	Expected result
AC01	Reconstruct an investigation from import/detection to outcome and export its linked records.	The linked chain is recoverable; source/export counts and checksums reconcile with the manifest.
AC02	Attempt prohibited audit edits and inspect an investigation with missing evidence.	Edits fail and missing evidence is explicitly declared.

Decisions still required: See DET-046.

SRS-AUD-105 — Audit trail

Attribute	Specification
Status	Proposed response
TM source	REQ-WFO-004; URG-T40-R05
Source modality	shall; all source conditions remain applicable

The solution shall preserve each workflow execution’s decision and execution history through to its case/outcome reference.

Execution evidence	Required content
Origin and assessment	Origin event/prediction, validation/quality result and risk inputs/result.
Decision	Matched rule/version/priority, applicable restrictions, selected/withheld action and reason.
Human intervention	Approval/intervention actor and time.
Device execution	IoT command identity, attempt and result.
Outcome	Final case/outcome reference.

Clause	Required behaviour
B01	Retain the specified evidence for each execution, including blocked and failed paths.
B02	Store changes as history so configuration edits cannot rewrite earlier decisions.
B03	Distinguish delivery attempt counts from separate actions.
B04	Distinguish physical results from operator-assessed threat outcomes.
B05	Allow authorised reviewers to traverse the chain in both directions and export it under audit permissions.
B06	Identify missing or expired evidence explicitly.

Exceptions: Later rule changes or device relocation must not replace the original versions or locations needed to reconstruct earlier execution.

Verification:

Criterion	Scenario / method	Expected result
AC01	Select normal, blocked and failed workflows, then change a rule and relocate a device.	Each complete causal chain remains reconstructable with its original versions and locations.
AC02	Review redacted trace extracts in both directions.	Execution evidence retains its links and distinguishes attempts, actions, physical results and threat outcomes.

SRS-AUD-106 — Audit Trail

Attribute	Specification
Status	Proposed response
TM source	REQ-MLGRL-007; URG-T53-R08
Source modality	shall; all source conditions remain applicable

The solution shall correlate operational AI/ML results with their inputs, versions, guardrail decisions, human interventions and subsequent actions/outcomes.

Clause	Required behaviour
B01	Link each operational AI/ML result to the model/configuration version, relevant inputs/references and timestamp, guardrail checks, decision/rule version, human intervention and resulting action/outcome.
B02	Preserve rejected, constrained and no-action paths as well as successful actions.
B03	Record actor, time and reason for human approval, classification correction and override without overwriting the original prediction.
B04	Maintain stable links through prediction, alert/case and any command ID.
B05	Distinguish Requested/Sent/Confirmed device statuses from observed threat resolution and operator case closure.
B06	Restrict audit access and route record changes through controlled application paths.
B07	Retain source references or approved snapshots sufficient for review under the agreed retention policy; full raw payload or prompt retention is not automatically required.
B08	Where protected input cannot be retained, record its identifier, transformation and approved reproducibility limitation.

Exceptions: Protected-input limits must remain visible. Command confirmation cannot establish threat resolution, and human intervention cannot erase the original prediction.

Verification:

Criterion	Scenario / method	Expected result
AC01	Trace accepted, rejected, low-confidence and failed-action examples end to end.	Each path retains the required links, original prediction and applicable intervention reasons for authorised review.
AC02	Attempt to rewrite history using normal application functions and attempt unauthorised access.	History rewrites and unauthorised access are denied.
AC03	Inspect a confirmed device command and its subsequent case/outcome.	Confirmation remains distinct from threat resolution and case closure.

Decisions still required: See DET-047.

SRS-AUD-107 — Auditability

Attribute	Specification
Status	Proposed response
TM source	REQ-ETRES-003; URG-T54-R04
Source modality	shall; all source conditions remain applicable

The solution shall retain technically available inference/decision evidence and explicitly disclose limits on traceability and reproducibility.

Information group	Required evidence
Model identity	Technically available model/version identifier actually used.
Prediction time	Prediction timestamp.
Inputs	Input/reference data.
Result	Inference/decision result.
Score	Available confidence/risk score.
Threshold	Configured threshold.
Action	Subsequent action.
Intervention	User intervention.
Hosted LLM evidence	Available provider/model revision, prompt-template/retrieval configuration, permitted source references, request/result reference and generation time.

Clause	Required behaviour
B01	Retain the eight inference/decision information groups where technically available.
B02	Link to the common prediction contract, guardrail/decision record and lifecycle package instead of duplicating unconstrained sensitive data in each log.
B03	For each unavailable field, record why it is missing and what can no longer be traced. Do not invent a confidence value when none is supplied.
B04	Preserve the model/configuration identity actually used for historic results after deployment changes.
B05	Record the available hosted LLM evidence for hosted output.
B06	If the provider cannot identify a fixed model revision or reproduce the same output from the same input, state that limitation. Retain enough permitted evidence to review the answer.

Exceptions: Do not invent details about the provider’s internal operation. If repeatable generation is unavailable, do not promise identical wording when an answer is generated again.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect a sample inference/decision record.	All eight information groups are represented by available evidence or applicable absence reasons.
AC02	Trace an older prediction after model replacement.	Its original package, inputs, decision and model/configuration identity remain identifiable.
AC03	Inspect a hosted API sample against returned provider metadata and supporting records.	Available metadata reconciles without requiring unavailable provider internals, exposing secrets or promising unsupported replay.

3.2.13 AI Assistant

This module proposes a read-only assistant for authorised FALCON users to ask questions and request operational summaries. It retrieves permitted records, explains available information and links answers to their supporting records.

Submodules: Read-only questions; bilingual on-demand summaries; permission-filtered retrieval; supporting-record citations; missing information; API failure.

Boundaries: This is additional scope for TM review, with conditional URG narrative coverage. M4 allocation, LLM processing approvals and evaluation remain To Confirm. The initial proposal excludes operational writes, autonomous commands, scheduled summaries and AI-summary export. English and Bahasa Malaysia support applies to assistant answers and summaries; it does not establish a bilingual requirement for all reporting.

Module open decisions: Named LLM providers, processing regions, retention arrangements, data-processing approval and evaluation remain unresolved. An approved provider or processing arrangement is not established by this proposal.

PL-AST-001 — Permission-filtered read-only questions

Attribute	Specification
Status	Proposed
Provenance	Existing AI Assistant Proposal; N12/N13/N15

Retrieve and explain FALCON information through read-only queries within the requesting user’s permissions.

Clause	Required behaviour
B01	Support questions about permitted assets, devices/status, events/alerts, cases, imported incident history and available risk results.
B02	Apply the requesting user’s permissions to retrieved information and returned record links.
B03	Explain only the information available within that authorised scope.

Exceptions: Denied records and links must not be returned through the assistant.

Verification:

Criterion	Scenario / method	Expected result
AC01	Query known records in permitted and denied contexts.	Only authorised records and links appear in read-only answers.

PL-AST-002 — On-demand operational summaries

Attribute	Specification
Status	Proposed
Provenance	Existing AI Assistant Proposal

Produce an operational summary on request for a selected site and period.

Clause	Required behaviour
B01	Apply the selected site and period to the summary.
B02	Summarise outstanding alerts/cases, recent incidents, device problems and recorded responses/outcomes.
B03	Base included counts, statuses and outcomes on the underlying records and selected filters.

Exceptions: Scheduled summaries and AI-summary export are outside the initial proposal.

Verification:

Criterion	Scenario / method	Expected result
AC01	Request a summary for a selected site and period.	Each included count, status and outcome reconciles with underlying records and the selected filters.

PL-AST-003 — English and Bahasa Malaysia

Attribute	Specification
Status	Proposed
Provenance	Existing AI Assistant Proposal

Support English and Bahasa Malaysia for assistant answers and summaries.

Clause	Required behaviour
B01	Provide assistant answers in English and Bahasa Malaysia.
B02	Provide assistant operational summaries in English and Bahasa Malaysia.

Verification:

Criterion	Scenario / method	Expected result
AC01	Evaluate an agreed set of questions and summaries in both languages against reviewed expected information.	Answers and summaries convey the expected information under the agreed evaluation criteria.

Decisions still required: See DET-048.

PL-AST-004 — Supporting records and uncertainty

Attribute	Specification
Status	Proposed
Provenance	Existing AI Assistant Proposal

Make assistant answers reviewable through permitted supporting-record links and explicit limits on what the records establish.

Clause	Required behaviour
B01	Link answers to supporting records within the user’s permissions.
B02	Identify the period covered and relevant data limitations.
B03	Distinguish recorded facts from interpretations.
B04	State when records cannot support an answer and disclose uncertainty or missing information.

Exceptions: Unsupported or conflicting records must not produce an unqualified factual answer.

Verification:

Criterion	Scenario / method	Expected result
AC01	Ask questions with supporting records.	Answers include permitted source links, period and applicable limitations.
AC02	Ask unsupported or conflicting-data questions.	Uncertainty and missing information are disclosed; facts and interpretations remain distinguishable.

PL-AST-005 — No operational writes

Attribute	Specification
Status	Proposed
Provenance	Existing read-only proposal and AI response specification

Keep the assistant read-only and prevent retrieved content from expanding its permissions.

Clause	Required behaviour
B01	Prevent the assistant from executing device commands, case changes and rule edits.
B02	Retrieved content shall not expand permissions.
B03	Apply the read-only boundary to direct requests and instructions embedded in retrieved content.

Exceptions: A request or retrieved instruction to activate a device or change an operational record does not authorise assistant execution.

Verification:

Criterion	Scenario / method	Expected result
AC01	Request device activation, case changes and rule edits directly.	No write or action capability executes.
AC02	Embed equivalent instructions in retrieved content.	Permissions remain unchanged and no write or action capability executes.

PL-AST-006 — LLM API failure isolation

Attribute	Specification
Status	Proposed
Provenance	Existing AI Assistant Proposal

Use an approved LLM API while keeping core FALCON functions independent of assistant service availability.

Clause	Required behaviour
B01	Use an approved LLM API for assistant processing.
B02	Display explicit assistant unavailability when the LLM service fails.
B03	Allow maps, alerts, cases and reports to continue operating independently during that failure.

Exceptions: LLM API unavailability affects the assistant without disabling the core functions listed above.

Verification:

Criterion	Scenario / method	Expected result
AC01	Make the LLM API unavailable.	An explicit assistant-unavailable response appears while maps, alerts, cases and reports continue operating.

Decisions still required: See DET-049.

3.2.14 Evidence and Media Management

Purpose: Keep evidence identifiable, retrievable by authorised users and meaningful throughout its retention period.

Actors: Operators and assigned Field Team members attach or retrieve permitted evidence. Field Team access starts in M3. Devices supply event evidence.

Submodules: Evidence identity; upload/linking; retrieval permissions; unavailable-media handling; preservation and expiry; live-view separation.

Boundaries: Evidence availability does not establish a threat outcome. Live viewing remains distinct from stored evidence; retention follows the agreed data-class schedule.

SRS-MED-001 — Evidence provenance

Attribute	Specification
Status	Proposed.
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.

FALCON shall retain the identity and provenance of evidence associated with an event or case.

Required information

Information	Requirement
Identity and association	Evidence identity and associated event/case.
Source	Source device or uploader.
Times	Capture time where supplied, and receipt time.
Media reference	Media type and storage reference.

Functional behaviour

Clause	Required behaviour
B01	Retain the required information in the preceding table for each evidence record.
B02	When correcting an association, preserve the previous association and the actor responsible for the correction.

Verification:

Criterion	Scenario / method	Expected result
AC01	Device event evidence	Identity, times and source match the supplied evidence and its event association.
AC02	Operator case evidence	Uploader, receipt time and case association remain traceable.
AC03	Correct an association	The corrected association, previous association and correction actor can be reconciled.

SRS-MED-002 — Protected retrieval

Attribute	Specification
Status	Proposed.
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.
Drafting decision	ROLE-001–003; user agreed, TM review pending.

FALCON shall enforce permission for the underlying record whenever evidence is accessed or downloaded.

Functional behaviour

Clause	Required behaviour
B01	Enforce the permission check at the service boundary.
B02	Apply the same check to a guessed or copied file reference; possession of a reference shall not bypass permission.

Verification:

Criterion	Scenario / method	Expected result
AC01	Authorised access and download	The permitted evidence is returned.
AC02	Denied direct retrieval using a guessed or copied reference	Evidence content is not returned.
AC03	Access removed after a reference was obtained	A subsequent denied retrieval does not return the content.
AC04	Field Team retrieves evidence for assigned work, unrelated work and work reassigned away	Assigned evidence is available within its permissions; unrelated or reassigned evidence is denied even through a copied reference.

SRS-MED-003 — Unavailable evidence

Attribute	Specification
Status	Proposed.
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.

FALCON shall show the applicable limitation when referenced evidence cannot be retrieved.

Functional behaviour

Clause	Required behaviour
B01	Identify whether evidence is pending, missing, corrupt, unavailable or expired, as applicable.
B02	Retain the associated event/case metadata when evidence cannot be retrieved.
B03	Do not present missing evidence as proof that no threat occurred.

Verification:

Criterion	Scenario / method	Expected result
AC01	Referenced media is inaccessible	The event/case remains readable and shows the applicable limitation.
AC02	Pending, missing, corrupt and expired evidence	Each applicable condition is identified without implying that no threat occurred.

SRS-MED-004 — Retention and preservation

Attribute	Specification
Status	Proposed.
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.

FALCON shall apply the agreed evidence retention schedule and authorised preservation restrictions.

Functional behaviour

Clause	Required behaviour
B01	Apply the agreed schedule for the evidence data class.
B02	Retain evidence subject to an authorised preservation restriction.
B03	Make each purge auditable while retaining required provenance and the meaning of retained case outcomes.

Verification:

Criterion	Scenario / method	Expected result
AC01	Eligible evidence reaches expiry under an agreed short test schedule	The eligible object expires; required metadata and auditable purge evidence remain.
AC02	Protected evidence reaches the same expiry point	The preservation restriction prevents its removal.
AC03	Review retained records after purge	Permissions remain enforced and retained case outcomes retain their meaning.

Decisions still required: See DET-050.

3.2.15 Notification and Escalation Management

Purpose: Notify the intended internal audience and execute configured escalation without confusing delivery with operational acknowledgement.

Actors: Operators receive and view internal notifications; authorised operations staff inspect delivery failures.

Submodules: Internal recipient selection; delivery versus acknowledgement; escalation timers; repeat handling; exceptions and audit.

Boundaries: External notification channels require separately agreed interfaces and delivery scope. Per-user read indicators remain proposed.

SRS-NTF-001 — Internal notification record

Attribute	Specification
Status	Proposed.
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.

A qualifying workflow shall create an internal notification linked to its alert and intended Operator audience.

Functional behaviour

Clause	Required behaviour
B01	Retain the link between the notification, alert and intended Operator audience.
B02	Keep notification creation, delivery, per-user viewing and shared alert acknowledgement as distinct facts.
B03	Merely opening a notification shall not acknowledge the alert. Per-user read indicators remain a proposal.

Verification:

Criterion	Scenario / method	Expected result
AC01	Qualifying workflow creates an alert	The notification references that alert and its intended Operator audience.
AC02	Two Operators view the notification	Viewing alone does not change shared alert acknowledgement.

SRS-NTF-002 — Escalation execution

Attribute	Specification
Status	Proposed.
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.

FALCON shall execute enabled escalation rules once per qualifying escalation step.

Functional behaviour

Clause	Required behaviour
B01	Evaluate the qualifying state, elapsed-time basis and stop condition specified by the enabled rule.
B02	Apply the configured recipient and priority.
B03	Retain the rule version and reason for each escalation.
B04	Prevent duplicate execution of the same step, including on retry.
B05	Cancel escalation when its agreed stop condition occurs.

Verification:

Criterion	Scenario / method	Expected result
AC01	Qualifying state reaches an agreed short timer	One escalation executes with the configured recipient and priority, recorded rule version and reason.
AC02	Retry the same escalation step	No duplicate execution occurs.
AC03	Agreed stop condition occurs	The escalation is cancelled in accordance with that condition.

Decisions still required: See DET-051.

SRS-NTF-003 — Delivery exception

Attribute	Specification
Status	Proposed.
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.

FALCON shall retain a visible internal delivery failure without erasing or closing the associated alert.

Functional behaviour

Clause	Required behaviour
B01	Make delivery failure visible to authorised operations staff.
B02	Keep the associated alert actionable after delivery failure.
B03	Treat external notification channels as separately agreed interface and delivery scope.

Verification:

Criterion	Scenario / method	Expected result
AC01	Internal delivery fails	The failure is recorded and visible to authorised operations staff; the alert remains actionable.
AC02	Review delivery test evidence	An internal-queue test is not used to pass external-channel delivery.

3.2.16 Reference Data and Operational Configuration

Purpose: Control operational reference values and apply reviewable, validated configuration changes.

Actors: Administrators manage approved reference values; configuration changes retain the responsible actor.

Submodules: Sites and zones; event mappings; closure outcomes; parameter versions; configuration validation and retirement.

Boundaries: Numerical defaults require explicit agreement. Configuration changes preserve historical meaning and do not replay physical commands.

SRS-CFG-001 — Controlled reference values

Attribute	Specification
Status	Proposed.
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.

Administrators shall manage approved operational reference values while preserving their historical meaning.

Functional behaviour

Clause	Required behaviour
B01	Support approved site/zone definitions, input-category mappings and closure outcomes.
B02	Prevent new selection of a retired value.
B03	Preserve the meaning of historical records referencing a retired value.

Verification:

Criterion	Scenario / method	Expected result
AC01	Retire a previously used outcome and site reference	Historic records still resolve to the applicable meaning.
AC02	Attempt a new selection of a retired value	The invalid selection is rejected.

SRS-CFG-002 — Parameter change validation

Attribute	Specification
Status	Proposed.
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.

FALCON shall validate configuration changes before activating them.

Functional behaviour

Clause	Required behaviour
B01	Record the value, unit, scope, effective version, actor and time.
B02	Reject invalid types, contradictory ranges and missing mandatory parameters before activation.
B03	Leave the active version unchanged when validation fails.
B04	Use numerical defaults only after explicit agreement.

Verification:

Criterion	Scenario / method	Expected result
AC01	Submit a valid setting	The accepted configuration retains its value, unit, scope, version, actor and time.
AC02	Submit an invalid type, inverted time range or missing mandatory parameter	Activation is rejected and the active version remains unchanged.

Decisions still required: See DET-052.

SRS-CFG-003 — Reviewable change effect

Attribute	Specification
Status	Proposed.
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.

FALCON shall show the affected scope before applying changes to live rules or device associations.

Functional behaviour

Clause	Required behaviour
B01	Show the affected scope before applying the change.
B02	Retain the previous configuration version.
B03	Do not silently rewrite past events or replay physical commands as a result of a configuration change.

Verification:

Criterion	Scenario / method	Expected result
AC01	Change a rule parameter	The affected scope is shown and the previous version remains available.
AC02	Change a device association	The affected scope and prior history remain reviewable.
AC03	Inspect already-recorded events and commands after either change	Past events are not silently rewritten and physical commands are not replayed.

3.3 Quality of Service

Purpose: Define resilience, measurable operating quality and maintainable recovery. Boundary: Source targets remain unapproved until section 5.4 agreement; test measurements are evidence, not invented acceptance values.

3.3.1 Reliability Recovery and Retention

Submodules: Fault isolation; recovery; backup and restoration; retention; interrupted communication; AI fallback.

Actors: Superadmins manage platform backups and recovery. Operational users view permitted records. Checks: Record data acceptance, physical execution, service status and historical evidence separately.

SH-REL-001 — Fault and recovery behaviour

Attribute	Specification
Status	Proposed.
Provenance	Baseline Sources#SRC-03

The platform shall preserve records and expose limitations during device, power, communication and service faults.

Clause	Control / behaviour
B01	Define and verify behaviour during device faults, power loss, connection loss, and service recovery.

Verification:

Criterion	Scenario / method	Expected result
AC01	Device fault, power loss, connection loss and service recovery	Records remain preserved where captured; limitations are visible and no stale automatic action replays.

SRS-REL-101 — Fault Tolerance

Attribute	Specification
Status	Proposed response.
TM source	REQ-REL-001; URG-T27-R02.
Source modality	shall; all source conditions remain applicable.

Accepted events shall survive the responsible intake’s restart, and partial failures shall remain traceable.

Clause	Control / behaviour
B01	Acknowledge accepted events only after the responsible intake has made the accepted payload durable; retain retryable work and a deduplication key across process restart.
B02	Proposed platform writes commit event state and its pending downstream work together, then reconcile asynchronous delivery using idempotent consumers.
B03	Store binary evidence with checksum/size and a pending/available/failed reference so partial bucket/database failure cannot create a fictitiously available file.
B04	Recover interrupted jobs or mark them failed with reason; isolate failed ingestion/media/model workers so unrelated authorised functions remain usable.
B05	State when data can be lost, including before it is saved durably on the device or edge. Do not promise zero data loss.

Verification:

Criterion	Scenario / method	Expected result
AC01	Terminate intake/workers before/after receipt and commit	Unique accepted records reconcile; no acknowledged event silently disappears.
AC02	Interrupt bucket/database storage and replay submissions	Evidence state remains pending/failed where appropriate; downstream alerts/actions are not duplicated.
AC03	Inspect fault-injection evidence	Logs and reconciliation counts identify retained work and declared loss boundaries.

Decisions still required: Section 5.4, OPEN-10; numerical entry “Availability and recovery (PAR-04)”.

SRS-REL-102 — Communication Failure

Attribute	Specification
Status	Proposed response.
TM source	REQ-REL-002; URG-T27-R03.
Source modality	shall; all source conditions remain applicable.

Communication loss shall preserve usable information and prevent prohibited or duplicated physical actions.

Clause	Control / behaviour
B01	During sensor/external-service connectivity loss, preserve last-known data with timestamps and stale/unverifiable labels.
B02	A failed IoT service does not prove that every device is Offline.
B03	Evaluate individual device contact timeout only with valid service observations.
B04	Continue authorised record review and unaffected platform functions.
B05	Withhold actions that cannot satisfy availability, event-age, approval, maintenance, pause or cooldown checks; the IoT service alone performs eligible bounded retries of the same command identity.
B06	Reconnection must not replay withheld/stale physical actions automatically.
B07	Designated edge functions continue as specified in URG-T36-R03; offline deterrence requires a device-specific decision.

Verification:

Criterion	Scenario / method	Expected result
AC01	Disconnect a device, IoT service and external dependency separately	Distinct status displays identify the affected boundary; records and unaffected authorised functions remain usable.
AC02	Reconnect with queued/delayed events	No prohibited stale action replay or duplicate physical execution occurs.

Decisions still required: Section 5.4, OPEN-03/OPEN-04; numerical entry “Commands and connectivity recovery (PAR-09)”.

SRS-REL-103 — Data Protection

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-REL-003; URG-T27-R04.
Source modality	shall; all source conditions remain applicable.

The solution shall recover the agreed service and data within agreed recovery targets.

Specification element	Definition
Measurement boundary	Failure declaration → restoration of agreed service; recovery point references last recoverable committed data.
Unit / target status	Elapsed recovery time and permitted data loss: values/units To Confirm.
Test workload	Representative failed deployment, database/evidence/configuration/model set and pending work.
Evidence	Isolated restore drill, reconciliation, integrity checks and defects.

Clause	Control / behaviour
B01	Maintain recovery procedures for database, bucket evidence, IoT service, application/workers, configuration and model artefacts.
B02	The proposed backup set records version, creation/consistency point, checksums, encryption/access conditions and restore dependencies.
B03	Restore to an isolated environment, reconcile record-to-file links and pending events/commands, then resume only valid current work; do not replay old actuator commands as a by-product of restore.
B04	Measure recovery time from declared failure to restored agreed service and recovery point from the last recoverable committed data.
B05	The solution shall meet agreed RTO/data-loss targets; the source title “Data Protection” is answered by its recovery description.

Verification:

Criterion	Scenario / method	Expected result
AC01	Restore representative deployment from backup in isolation	Integrity and sampled record/evidence/rule/model links reconcile.
AC02	Reconcile pending work and post-backup loss	Valid current work resumes without old actuator replay; loss is measured.
AC03	Compare drill measurements with approved targets	Elapsed recovery and recovery point are evidenced; report and defects are retained.

Decisions still required: Section 5.4, OPEN-10/Q10; numerical entry “Availability and recovery (PAR-04)”.

SRS-REL-104 — Operational Availability

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-AVAIL-001; URG-T28-R02.
Source modality	shall; all source conditions remain applicable.

Operational availability shall measure agreed usable functions rather than endpoint reachability alone.

Specification element	Definition
Measurement boundary	Agreed usable service time ÷ agreed operational time; approved maintenance exclusions identified.
Unit / target status	Availability ratio; percentage, observation window and support commitment are not assumed.
Workload	Event ingestion, current status, required alerts and permitted response functions; component probes explain partial outage.
Evidence	Synthetic operations, incident intervals and restoration proof.

Clause	Control / behaviour
B01	Define the operational service as the agreed ability to ingest events, view current status, generate required alerts and perform permitted response functions; measure component availability separately to explain partial outages.
B02	Record outage start/end, affected function/site, cause and restoration evidence.
B03	Calculate availability as agreed usable service time divided by agreed operational time, identifying any approved maintenance exclusions explicitly.
B04	Monitor dependency degradation so a reachable login page does not establish full availability.
B05	Hosting redundancy and failover are sized to the approved target; no availability percentage or round-the-clock support commitment is inferred.

Verification:

Criterion	Scenario / method	Expected result
AC01	Health probes and synthetic operations during agreed observation window	Evidence establishes usable operational functions and component availability.
AC02	Partial/full failure injection	Incident start/end and restoration records reconcile with the availability calculation and approved exclusions.

Decisions still required: Section 5.4, OPEN-10/OPEN-15/Q10; numerical entry “Availability and recovery (PAR-04)”.

SRS-REL-105 — Data Retention

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-COMP-004; URG-T30-R05.
Source modality	shall; all source conditions remain applicable.

Each data category shall have an approved retention policy and traceable expiry handling.

Clause	Control / behaviour
B01	Maintain retention policy per category: raw observations/health, detection/event/alert records, incident/case/outcome history, images/clips, import originals/rejections, model/dataset artefacts, audit/security/diagnostic logs, generated reports and backups.
B02	Each policy states retention trigger, duration, storage tier, hold condition and approved final treatment.
B03	Proposed expiry jobs respect linked-record dependencies and holds, record deletion/anonymisation outcome and expose failures.
B04	Expired evidence references retain a permitted tombstone/status so history is not misleading; restored data re-enters current retention policy.
B05	No numeric retention or deletion schedule is approved in this SRS response.

Verification:

Criterion	Scenario / method	Expected result
AC01	Boundary-aged data with/without holds; authorised test expiry	Policy treatment is correct, permitted reference tombstones remain and deletion failures are visible.
AC02	Restore older backup	Restored data is reconciled to current retention policy.

Decisions still required: Section 5.4, OPEN-10; numerical entry “Retention, backup and reporting scale (PAR-12)”.

SRS-REL-106 — Fallback

Attribute	Specification
Status	Proposed response.
TM source	REQ-MLGRL-006; URG-T53-R07.
Source modality	shall; all source conditions remain applicable.

Each failed model/service dependency shall enter a defined fallback state without bypassing action restrictions.

Clause	Control / behaviour
B01	Define fallback per model/service and dependency.
B02	On failed/unreliable inference, missing required data or supporting sensor failure, retain existing observations and last-known results with their original time and a clear unavailable/constrained indication.
B03	Block new automated actions that require the failed intelligence; do not show stale scores as current.
B04	Human review of available evidence and unaffected permitted workflows remain available with their ordinary restrictions.
B05	When the proposed LLM API is unavailable, report assistant unavailability while maps, alerts, cases and ordinary reports continue operating.
B06	No alternate provider or silent external-data transmission is assumed.
B07	On restoration resume validated new requests; do not replay previously withheld physical actions or portray partially generated answers as complete.
B08	Offline deterrence remains To Confirm under the device policy.
B09	The fallback runbook identifies the affected function, notification and restoration check.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inference failure, stale/absent input or unreliable sensor	Affected result is constrained/unavailable with original last-known time; dependent automation is blocked.
AC02	LLM outage	Assistant failure is explicit; unrelated maps, alerts, cases and reports continue.
AC03	Service restoration	Validated new processing succeeds without replaying withheld commands or completing partial answers by assertion.
AC04	Selected-device fallback inspection	Offline-action disposition and restoration checks remain explicit.

Decisions still required: Section 5.4, OPEN-03/OPEN-11.

SRS-REL-107 — Data Storage

Attribute	Specification
Status	Proposed response.
TM source	REQ-CCP-004; URG-T37-R05.
Source modality	shall; all source conditions remain applicable.

The platform shall preserve operational records and controlled object references in the proposed relational and bucket stores.

Clause	Control / behaviour
B01	Use PostgreSQL for sensor metadata/readings, devices/deployments, events, alerts, risk/model outputs and lineage, workflow/case/outcome records and audit history.
B02	Use bucket storage for images/video event evidence where captured, import originals, model/dataset artefacts and generated reports, with relational references.
B03	Each object reference records category, owner/parent, checksum, size, media type, creation time, availability state and retention/permission attributes.
B04	Enforce referential/idempotency constraints and separate operational/audit write permissions.
B05	Pending or failed upload is visible; reconciliation detects orphan objects/missing files.
B06	On-demand live viewing is not automatically recorded; initial manual/continuous recording remains outside the user-approved proposal.

Verification:

Criterion	Scenario / method	Expected result
AC01	Persist/retrieve every listed category	Permissions, object integrity and source/version links are correct.
AC02	Interrupt upload and storage	Pending/failed state and orphan/missing-file repair reporting appear.

SRS-REL-108 — Data Retention

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-CCP-005; URG-T37-R06.
Source modality	descriptive obligation; all source conditions remain applicable.

A proposed retention and storage-capacity schedule shall cover every major category in URG-T30-R05.

Clause	Control / behaviour
B01	For every major category listed in URG-T30-R05, provide a proposed retention schedule with duration or explicit unresolved value, retention start event, operational/archive tier, hold/expiry behavior and storage estimate.
B02	Compute required capacity from daily records × average stored record/index size × retention, plus event/evidence count × mean/peak object size, replication/backup overhead and growth allowance; show model/version/dataset and report storage separately.
B03	Retain incident/evidence links according to policy even when binary evidence expires.
B04	Longest retention is not presumed best: balance investigations, data rights, cost and restore requirements.
B05	No numeric period is accepted without TM decision.

Verification:

Criterion	Scenario / method	Expected result
AC01	Review all retention categories	Each has a policy and capacity formula with approved values or unresolved entries.
AC02	Recalculate using measured sample sizes	Storage estimates reproduce from recorded inputs.
AC03	Approved expiry/hold and restore tests	Links and policy reconciliation behave as specified; schedule and sizing inputs remain available.

Decisions still required: Section 5.4, OPEN-10; numerical entry “Retention, backup and reporting scale (PAR-12)”.

3.3.2 Performance and Capacity

Submodules: Event throughput; alert latency; monitored capacity; dashboard response; scaling and resource cost.

Actors: Delivery/engineering teams measure representative workloads; TM agrees acceptance conditions. Boundary: Separate end-to-end delay, component delay, physical pilot quantities and declared synthetic scale.

SH-PER-001 — Measured performance and workload

Attribute	Specification
Status	Proposed.
Provenance	Baseline Sources#SRC-03

Performance shall be measured against agreed workload and timing definitions; target values remain To Confirm.

Specification element	Definition
Target status	Workload, processing time, delivery time and platform response values remain To Confirm.
Evidence	Measurements under documented agreed conditions.

Clause	Control / behaviour
B01	Define and verify workload, processing time, event delivery time, and platform response targets under agreed conditions.

Verification:

Criterion	Scenario / method	Expected result
AC01	Documented representative workload	Processing, delivery and interface response measurements are reproducible; unagreed targets remain To Confirm.

Decisions still required: Section 5.4, Q10 and applicable performance numerical entries.

SRS-PER-101 — Event Processing

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-PERF-001; URG-T25-R02.
Source modality	shall; all source conditions remain applicable.

FALCON shall process accepted events within the agreed target under the agreed workload.

Specification element	Definition
Primary boundary	Durable platform receipt → queryable event with validation result.
Separate measures	IoT-to-platform transit; inference/evidence wait; recorded source occurrence and IoT receipt.
Workload / unit	Representative event mix and burst; elapsed time distribution, errors and queue age; agreed time unit pending.
Target status	POC target unapproved; acceptance requires agreed target and workload.

Clause	Control / behaviour
B01	For each accepted incoming event, record the source occurrence time, IoT-service receipt time, durable platform receipt and completion of validation, de-duplication and operational persistence.
B02	The proposed event-processing measure runs from durable platform receipt to the event becoming queryable with its validation result; separately expose IoT-to-platform transit and any inference/evidence wait so this boundary cannot hide end-to-end delay.
B03	Return a rejection reason and correlation ID for invalid submissions.
B04	Keep unfinished accepted work visibly pending/failed; it must not disappear.
B05	Run ingestion and media/model work through bounded queues so an evidence upload cannot block all event recording.
B06	Processing shall meet the agreed target under the agreed workload; the source’s POC target remains unapproved.

Verification:

Criterion	Scenario / method	Expected result
AC01	Timestamped representative set and burst including invalid, duplicate and unavailable-evidence cases	Submitted/accepted/rejected counts reconcile and work remains visible.
AC02	Timing and load evidence review	Latency distribution, errors and queue age compare to the approved target; request logs, query results and workload/environment configuration are retained.

Decisions still required: Section 5.4, Q10; numerical entry “Event processing time (PAR-01)”.

SRS-PER-102 — Alert Latency

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-PERF-002; URG-T25-R03.
Source modality	shall; all source conditions remain applicable.

Alert generation shall meet the agreed latency target measured from receipt of sufficient evidence.

Specification element	Definition
Start	First receipt at which subsequently validated evidence was sufficient under the rule/classifier.
End	Alert durably created and available in authorised internal queue.
Separate measures	Pre-sufficiency time and client display delay; validation completion retained and validation time included.
Workload / unit	Normal/burst evidence sequences, grouped repeats and missing evidence; elapsed time unit To Confirm.
Target status	Source “Target capacity: TBD” provides no numerical latency criterion.

Clause	Control / behaviour
B01	Start the alert-latency clock at the first receipt instant at which the subsequently validated evidence set was sufficient under the applicable rule/classifier; retain that receipt timestamp and the rule/model version.
B02	Record validation completion separately; include validation time within alert latency.
B03	End it when the alert is durably created and available in the authorised internal queue; measure client display delay separately.
B04	If required evidence is missing, show a pending or insufficient-evidence state. Do not hide work that is waiting for evidence.
B05	Record the time before sufficiency as a separate measure.
B06	Qualifying repeated detections update their grouped alert while retaining individual events; record-only events are not miscounted as missed alerts.
B07	Alert generation shall meet the agreed latency target; the source label “Target capacity: TBD” does not supply a number.

Verification:

Criterion	Scenario / method	Expected result
AC01	Known evidence-completion sequences and grouped repeats	Start/end timestamps match sufficiency under the rule; grouped alerts retain individual events.
AC02	Missing evidence under normal/burst conditions	Pending/insufficient state is visible; record-only events are not reported as missed alerts.
AC03	Queue/client trace review	Latency and failed alerts are reported with distinct validation, pre-sufficiency and client-delay evidence.

Decisions still required: Section 5.4, Q10; numerical entry “Alert latency (PAR-02)”.

SRS-PER-103 — Concurrent Monitoring

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-PERF-003; URG-T25-R04.
Source modality	shall; all source conditions remain applicable.

The platform shall support the agreed monitoring capacity across separately identified sites, assets and devices.

Specification element	Definition
Capacity dimensions	Registered/active devices, monitored locations, assets, input rates, evidence sizes, users, live sessions, scoring jobs and history.
Measurement boundary	Concurrent ingestion, map queries, scoring and agreed video load at agreed cardinality.
Target status	Agreed quantities are acceptance capacity; one M2 controlled location is only a demonstration.
Evidence	Latency, saturation, storage growth, resource limits, load scripts and configuration.

Clause	Control / behaviour
B01	Maintain separately identified sites, assets and devices without a single-site schema assumption.
B02	Capacity planning shall specify active/registered devices, monitored locations, fibre assets, input rates, evidence sizes, concurrent users, live-video sessions, scoring jobs and retained history.
B03	Use paginated queries and bounded job/stream concurrency, apply backpressure, and report admission failures rather than silently discard critical events.
B04	Acceptance capacity is the agreed number of locations, devices and assets. The single controlled M2 location is for demonstration only.
B05	Size and scale the selected deployment using the resource model in URG-T37-R04.

Verification:

Criterion	Scenario / method	Expected result
AC01	Populate agreed site/device/asset cardinality and run simultaneous ingest, map, scoring and video load	Records reconcile; latency, saturation, storage growth and resource limits are measured.
AC02	Load evidence review	Scripts and configuration identify the agreed acceptance workload, separately from one-location M2 demonstration.

Decisions still required: Section 5.4, Q10; numerical entry “Monitored capacity and dashboard response (PAR-03)”.

SRS-PER-104 — Dashboard Response

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-PERF-004; URG-T25-R05.
Source modality	shall; all source conditions remain applicable.

Dashboard response shall meet the agreed target for usable operational values and controls under documented load.

Specification element	Definition
Boundary	Permitted navigation/filter/refresh request → displayed operational values and usable map/list controls.
Separate measures	Browser versus API; first load versus cached refresh.
Workload	Agreed site/asset volume, users, client/network profile and concurrent ingestion.
Target status	Response target and elapsed-time unit require agreement; partial shell is not completion.

Clause	Control / behaviour
B01	Dashboard response is measured from a permitted user’s navigation/filter/refresh request to display of the requested operational values and usable map/list controls.
B02	Report browser and API timings separately and distinguish first load from cached refresh.
B03	Page and filter large result sets; load evidence/live media on demand.
B04	Show loading, empty, stale and failed states explicitly; a failed risk service must not be displayed as zero risk.
B05	Define normal operating conditions using the agreed site/asset volume, concurrent users, client/network profile and concurrent ingestion workload.
B06	Meet the agreed response target without presenting a partial shell as a completed dashboard.

Verification:

Criterion	Scenario / method	Expected result
AC01	First load, site/date filters, drill-down and map navigation at agreed load; cold/warm caches	Usable values/controls meet the agreed target with separate browser and API timings.
AC02	Dependency failure	Stale/unavailable states appear without zero-risk substitution.
AC03	Evidence review	Screenshots, browser timings, API traces and errors are retained; a partial shell is not counted as completion.

Decisions still required: Section 5.4, Q10; numerical entry “Monitored capacity and dashboard response (PAR-03)”.

SRS-PER-105 — Capacity Expansion

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-REX-005; URG-T47-R06.
Source modality	shall; all source conditions remain applicable.

The deployment shall demonstrate a measured expansion path from POC workload to the agreed larger workload.

Specification element	Definition
Comparison	Initial POC profile versus agreed larger site/device/source profile.
Workload	Assets/history, event/evidence rate, live sessions, users, model jobs, retention and replay/recovery demand.
Target status	Larger profile, scaling triggers and limits require agreement.
Evidence	Actual-device representativeness, reproducible synthetic generators, integrity/timing/resource and cost results.

Clause	Control / behaviour
B01	Demonstrate a capacity path from the initial POC workload to an agreed larger site/device/source set using the sizing model and measured bottlenecks.
B02	Include added asset/history cardinality, event/evidence rate, live sessions, users, model jobs, retention and replay/recovery demand.
B03	Show which resources/workers/storage/network and operating costs grow, the trigger for each increase and limits requiring further design.
B04	Reuse core data/interface/workflow structure and confirm new sites retain correct identities/placement/permissions.
B05	Synthetic load may test scale beyond physical pilot quantities, but must be declared and validated against actual-device traffic characteristics.

Verification:

Criterion	Scenario / method	Expected result
AC01	Base and expanded reproducible profiles with actual-device flows	Latency, errors and data integrity are measured; synthetic load is declared and representative.
AC02	Before/after resource review	CPU, memory, network and storage evidence supports resource/cost estimates and scaling triggers.

Decisions still required: Section 5.4, Q10; numerical entries “Monitored capacity and dashboard response (PAR-03)” and “Retention, backup and reporting scale (PAR-12)”.

SRS-PER-106 — Scalability Cost

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-COST-004; URG-T49-R05.
Source modality	shall; all source conditions remain applicable.

Expansion cost shall be estimated from workload and resource drivers, including step changes.

Specification element	Definition
Cost boundary	Fixed shared platform, per-site/device costs and resource/support tier changes.
Workload	Agreed additional sites/assets/sensors/sources/users and operating demand.
Unit / target status	Currency/rate basis and quantities follow the agreed sizing/BOM/service-rate model; no assumed linear cost rule.
Evidence	Sensitivity cases, amortisation/reuse, load-test resource use, tier limits and uncertainty.

Clause	Control / behaviour
B01	Model expansion by additional sites, monitored assets, sensors, data sources and users, separating fixed shared-platform costs from per-site/per-device costs and step changes.
B02	Main drivers include survey/install/access travel, hardware/power/bearer, media rate/live concurrency and egress, retained data/backups, inference/training compute, source-adapter development, licensing/users, support load, maintenance/replacements and redundancy.
B03	Provide base/expanded sensitivity cases for agreed quantities and workload; show amortisation/reuse explicitly and avoid assuming cost grows only linearly with sensor count.
B04	Identify thresholds where hosting, network or support tier must increase.

Verification:

Criterion	Scenario / method	Expected result
AC01	Recompute expansion from sizing, BOM and service rates	Base/expanded scenarios reproduce and include uncertainty plus cost-per-site breakdown.
AC02	Compare model to load-test consumption and tier limits	Step changes and non-linear cost drivers are supported by evidence.

Decisions still required: Section 5.4, Q10; numerical entry “Monitored capacity and dashboard response (PAR-03)”.

3.3.3 Maintenance and Diagnostics

Submodules: Service monitoring; health diagnosis; planned maintenance; component replacement; controlled update and rollback.

Actors: Superadmins manage approved platform maintenance. Assigned field personnel carry out physical work within their work instructions. Operational users see service impact and restrictions. Rule: Maintenance must not hide actual health or bypass device-action restrictions.

SH-MNT-001 — Maintenance procedures and ownership

Attribute	Specification
Status	Proposed.
Provenance	Baseline Sources#SRC-03

Maintenance and recovery procedures shall identify accountable responsibilities and execution evidence.

Clause	Control / behaviour
B01	Define inspection, diagnostics, component replacement, software update, and recovery procedures with assigned responsibilities.

Verification:

Criterion	Scenario / method	Expected result
AC01	Walk through inspection, diagnostics, replacement, update and recovery	Responsibilities and execution evidence are recorded.

SRS-MNT-101 — Maintenance

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-AVAIL-002; URG-T28-R03.
Source modality	shall; all source conditions remain applicable.

Where maintenance windows apply, changes shall use the approved window and controlled restrictions.

Clause	Control / behaviour
B01	Where maintenance windows apply, schedule changes within the approved window and identify affected devices/services and expected impact.
B02	Before work, record the change/version, responsible person, backup/rollback checkpoint and authorised operational restrictions.
B03	Display maintenance state without falsifying device health.
B04	Preserve event records and prohibit maintenance-disallowed activations.
B05	Validate recovery before ending the window, release only the approved restrictions and retain overrun/outage records.
B06	Emergency changes use the separately agreed exception/approval process, not an assumed exemption from the window requirement.

Verification:

Criterion	Scenario / method	Expected result
AC01	Rehearse planned device/service maintenance	Impact notice and restrictions are correct; recovery/rollback evidence includes start/end times.
AC02	Maintenance overrun	Overrun is recorded and reviewed rather than silently excluded.

Decisions still required: Section 5.4, OPEN-04/OPEN-10/OPEN-16; numerical entry “Availability and recovery (PAR-04)”.

SRS-MNT-102 — Maintenance & Management

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-O&M-001; URG-T46-R02.
Source modality	shall; all source conditions remain applicable.

Operational runbooks shall support controlled inspection, replacement, update, diagnosis and recovery.

Clause	Control / behaviour
B01	Provide sensor cleaning, inspection and calibration runbooks.
B02	Provide battery inspection, recharge and replacement runbooks.
B03	Provide equipment-swap procedures that preserve identity and deployment history.
B04	Provide software/model update and configuration/requirement/version change-control runbooks.
B05	Provide staged deployment and rollback procedures; the source extract retains the spelling “Roolback”.
B06	Provide fault-diagnosis, database/bucket/configuration/model backup/recovery and health/log monitoring runbooks.
B07	For each runbook state trigger/interval, accountable role, prerequisites/tools, permitted impact/window, steps, validation, rollback/stop condition and records.
B08	Preserve the prior validated artefact/configuration and assess schema compatibility before updating.
B09	After update failure restore a compatible state without replaying stale commands.
B10	Run relevant regression tests after sensor/model/configuration changes.
B11	Include supported-version/license expiry and spare/replacement constraints.

Verification:

Criterion	Scenario / method	Expected result
AC01	Rehearse battery/equipment replacement and software/model/config updates	Versions/history, working function and event/outcome records remain correct.
AC02	Failed release rollback, diagnosis and restore	Compatible working state returns without unintended actuation; runbook execution evidence is retained.

Decisions still required: Section 5.4, OPEN-10/OPEN-16.

3.4 Compliance Security and Privacy

Submodules: TM policies; data protection; authentication/authorisation/accounting; third-party dependencies; threat assessment; security evidence.

Purpose: Protect operational assets and information and apply the required TM controls. Actors: Superadmins manage platform security settings; TM reviewers confirm applicable policies and acceptance. Compliance has not yet been verified. No certification is claimed.

SH-SEC-001 — Security and privacy controls

Attribute	Specification
Status	Proposed.
Provenance	Baseline Sources#SRC-03

Security controls shall protect identities, access, communications, stored data, credentials and updates.

Clause	Control / behaviour
B01	Define security controls for device identity, access, communications, stored data, credentials, and software updates.

Verification:

Criterion	Scenario / method	Expected result
AC01	Verify agreed identity, communication, data, credential and update controls	Security-assessment and remediation evidence cover the agreed scope.

SRS-SEC-101 — Data Protection

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-SEC-003; URG-T26-R04.
Source modality	shall; all source conditions remain applicable.

Sensitive operational records, evidence and credentials shall be protected across applicable transport and storage paths.

Specification element	Definition
Assets	Sensitive records, evidence, credentials and backups.
Enforcement	Authenticated/encrypted transport; private restricted storage; controlled service/key access.
Failure / evidence	Reject untrusted peers and unauthorised objects; retain redacted configuration and end-to-end test evidence.

Clause	Control / behaviour
B01	Protect sensitive operational records, evidence and credentials on all relevant paths.
B02	Proposed design uses authenticated encrypted MQTT/HTTP transport, private database/bucket access, encrypted persistent volumes/objects and backups, and managed restricted key access.
B03	Issue authorised short-lived evidence/media access instead of public object links; redact tokens and unnecessary personal content from logs and diagnostics.
B04	Separate service identities by responsibility and revoke compromised access without changing device/business IDs.
B05	Reject untrusted transport peers and unauthorised object access.

Verification:

Criterion	Scenario / method	Expected result
AC01	Transport/storage/backup configuration inspection and sensitive-record trace	Approved protection covers end-to-end paths; retained evidence excludes keys.
AC02	Unauthorised API/object access or invalid transport peer	Access is rejected; logs are redacted.

Decisions still required: Section 5.4, OPEN-10/Q14.

SRS-SEC-102 — Security of AI Functions

Attribute	Specification
Status	Proposed response.
TM source	REQ-SEC-006; URG-T26-R07.
Source modality	shall; all source conditions remain applicable.

AI inputs and outputs shall remain subject to validation, restricted privileges and normal operational authorisation.

Specification element	Definition
Assets	Operational privileges, model artefacts, retrieved records and prompts.
Enforcement	Validated inputs/outputs, isolated jobs, audited configuration and read-only M4 assistant.
Failure / evidence	Reject/mark compromised outputs unavailable; adversarial tests demonstrate no unauthorised operational write.

Clause	Control / behaviour
B01	Treat imported text, media metadata, model outputs and retrieved records as untrusted inputs.
B02	Validate type, size and schema; isolate training/inference jobs from operational write credentials and use approved model artefacts with recorded versions.
B03	The proposed M4 chatbot is read-only: retrieved instructions or generated text cannot grant permissions, change thresholds, send commands or close cases.
B04	Prediction/detection outputs enter the platform’s validated rule/approval path; compromised or malformed outputs are rejected or marked unavailable, with normal non-AI operations continuing.
B05	Restrict and audit model/guardrail/configuration changes and prevent secrets or unauthorised records entering prompts.

Verification:

Criterion	Scenario / method	Expected result
AC01	Malicious retrieved instructions, malformed predictions and out-of-role retrieval	No unauthorised command/write occurs; rejected inputs are visible and only permitted records return.
AC02	Unauthorised model/config change or AI dependency failure	Changes are restricted; maps/cases and normal non-AI operations continue.

Decisions still required: Section 5.4, OPEN-10/OPEN-11.

SRS-SEC-103 — Enterprise Security

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-COMP-001; URG-T30-R02.
Source modality	shall; all source conditions remain applicable.

Applicable TM security controls shall be mapped to deployment evidence or explicit unresolved exceptions.

Clause	Control / behaviour
B01	Maintain a TM security-control applicability register identifying policy name/version, applicable component/interface/data, required control, implementation evidence, assessor and unresolved exception.
B02	Map the proposed identity, network, data, cloud, AI and workflow controls to that register; apply required controls before the affected deployment is accepted.
B03	Where policy requirements conflict with the draft technology or operating model, record the gap and corrective design or proposed exception for TM decision.
B04	No generic security checklist or successful login test shall be represented as evidence of TM-policy compliance.

Verification:

Criterion	Scenario / method	Expected result
AC01	Policy-to-control review with sampled configurations and negative tests	Every applicable control maps to evidence or an explicitly unresolved exception; no generic checklist is claimed as compliance.

Decisions still required: Section 5.4, OPEN-10/Q14.

SRS-SEC-104 — Data Protection

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-COMP-002; URG-T30-R03.
Source modality	shall; all source conditions remain applicable.

Data processing shall follow approved purpose, access, location, recipient and retention arrangements.

Clause	Control / behaviour
B01	Maintain a data inventory stating category, origin, purpose, permitted use, ownership, personal/sensitive content, processing locations, recipients, retention and required approval.
B02	Apply data minimisation and role-restricted access to imagery, contact details, incident records and location data; prevent uploads to unapproved external services, including LLM providers.
B03	Define correction, access/investigation and deletion/hold handling in accordance with applicable organisational/regulatory obligations.
B04	Record cross-border/third-party processing decisions and contractual restrictions before enabling the affected flow.
B05	Regulatory applicability and lawful processing arrangements require competent TM review, not inference from deployment geography.

Verification:

Criterion	Scenario / method	Expected result
AC01	Trace collection/import through storage, reports, backups and approved external API	Recipients, locations and retention match the approved inventory.
AC02	Denied transfer/access tests	Unapproved access/flows are blocked; policy review and redacted flow evidence remain available.

Decisions still required: Section 5.4, OPEN-10/Q14.

SRS-SEC-105 — Third-Party Technology

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-COMP-005; URG-T30-R06.
Source modality	shall; all source conditions remain applicable.

Third-party dependencies shall have verified rights and approval for their intended use.

Clause	Control / behaviour
B01	Maintain an inventory of third-party hardware, firmware, software packages, datasets, maps, model weights, libraries, cloud/LLM services and connectivity dependencies.
B02	Record version, supplier, license/contract, use/redistribution constraints, attribution, expiry/subscription and permitted deployment/processing region.
B03	Review model-weight and training-data rights separately from runtime-library licensing.
B04	Block unapproved restricted components from a release and retain replacement/renewal actions for expiring dependencies.
B05	A technical proof of concept does not establish commercial reuse rights or transfer TM information to a provider.

Verification:

Criterion	Scenario / method	Expected result
AC01	Compare deployed build/BOM and model/data manifests with rights register	Dependencies and required notices match approved contracts/licenses.
AC02	Expiry and incompatible/unmatched dependency inspection	Renewal/replacement actions or blocked release state are explicit.

Decisions still required: Section 5.4, OPEN-10/Q14.

SRS-SEC-106 — Architecture

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-CYBER-001; URG-T42-R02.
Source modality	shall; all source conditions remain applicable.

The security architecture shall identify trust boundaries and enforcement points across the complete operational path.

Clause	Control / behaviour
B01	Document trust boundaries across Device → Connectivity → Edge → Cloud/central → Application → API → User, including reverse command/control and evidence/live-media paths.
B02	For each boundary state authenticated principals, allowed traffic, authorisation point, data classification, encryption/key ownership, audit/monitoring and compromise/failure response.
B03	Separate device credentials from platform and user identity; segregate administrative access from ordinary data paths.
B04	Include offline imports, backups, model artefacts and approved external services.
B05	Show isolation between untrusted input/inference and operational commands.
B06	The security design remains proposed pending applicable TM policy review. No certification is claimed.

Verification:

Criterion	Scenario / method	Expected result
AC01	Threat/data-flow review across every component/interface	Trust-boundary controls and unresolved exceptions are recorded.
AC02	Cross-boundary negative test on representative actual deployment	Unauthorised access is denied and implemented controls have evidence.

Decisions still required: Section 5.4, OPEN-10/Q14.

SRS-SEC-107 — Security Control

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-CYBER-002; URG-T42-R03.
Source modality	shall; all source conditions remain applicable.

The solution shall enforce the eight specified security-control areas at server/service boundaries.

Clause	Control / behaviour
B01	Provide registered, revocable device identities.
B02	Use authenticated encrypted communication.
B03	Enforce API schema, size and rate limits with object/action authorisation.
B04	Use Administrator-managed users and approved sessions.
B05	Restrict and encrypt data/backup access; minimise data.
B06	Apply least privilege to central infrastructure and protect secrets.
B07	Control model artefacts, validate untrusted inputs and restrict AI data access.
B08	Version operational rules; enforce approvals/restrictions and correlate action audit.
B09	Monitor security failures and define revocation, isolation and recovery for compromised principals.
B10	Enforce controls at servers/services, including evidence/media; UI-only controls are insufficient.
B11	Map each control to applicable TM policy and retained tests.

Verification:

Criterion	Scenario / method	Expected result
AC01	Role/object access, malformed input and revoked-device tests	Applicable server/service controls reject prohibited access.
AC02	Unauthorised model/rule change, secret-redaction and restriction-bypass tests	Controls prevent changes/leaks/bypasses.
AC03	Storage/network and eight-area evidence review	Each named area has applicable policy mapping and retained evidence.

Decisions still required: Section 5.4, OPEN-10/Q14.

SRS-SEC-108 — AAA

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-CYBER-003; URG-T42-R04.
Source modality	shall; all source conditions remain applicable.

Operational device exchange shall require a unique authorised device or explicitly mediated adapter identity.

Specification element	Definition
Assets	Device/adapter identity, telemetry/command resources and credentials.
Enforcement	Authenticate before acceptance/dispatch; restrict identity to its own permitted resources/actions.
Failure / evidence	Unknown/revoked or cross-device access is denied; replacement/registration audit remains traceable.

Clause	Control / behaviour
B01	Provision a unique registered identity for each field device or explicitly identified secure adapter where native capability requires mediation.
B02	Authenticate before accepting operational telemetry or dispatching commands; restrict each identity to its own permitted publish/subscribe/API resources and device actions.
B03	Unknown devices cannot auto-enrol.
B04	Keep credentials separate from asset IDs, protect provisioning/storage, support revocation/rotation and audit registration/replacement.
B05	Restrict local maintenance interfaces and avoid shared default credentials.
B06	If native device security is inadequate, assess an isolated trusted gateway and document the residual exposure for approval; transport receipt is never treated as identity authorisation or execution proof.

Verification:

Criterion	Scenario / method	Expected result
AC01	Unknown/revoked credentials and cross-device publication/commands	Only authorised device exchange is accepted and mapped.
AC02	Replacement and re-enrolment	Identity/registration history is auditable; credentials remain absent from logs/exports.

Decisions still required: Section 5.4, OPEN-10/Q14.

SRS-SEC-109 — Data Privacy

Attribute	Specification
Status	Proposed conditional response.
TM source	REQ-ETRES-002; URG-T54-R03.
Source modality	shall; all source conditions remain applicable.

Applicable personal, sensitive or identifiable information shall be processed only within approved purposes and controls.

Clause	Control / behaviour
B01	Where input, evidence, labels, prompts or outputs contain personal, sensitive or identifiable information, identify the categories and processing purpose before use.
B02	Apply minimum-necessary fields, role-controlled access, protection in transit/storage and approved retention/deletion controls in accordance with the applicable TM policy and regulatory requirements.
B03	Record policy references and approval scope; this SRS does not assert a completed legal-compliance assessment.
B04	For the proposed LLM API, use only TM-approved fields/records and processing arrangements.
B05	Prefer record summaries or redacted fields sufficient for the task; photographs, unrelated identifiers and full incident narratives are not automatically sent.
B06	Exclude credentials from prompts, user responses and ordinary logs.
B07	Permission checks apply both before retrieval/transmission and when returning links or answers.
B08	Until external-processing approval is settled, use permitted test data rather than transmit operational data.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect category-specific data flows and policy mapping	Purpose, policy and approval scope are recorded without asserting completed legal compliance.
AC02	Denied record/field, redacted prompt and excluded secret tests	Actual approved API payload contains only permitted data; protected audit evidence supports the result.
AC03	Retention/deletion including retrieval copies	Configured policy is enforced.
AC04	External processing approval gap	Operational data is not transmitted; only permitted test data is used.

Decisions still required: Section 5.4, OPEN-10/OPEN-11/Q14.

3.5 Design and Implementation

The criteria below describe planned tests. Test execution: Not Run; editing this document does not demonstrate acceptance.

3.5.1 Architecture Deployment and Portability

Purpose: Define component responsibilities, deployment, portability and capacity.

Actors: Architecture, platform/IoT and deployment leads; TM architecture/security reviewers.

Submodules: Component boundaries; deployment model; resource sizing; interfaces; site replication; configuration; licensing.

Boundaries: Layers describe logical responsibilities. Provider and live-TM integration approval are not implied.

SRS-ARC-101 — Deployment Model

Attribute	Specification
Status	Proposed deviation
TM source / URG locator	REQ-CCP-002; URG-T37-R03
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

The proposed deployment uses an isolated POC/Pilot central environment and field/edge infrastructure, with offline TM imports and actual IoT-device integration.

Rule	Architecture / deployment rule
B01	Propose an isolated POC/Pilot central environment plus field/edge infrastructure, with offline TM asset/incident imports and actual IoT-device integration.
B02	Identify the final component placement explicitly as public cloud, private cloud, TM infrastructure, hybrid, edge or a combination once approved.
B03	Record tenancy, network ownership, region/residency, access and operational responsibility.
B04	No selected provider or live TM network connection is implied.
B05	Live production integration remains unavailable under user direction and is an unresolved proposed deviation from applicable URG integration/allocation entries, requiring TM agreement.
B06	A portable API/mock test does not close that deviation.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect deployment boundary, network and data-flow evidence	Selected environment matches approved residency/access requirements without accidental dependency on live TM production services.
AC02	Review integration disposition	The deviation remains explicitly open until TM approval; portable/API mock evidence does not close it.

Decisions still required: See section 5.4, OPEN-01, OPEN-10 and Q09.

SRS-ARC-102 — End-to-End Architecture

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-ARCH-001; URG-T31-R02
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

The proposed architecture allocates logical responsibilities from field capture to authorised response and recorded outcome.

Rule	Architecture / deployment rule
B01	The proposed logical flow is Field/Physical capture or protection → Connectivity transport → optional Edge filtering/detection/buffering → IoT service normalisation and central platform persistence → AI/Analytics assessment → Application review → Workflow/Integration decision, authorised preventive action and recorded outcome.
B02	Layers are logical responsibilities, not seven mandatory separate deployments.
B03	Every device observation, health message, command and live-media interaction passes through the IoT service boundary.
B04	Platform rules own validation/priority/approval/case closure.
B05	Model output alone cannot actuate.
B06	PostgreSQL stores records.
B07	Buckets store files.
B08	Offline TM imports supply asset/history context.
B09	The standalone boundary remains a proposed deviation from live enterprise integration, requiring TM agreement.
B10	Device integration is retained.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect data-flow diagram and trace an actual animal/rodent detection	Every applicable component links detection to Operator action and recorded outcome; conditional layers are identified.
AC02	Trace construction/theft and predictive preventive flows through allocated capability tests	Applicable flow responsibilities and conditional layers are demonstrable for each allocated capability.

Decisions still required: See section 5.4, OPEN-01, OPEN-03 and Q09.

SRS-ARC-103 — Architecture Documentation

Attribute	Specification
Status	Proposed response
TM source / URG locator	REQ-ARCH-002; URG-T31-R03
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Deliver a versioned logical and physical architecture pack covering the components, interfaces and controls below.

Rule	Architecture / deployment rule
B01	Deliver a versioned logical and physical architecture pack naming physical components.
B02	Name cameras/sensors/IoT devices.
B03	Name bearer networks and trust zones.
B04	Name any edge controller/runtime.
B05	Name central/cloud compute.
B06	Name application and workflow services.
B07	Name PostgreSQL and bucket stores.
B08	Name model training/inference/registry components.
B09	Name dashboard/live-view entry points.
B10	Name API endpoints and external/offline interfaces.
B11	Name identity, encryption, access, audit, backup and monitoring controls.
B12	Each component entry states responsibility, inputs/outputs, deployment location, interfaces, failure/degraded behavior, data stored and operational owner.
B13	Show signal and command direction, authentication boundaries, ports/protocols, storage/recovery dependencies and deployment variants.
B14	Mark unknown vendor and site details as To Confirm; do not describe them as installed.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect every listed architecture component class and event, evidence, command, import, inference and backup path	Paths agree with API/data contracts; review findings and architecture revision history are retained.

Decisions still required: See section 5.4, OPEN-02, OPEN-03 and OPEN-10.

SRS-ARC-104 — Component Traceability

Attribute	Specification
Status	Proposed response
TM source / URG locator	REQ-ARCH-003; URG-T31-R04
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Link major components and interfaces to the original source and local requirement IDs.

Rule	Architecture / deployment rule
B01	Provide a component-to-requirement matrix linking each major component and interface to literal URG IDs plus source locators and existing PL/HW/SH/FE/MD requirement IDs where present.
B02	Include shared controls, field equipment, external dependencies and supporting engineering deliverables, not only application modules.
B03	For each row show the responsibility satisfied, allocation, verification method and linked design artefact.
B04	Identify an untraced component as an explicit supporting refinement/additional proposal.
B05	Identify an uncovered requirement as a gap requiring response.
B06	Keep duplicate or unusually formatted source IDs; do not replace them with new requirement IDs.

Verification:

Criterion	Scenario / method	Expected result
AC01	Reconcile inventory and traceability matrix in both directions; sample functional and NFR paths	Requirement, component and planned verification links reconcile; untraced components and uncovered requirements remain recorded findings.

Decisions still required: See section 5.4, OPEN-12 and Q01–Q03.

SRS-ARC-105 — Technology Justification

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-ARCH -004; URG-T31-R05
Source modality	descriptive obligation; all source conditions remain applicable
Test execution	Not Run

Document evidence-based technology choices, alternatives, dependencies and replacement paths.

Rule	Architecture / deployment rule
B01	For each major technology, provide a selection record stating operating need, evaluated alternatives, assumptions, measured or supplier-supported suitability, security/licensing, integration, maintainability, lifecycle cost, portability and failure limitations.
B02	Retain PostgreSQL, bucket storage and MQTT/HTTP as user-confirmed choices while evaluating versions/providers/broker/transport details.
B03	Assess edge/GPU need against sensor/video/inference workload, network and energy constraints.
B04	Keep camera, deterrent, map supplier, model family and hosting unselected until evidence supports them.
B05	A selected technology must have an exit/replaceability path or a declared proprietary dependency.
B06	Preserve literal ID REQ-ARCH -004.

Verification:

Criterion	Scenario / method	Expected result
AC01	Review every major BOM, software and deployment choice and rejected alternatives	Rationale cites a benchmark, site measurement, requirement or vendor evidence; alternatives use comparable criteria.

Decisions still required: See section 5.4, OPEN-03, OPEN-10 and Q02.

SRS-ARC-106 — Cloud Architecture

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-CCP-001; URG-T37-R02
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Document the proposed central topology and its durable-state, device-interaction and failure boundaries.

Rule	Architecture / deployment rule
B01	Proposed central topology comprises a protected web/API application, separate FALCON IoT service with protocol adapters, ingestion/media and background workers, workflow/risk services, PostgreSQL, private bucket storage and separately controlled model processing/registry.
B02	Show compute/runtime boundaries, storage/database capacity, network zones and allowed traffic, identity/secrets controls, monitoring/logging, backup/restore path and external/offline integration endpoints.
B03	Keep application/workflow state durable.
B04	Bound worker queues and expose dependency failure.
B05	The IoT service is the only device-interaction boundary.
B06	Separate deployment units only where load/security/failure isolation requires them.
B07	This does not mandate a distributed microservice stack or particular cloud vendor.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect deployable topology/configuration inventory; exercise event, command, media, inference and backup paths	Network/security configuration and component-to-requirement links are retained for the exercised paths.
AC02	Make each dependency unavailable	Declared degraded/failure handling is observed without loss of required durable state; evidence remains linked to the topology.

Decisions still required: See section 5.4, OPEN-10 and Q10; numerical parameters “Monitored capacity and dashboard response (PAR-03)” and “Availability and recovery (PAR-04)”.

SRS-ARC-107 — Resource Requirements

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-CCP-003; URG-T37-R04
Source modality	descriptive obligation; all source conditions remain applicable
Test execution	Not Run

Provide reproducible resource sizing based on measured workloads and explicit assumptions.

Rule	Architecture / deployment rule
B01	Provide a sizing sheet with calculations and assumptions that can be checked and repeated.
B02	CPU demand derives from measured request/ingest/worker service time and peak rates.
B03	GPU is included only for selected model throughput/latency that needs it.
B04	Memory includes runtime/model working sets, active jobs and database cache.
B05	Storage includes retained row/index growth, evidence/model/import/report objects, queue reserve and backups.
B06	Network demand sums telemetry, event media, requested live streams, updates and replay overhead.
B07	Database capacity states record cardinalities, query concurrency, write rate, index/retention assumptions and recovery overhead.
B08	Record headroom, benchmark environment and scaling trigger as proposed parameters.
B09	Show how different values for unknown inputs affect the sizing result.

Verification:

Criterion	Scenario / method	Expected result
AC01	Benchmark messages, queries, model jobs and streams; calculate base, peak and failure-recovery capacity	Sizing is reproducible from measured workload and retained environment assumptions.
AC02	Load-test candidate sizing	Observed resource use and bottlenecks reconcile with the sizing sheet; workload and environment manifest are retained.

Decisions still required: See section 5.4, Q10; numerical parameters “Monitored capacity and dashboard response (PAR-03)”, “Live-view quality and sessions (PAR-10)” and “Retention, backup and reporting scale (PAR-12)”.

SRS-ARC-108 — Scalability

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-CCP-006; URG-T37-R07
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Support expansion through configuration, canonical contracts and measured capacity controls without rewriting core concepts.

Rule	Architecture / deployment rule
B01	Represent site/device/source as data/configuration, with indexed/paginated queries and adapters using the same canonical contracts.
B02	Scale ingestion, media and model workers independently within measured database/broker/storage limits.
B03	Externalise durable queue/work state so restarting a worker does not lose accepted work.
B04	Partition high-volume data or add replicas only when the capacity assessment demonstrates need, preserving consistency of commands, cases and audit.
B05	Apply bounded concurrency/backpressure and expose saturation.
B06	Expansion must not require rewriting core asset/event/workflow concepts.
B07	New device-specific adapters or site engineering may still be necessary and declared.

Verification:

Criterion	Scenario / method	Expected result
AC01	Add a second configured site/source and increase load through the planned POC-to-Pilot envelope	Isolation/associations remain correct without core-code redesign; agreed latency and data-integrity measures are met, with bottleneck/scaling evidence and any observed deviations retained.

Decisions still required: See section 5.4, Q10; numerical parameters “Monitored capacity and dashboard response (PAR-03)”, “Event processing time (PAR-01)” and “Alert latency (PAR-02)”.

SRS-ARC-109 — Site Replication

Attribute	Specification
Status	Proposed response
TM source / URG locator	REQ-REX-001; URG-T47-R02
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Replicate additional sites using the common contracts and a controlled deployment package.

Rule	Architecture / deployment rule
B01	Instantiate additional sites through registered site/asset/device/deployment records and approved site configuration, reusing the same IoT, event, risk, workflow and access contracts.
B02	Replication package includes core application/runtime release, compatible device adapters, database/schema changes, site-specific assets/geometry, rule/settings versions and deployment/commissioning checklist.
B03	Survey, power, connectivity, mounting and field-safe action policy remain site-specific inputs.
B04	Configuration reuse cannot waive them.
B05	Verify central capacity before connecting the new site and isolate incomplete provisioning so it cannot emit accepted events or commands under another identity.

Verification:

Criterion	Scenario / method	Expected result
AC01	Create second site from replication package, register/import devices/assets and run end-to-end flow	Histories and identities do not collide; any code changes are recorded and justified as adapter/configuration changes rather than fundamental redesign.

Decisions still required: See section 5.4, OPEN-02, OPEN-03 and OPEN-04.

SRS-ARC-110 — Deployment Portability

Attribute	Specification
Status	Proposed response
TM source / URG locator	REQ-PORT-001; URG-T48-R02
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Package core services, migrations, interfaces and configuration for redeployment at additional fibre locations.

Rule	Architecture / deployment rule
B01	Package core services, data migrations, interfaces and site configuration so they can be redeployed at additional fibre locations without changing the core architecture.
B02	Keep site coordinates, monitored assets, network endpoints, device mappings and operational settings outside core application code.
B03	Revalidate physical placement, power, connectivity, environment and safety for each location.
B04	Retain device relocation/deployment history instead of overwriting old records.
B05	Portability does not guarantee that the same sensors, mounts and communications links suit every site or remove the need for installation work.

Verification:

Criterion	Scenario / method	Expected result
AC01	Deploy second-location configuration with the same application release	Registration, ingestion, dashboard, authorised workflow and historic-location checks succeed against the agreed configuration; site-specific adaptations are documented.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03.

SRS-ARC-111 — Technology Dependency

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-PORT-002; URG-T48-R03
Source modality	shall/may; all source conditions remain applicable
Test execution	Not Run

Maintain a dependency and exit register for the selected hardware, software, services and external interfaces.

Rule	Architecture / deployment rule
B01	Maintain a dependency/exit register for proprietary hardware interfaces/firmware, controller accelerators/runtime, map/GIS tools, model weights/frameworks, database extensions, bucket/cloud identity/monitoring services, connectivity providers and external APIs.
B02	For each state purpose, criticality, license/service terms, data export format, replacement option, adaptation effort, unsupported feature risk and migration cost/time.
B03	Retain PostgreSQL, buckets and MQTT/HTTP as chosen abstractions while declaring provider-specific features actually used.
B04	Exportability is tested.
B05	An open protocol alone does not demonstrate that the whole solution can be moved to another platform.
B06	Provider/model/vendor remains unselected unless separately approved.

Verification:

Criterion	Scenario / method	Expected result
AC01	Reconcile deployed BOM and service/configuration inventory with dependency register	Dependencies and declared limitations are complete and traceable.
AC02	Rehearse representative records/files/configuration export/import and one replaceable boundary	Exportability and replacement limitations are evidenced; migration results are retained.

Decisions still required: See section 5.4, OPEN-03 and OPEN-10.

SRS-ARC-112 — Deployment Replicability

Attribute	Specification
Status	Proposed response
TM source / URG locator	REQ-PORT-004; URG-T48-R05
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Provide a reproducible deployment guide identifying prerequisites, responsibilities, gates and recovery procedures.

Rule	Architecture / deployment rule
B01	Provide a replication guide naming required central/edge software versions, selected equipment/BOM, power/mounting/connection prerequisites, site survey/design, permitted credentials, asset/device imports, adapter/API dependencies, configuration bundle, model/rule versions and capacity allocation.
B02	Sequence provisioning, installation, calibration, integration, verification, monitored operation and handover.
B03	State who performs/accepts each gate and how failed deployment is isolated/rolled back.
B04	Identify reusable components versus site engineering and optional dependencies.
B05	Keep the target site uncommissioned until required evidence is accepted, with residual limitations documented.

Verification:

Criterion	Scenario / method	Expected result
AC01	A person other than the guide author reproduces a clean deployment using the package	End-to-end function and recovery behaviour are reproduced; missing prerequisites and ambiguities are recorded.

Decisions still required: See section 5.4, OPEN-02, OPEN-03 and OPEN-16.

SRS-ARC-113 — Licensing and Subscription

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-COST-003; URG-T49-R04
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

List required and optional recurring licensing/subscription dependencies and their operational impact.

Rule	Architecture / deployment rule
B01	List all required recurring software/platform/model/cloud/connectivity/data/map/support and other license/subscription dependencies, with supplier, item/version/tier, metric billed, included allowance, overage/egress, renewal/termination, data/usage rights, support/end-of-life and service failure/expiry behavior.
B02	Distinguish optional services from those needed to sustain core operation.
B03	Record whether an LLM outage affects only the proposed assistant.
B04	Include per-device/SIM, per-user, per-inference/token, storage/backup and software maintenance charges where relevant.
B05	Reference current supplier terms/quotes when selected and state unknowns explicitly.
B06	No subscription or purchase is approved by this specification.

Verification:

Criterion	Scenario / method	Expected result
AC01	Reconcile dependency/cost registers with deployed service/license inventory	Required and optional subscription dependencies and cost assumptions are traceable.
AC02	Model allowance exhaustion and expiry	Observed functional impact and data export/exit obligations match the declared terms and limitations.

Decisions still required: See section 5.4, OPEN-03 and OPEN-10.

3.5.2 Edge Controller

Purpose: Allocate edge workload and justify controller resources and dependencies.

Actors: Hardware/edge and IoT leads; engineering reviewers.

Submodules: Workload assessment; hardware/software dependencies; local processing; compute/storage/interface sizing.

Boundaries: A separate inference controller is conditional on measured need; local physical-action authority is not implied.

HW-CTL-001 — Controller resources and interfaces

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-03
Test execution	Not Run

Provide sufficient computing, storage, and interfaces for the agreed camera, sensor, and edge workloads.

Verification:

Criterion	Scenario / method	Expected result
AC01	Run agreed camera, sensor and edge workload on selected unit	Resource usage is recorded against agreed capacity limits; no pass is inferred before those limits are agreed.

Decisions still required: See section 5.4, OPEN-03 and Q10; numerical parameter “Monitored capacity and dashboard response (PAR-03)”.

SRS-CTL-101 — Assessment of edge functions

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-EDGE-001; URG-T36-R02
Source modality	shall/may; all source conditions remain applicable
Test execution	Not Run

For each proposed edge function, state the device capability and measured operating need that justify running it locally.

Rule	Controller capability / condition
B01	Document an edge-function allocation for preliminary filtering, video/image processing, event detection, aggregation, compression, local decision-making and temporary storage, identifying each as selected, unnecessary or unresolved with rationale.
B02	Proposed minimum on a capable edge unit is acquisition, timestamp/identity preservation, health and buffering.
B03	Place filtering/inference/compression locally only when measured bandwidth, latency, privacy or offline needs justify the compute/energy cost.
B04	Ready-made detection devices may emit events without a separate inference controller.
B05	Central platform retains business rules/cases.
B06	No generic local physical-action authority is inferred.
B07	Record inputs, outputs, configuration/model version, resource bounds and degraded behavior for each selected function.

Verification:

Criterion	Scenario / method	Expected result
AC01	Review function allocation against selected hardware; exercise each chosen function with sample input, resource measurement and central-link loss	Selected functions exhibit documented outputs, resource bounds and degraded behaviour.
AC02	Inspect excluded functions	Evidence shows each is handled elsewhere or is genuinely inapplicable.

Decisions still required: See section 5.4, OPEN-03 and OPEN-04; numerical parameters “Commands and connectivity recovery (PAR-09)” and “Power and sustained operation (PAR-11)”.

SRS-CTL-102 — Hardware Dependency

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-COST-002; URG-T49-R03
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Justify each proposed hardware item using functional value, alternatives and lifecycle implications.

Rule	Controller capability / condition
B01	For each proposed physical item explain the threat/function it enables, why existing infrastructure or a simpler option is insufficient, measured/expected operational benefit and limitations.
B02	Attach installation/mounting, power/duty/autonomy, communications/data, maintenance/calibration, consumables, replacement/spares, useful-life/end-of-support and disposal implications.
B03	Separate sensing/detection value from deterrent/protection effectiveness.
B04	A working actuator is not evidence of prevention benefit.
B05	Compare at least the relevant lower-complexity/no-extra-hardware option where credible.
B06	Quantify with validated trials or mark assumptions.
B07	Do not preserve an accelerator/sensor solely because it appeared in a historical proposal.

Verification:

Criterion	Scenario / method	Expected result
AC01	Trace every BOM item to requirement/use-case evidence and review alternatives, value and lifecycle implications	Observed POC performance supports the claimed necessity; maintenance and power burden reconcile with the assessment.

Decisions still required: See section 5.4, OPEN-03.

3.5.3 Sensors Camera and Live View

Purpose: Specify sensing, placement, calibration, evidence and authorised live viewing.

Actors: Hardware/IoT leads, authorised maintainers, Operators and Administrators.

Submodules: Threat-to-sensor mapping; coverage and placement; calibration; animal/tamper detection; health; event media; live viewing.

Boundaries: Actual-device evidence is required where stated. One camera per panel does not establish system concurrency; live viewing does not add recording.

HW-SEN-001 — Sensor and camera acquisition

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-03
Test execution	Not Run

Connect selected sensors and camera to the edge system and capture observations with timestamps and source identity.

Verification:

Criterion	Scenario / method	Expected result
AC01	Capture observations from actual selected sensors/camera	Timestamps, source identity and available evidence match the observation; separately specified live-view controls are verified.

Decisions still required: See section 5.4, OPEN-02, OPEN-03, OPEN-09 and OPEN-14; numerical parameter “Sensor coverage and detection (PAR-05)”.

SRS-SEN-001 — On-demand live view

Attribute	Specification
Status	Proposed
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.
Test execution	Not Run

Administrators and Operators shall start and stop a live session for one supported camera per viewing panel through the IoT-mediated path.

Rule	Sensing / live-view rule
B01	Viewer-only accounts shall be denied.
B02	Session inactivity shall terminate viewing using the agreed timeout, and start/stop/timeout shall be audited.

Verification:

Criterion	Scenario / method	Expected result
AC01	View actual supported camera from device and related-event entry points using Administrator and Operator roles	Each allowed role can start and explicitly stop the IoT-mediated session; start/stop actions are audited.
AC02	Attempt Viewer access and exercise inactivity termination	Viewer access is denied; viewing terminates at the agreed inactivity condition and termination is audited.

Decisions still required: See section 5.4, OPEN-14; numerical parameter “Live-view quality and sessions (PAR-10)”.

SRS-SEN-002 — Live and saved media distinction

Attribute	Specification
Status	Proposed
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.
Test execution	Not Run

Live viewing shall be identified separately from stored event images/clips.

Rule	Sensing / live-view rule
B01	Initial live-view scope excludes manual and continuous recording.
B02	Displaying an image shall not count as demonstrating continuous live video.

Verification:

Criterion	Scenario / method	Expected result
AC01	Compare actual moving live scene with saved event evidence	Live and stored media have clear distinct labels; a saved image is not accepted as continuous live-video evidence.

Decisions still required: See section 5.4, OPEN-14.

SRS-SEN-101 — Sensor Connectivity

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-INTHW-001; URG-T12-R02
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Where sensors are deployed, observations pass from registered authorised devices through the IoT service to the platform.

Rule	Sensing / live-view rule
B01	Where sensors are deployed, registered and authorised devices send observations through the IoT service, which authenticates the source, translates its payload and supplies the platform.
B02	Retain originating device, source observation/event identity, original time, receipt time and available evidence/health data.
B03	MQTT and HTTP remain the recorded protocol direction.
B04	Exact device adapter and payload are not assumed.
B05	Resolve the observation against the device deployment valid at its original event time, then its monitored location and linked fibre asset where available.
B06	Missing/invalid required fields are quarantined or flagged with a reason.
B07	An unknown device is rejected.
B08	Ambiguous event time or overlapping/missing deployment history retains the observation for authorised review but withholds association-dependent automatic action.
B09	Do not discard separate genuine detections merely because they share values.

Verification:

Criterion	Scenario / method	Expected result
AC01	Trace actual deployed sensor observation through its adapter	Registered source and applicable deployment/location/asset are preserved through the IoT path.
AC02	Replay same identity; submit a genuine new detection	Replay creates no duplicate; the distinct genuine detection remains retained.
AC03	Submit unregistered device, invalid payload and delayed pre-relocation observation, including ambiguous history/time	Unknown source is rejected; invalid input has a reason; determinable historic placement is used and ambiguity remains reviewable without association-dependent action.

Decisions still required: See section 5.4, OPEN-03 and OPEN-07.

SRS-SEN-102 — Infrastructure Tampering

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-FUNC-031; URG-T17-R03
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Where appropriate monitoring equipment is deployed, record supported tamper/access observations against the commissioned asset and deployment.

Rule	Sensing / live-view rule
B01	Where appropriate equipment is deployed on cabinets, manholes, poles or other designated fibre infrastructure, register its monitored asset and the supported abnormal-access/tamper signature.
B02	Translate a qualifying observation into an event retaining raw/source indication, device, applicable deployment, time and available evidence.
B03	The commissioned equipment/asset mapping is a precondition.
B04	A database record alone does not establish monitoring coverage.
B05	When authorised maintenance context exists, label it for operator assessment and apply the agreed alert rules.
B06	Maintenance restrictions may prevent physical response but do not delete tamper observations.
B07	Unsupported signals, absent sensor contact or stale status are device/coverage conditions rather than evidence that no tampering occurred.
B08	Do not modify underlying fibre infrastructure without separately approved installation scope.

Verification:

Criterion	Scenario / method	Expected result
AC01	Apply safe approved tamper/access stimulus and benign condition for each selected equipment/asset type	Mapped asset, timestamps and raw indication match the commissioned observation.
AC02	Test maintenance context and disconnected sensor	Observations/history and unavailable coverage remain distinguishable; maintenance does not erase tamper evidence.

Decisions still required: See section 5.4, OPEN-02, OPEN-03 and OPEN-04.

SRS-SEN-103 — Animal Activity Detection

Attribute	Specification
Status	Proposed response
TM source / URG locator	REQ-FUNC-040; URG-T18-R02
Source modality	shall/may; all source conditions remain applicable
Test execution	Not Run

Demonstrate actual animal/rodent observations in M2 and integrated field detection, response and outcome in M3.

Rule	Sensing / live-view rule
B01	At an agreed controlled location in M2, receive an actual animal/rodent detection or identifiable observation through the IoT service, associate it to the monitored deployment and show it with available evidence.
B02	Demonstrate a separate authorised operator-triggered actual deterrent and basic live view.
B03	M3 integrates actual field detection, rule decision, response and outcome.
B04	Detector processing location, species and deterrent are not assumed.
B05	For each supported activity, produce event identity, animal/rodent category or unclassified activity, device/source, original/receipt time, deployment and available evidence/confidence.
B06	Review monkey-related drop-fibre damage and recurring rodent damage from the narrative when defining supported scenarios.
B07	Activity is a potential damage indicator, not proof of damage.
B08	Missing evidence or unsuitable light/coverage is an explicit limitation.
B09	No rule match means record only and no automatic physical action.

Verification:

Criterion	Scenario / method	Expected result
AC01	Actual selected device under agreed safe conditions: animal/rodent event, benign input and unsupported condition	Event traces to platform with supported classification/evidence and explicit limitations; benign/unmatched input cannot cause unapproved physical action.
AC02	Separately demonstrate M2 manual deterrent and basic live view	Actual authorised deterrent and live-view evidence are retained separately from detection.
AC03	M3 integrated rule, approval and action-result test	Full field response path is evaluated against agreed detection metrics and records outcome separately from execution.

Decisions still required: See section 5.4, OPEN-02, OPEN-03, OPEN-04 and OPEN-09; numerical parameter “Sensor coverage and detection (PAR-05)”.

SRS-SEN-104 — Animal Classification

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-FUNC-041; URG-T18-R03
Source modality	should; all source conditions remain applicable
Test execution	Not Run

Where suitable data is available, the detector should return reviewed animal/rodent categories and supplied confidence.

Rule	Sensing / live-view rule
B01	Where image, sensor or other suitable data is available, the detector should return reviewed animal/rodent activity categories and any source-supplied confidence.
B02	Preserve raw class and mapped operational category with the classifier/version.
B03	Proposed initial resolution is the minimum category needed by an approved response rule.
B04	Species-level labels require suitable evidence and validation.
B05	An uncertain or unsupported class remains Unclassified/Needs review rather than a guessed species.
B06	Allow an appropriately authorised operator to record a corrected/reviewed category and reason as feedback while retaining the original detection and its evidence.
B07	Only approved rules using sufficiently supported inputs may request action.
B08	Missing confidence is not numeric zero and does not satisfy a confidence condition.
B09	A category change does not replay past physical actions.

Verification:

Criterion	Scenario / method	Expected result
AC01	Reviewed examples for every supported category; ambiguous input, unsuitable evidence and absent confidence	Category results meet agreed criteria or retain recorded failures; no unsupported species label or numeric-zero confidence is invented.
AC02	Inspect model/source and Operator correction provenance	Original and corrected categories remain traceable; correction does not replay past physical actions; class-level test results are retained.

Decisions still required: See section 5.4, OPEN-03 and OPEN-09; numerical parameter “Sensor coverage and detection (PAR-05)”.

SRS-SEN-105 — Field Deployment Design

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-PHY-001; URG-T32-R02
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Provide a site deployment schedule and arrangement drawing for each installed field component.

Rule	Sensing / live-view rule
B01	Provide a site deployment schedule and arrangement drawing for each installed field component, with unique item/device ID, monitored threat/asset/zone, location, mounting, power, communications, coverage and maintenance access.
B02	Assess applicability separately for cameras, IoT sensors, acoustic/vibration sensors, cabinet sensors, manhole sensors, environmental sensors, animal/rodent detection devices, communication gateways, power systems, mounting equipment and enclosures.
B03	A category not selected receives a reason and alternative coverage, rather than an assumed installation commitment.
B04	Include selected deterrent/passive protection components and their physical separation from sensing where needed.
B05	The M2 arrangement must connect actual selected detection and deterrent hardware through the IoT service.
B06	Final site arrangement cannot be inferred from a lab layout.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect every listed category in applicability/BOM schedule and trace installed items	Every installed item links to drawing, inventory and requirement; excluded categories retain rationale.
AC02	Demonstrate actual M2 signal/command path and inspect field layout before energisation	Selected detection/deterrent hardware uses the IoT boundary; field arrangement has its own inspection evidence.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03.

SRS-SEN-106 — Threat-to-Sensor Mapping

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-SENS-001; URG-T33-R02
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Maintain a validated threat-to-sensor mapping for construction, theft/vandalism and animal/rodent scenarios.

Rule	Sensing / live-view rule
B01	Maintain a threat-to-sensor matrix across construction, theft/vandalism and animal/rodent scenarios.
B02	For construction, assess visible machinery/person/activity and acoustic/vibration indications near fibre.
B03	For theft/vandalism, assess intrusion, cabinet/manhole access or abnormal disturbance.
B04	For animal/rodent, assess observed presence/approach/contact at the agreed species/size/zone.
B05	Validate each proposed sensing method; do not assume one generic camera can recognise every threat.
B06	Record sensor output, physical evidence, expected detection/classification stage, complementary data, limitations and the action decision it can inform.
B07	Passive protection has no sensing claim unless monitored separately.
B08	Detection does not itself prove fibre damage or successful deterrence.

Verification:

Criterion	Scenario / method	Expected result
AC01	Review every target threat and test positive/negative observations with selected sensors	Labelled evidence, detected outputs and coverage/false-alarm limitations substantiate the mapping without unsupported sensing or effectiveness claims.

Decisions still required: See section 5.4, OPEN-03 and OPEN-09.

SRS-SEN-107 — Sensor Coverage

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-SENS-002; URG-T33-R03
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Record validated effective sensing coverage and exclusions for the designated risk area.

Rule	Sensing / live-view rule
B01	Record effective coverage as the validated observable area/segment/zone under stated target size, distance, lighting, orientation, occlusion and environmental conditions.
B02	For non-visual sensors record the physical coupling/propagation or monitored enclosure/point that bounds detection.
B03	Overlay each sensor’s validated coverage on the designated risk area, identify overlaps and blind spots, and describe combined coverage plus any uncovered approach.
B04	Select placement/additional sensing or constrain the claimed monitored area when test evidence does not cover the proposed zone.
B05	A map icon or datasheet maximum range alone is insufficient proof of field coverage.

Verification:

Criterion	Scenario / method	Expected result
AC01	Documented grid/path/zone test at boundaries and expected blind spots in agreed day/night conditions	Validated coverage, distances, test evidence and remaining exclusions are retained for representative targets.

Decisions still required: See section 5.4, OPEN-02 and Q10; numerical parameter “Sensor coverage and detection (PAR-05)”.

SRS-SEN-108 — Sensor Detection Performance

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-SENS-003; URG-T33-R04
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Record selected-sensor performance using applicable measurable characteristics and declared test conditions.

Rule	Sensing / live-view rule
B01	Create a selected-sensor performance sheet with measurable detection range, field of view, sensitivity/threshold, detection/reporting frequency, sampling rate, accuracy and false-positive/false-negative characteristics where applicable.
B02	Distinguish raw sensor accuracy/resolution from model classification quality and end-to-end detection success.
B03	State units, target/ground-truth definition, sample count, environmental/lighting/distance conditions, firmware/model/configuration and confidence/uncertainty.
B04	Non-applicable characteristics require reasons.
B05	Absent vendor values require measurement or an explicit limitation.
B06	Report both detected and missed threat opportunities and false alarms over a declared observation basis.
B07	No minimum percentage or range is invented.

Verification:

Criterion	Scenario / method	Expected result
AC01	Labelled positive/negative trials over proposed operating envelope; collect raw/model outputs	Applicable detection/error measures include denominators and condition slices; comparison uses agreed limits and retains failures as evidence.

Decisions still required: See section 5.4, Q10; numerical parameter “Sensor coverage and detection (PAR-05)”.

SRS-SEN-109 — Sensor Placement

Attribute	Specification
Status	Proposed response
TM source / URG locator	REQ-SENS-004; URG-T33-R05
Source modality	descriptive obligation; all source conditions remain applicable
Test execution	Not Run

Select and validate sensor placement through the stated site assessment method.

Rule	Sensing / live-view rule
B01	Apply this placement method: identify the threatened asset/segment and expected threat approach.
B02	Inspect line of sight or sensor coupling, target scale and environmental interference.
B03	Select position/orientation and candidate coverage.
B04	Check power/connectivity, structural fit, physical safety, privacy and maintenance access.
B05	Then validate coverage with representative trials.
B06	Record the selected and rejected positions with reasons.
B07	For cameras, relate mounting/FOV to usable evidence and on-demand live view.
B08	For cabinet/manhole/vibration sensors, document attachment and measured response at the protected structure.
B09	Re-run the method when infrastructure, vegetation, construction or device placement changes.

Verification:

Criterion	Scenario / method	Expected result
AC01	Review one position-selection record and repeat site placement/coverage checks	Rejected locations and constraints remain documented; final arrangement matches approved drawing.

Decisions still required: See section 5.4, OPEN-02; numerical parameter “Sensor coverage and detection (PAR-05)”.

SRS-SEN-110 — Sensor Calibration

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-SENS-005; URG-T33-R06
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Where calibration applies, retain the calibration procedure, results, configuration history and validation conditions.

Rule	Sensing / live-view rule
B01	Where calibration applies, store the manufacturer/reference procedure, required reference instrument/target, device identity, calibration date, operator, environmental conditions, measured results and next check trigger.
B02	Save configuration/threshold versions and permitted ranges.
B03	Only authorised maintainers change them.
B04	Validate sensor operation after initial setup, relocation, firmware/sensor replacement or material drift.
B05	If calibration is failed/expired where required, identify the affected readings as not validated and constrain dependent decisions according to the approved quality policy.
B06	Where a device is factory-calibrated or has no adjustable calibration, retain evidence and define a functional validation instead of inventing a calibration control.

Verification:

Criterion	Scenario / method	Expected result
AC01	Calibrate/configure representative sensor and compare before/after readings with traceable reference	Calibration and configuration history retains the measured results.
AC02	Attempt invalid/unauthorised change; simulate failed calibration	Invalid/unauthorised changes do not become valid configuration; affected readings and dependent decisions follow the approved calibration/quality policy.

Decisions still required: See section 5.4, OPEN-03 and OPEN-07; numerical parameter “Sensor coverage and detection (PAR-05)”.

SRS-SEN-111 — Sensor Data Integrity

Attribute	Specification
Status	Proposed response
TM source / URG locator	REQ-SENS-007; URG-T33-R08
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Preserve sensor identity, timing, source values, quality and historical deployment association in accepted records.

Rule	Sensing / live-view rule
B01	Accepted sensor records carry registered device/sensor-channel identity, original timestamp with clock-quality indication, service receipt timestamp, deployment/location reference, measurement or event type/value, relevant unit and supplied device status.
B02	Derive the initial location from registered placement rather than require per-event GPS.
B03	Preserve raw source unit/value and validated normalised representation where conversion is needed.
B04	Flag a missing required unit, time or status as a quality issue; do not supply an assumed value.
B05	Retain source and platform identities separately for deduplication.
B06	Proposed delayed-event association uses a trustworthy event time and non-overlapping deployment history.
B07	Uncertain/boundary time is flagged unresolved without rewriting historical placements or enabling location-dependent automatic action.

Verification:

Criterion	Scenario / method	Expected result
AC01	Complete, missing-unit, unknown-device, duplicate and delayed records across relocation	Validation results are explicit; source metadata remains unchanged; reliable historical deployment is used, otherwise association is explicitly unresolved.

Decisions still required: See section 5.4, OPEN-07.

SRS-SEN-112 — Findings

Attribute	Specification
Status	Proposed response
TM source / URG locator	REQ-SITE-002; URG-T44-R03
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Translate material site-survey findings into traceable design decisions, constraints or corrective actions.

Rule	Sensing / live-view rule
B01	Convert each material survey finding into a design decision, constraint or corrective action with traceability to placement/coverage, selected component/environmental envelope, power budget, bearer, mounting/security or maintenance access.
B02	Revise drawings/BOM/configuration and test conditions accordingly.
B03	Identify residual blind spots, inadequate supply/coverage or unresolved permissions and provide an alternative or explicit TM decision before commissioning.
B04	Preserve the original finding, disposition, responsible owner and verification.
B05	Recheck affected design assumptions and acceptance checks when field conditions change.

Verification:

Criterion	Scenario / method	Expected result
AC01	Trace coverage, power, network and installation/security survey findings to final design and commissioning	Each material finding has disposition/evidence; critical open findings reconcile to resolution or an approved limitation.

Decisions still required: See section 5.4, OPEN-02.

SRS-SEN-113 — Additional Sensors

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-REX-003; URG-T47-R04
Source modality	should; all source conditions remain applicable
Test execution	Not Run

Additional sensor types should integrate through declared IoT capabilities and canonical contracts.

Rule	Sensing / live-view rule
B01	Additional sensor types should join through an IoT adapter and capability profile declaring identity/channel, unit/schema, timing, status/health, evidence, commands/feedback and calibration limits.
B02	Translate native payloads into canonical observation/event/health contracts without coupling the central platform to vendor message structures.
B03	Register/authorise the device and map its placement before accepting operational data.
B04	Unsupported capabilities remain explicitly unavailable.
B05	An adapter must not claim execution confirmation or duplicate-execution control it cannot prove.
B06	If a sensor changes what the data means, review and extend the interface contract and carry out the required migration; do not silently change existing field meanings.

Verification:

Criterion	Scenario / method	Expected result
AC01	Second contrasting sensor simulator or selected type connected through adapter; contract, identity, quality and replay tests	Existing device flows remain unchanged; capability matrix and limitations are retained, including unsupported capabilities.

Decisions still required: See section 5.4, OPEN-03 and OPEN-07.

3.5.4 Edge Software

Purpose: Specify selected local processing, buffering and synchronisation.

Actors: Edge/IoT leads and engineering reviewers.

Submodules: Acquisition and timestamping; permitted local processing; buffering; restart recovery; synchronisation.

Boundaries: Offline sensing/buffering does not authorise autonomous deterrence or replay of withheld/expired actions.

HW-SW-001 — Local processing

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-03
Test execution	Not Run

Acquire camera and sensor data and run the agreed local processing.

Verification:

Criterion	Scenario / method	Expected result
AC01	Known camera/sensor inputs processed using agreed local functions	Outputs and provenance match the expected processing result.

Decisions still required: See section 5.4, OPEN-03 and OPEN-04; numerical parameter “Commands and connectivity recovery (PAR-09)”.

HW-SW-002 — Buffering and recovery

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-03
Test execution	Not Run

Support local buffering and recovery when connectivity is interrupted.

Verification:

Criterion	Scenario / method	Expected result
AC01	Interrupt connectivity and fill/recover agreed buffer workload	Original timestamps are preserved and applicable data loss/overflow is reported.

Decisions still required: See section 5.4, OPEN-03 and OPEN-04; numerical parameter “Commands and connectivity recovery (PAR-09)”.

SRS-EDG-101 — Resiliency

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-EDGE-002; URG-T36-R03
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Designated edge functions shall continue during temporary central-connectivity loss within their agreed power and storage envelope.

Rule	Edge operating condition
B01	During temporary central-connectivity loss, designated edge functions shall continue within their agreed power/storage envelope: proposed local capture, source timestamping, installed validated detection where selected, health recording and durable buffering.
B02	Retain the last approved configuration/model needed for those functions and make queue/resource limits visible after reconnection or locally where supported.
B03	Do not equate lost central connectivity with permission for autonomous deterrence.
B04	Offline action eligibility, limits, stop behavior and recovery must be separately approved for the chosen device/site.
B05	Until then the draft leaves that decision open while retaining the required offline sensing/buffering design.
B06	Document exactly what stops when capacity/power is exhausted.

Verification:

Criterion	Scenario / method	Expected result
AC01	Disconnect central link for agreed endurance window	Acquisition, selected detection and queue records reconcile to expected input and selected recovery behaviour.
AC02	Full storage and power interruption	Documented exhausted-capacity behaviour occurs without unintended physical action.

Decisions still required: See section 5.4, OPEN-03 and OPEN-04; numerical parameter “Commands and connectivity recovery (PAR-09)”.

SRS-EDG-102 — Synchronisation

Attribute	Specification
Status	Proposed response
TM source / URG locator	REQ-EDGE-003; URG-T36-R04
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Synchronise buffered metadata and evidence through the IoT service after connectivity returns.

Rule	Edge operating condition
B01	After connectivity returns, re-authenticate the device/edge identity and synchronise queued metadata/evidence through the IoT service using original IDs/times, payload schema/version and integrity checks.
B02	Resume incomplete files where the chosen transport supports it, otherwise retry the same identified object.
B03	Acknowledge only the durable accepted state.
B04	Apply rate-limited catch-up so replay does not starve current critical telemetry.
B05	Deduplicate retransmissions, preserve real separate detections and flag out-of-order/delayed/clock-uncertain data.
B06	Resolve device deployment from recorded history when reliable.
B07	Ambiguous relocation association is exposed for review.
B08	Synchronisation does not rerun historical rules into expired or withheld deterrent actions.

Verification:

Criterion	Scenario / method	Expected result
AC01	Reconnect after duplicates, interrupted evidence, uncertain clock and relocation during outage	Counts, checksums and location associations reconcile; ambiguity is explicit, current traffic remains observable and stale commands do not execute.

Decisions still required: See section 5.4, OPEN-03 and OPEN-04; numerical parameter “Commands and connectivity recovery (PAR-09)”.

3.5.5 Connectivity

Purpose: Select site communications and define loss, retry and recovery behaviour.

Actors: Connectivity, edge and IoT leads; TM site owners.

Submodules: Site communications assessment; protocol adaptation; connection loss; acknowledgements; store-and-forward.

Boundaries: MQTT/HTTP are protocol decisions; each site bearer and media capability still needs evidence. IoT owns command retries.

HW-CON-001 — Event evidence and health transport

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-03
Test execution	Not Run

Transmit events, evidence, and device health through the agreed communications interface.

Verification:

Criterion	Scenario / method	Expected result
AC01	Trace actual-device event, evidence reference and health reading across selected communication path	Corresponding platform records retain the expected source/transport association.

Decisions still required: See section 5.4, OPEN-02, OPEN-03 and OPEN-04; numerical parameter “Commands and connectivity recovery (PAR-09)”.

HW-CON-002 — Acknowledgement retry and buffering

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-03
Test execution	Not Run

Define acknowledgement and retry behaviour with edge buffering to handle interrupted connectivity.

Verification:

Criterion	Scenario / method	Expected result
AC01	Interrupt and restore selected connection	Agreed acknowledgements/retries preserve original timestamps with duplicate-free recovery; unsupported buffering has an explicit disposition.

Decisions still required: See section 5.4, OPEN-02, OPEN-03 and OPEN-04; numerical parameter “Commands and connectivity recovery (PAR-09)”.

SRS-CON-101 — Field Connectivity

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-CONN-001; URG-T35-R02
Source modality	shall/may; all source conditions remain applicable
Test execution	Not Run

Connect selected devices through assessed bearers and the IoT service using the documented protected platform interface.

Rule	Connectivity / recovery rule
B01	Connect selected devices to the IoT service using assessed site bearer links, and connect that service to the platform over the documented protected interface.
B02	MQTT and HTTP are retained protocol decisions.
B03	Adapters mediate native device protocols as required.
B04	Evaluate fibre, Wi-Fi, cellular, LPWAN, radio, satellite or another suitable bearer where appropriate rather than require all.
B05	Carry observations/status and command/results.
B06	Transfer evidence and requested live video through a capacity-suitable path within the IoT boundary.
B07	A low-bandwidth bearer suitable for telemetry is not assumed suitable for continuous video.
B08	Expose loss/quality limitations and rejected/failed transfers.

Verification:

Criterion	Scenario / method	Expected result
AC01	Demonstrate actual-device observations, evidence, health, command/results and requested live-view path on proposed bearer	Throughput, latency, reconnection behaviour and supported-function limitations are captured.

Decisions still required: See section 5.4, OPEN-02, OPEN-03 and OPEN-04; numerical parameter “Commands and connectivity recovery (PAR-09)”.

SRS-CON-102 — Connectivity Selection

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-CONN-002; URG-T35-R03
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Select site connectivity using measured coverage, workload, energy, reliability, security and cost evidence.

Rule	Connectivity / recovery rule
B01	Issue a site connectivity comparison using measured/verified coverage, sustainable and burst bandwidth, latency/jitter, reliability/outage behavior, device power consumption, environmental/installation constraints, security and ongoing cost.
B02	Model telemetry, event images/clips, concurrent requested streams, updates and buffer replay separately.
B03	Include uplink limits and data caps.
B04	Explain selected primary bearer and whether fallback is needed for the agreed service target.
B05	Define degraded behavior when media cannot pass but event metadata can, and document any site requiring additional infrastructure.
B06	Marketing coverage maps or protocol choice alone are insufficient field evidence.

Verification:

Criterion	Scenario / method	Expected result
AC01	Site signal/path and representative upload/stream tests where access permits	Findings reconcile to workload/energy/cost assumptions; alternate-bearer trade-offs and unresolved coverage risk are retained.

Decisions still required: See section 5.4, OPEN-02, OPEN-03 and OPEN-04; numerical parameter “Commands and connectivity recovery (PAR-09)”.

SRS-CON-103 — Communication Loss

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-CONN-003; URG-T35-R04
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Continue selected local functions during communication loss and recover delivery without stale or duplicate physical action.

Rule	Connectivity / recovery rule
B01	On communication loss, continue the selected local acquisition/buffering functions and report loss after the configured contact threshold.
B02	For critical event information use durable local or edge storage where technically supported, preserving source IDs/time and available evidence.
B03	Acknowledgement and deletion rules distinguish transport receipt from durable application acceptance.
B04	Retry metadata/file transfer within bounded capacity and expose pending, failed and dropped/lost counts.
B05	Reconnection re-authenticates, resumes/replays idempotently and labels delayed data.
B06	Commands use the separate IoT-owned retry/expiry contract.
B07	Recovery of event delivery does not authorise stale actuator replay.
B08	If a selected device cannot retain critical information, require a supporting edge design or an explicit TM-reviewed limitation/deviation.

Verification:

Criterion	Scenario / method	Expected result
AC01	Interrupt during receipt, upload and command handling, then restore link	Source/accepted/lost counts, checksums and original times reconcile without duplicate records/actions or stale actuator replay.
AC02	Restart while disconnected; reach full buffer	Agreed persistence, capacity and loss-reporting behaviour is evidenced.

Decisions still required: See section 5.4, OPEN-02, OPEN-03 and OPEN-04; numerical parameter “Commands and connectivity recovery (PAR-09)”.

SRS-CON-104 — Store-and-Forward

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-CONN-004; URG-T35-R05
Source modality	should; all source conditions remain applicable
Test execution	Not Run

Where connectivity is not assured, the proposed design adopts bounded persistent store-and-forward under the source should recommendation.

Rule	Connectivity / recovery rule
B01	Where continuous connectivity cannot be guaranteed, the proposed design adopts the source’s “should” recommendation through a bounded persistent edge/device queue.
B02	Store source event identity/time, deployment reference, status and required event metadata before sending.
B03	Retain relevant evidence subject to declared capacity.
B04	Size the queue from agreed event/evidence rate and outage duration, define acknowledgement-based removal, restart durability and an approved overflow priority/loss report.
B05	Protect queued data and upload securely after restoration, retaining original timestamps and verifying evidence integrity.
B06	If native buffering is inadequate, evaluate an edge companion.
B07	Document any residual nonconformance instead of treating the recommendation as irrelevant.

Verification:

Criterion	Scenario / method	Expected result
AC01	Known sequence during link loss; restart buffering component, then reconnect	All in-capacity records/evidence reconcile with original identity/time and integrity.
AC02	Controlled capacity exceedance	Loss counters and approved overflow priorities reflect actual loss without false completeness claims.

Decisions still required: See section 5.4, OPEN-02, OPEN-03 and OPEN-04; numerical parameter “Commands and connectivity recovery (PAR-09)”.

3.5.6 Solar and Power

Purpose: Size and verify field power, overnight operation and failure recovery.

Actors: Power/hardware engineers, site owners and commissioning personnel.

Submodules: Load budget; overnight operation; solar/battery sizing; power monitoring; interruption and recovery.

Boundaries: HW-PWR-001 retains its Confirmed overnight-operation statement. Its acceptance conditions remain unagreed; solar sizing remains Proposed.

HW-PWR-001 — Overnight operation

Attribute	Specification
Status	Confirmed
Provenance	Baseline Sources#SRC-02
Test execution	Not Run

The field unit must support operation overnight.

Verification:

Criterion	Scenario / method	Expected result
AC01	Selected field unit operates through agreed overnight test with approved duty cycle and initial battery condition	Required overnight operation is evidenced by retained power, health and time logs; duration and pass limits must be agreed before judging acceptance.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03; numerical parameter “Power and sustained operation (PAR-11)”.

HW-PWR-002 — Solar load and energy sizing

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-03
Test execution	Not Run

Provide a solar-based power system sized against the agreed total load and operating conditions.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect sizing against measured total load and agreed operating/environmental conditions	Energy balance and operating-test evidence substantiate the proposed solar sizing.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03; numerical parameter “Power and sustained operation (PAR-11)”.

SRS-PWR-101 — Power Architecture

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-PEM-001; URG-T34-R02
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Produce a measured load schedule and power architecture for every device/field unit, preserving the confirmed overnight requirement.

Rule	Power capability / operating condition
B01	Produce a per-device/field-unit load schedule and power diagram showing source, voltage/current, conversion/distribution, isolation/protection, storage/charging and monitoring points.
B02	Include controller/sensor idle and active consumption, startup/inrush, night illumination, communications/reconnect, evidence/live-video, cooling and permitted deterrent duty cycle.
B03	Calculate daily/overnight energy from measured duty cycles plus conversion losses and approved design margin.
B04	Size cable/protection and battery/solar/PoE capacity against the resulting envelope.
B05	Preserve HW-PWR-001 overnight operation.
B06	Record what remains operational and how faults are reported under low power.
B07	Physical action limits remain device/site-policy decisions.

Verification:

Criterion	Scenario / method	Expected result
AC01	Measure representative modes and peak demand; compare budget with selected source/storage ratings	Diagram, measurements and sizing assumptions reconcile.
AC02	Demonstrate agreed overnight workload	Required operation continues for the agreed test conditions; measured evidence is retained.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03; numerical parameter “Power and sustained operation (PAR-11)”.

SRS-PWR-102 — Power Availability

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-PEM-002; URG-T34-R03
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

The equipment schedule shall identify the actual power source, backup and distribution dependencies of each powered component.

Rule	Power capability / operating condition
B01	The installed-equipment schedule shall identify mains, battery, solar, PoE or other actual source for every powered component, plus backup source and distribution dependencies.
B02	For mains/PoE record supply point, capacity and approved isolation/protection.
B03	For battery record chemistry/capacity and charging interface.
B04	For solar record panel/controller/storage topology and exposure assumptions.
B05	Unpowered passive protection is marked as such.
B06	The existing solar-based proposal is assessed site by site.
B07	It does not make solar compulsory for every camera/controller.
B08	A missing or insufficient source blocks the affected installation until a reviewed alternative is provided.

Verification:

Criterion	Scenario / method	Expected result
AC01	Reconcile every BOM item/accessory to power diagram and capacity; controlled shared-supply disconnection	Declared source dependencies and fault indications match the installed equipment.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03; numerical parameter “Power and sustained operation (PAR-11)”.

SRS-PWR-103 — Battery Operation

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-PEM-003; URG-T34-R04
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Where battery operation is proposed, calculate usable energy and define endurance, charging, replacement and maintenance behaviour.

Rule	Power capability / operating condition
B01	Where battery operation is proposed, calculate usable energy from nominal capacity, approved depth of discharge, conversion efficiency, temperature/age derating and reserve assumptions.
B02	Estimate duration using the measured operating workload.
B03	Specify replacement/recharge trigger, expected charge time, access/tooling, safe handling/disposal and maintenance records using manufacturer requirements.
B04	State whether operation continues during battery change/charging and what data/action is unavailable if it cannot.
B05	Monitor available state/voltage indicators and distinguish an estimate from guaranteed autonomy.
B06	Include overnight demand and the chosen no-sun/outage case where relevant.
B07	No chemistry, capacity or duration is selected here.

Verification:

Criterion	Scenario / method	Expected result
AC01	Discharge/recharge or validated representative endurance test under agreed workload/environment	Achieved duration and trigger behaviour reconcile to declared assumptions and measured workload.
AC02	Rehearse battery replacement	Data continuity/unavailability and configuration retention match the declared operating method.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03; numerical parameter “Power and sustained operation (PAR-11)”.

SRS-PWR-104 — Power Failure

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-PEM-004; URG-T34-R05
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Where technically feasible, receive explicit power-fault telemetry through the IoT service and distinguish it from inferred contact loss.

Rule	Power capability / operating condition
B01	Where technically feasible, receive explicit mains/charger/battery/voltage fault telemetry or a supported last-gasp signal for critical devices through the IoT service.
B02	Identify device, fault type, original and receipt time and last available energy/health readings.
B03	If loss of power removes all communications, use contact loss as an indirect symptom labelled cause unknown.
B04	Do not report a confirmed power failure from silence alone.
B05	Retain local fault information for forwarding after restoration where supported, and verify restart configuration/data recovery.
B06	Critical-device designation and safe hardware behavior during brownout/power return require the approved equipment policy.

Verification:

Criterion	Scenario / method	Expected result
AC01	Remove primary supply, simulate low voltage/complete loss, then restore	Direct versus inferred status, delayed fault delivery and preserved records match available evidence; no unintended actuator activation occurs.

Decisions still required: See section 5.4, OPEN-03 and OPEN-04; numerical parameters “Commands and connectivity recovery (PAR-09)” and “Power and sustained operation (PAR-11)”.

3.5.7 Enclosure and Mounting

Purpose: Specify environmental protection, mounting, access and installation drawings.

Actors: Qualified installation personnel, site engineering and security reviewers.

Submodules: Weather and thermal protection; mounting; physical security; cable entry; service access; installation drawings.

Boundaries: Site engineering/manufacturer limits govern installation; no enclosure rating or installation permission is invented.

HW-ENC-001 — Environmental enclosure and mounting

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-03
Test execution	Not Run

Provide enclosure, thermal management, cable entry, mounting, and service access appropriate to the agreed site conditions.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect enclosure, thermal arrangement, cable entry, mounting and service access	Selected arrangement meets agreed site/environment criteria; any observed non-conformance is retained and does not establish a pass.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03.

SRS-ENC-101 — Physical Installation

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-PHY-003; URG-T32-R04
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Provide installation instructions, diagrams and checks against approved site engineering and manufacturer requirements.

Rule	Installation / environmental rule
B01	Each installation work instruction shall state the mounting interface/load and fastening method.
B02	The work instruction shall state cable types/routing/strain relief/separation and labels.
B03	The work instruction shall state enclosure, glands and thermal/service clearances.
B04	The work instruction shall state power source, isolation and protection.
B05	The work instruction shall state grounding/bonding and surge/lightning assessment.
B06	The work instruction shall state weather/dust/corrosion protection.
B07	The work instruction shall state lock/tamper controls.
B08	The work instruction shall state safe maintenance access.
B09	Supply connection diagrams, BOM revisions and pre-energisation checks, using manufacturer instructions and applicable approved site engineering standards.
B10	Identify any excavation, pole/structure work, traffic/access control or proximity to live infrastructure requiring specialist permission.
B11	Failed fit, wiring, protection or access checks prevent commissioning until corrected or formally dispositioned.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect assembled/installed unit against approved drawings and signed checklist	Cable, ground and power checks, photographs, component identities and non-conformances are recorded.
AC02	Qualified-person inspection of safety-critical details	Required installation checks have competent verification evidence before commissioning disposition.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03.

SRS-ENC-102 — Outdoor Environment

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-PHY-004; URG-T32-R05
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Assess each component and complete assembly against the intended environment and supported operating/storage envelope.

Rule	Installation / environmental rule
B01	For each component and assembled unit, state intended site exposure and manufacturer-supported operating/storage limits, then assess the whole assembly against temperature, humidity/condensation, rainfall/water exposure, dust, vibration, sunlight/UV/solar heating, corrosion and physical impact where applicable.
B02	Include enclosure heat rise, cable entries and ventilation effects.
B03	A rating for one component does not certify the complete assembly.
B04	Provide environmental mitigations and inspection/maintenance conditions, and record any derating.
B05	Outside-envelope operation is a reported limitation/fault requiring the approved operational response.
B06	No invented ingress rating, temperature range or impact class is accepted by this draft.

Verification:

Criterion	Scenario / method	Expected result
AC01	Compare survey exposure with datasheets/engineering evidence; inspect protective details	Whole-assembly environmental assumptions and mitigations are evidenced, including limitations.
AC02	Test representative agreed environment or supply accepted qualification evidence	Functional before/after performance and limitations are retained.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03.

SRS-ENC-103 — Physical Security

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-PHY-005; URG-T32-R06
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Apply the selected site’s physical-security assessment to equipment access, mounting, identification and supported tamper reporting.

Rule	Installation / environmental rule
B01	Use the selected site’s physical-security assessment to specify lockable/serviceable enclosures, controlled key/access custody, protected cables and connectors, tamper-resistant mounting and visible unique asset identification.
B02	Restrict exposed maintenance ports and credentials.
B03	Where selected hardware supports tamper/open/removal sensing, report the observation with device/time and route it under a configured operational rule.
B04	Absence of that hardware is declared, not simulated.
B05	Log authorised maintenance/removal/relocation separately from suspected tamper.
B06	Position equipment to reduce theft/damage exposure while preserving sensing coverage and safe maintenance access.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect access/fastening/cables; agreed non-destructive unauthorised access/removal scenarios	Supported tamper reports and authorised maintenance records remain distinct; site assessment and exception decisions are retained.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03.

SRS-ENC-104 — Illustration

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-INST-002; URG-T43-R03
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Where applicable, issue controlled site drawings sufficient to reproduce and inspect the installation.

Rule	Installation / environmental rule
B01	Where site-specific drawings apply, issue a revision-controlled location/layout plan, mounting elevation/detail, sensor orientation and coverage, cable/communications routing, power/isolation/grounding diagram and enclosure/component arrangement.
B02	Mark existing fibre/infrastructure, access/clearances, known hazards and drawing reference coordinates.
B03	Cross-reference device/BOM IDs and installation instructions.
B04	Label conceptual drawings separately from approved-for-installation and as-built versions.
B05	If a drawing type is unnecessary for a simple configuration, record why. Retain enough detail to reproduce and inspect the installation.

Verification:

Criterion	Scenario / method	Expected result
AC01	Compare drawings, survey, BOM and installation; redline differences	Revision/status, labelled connections, coverage and access are correct or explicitly reconciled in as-built updates; drawings/photos are retained.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03.

3.5.8 Hardware Assembly

Purpose: Build identified units with traceable components, wiring and checks.

Actors: Assembly personnel, hardware engineers and commissioning reviewers.

Submodules: Bill of materials; wiring; unit identity; assembly instructions; inspection and functional checks.

Boundaries: Unresolved mandatory failures prevent proposed commissioning release.

HW-ASM-001 — Assembly and wiring records

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-03
Test execution	Not Run

Document the approved component list, wiring, connections, assembly steps, and unit identification.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect approved component/wiring/assembly/identity record	Each selected component traces to the actual assembled unit.

Decisions still required: See section 5.4, OPEN-03 and OPEN-16.

HW-ASM-002 — Unit inspection and functional checks

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-03
Test execution	Not Run

Check each assembled unit against the approved assembly and functional checklist.

Verification:

Criterion	Scenario / method	Expected result
AC01	Execute approved assembly/functional checklist on identified unit	Measured results and deviations are retained against the unit identity.

Decisions still required: See section 5.4, OPEN-03 and OPEN-16.

SRS-ASM-001 — As-built unit record

Attribute	Specification
Status	Proposed
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.
Test execution	Not Run

Each assembled unit shall have a traceable as-built component/wiring/configuration record, functional check result and recorded deviations from the reviewed design.

Rule	Assembly / release rule
B01	Unresolved failed checks shall block the proposed commissioning release.

Verification:

Criterion	Scenario / method	Expected result
AC01	Reconcile selected unit identities/components with as-built record	Physical unit and recorded configuration are traceable.
AC02	Record failed mandatory check	Proposed commissioning release remains pending.

Decisions still required: See section 5.4, OPEN-03 and OPEN-16.

3.5.9 Testing and Commissioning

Purpose: Record integration, endurance, failure tests and commissioning disposition.

Actors: Qualified installation/test personnel, responsible maintainers and acceptance authority.

Submodules: Installation method; site checks; integration and sustained-operation tests; as-built evidence; commissioning decision.

Boundaries: Installation alone is not acceptance; actual-device/site checks and approved test conditions remain required.

HW-TST-001 — System and interruption tests

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-03
Test execution	Not Run

Record functional, integration, sustained-operation, and power-interruption test results against agreed criteria.

Verification:

Criterion	Scenario / method	Expected result
AC01	Execute agreed functional, integration, sustained-operation and power-interruption cases	Actual results, conditions and deviations are recorded against agreed criteria.

Decisions still required: See section 5.4, OPEN-02, OPEN-03, OPEN-16 and Q10; numerical parameter “Power and sustained operation (PAR-11)”.

HW-TST-002 — Site commissioning evidence

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-03
Test execution	Not Run

Record installation checks, field validation results, and acceptance of each commissioned unit.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect installation and field-validation evidence for identified site/unit	Explicit commissioning decision references the evidence.

Decisions still required: See section 5.4, OPEN-02, OPEN-03, OPEN-16 and Q10; numerical parameter “Power and sustained operation (PAR-11)”.

SRS-COM-001 — Handover readiness

Attribute	Specification
Status	Proposed
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.
Test execution	Not Run

Commissioning shall retain the site/unit evidence and an explicit acceptance decision; installation alone is not acceptance.

Rule	Commissioning gate / record
B01	Commissioning shall record site/unit identity, installed configuration, functional and integration checks, limitations, defects, responsible maintainer and explicit acceptance decision.
B02	Installation alone shall not establish acceptance.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect complete and incomplete commissioning packs	Required identity/configuration/check/maintainer/disposition information is present; missing mandatory evidence or unresolved blocking defects prevents a pass.

Decisions still required: See section 5.4, OPEN-02, OPEN-03, OPEN-16 and Q10; numerical parameter “Power and sustained operation (PAR-11)”.

SRS-COM-101 — Methodology / Working Instruction

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-INST-001; URG-T43-R02
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Deliver a sequenced installation and commissioning instruction with defined responsibilities, evidence and stop/correction gates.

Rule	Commissioning gate / record
B01	Deliver a sequenced work instruction with gates: survey and infrastructure assessment.
B02	Include a gate for approved placement/power/connectivity/BOM.
B03	Include a gate for inspected assembly and installation.
B04	Include a gate for authorised identity/configuration.
B05	Include a gate for sensor calibration/validation.
B06	Include a gate for IoT/platform integration.
B07	Include a gate for functional tests.
B08	Include a gate for agreed performance and failure/recovery tests.
B09	Include a gate for operational handover.
B10	Each step identifies inputs, responsible competence, tools, expected result, evidence and stop/correction condition.
B11	Before physical work check permits, safe access, structure/electrical constraints and allowed test actions.
B12	Record deviations.
B13	Failed safety, identity, connectivity, calibration or essential functional checks block commissioning of the affected unit.
B14	Handover includes operating limitations, support contacts, maintenance/backup procedures and accepted outstanding issues.

Verification:

Criterion	Scenario / method	Expected result
AC01	Execute work instruction on actual selected unit/site	Test/configuration records and signed gate decisions are retained; defects reconcile to correction/retest or an explicitly approved limitation.

Decisions still required: See section 5.4, OPEN-02, OPEN-03, OPEN-16 and Q10; numerical parameter “Power and sustained operation (PAR-11)”.

3.5.10 Passive Protection

Purpose: Assess, prototype, record and evaluate passive protection.

Actors: Engineering reviewers, installation and inspection personnel.

Submodules: Candidate protection design; ground-level prototype; installation records; inspection; bypass/failure observations; effectiveness evaluation.

Boundaries: Additional engineering proposal only: no approved protection design or installation authorisation. Candidate dimensions/materials, cable loads and acceptance require engineering review.

FE-PAS-001 — Protection design assessment

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04
Test execution	Not Run

Assess candidate guard design, supports, access routes and installation constraints.

Verification:

Criterion	Scenario / method	Expected result
AC01	Review candidate design against documented loads, supports, access and installation limits	Each unresolved engineering item has a retained disposition.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03.

FE-PAS-002 — Ground-level protection prototype

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04
Test execution	Not Run

Build and inspect a ground-level prototype before any field installation.

Verification:

Criterion	Scenario / method	Expected result
AC01	Ground-level prototype inspection before installation approval	Agreed grip, rotation, bypass, jamming, environment and trapping-hazard checks are recorded.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03.

FE-PAS-003 — Installed protection record

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04
Test execution	Not Run

Record protection type, version and installation detail against the asset or location.

Verification:

Criterion	Scenario / method	Expected result
AC01	Retrieve installed protection record and compare with physical unit	Type/version, location, mounting configuration and installation evidence match.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03.

FE-PAS-004 — Inspection and failure history

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04
Test execution	Not Run

Record guard condition, maintenance, and observed bypass or failure.

Verification:

Criterion	Scenario / method	Expected result
AC01	Record inspection and observed bypass/failure	Condition, actor, date, evidence and servicing/removal disposition remain traceable.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03.

FE-PAS-005 — Protection effectiveness assessment

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04
Test execution	Not Run

Compare observations, access attempts and verified outcomes against the installed protection.

Verification:

Criterion	Scenario / method	Expected result
AC01	Compare reviewed observations/verified outcomes over agreed period with selected baseline	Coverage and confounders accompany the effectiveness assessment.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03.

SRS-PAS-001 — Protection installation gate

Attribute	Specification
Status	Proposed
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.
Test execution	Not Run

A proposed passive protection design remains subject to engineering approval and a reviewed ground-level prototype before field installation.

Rule	Protection capability / condition
B01	A proposed passive protection design shall remain subject to engineering approval of allowable loads, mounting, environmental conditions, access and bypass/trapping hazards.
B02	A ground-level prototype and documented review shall precede any field installation.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect engineering review and controlled prototype evidence against agreed hazards/loads	Release evidence precedes field installation.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03.

SRS-PAS-002 — Protection evaluation record

Attribute	Specification
Status	Proposed
Provenance	BA refinement of this module and recorded drafting direction; not a new TM source obligation.
Test execution	Not Run

Retain an evaluation record linking the protection design, installation, inspection, failure observations and outcome.

Rule	Protection capability / condition
B01	Each evaluated protection installation shall identify design version, monitored location, installed configuration, inspection history, observed bypass/failure and intervention outcome.
B02	Report comparison period and limitations.
B03	Do not infer causal effectiveness from deployment alone.

Verification:

Criterion	Scenario / method	Expected result
AC01	Reconcile test installation, inspection and observed failure	All link to the same design/location; evaluation identifies period, baseline and limitations.

Decisions still required: See section 5.4, OPEN-02 and OPEN-03.

3.5.11 Delivery Documentation and Handover

Purpose: Specify delivery evidence, lifecycle cost, dependencies and handover.

Actors: Delivery and engineering leads, reviewers, maintainers and acceptance authority.

Submodules: Delivery increments; dependencies and risk; deployment completion; lifecycle costs; manuals; support ownership and handover evidence.

Boundaries: Controlled documents, workbooks, registers and test records can satisfy deliverables when they carry the required reviewable evidence; new product screens are not required. Dates and ownership follow the agreed delivery plan.

Deliverable	Minimum specified contents	Source relationship and proposed stage
Architecture and interface pack	Logical/physical components as selected, data/control/media flows, trust boundaries, storage, AI processing location, device/platform responsibilities, interface version/error/security contract, deployment dependencies and technology rationale.	REQ-ARCH/INT/APINT and related narrative; M1 draft, updated with each equipment/interface change.
Data-source and model pack	Source inventory/permission, schema/quality/lineage, missing-data eligibility, label/target definitions, dataset/model versions, evaluation/baseline, limitations, monitoring/retraining and approval evidence.	Data and AI/ML responses; M1 design, M3 initial model evidence, later updates.
Site survey and deployment design	Site identity/constraints, monitored risks, geometry/coverage, access, safety/security/environment, connectivity/power, equipment necessity/alternatives and installation arrangement.	REQ-SITE-001/002 and field-deployment obligations; before the relevant physical installation.
Bill of materials and unit/build record	Selected item/model/version, quantity per agreed site/unit, capability/interface, supplier/support assumptions, configuration and assembly/qualification record.	Hardware/installation/lifecycle obligations; selected-design stage. No purchase or quantity is authorised by this table.
Installation as-built and commissioning record	Actual device/site/deployment identities, position/orientation, power/connectivity, configuration/calibration, assembly/install checks, deviations, test outcomes, photographs/evidence where appropriate, handover references.	REQ-INST family and HW-TST records; before claiming the installed unit/site commissioned.
Verification and acceptance pack	Requirement/case mapping, test configuration/data, expected/actual results, evidence, model metrics, performance/security/recovery findings and authorised dispositions.	REQ-TEST/VER and N27/N28; per milestone, including system-wide end-to-end evidence.
Lifecycle cost and dependency assessment	Selected-design acquisition, deployment, recurring infrastructure/connectivity/API, energy/battery, maintenance/calibration, replacement, licensing, support and retirement assumptions; quantities/unit costs/currency/time horizon, source quotes and sensitivity.	Lifecycle-cost/hardware-dependency responses; draft structure at design, actual costs only after verified inputs. Unknown amounts remain unknown.
Operations and support pack	Monitoring/triage, device/site health, backup/restore, credential/change/rollback procedures, sensor/power/equipment maintenance, escalation/support boundaries, known limitations and recovery/continuity behavior.	REQ-O&M-001/002 and cross-cutting requirements; initial procedures before operation, updated for pilot/handover.
Delivery and handover pack	Dependency-aware schedule, stage scope/evidence/entry-exit criteria, risk register, training material/attendance, asset/configuration inventory and applicable source/licensing/document transfer.	Schedule, maintainability, portability and workbook deliverables; dates/owners governed by agreed delivery plan, not invented here.

Source-listed security and load assessment evidence

The Project Roadmap M5 deliverables explicitly include performance, load, stress and VAPT reports with remediation/retest evidence.

Assessment scope / condition
Retain these as proposed M5 acceptance deliverables, not silently replace them with ordinary permission/API tests.
Before scheduling assessment, agree the authorised environment/targets, scope, method, assessor/independence requirements if any, permitted test activity, data handling, disruption limits, severity/disposition rules and report audience.
No external assessor, paid engagement, security certification or test authorisation is implied by this SRS.
Keep vulnerability/penetration assessment findings, remediation and retest evidence distinct from routine functional checks; use an approved test plan and explicit scope.

Decisions still required: See section 5.4, OPEN-10, OPEN-16 and Q10; numerical parameter “Monitored capacity and dashboard response (PAR-03)”.

SRS-DEL-101 — Lifecycle Cost

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-COST-001; URG-T49-R02
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Provide a lifecycle cost workbook with traceable quantities, cost assumptions and uncertainty.

Rule	Delivery / governance rule
B01	Provide a lifecycle cost workbook with item/unit/quantity, one-time versus recurring basis, frequency, assumed useful life, evidence/quote date, currency/tax treatment and uncertainty.
B02	Include design/development/integration.
B03	Include lifecycle costs for site survey/permits/civil/mount/cabling work.
B04	Include lifecycle costs for sensors/controller/camera/deterrent/protection/power/enclosures and spares.
B05	Include lifecycle costs for hosting/storage/backups/egress.
B06	Include lifecycle costs for connectivity.
B07	Include lifecycle costs for software/maps/models/data/LLM licensing.
B08	Include lifecycle costs for operations/monitoring/support/training.
B09	Include lifecycle costs for cleaning/calibration/battery/part replacement and travel.
B10	Include lifecycle costs for upgrades/revalidation/security.
B11	Include lifecycle costs for scaling.
B12	Include lifecycle costs for decommissioning/data migration/disposal.
B13	Sum initial deployment plus recurring operation and scheduled replacements over the agreed evaluation horizon, distinguishing reusable central from per-site costs.
B14	No vendor prices or budget are invented.

Verification:

Criterion	Scenario / method	Expected result
AC01	Review cost categories against BOM, services, maintenance and deployment; recompute totals and sensitivity	Sourced quotes or labelled estimates support calculations; double counting and missing recurring costs are flagged.

Decisions still required: See section 5.4, OPEN-16.

SRS-DEL-102 — Delivery Milestones

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-DEPL-001; URG-T50-R02
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Use proposed technical milestone gates with explicit scope, dependencies, evidence and acceptance disposition.

Rule	Delivery / governance rule
B01	Propose technical gates: M1 full-solution SRS/traceability, architecture/interfaces, site/design assumptions and verification plan.
B02	Propose M2 gate: working platform foundations, approved prototype equipment procurement/assembly/configuration and actual-device controlled animal/rodent flow plus basic live view.
B03	Propose M3 gate: surveyed/installed field integration, configurable workflows/cases, initial historical and predictive risk, reports and integrated tests.
B04	Propose M4 gate: second agreed capability, preventive/intervention functions and proposed read-only assistant.
B05	Propose M4–M5 gate: basic mobilisation.
B06	Propose M5–M7 gate: remaining capability/MVP completion, readiness, POC/Pilot validation, maintenance and handover as agreed.
B07	For every gate include design/development, procurement where applicable, integration, installation, configuration, test, POC/Pilot and deployment outputs rather than a software-only demo.
B08	Explicitly map unresolved URG initial-phase allocations/deviations.
B09	No silent deferral.
B10	Reconcile the live workbook conflicts in the linked Delivery Allocation section: source milestone dates differ across tabs, and older Case/Preventive deferrals conflict with the latest user-confirmed M3 cases/M4 preventive direction.
B11	This response retains that current functional direction without selecting an authoritative date.

Verification:

Criterion	Scenario / method	Expected result
AC01	Review milestone-to-requirement/deliverable mapping, entry/exit criteria and prerequisites	Each gate records actual delivery, defects, deviations and authorised sign-off separately from planned scope.

Decisions still required: See section 5.4, OPEN-01, OPEN-09, OPEN-11, OPEN-16 and Q09.

SRS-DEL-103 — Deployment Completion

Attribute	Specification
Status	Proposed conditional response
TM source / URG locator	REQ-DEPL-002; URG-T50-R03
Source modality	shall/may; all source conditions remain applicable
Test execution	Not Run

Complete the agreed deployment scope against the baselined programme schedule and retain evidence of actual completion.

Rule	Delivery / governance rule
B01	Complete the agreed deployment scope within the approved programme schedule once baselined.
B02	Track each site/component activity with prerequisite, accountable owner, planned start/finish, actual status/evidence and impact on the next technical gate.
B03	Define completion as installed/configured required equipment and services, accepted tests/as-built/handover, plus explicit accepted outstanding items.
B04	Procurement receipt or dashboard demonstration alone is not deployment completion.
B05	Forecast slippage from real dependencies and obtain the appropriate scope/date decision rather than silently reduce requirements.
B06	This SRS supplies stable dependencies.
B07	Volatile receipt estimates remain in working delivery tracking.

Verification:

Criterion	Scenario / method	Expected result
AC01	Reconcile approved schedule and deployment inventory with commissioning, tests and handover	Variances and change approvals are recorded; forecast dates remain distinct from completed dates.

Decisions still required: See section 5.4, OPEN-16.

SRS-DEL-104 — Schedule Dependencies

Attribute	Specification
Status	Proposed response
TM source / URG locator	REQ-DEPL-003; URG-T50-R04
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Maintain an evidence-based dependency register across site, data, equipment, services, approvals and acceptance inputs.

Rule	Delivery / governance rule
B01	Maintain a dependency register for site access/readiness/permits and engineering approval.
B02	Track dependencies for TM asset/incident data/sample/quality/rights.
B03	Track dependencies for field connectivity and power.
B04	Track dependencies for hardware procurement, adapter compatibility, lead times and spares.
B05	Track dependencies for third-party hosting/model/map/services/contracts.
B06	Track dependencies for production/non-production integration access and credentials.
B07	Track dependencies for security/privacy/safe-action approvals.
B08	Track dependencies for review/acceptance authority.
B09	Each dependency states affected requirement/milestone, needed input/decision, owner, required-by gate, evidence/status, fallback and critical-path impact.
B10	A fallback that alters customer scope remains a proposed deviation requiring decision, including replacing live TM integration with offline files.
B11	Do not publish transient data-receipt estimates as SRS commitments.

Verification:

Criterion	Scenario / method	Expected result
AC01	Review dependencies against every milestone and installation/model/interface prerequisite	Fulfilled status has actual receipt/access/approval evidence; unresolved dependencies have assessed schedule impact.

Decisions still required: See section 5.4, OPEN-01, OPEN-02, OPEN-07, OPEN-10, OPEN-16 and Q14.

SRS-DEL-105 — Schedule Risk

Attribute	Specification
Status	Proposed response
TM source / URG locator	REQ-DEPL-004; URG-T50-R05
Source modality	shall; all source conditions remain applicable
Test execution	Not Run

Maintain material schedule risks, mitigation evidence, contingency decisions and impact on approved delivery dates.

Rule	Delivery / governance rule
B01	Record material schedule risks with cause, affected deliverable, probability/impact assessment, trigger, mitigation, contingency owner and decision deadline.
B02	Include late/unsuitable TM data, unclear acceptance targets, site/permit/power/bearer readiness, unavailable hardware/long lead time, adapter/live-video incompatibility, deficient sensor/model performance, field-safe action approvals, policy/hosting approval, integration access, failed endurance/recovery/security tests and reviewer availability.
B03	Mitigate through early samples/site surveys, controlled actual-device tests, adapter contracts, alternative qualified components, staged independent work and explicit review gates.
B04	Contingencies must not silently substitute historical counts for prediction, simulated devices for required actual-device evidence, or waive customer obligations.

Verification:

Criterion	Scenario / method	Expected result
AC01	Review risk triggers against current gate evidence	Completed mitigation, residual risk/contingency decisions, approved-date impact and required retest are recorded.

Decisions still required: See section 5.4, OPEN-16 and Q10.

3.6 AI and Machine Learning

This section defines the logical obligations for predictive and detection models, their evidence and controlled operational use. Model choice, runtime placement and numerical acceptance criteria remain subject to the decisions in section 5.4.

3.6.1 Predictive Model Lifecycle

Purpose and actors: AI/data practitioners prepare and evaluate model evidence; authorised reviewers and release operators approve, deploy and monitor versions; Operators review their operational results.

Boundaries: Historical indicators, observed detections and future-risk predictions remain distinct. Dataset availability, approved processing and verified outcomes constrain model use; neither a model output nor a lifecycle update authorises a physical action.

Submodules: Dataset lineage; target/horizon; reproducible training; held-out evaluation; baseline comparison; registry; deployment; drift; rollback and feedback.

MD-PRED-001 — Traceable analytical datasets

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Prepare traceable analytical datasets combining incident history, asset and location context, and available field observations.

Verification:

Criterion	Scenario / method	Expected result
AC01	Recreate a dataset snapshot and reconcile source IDs, periods, quality checks, joins and exclusions to the input batches.	Snapshot sources, periods, quality decisions, joins and exclusions reconcile to the input batches.

Decisions still required: See section 5.4: OPEN-07 and OPEN-08.

MD-PRED-002 — Prediction objective and inputs

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Define model input variables and the incident or risk outcome to estimate for a location and period.

Verification:

Criterion	Scenario / method	Expected result
AC01	Review the target, time horizon, geographic unit and permitted inputs; reject a scoring configuration missing required agreed definitions.	Target, horizon, geographic unit and permitted inputs are agreed; incomplete configurations cannot score.

Decisions still required: See section 5.4: OPEN-08.

MD-PRED-003 — Reproducible training

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Train candidate models with reproducible, recorded configurations.

Verification:

Criterion	Scenario / method	Expected result
AC01	Repeat a recorded training run with the same dataset and configuration; reconcile model artefact/version and documented reproducibility tolerance.	The repeated run reconciles to its recorded artefact/version within the documented tolerance.

Decisions still required: See section 5.4: OPEN-08; Model performance and improvement (PAR-06) parameters.

MD-PRED-004 — Held-out evaluation

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Evaluate held-out results and review errors by cause, location and time.

Verification:

Criterion	Scenario / method	Expected result
AC01	Evaluate on held-out, leakage-checked data and compare with the agreed baseline by time/location/cause; record metrics and error cases.	Held-out metrics and cause/location/time errors are recorded against the baseline without leakage.

Decisions still required: See section 5.4: OPEN-08; Model performance and improvement (PAR-06) parameters.

MD-PRED-005 — Model version registry

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Register model versions with input definitions, training data references, evaluation results and approval status.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect a registered version for dataset, feature/schema, runtime, training/evaluation and approval references; reject deployment without required evidence.	The registered package has complete evidence; deployment is rejected when required evidence is absent.

Decisions still required: See section 5.4: OPEN-08 and OPEN-16.

MD-PRED-006 — Approved deployment and scoring

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Deploy an approved model, score on agreed schedules or triggers, and retain the model version with each result.

Verification:

Criterion	Scenario / method	Expected result
AC01	Deploy an approved version, score a known input and exercise failure/rollback; verify each result identifies the version and does not silently substitute historical counts.	Approved scoring, failure and rollback retain producing versions; historical counts do not replace predictions.

Decisions still required: See section 5.4: OPEN-08.

MD-PRED-007 — Mapped prediction results

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Link predictive scores, explanations and assessment times to assets or areas for map display and review.

Verification:

Criterion	Scenario / method	Expected result
AC01	Select a mapped prediction and reconcile location, horizon, score, explanation, confidence/limitations and source/model version.	The mapped result reconciles to its location, horizon, score, explanation, limitations and source/model version.

Decisions still required: See section 5.4: OPEN-08.

MD-PRED-008 — Performance review and retraining

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Review model performance, data changes and verified outcomes to guide controlled retraining or replacement.

Verification:

Criterion	Scenario / method	Expected result
AC01	Introduce a reviewed drift/degradation condition; verify monitoring, review decision and controlled retraining/replacement without unapproved automatic promotion.	Drift/degradation initiates a recorded review and controlled lifecycle decision; no unapproved promotion occurs.

Decisions still required: See section 5.4: OPEN-08; Model degradation threshold (PAR-07) parameters.

SRS-PRD-101 — Risk Factors

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-051; URG-T19-R03.
Source modality	shall; all source conditions remain applicable.

Maintain reviewed input factors and their lineage for each prediction configuration.

Input factors and lineage

Clause	Specification
B01	For each prediction configuration list relevant available factors and their source/cutoff, transformation, units, quality/eligibility and version.
B02	Review historical fibre faults, location, infrastructure characteristics, construction activity, environmental conditions, sensor observations, previous theft/vandalism and animal/rodent activity.
B03	These are potential factors, not mandatory promises of eight available feeds.
B04	Include only inputs useful and legitimately available for the target; record why candidates are unavailable or excluded.

Input eligibility

Clause	Specification
B05	Apply a documented missing-value policy appropriate to the approved method, record any imputation and do not automatically equate missing history/telemetry with no incidents/activity.
B06	Reject incompatible input schemas or withhold an ineligible prediction with a reason.
B07	Use deployment/location history for mobile device observations and distinguish predictor collection time from outcome time.
B08	Factor changes require a new reviewed input/model version.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect a factor lineage matrix covering every listed candidate family.	Every candidate family has lineage or an exclusion/unavailability reason.
AC02	Reconstruct an output from accepted factor values; remove a required factor, change schema, supply future-dated data and relocate a device to test gating/time-location treatment.	Accepted inputs reconstruct the output; required-factor, schema, future-data and relocation cases follow eligibility/time/location controls.
AC03	Verify exclusions and imputation are visible in evaluation evidence.	Exclusions and imputation remain visible in evaluation evidence.

Decisions still required: See section 5.4: OPEN-07 and OPEN-08.

SRS-PRD-102 — Prediction Explainability

Attribute	Specification
Status	Proposed conditional response
TM source	REQ-FUNC-054; URG-T19-R06.
Source modality	should; all source conditions remain applicable.

Where an AI/ML model produces risk results, it should explain the major contributing factors using a suitable method.

Explanation output

Clause	Specification
B01	Where an AI/ML model produces a risk result, it should provide the major contributing factors using an explanation method suitable for that model.
B02	Present factor name, actual relevant input or reference, contribution/direction where supported, assessment period and model version, plus limitations.
B03	Distinguish model association from causation.
B04	A generic generated narrative unsupported by the assessment inputs is not an explanation of that prediction.

Unavailable and historical explanations

Clause	Specification
B05	If an explanation is unavailable, say so and retain the prediction with its review status/limitations under the approved release policy; do not invent a reason.
B06	For a rules-based historical score, show applied factors/weights separately without claiming an AI/ML explanation.
B07	Authorised users may open supporting records; any restricted records remain protected.

Verification:

Criterion	Scenario / method	Expected result
AC01	For an approved model compare displayed leading factors and values with its stored input/explanation output.	Displayed factors and values match the stored inputs and explanation output.
AC02	Perturb a reviewed factor and inspect expected interpretation.	The observed effect is assessed against the reviewed model-specific expected interpretation; no universal direction or magnitude is assumed.
AC03	Test missing explanation, restricted evidence and historical-rule output; verify no causal claim or invented reason.	Missing explanations are declared; restricted records remain protected and historical rules do not become invented AI or causal explanations.

Decisions still required: See section 5.4: OPEN-08.

SRS-PRD-103 — AI/ML Use Case

Attribute	Specification
Status	Proposed response
TM source	REQ-AIML-001; URG-T51-R02.
Source modality	shall; all source conditions remain applicable.

Maintain a specification and applicability decision for each supported AI/ML use case.

Use-case specification

Clause	Specification
B01	Maintain a use-case specification for each supported capability, identifying its operational purpose, permitted inputs, output, user, deployment location, decision boundary and evidence of effectiveness.
B02	The catalogue shall explicitly assess fibre fault prediction, risk assessment, threat/event detection, threat classification, anomaly detection, hotspot identification, fault likelihood estimation, preventive action recommendation and any other proposed AI/ML capability.
B03	Record whether each use case applies and why; a separate learned model is not required for every use case.

Initial delivery boundaries

Clause	Specification
B04	For the initial delivery, distinguish observed threat detection/classification, retrospective hotspot indicators and future-risk prediction.
B05	M3 shall present historical risk separately from an initial prediction for a defined future period and location/segment; historical counts do not demonstrate prediction.
B06	M4 preventive recommendations initially use configured rules, while the proposed conversational assistant retrieves records and generates summaries.
B07	Neither is represented as an approved autonomous agent.
B08	Any anomaly or additional fault-estimation model needs a defined objective/data/evaluation before being described as supported.
B09	Predictions and recommendations feed the configured platform workflow; automation is a separately authorised execution capability.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect the catalogue against all nine source entries.	All nine source entries have a supported, conditional or unsupported disposition.
AC02	Demonstrate a detection, a historical indicator and a future-risk result with distinguishable labels/time meaning.	Detection, retrospective indicators and future-risk results have distinct labels and time meaning.
AC03	Trace any recommendation to its rule/model and show that displaying it alone issues no command.	Recommendations trace to their rule/model; display alone issues no command.
AC04	Unsupported/conditional use cases must have an explicit disposition; no historical-only demonstration passes M3 prediction.	Conditional/unsupported entries are explicit; historical-only evidence cannot pass M3 prediction.

Decisions still required: See section 5.4: OPEN-08, OPEN-09 and OPEN-11.

SRS-PRD-104 — Model Selection

Attribute	Specification
Status	Proposed response
TM source	REQ-AIML-002; URG-T51-R03.
Source modality	shall; all source conditions remain applicable.

Select each model through a recorded comparison of applicable candidates and operational constraints.

Selection evidence

Clause	Specification
B01	Prepare a short selection record per use case comparing viable candidates, including a non-learned reference where appropriate.
B02	Address each applicable source factor: training-data nature/availability, prediction/detection objective, accuracy, false-positive and false-negative consequences, explainability, compute demand, inference latency, scalability, maintainability and field/edge/central suitability.
B03	Record an explicit reason where a factor does not apply.

Selection boundaries

Clause	Specification
B04	Use measured evaluation and target-hardware trials to select a candidate rather than prescribing an algorithm in this SRS.
B05	Detection placement remains a device/edge/server decision after device selection; the IoT boundary stays intact.
B06	Predictive-model selection is separate from detection and from the user-proposed LLM API for M4 chat/summaries.
B07	The selected package must expose the inputs and outputs required by the common contract above; an incompatible or unevaluated candidate is not promoted solely because a demonstration runs.

Verification:

Criterion	Scenario / method	Expected result
AC01	Review one completed selection record per applicable use case for all ten factors and recorded alternatives.	Each applicable use case covers all ten factors and recorded alternatives.
AC02	Reproduce a candidate/reference comparison on the declared dataset and inspect resource/latency observations on the intended runtime.	The declared candidate/reference comparison is reproducible and intended-runtime resource/latency observations are retained.
AC03	Verify selection does not conflate classifier accuracy, future-risk validity and assistant answer quality.	Classifier accuracy, future-risk validity and assistant answer quality are assessed separately.

Decisions still required: See section 5.4: OPEN-03, OPEN-08 and OPEN-11.

SRS-PRD-105 — Baseline Comparison

Attribute	Specification
Status	Proposed response
TM source	REQ-AIML-004; URG-T51-R05.
Source modality	shall/may; all source conditions remain applicable.

Define and justify a reference baseline, then compare the candidate under equivalent evaluation conditions.

Comparison rules

Clause	Specification
B01	Define an appropriate reference before final model comparison for every AI/ML use case.
B02	Consider rule-based detection, threshold detection, statistical methods, existing operational practice or another agreed reference. Select and justify the appropriate reference; all five are not required.
B03	Run candidate and baseline on comparable inputs, outcome definitions, time horizons and evaluation conditions, reporting measurable change in the agreed primary measure together with false-positive/false-negative and operational trade-offs.

Use-case application and acceptance

Clause	Specification
B04	For initial prediction, a defensible simple historical/statistical reference is a candidate baseline, subject to data review; its presence does not make retrospective hotspots a prediction deliverable.
B05	For a hosted assistant, define an agreed task-level reference such as the existing record-search/summary process, with supported-answer and operational usefulness checks, rather than claiming access to provider training data.
B06	A model that fails to demonstrate the required improvement stays unaccepted pending revision or an explicit TM disposition.

Verification:

Criterion	Scenario / method	Expected result
AC01	Retain baseline definition/version, identical comparison-set references, candidate outputs, calculation and difference report.	Baseline version, identical comparison set, candidate outputs, calculations and differences remain available.
AC02	Check that neither comparison uses unavailable future data.	Neither comparison uses unavailable future data.
AC03	Demonstrate that a non-improving result is recorded as unmet rather than omitted or described as a pass.	Non-improvement is recorded as unmet, without omission or a false pass.
AC04	Minimum improvement/decision rule requires agreement.	Minimum improvement and the acceptance decision rule remain subject to agreement.

Decisions still required: See section 5.4: OPEN-08 and OPEN-11; Model performance and improvement (PAR-06) parameters.

SRS-PRD-106 — Training Data

Attribute	Specification
Status	Proposed response
TM source	REQ-MLDM-001; URG-T52-R02.
Source modality	shall; all source conditions remain applicable.

Maintain versioned, traceable dataset records for each model throughout development and operation.

Dataset register

Clause	Specification
B01	Maintain a dataset register for development, training, validation and operation of each model.
B02	Each entry records source/owner and permitted use, data type and format, expected frequency, required history, actual/required volume, quality rules, labelling needs, retention rule and known limitations.
B03	Link unchangeable import/snapshot references and transformations to the model package. Record each update as a new dataset version so the previous evaluation basis remains traceable.

Data availability and permitted use

Clause	Specification
B04	Document TM offline assets and incident/docket history separately from device observations/evidence and operator outcome labels.
B05	Record a missing dataset as an unresolved dependency; do not treat it as available for training.
B06	For a pretrained detector or hosted LLM, record the supplier’s available provenance/limitations and the local task-evaluation/retrieval datasets; do not claim custody of inaccessible pretraining data or require bespoke pretraining by implication.
B07	Dataset access and any API use remain subject to approved purposes and retention.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect a register entry for all ten required source fields and trace a model input sample to its import/observation version and permitted purpose.	All ten register fields and a sample input resolve to versioned sources and permitted purpose.
AC02	Check an absent history period, a third-party model with unavailable pretraining detail and a dataset version update are recorded explicitly.	Missing history, unavailable pretraining detail and dataset updates have explicit records.
AC03	Verify unauthorised access is rejected.	Unauthorised access is denied.

Decisions still required: See section 5.4: OPEN-07, OPEN-08, OPEN-10 and OPEN-11.

SRS-PRD-107 — Training, Validation and Test Data

Attribute	Specification
Status	Clarification required
TM source	REQ-MLDM-004; URG-T52-R05.
Source modality	shall/may; all source conditions remain applicable.

Retain the source baseline-comparison obligation and separately propose split/leakage controls pending Q06.

Literal source obligation

Clause	Specification
B01	Q06 remains unresolved: the title is “Training, Validation and Test Data” but the description repeats baseline comparison.
B02	The description’s complete baseline obligation is retained: define and justify a rule, threshold, statistical, existing-practice or other agreed reference as appropriate, then demonstrate measurable improvement under the comparison response in URG-T51-R05.

Proposed data partition rules

Clause	Specification
B03	Separately propose a split/leakage-control policy to address the title without presenting it as corrected TM wording.
B04	Freeze a versioned final test set before final candidate evaluation; use development/training data for fitting and validation data for model/threshold selection.
B05	Keep related records from the same incident, repeated frames and duplicate imports together.
B06	For future-risk testing, choose time-separated evaluation with inputs limited to information available at prediction time; where location generalisation is claimed, add a suitably separated location/site evaluation.
B07	Record the split rationale and any small-data limitations.
B08	No fixed train/validation/test percentages are selected.

Verification:

Criterion	Scenario / method	Expected result
AC01	Verify baseline evidence for this row independently of its title.	The literal baseline obligation has evidence independently of the title.
AC02	Inspect membership lists and separation rules; attempt to trace a duplicate event/frame or later outcome across partitions and verify it is excluded from leakage.	Membership/separation rules prevent duplicates, related frames and later outcomes from leaking across partitions.
AC03	Reproduce the test using the frozen dataset and preprocessing.	The frozen dataset and preprocessing reproduce the test.
AC04	The split policy is proposed and does not resolve Q06.	The split policy remains proposed and Q06 remains unresolved.

Decisions still required: See section 5.4: OPEN-12 / Q06; OPEN-08.

SRS-PRD-108 — Data Drift

Attribute	Specification
Status	Proposed response
TM source	REQ-MLDM-006; URG-T52-R07.
Source modality	shall/may; all source conditions remain applicable.

Monitor operational models for applicable changes in inputs, sensor behaviour and event patterns.

Mandatory monitoring

Clause	Specification
B01	The monitoring capability is mandatory under the source; only the selection of applicable drift/metric indicators is conditional.

Reference and observations

Clause	Specification
B02	Maintain a versioned reference profile for each operational model’s key inputs and outputs, with configurable review windows and material-change criteria.
B03	Where applicable compare missingness/value/category distributions for data/feature drift, sensor health/readings/configuration for behaviour changes, and event rates/classes/location/time patterns for significant event changes.
B04	Include sample counts and changes in import coverage or deployed equipment; distinguish these changes from changes in threat activity.

Review and operating response

Clause	Specification
B05	Record and report the affected model, feature/source, period, reference, observed change and proposed review action.
B06	A drift indication initiates review; it does not by itself prove lower accuracy or authorise retraining/deployment.
B07	Too little current data is shown as insufficient monitoring evidence.
B08	Known quality/health failures can block dependent automation under the guardrail while unaffected platform functions continue.

Verification:

Criterion	Scenario / method	Expected result
AC01	Compare a stable sample with controlled changes to a feature distribution, a sensor’s behaviour and event pattern; verify the applicable report identifies each source and period.	Applicable changes identify their feature/sensor/event source and observation period.
AC02	Check small/empty windows and changed device populations do not manufacture an accuracy claim.	Small/empty windows and changed device populations do not manufacture accuracy findings.
AC03	Threshold-crossing outcomes are checked against the agreed configuration.	Threshold outcomes match the agreed monitoring configuration.

Decisions still required: See section 5.4: OPEN-08; Model degradation threshold (PAR-07) parameters.

SRS-PRD-109 — Corroboration

Attribute	Specification
Status	Proposed conditional response
TM source	REQ-MLGRL-004; URG-T53-R05.
Source modality	shall; all source conditions remain applicable.

Where corroboration applies, define and check the required evidence before enabling the dependent workflow.

Corroboration configuration

Clause	Specification
B01	For workflows where corroboration is applicable, configure the required corroborating evidence and correlation rule before enablement.
B02	A proposed rule may combine a model prediction with another sensor observation, a separate source, relevant incident history or contextual asset/site information.
B03	Preserve source IDs, times, location linkage and the result of each check.

Evidence eligibility

Clause	Specification
B04	Count retransmission or multiple copies of one observation as one item, not independent corroboration.
B05	A rule must say whether contextual history is sufficient or a contemporaneous observation is necessary; no blanket two-sensor requirement is imposed.
B06	If required evidence is absent, conflicting, stale or cannot be linked to the same asset/area, hold the dependent action for operator review and identify the reason.
B07	Do not assume extra sensors or live TM production feeds will be available.

Verification:

Criterion	Scenario / method	Expected result
AC01	Exercise a configured rule with valid corroboration, duplicate/replayed evidence, mismatched location/time, conflicting evidence and missing required evidence.	Valid, duplicate, mismatched, conflicting and missing evidence are evaluated under the configured rule.
AC02	Verify the evidence chain and that only the eligible case advances; blocked cases remain reviewable.	Only the eligible case advances; held cases retain their evidence chain and reason.
AC03	For a workflow without this condition, inspect the explicit applicability rationale.	A workflow without corroboration has an explicit applicability rationale.

Decisions still required: See section 5.4: OPEN-04 and OPEN-08.

SRS-PRD-110 — Human Validation

Attribute	Specification
Status	Proposed response
TM source	REQ-HITL-001; URG-T55-R02.
Source modality	shall; all source conditions remain applicable.

Support authorised human validation while preserving the original inference and the distinction between validation, action approval and outcome verification.

Review capability

Clause	Specification
B01	Where the workflow requires validation, provide authorised users with the prediction, applicable confidence/risk, supporting evidence and linked context.
B02	Support accept, reject, classification correction and feedback with a recorded intervention reason, actor and time.
B03	Preserve original model output alongside the reviewed classification/decision; a correction must not rewrite the original inference or the source evidence.

Authority and label boundaries

Clause	Specification
B04	Proposed M3 use places review with the permitted Operator for the relevant alert/case; Viewer remains read-only.
B05	Record unsupported or uncertain ground truth explicitly.
B06	Accepting a prediction is distinct from approving an operational action, while approving an action is distinct from verifying its outcome.
B07	If evidence is unavailable or access is denied, show the limitation and do not imply validation occurred.
B08	A human classification correction is a candidate label requiring the labelling quality process before model reuse.

Verification:

Criterion	Scenario / method	Expected result
AC01	Demonstrate review of prediction/evidence, accept, reject, modify classification, feedback and intervention reason.	Review, acceptance, rejection, correction and feedback retain intervention reasons.
AC02	Verify role denial, original-versus-reviewed values and audit.	Role denial and audit protect distinct original/reviewed values.
AC03	Check accept alone neither executes a command nor creates an unquestioned training label, and unavailable evidence leaves the validation limitation visible.	Acceptance alone neither commands action nor approves a training label; missing evidence leaves validation limitations visible.

Decisions still required: See section 5.4: OPEN-04 and OPEN-08.

SRS-PRD-111 — Model Versioning

Attribute	Specification
Status	Proposed response
TM source	REQ-MLOP-001; URG-T56-R02.
Source modality	shall; all source conditions remain applicable.

Give every operational model package a unique version identity and retain the producing identity with every inference.

Version register

Clause	Specification
B01	Assign a unique version identity to every model package deployed for operational use, including POC/Pilot operation.
B02	Keep its use case, model artifact/reference, input/preprocessing definitions, configuration, training/evaluation dataset references, results, approval state and intended runtime together in a controlled register.
B03	Every inference stores the identity actually used, not just the current active model name.

History and hosted-model limits

Clause	Specification
B04	Retain previous versions for audit and agreed rollback until retirement under the retention policy.
B05	A vendor-hosted API entry records the available provider/model identifier and revision plus the local prompt/retrieval configuration version; disclose if a provider cannot pin its internal version.
B06	“Production model” in the source does not authorise connection to TM production systems.
B07	User-facing labels may be readable names but must resolve to the unique package identity.

Verification:

Criterion	Scenario / method	Expected result
AC01	Deploy two distinguishable versions in a test environment, generate results and verify each resolves to its own package/configuration/evaluation record.	Each version produces results linked to its own package, configuration and evaluation evidence.
AC02	Check an attempted identity reuse/change is rejected or creates a new version.	Identity reuse/change is rejected or receives a new version.
AC03	Inspect available hosted-provider metadata and documented pinning limitations if applicable.	Available hosted metadata and version-pinning limits are documented where applicable.

Decisions still required: See section 5.4: OPEN-10 and OPEN-11.

SRS-PRD-112 — Model Deployment

Attribute	Specification
Status	Proposed response
TM source	REQ-MLOP-002; URG-T56-R03.
Source modality	shall; all source conditions remain applicable.

Release validated model versions through an authorised, traceable process with recovery and failure handling.

Release controls

Clause	Specification
B01	Use a controlled release process: identify the validated candidate package and intended environment, review acceptance/compatibility and residual limitations, record authorised release approval, install/activate the selected version, perform health/interface checks and retain the prior validated configuration for recovery.
B02	Log the deployment result and the versions serving predictions.
B03	Unvalidated candidates cannot become the active operational model through ordinary configuration changes.

Release operation and fallback

Clause	Specification
B04	For the POC/Pilot, a documented operator-run release/checklist is an acceptable proposed mechanism; a large automated MLOps platform is not assumed.
B05	Define the change window and handling of in-flight work so a version change cannot issue duplicate actions or reset approvals.
B06	If activation/checks fail, keep/revert to a compatible validated version or mark the dependent AI function unavailable while unaffected operations continue.
B07	Do not promise zero downtime without an agreed target.

Verification:

Criterion	Scenario / method	Expected result
AC01	Exercise an approved version update and a failed/incompatible activation.	Approved updates and failed/incompatible activations have recorded release outcomes.
AC02	Verify release records, versioned predictions, in-flight handling, no duplicate command, health checks and restoration/fallback.	Versioned results, health checks, in-flight handling and recovery remain traceable without duplicate commands.
AC03	Check unauthorised/unvalidated activation is denied and normal unaffected functions remain available during the planned failure case.	Unauthorised/unvalidated activation is denied; unaffected functions continue during planned failure.

Decisions still required: See section 5.4: OPEN-10 and OPEN-16.

SRS-PRD-113 — Model Performance Monitoring

Attribute	Specification
Status	Proposed response
TM source	REQ-MLOP-003; URG-T56-R04.
Source modality	shall; all source conditions remain applicable.

Monitor active model performance using applicable metrics and explicit evidence cohorts.

Mandatory monitoring

Clause	Specification
B01	The monitoring capability is mandatory under the source; only the selection of applicable drift/metric indicators is conditional.

Performance evidence

Clause	Specification
B02	Provide an operational monitoring view/report per active model/version and period.
B03	Include applicable prediction volume, accuracy, precision, recall, F1, false positives, false negatives, confidence distribution, data quality and model/data drift.
B04	Derive outcome-dependent metrics only from an identified, reviewed labelled cohort with sample counts and outcome-availability period; predictions awaiting outcomes stay pending rather than being counted correct.

Operational monitoring and assistant evaluation

Clause	Specification
B05	Maintain volume/confidence/input-health indicators even when truth labels are delayed.
B06	Relate reported errors to use case, site/condition and deployed version; do not infer predictive accuracy from a healthy API or the absence of complaints.
B07	Use agreed reference/thresholds for notifications and retain the report/evidence.
B08	For the assistant, monitor request failures and reviewed answer-grounding/permission issues with an agreed task-specific rubric rather than forcing classifier metrics onto text generation.

Verification:

Criterion	Scenario / method	Expected result
AC01	Generate known prediction/label samples and reconcile each applicable source metric with the monitoring report.	Applicable metric values reconcile to known prediction/label samples.
AC02	Check delayed/unavailable labels, empty classes and confidence absence are explicit.	Delayed or missing labels, empty classes and absent confidence remain explicit.
AC03	Verify drift/quality indicators and failure counts stay separate from accuracy; inspect different model versions and condition slices without merging their denominators.	Drift, input quality and failures remain distinct from accuracy; version/condition denominators are not merged.

Decisions still required: See section 5.4: OPEN-08 and OPEN-11; Model performance and improvement (PAR-06) and Model degradation threshold (PAR-07) parameters.

SRS-PRD-114 — Model Degradation

Attribute	Specification
Status	Proposed response
TM source	REQ-MLOP-004; URG-T56-R05.
Source modality	shall; all source conditions remain applicable.

Detect and report performance degradation against agreed evidence and threshold rules.

Source identity and comparison

Clause	Specification
B01	Retain this literal REQ-MLOP-004 as “Model Degradation”, URG-T56-R05; it is separate from the Closed-Loop AI/ML row URG-T57-R05.
B02	Compare current model performance with the agreed reference using a defined cohort, observation window, measure, threshold and minimum evidence rule.
B03	Record model/version, observed value, baseline, time, data sufficiency and affected use case.

Degradation response

Clause	Specification
B04	When the agreed degradation threshold is exceeded, generate an internal alert/notification for the designated authorised personnel and link the evidence and review status.
B05	Distinguish performance degradation supported by labels from input drift, API failure and insufficient evidence.
B06	Proposed response is investigation and, where warranted, constrained use or controlled rollback under the release process; a notification does not autonomously retrain or activate a replacement.

Verification:

Criterion	Scenario / method	Expected result
AC01	Provide a labelled sample that stays within the agreed limit and one that crosses it; verify only the configured condition creates the expected notification and evidence.	Only the configured threshold crossing produces the expected notification and evidence.
AC02	Exercise insufficient labels separately.	Insufficient labels produce an evidence limitation rather than confirmed degradation.
AC03	Verify source trace distinguishes this Model Degradation row from the duplicate-ID closed-loop row and both remain present.	Both literal REQ-MLOP-004 rows retain distinct titles/locators and evidence.

Decisions still required: See section 5.4: OPEN-12 / Q01; Model degradation threshold (PAR-07) parameters.

SRS-PRD-115 — Model Retraining

Attribute	Specification
Status	Proposed response
TM source	REQ-MLOP-005; URG-T56-R06.
Source modality	shall; all source conditions remain applicable.

Retrain applicable trainable components through reviewed datasets, reproducible evaluation and release approval.

Retraining lifecycle

Clause	Specification
B01	Define the retraining process for model components that are trainable within the delivery.
B02	Collect operational examples/outcomes and check permissions, provenance, quality and labels.
B03	Version the eligible dataset and fit a candidate with recorded configuration.
B04	Evaluate against the reference and protected test protocol.
B05	Review regressions and obtain release approval before deployment.
B06	Retain unsuccessful candidates and their evaluation disposition as appropriate to the approved retention policy.

Feedback and closed-model boundaries

Clause	Specification
B07	New or corrected operator feedback is not ingested blindly.
B08	For a third-party pretrained model/API whose weights cannot be retrained by the project, document that boundary and propose an applicable controlled alternative such as evaluated replacement, vendor update or separately approved adaptation.
B09	Retrieval/prompt changes require evaluation but are not described as weight retraining.
B10	Inability to satisfy an applicable retraining obligation needs TM disposition; it is not silently waived by choosing a hosted product.

Verification:

Criterion	Scenario / method	Expected result
AC01	Trace validated operational data through one reproducible candidate-training/evaluation exercise for each applicable trainable model.	Each applicable trainable model has a reproducible candidate exercise tracing reviewed operational data.
AC02	Verify unreviewed labels and final-test leakage are excluded, and a candidate failing review cannot become active.	Unreviewed labels and final-test leakage are excluded; rejected candidates cannot activate.
AC03	For hosted/closed models, inspect the explicitly approved lifecycle alternative and unresolved scope condition.	Hosted/closed-model entries retain the approved alternative and any unresolved retraining obligation.

Decisions still required: See section 5.4: OPEN-08 and OPEN-11.

SRS-PRD-116 — Model Rollback

Attribute	Specification
Status	Proposed response
TM source	REQ-MLOP-006; URG-T56-R07.
Source modality	shall; all source conditions remain applicable.

Support authorised restoration of a previously validated compatible model, with an explicit fallback where restoration is unavailable.

Rollback evidence

Clause	Specification
B01	Retain a previously validated, deployable model package and compatible preprocessing/configuration so an authorised release operator can restore it when the active update has unacceptable performance or behaviour.
B02	Record rollback reason, affected version, target version, operator/time, compatibility checks and resulting health/evaluation evidence; preserve predictions from both versions.

Compatibility and hosted fallback

Clause	Specification
B03	Reverting a model does not reverse physical actions, erase case history or repeat prior commands.
B04	If the earlier package cannot operate on the current schema/runtime, do not activate it blindly; use the defined AI-unavailable/review-only fallback while resolving compatibility.
B05	For externally hosted models, confirm that the provider offers a usable pinned previous version or propose another validated fallback before operational reliance.
B06	If no equivalent rollback capability can be supplied, retain an explicit unmet requirement/deviation for TM decision.

Verification:

Criterion	Scenario / method	Expected result
AC01	Activate a validated update, simulate unacceptable behaviour and restore the prior validated compatible package.	The prior validated compatible package can be restored after unacceptable update behaviour.
AC02	Verify health, output/version trace and absence of action replay.	Health and versioned outputs remain traceable without replaying actions.
AC03	Exercise a compatibility failure and hosted-version unavailability; confirm safe fallback and an open disposition rather than a false claim of successful rollback.	Incompatibility/hosted-version absence triggers the declared fallback and open disposition, not a false rollback success.

Decisions still required: See section 5.4: OPEN-10 and OPEN-11.

SRS-PRD-117 — Model Lifecycle Records

Attribute	Specification
Status	Proposed response
TM source	REQ-MLOP-007; URG-T56-R08.
Source modality	shall; all source conditions remain applicable.

Maintain linked lifecycle evidence and distinguish planned work, validation and release approval.

Lifecycle records

Clause	Specification
B01	Maintain linked lifecycle records for development, training, validation, approval, deployment, version changes, retraining, performance monitoring, rollback and retirement.
B02	For each significant activity identify model/use case/version, actor/time, inputs or dataset references, configuration, result, decision and evidence location.
B03	A controlled register plus stored reports/artifacts is sufficient for the initial POC/Pilot; no bespoke lifecycle-management interface is required by this proposal.

Approval and record protection

Clause	Specification
B04	Separate proposed, validated and authorised-for-use states in the record so existence of an artifact is not mistaken for release approval.
B05	Retiring a version prevents new selection while preserving historical inference/action references for the approved retention period.
B06	Protect records through role-controlled changes and retain change history.
B07	Provider limitations and unavailable underlying training records remain explicit in externally hosted model entries.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect a sample lifecycle chain covering all ten source activities, using recorded applicability where an activity has not yet occurred.	All ten lifecycle activities have evidence or recorded applicability where not yet performed.
AC02	Verify traceability of version/actor/evidence, access denial for unauthorised changes and historic lookup after retirement.	Version, actor and evidence links survive retirement; unauthorised changes are denied.
AC03	Planned/not-yet-performed activities remain pending rather than carrying invented evidence.	Planned activities remain pending without invented completion evidence.

Decisions still required: See section 5.4: OPEN-10 and OPEN-16.

SRS-PRD-118 — Prediction-to-Workflow Integration

Attribute	Specification
Status	Proposed response
TM source	REQ-MLIN-001; URG-T57-R02.
Source modality	shall; all source conditions remain applicable.

Deliver model results through a defined logical workflow contract without bypassing platform controls.

Logical result contract

Clause	Specification
B01	Transmit predictions, risk assessments and recommendations to the platform workflow component through a defined internal contract.
B02	Proposed payload includes result ID/type, affected asset/location/segment, source/model/version, assessment time and validity/horizon, result/score, applicable confidence, supporting-record references, data/guardrail state and correlation to the originating observation.
B03	Validate required identity/type/time fields before workflow evaluation.

Workflow acceptance and action controls

Clause	Specification
B04	Store or acknowledge each accepted result and preserve failures for review.
B05	Re-delivery of the same result must not create duplicate decisions/actions, while a genuinely new assessment receives its own identity.
B06	Stale, unresolvable or incomplete payloads remain retained/rejected with a reason and cannot trigger a dependent physical action.
B07	The platform applies its own permission/approval and safety controls; the AI service cannot bypass them.
B08	Field requests still pass through the FALCON IoT service.

Verification:

Criterion	Scenario / method	Expected result
AC01	Send one valid prediction, risk result and recommendation; trace each to workflow intake and decision.	A valid prediction, risk result and recommendation each trace to intake and decision.
AC02	Re-deliver a result and verify no duplicate action, then submit a genuinely new result and retain it.	Re-delivery does not duplicate action; a genuinely new assessment retains its own result identity.
AC03	Test invalid identity, stale validity and missing required location/evidence; verify reasoned rejection/review and no unsafe command.	Invalid, stale or incomplete results have reasoned rejection/review and cannot trigger unsafe commands.

Decisions still required: See section 5.4: OPEN-04, OPEN-07 and OPEN-08.

SRS-PRD-119 — Closed-Loop AI/ML

Attribute	Specification
Status	Proposed conditional response
TM source	REQ-MLOP-004; URG-T57-R05.
Source modality	shall; all source conditions remain applicable.

Where applicable, demonstrate a governed improvement loop from reviewed operational outcomes to an evaluated release decision.

Source identity and improvement loop

Clause	Specification
B01	Retain this literal REQ-MLOP-004 as “Closed-Loop AI/ML”, URG-T57-R05, separately from Model Degradation, URG-T56-R05.
B02	Where applicable, demonstrate a governed improvement loop: collect linked operational outcomes; review their quality/labels and error patterns; propose a model/data/rule improvement; evaluate it against the recorded reference; obtain release approval; deploy or reject the candidate; monitor the result.

Governance and hosted limitations

Clause	Specification
B03	The proposed first loop may be analyst/operator-run using versioned datasets and evaluation reports.
B04	Continuous improvement means a repeatable, evidence-linked lifecycle, not unattended weight updates after every feedback item.
B05	Unverified, ambiguous or intervention-confounded outcomes stay outside automatic training.
B06	For a closed hosted model, use only the lifecycle changes actually supported and agreed, and state if a retraining/rollback obligation needs separate disposition.

Verification:

Criterion	Scenario / method	Expected result
AC01	For an applicable use case, follow a real or clearly labelled demonstration outcome set into a reviewed improvement candidate and evaluation decision.	A real or clearly labelled demonstration set traces to a reviewed improvement candidate and evaluation decision.
AC02	Verify a rejected candidate remains inactive, an accepted release has traceable approval and subsequent monitoring, and both duplicate-ID rows remain separately verified.	Rejected candidates stay inactive; accepted releases have approval/monitoring and each duplicate-ID row has separate evidence.
AC03	A diagram alone is not a completed closed-loop demonstration.	A diagram alone is insufficient evidence of a completed loop.

Decisions still required: See section 5.4: OPEN-12 / Q01; OPEN-08 and OPEN-11.

3.6.2 Detection Model Lifecycle

Purpose and actors: Model practitioners and designated reviewers establish supported detection scenarios, evaluate representative observations and record limitations. Authorised maintainers monitor deployed versions; Operators retain separate investigation findings.

Boundaries: Detection indicates potential activity, not proven damage, guilt or threat resolution. Supported classes and processing placement depend on reviewed evidence and selected equipment. Approval, labelling and source-title conflicts remain separately traceable.

Submodules: Construction/theft/animal use cases; labelling; representative data; detection evaluation; runtime compatibility; monitoring and responsible use.

MD-AI-001 — Labelled source examples

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Assemble and label examples with traceable origins.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect a sample dataset for origin, usage permission, class definition, label and reviewer; quarantine unresolved or disputed labels.	Origins, permissions, definitions and reviewed labels are traceable; disputed labels are quarantined.

Decisions still required: See section 5.4: OPEN-08 and OPEN-09.

MD-AI-002 — Detection model selection

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Choose or adapt a model for the agreed detection or assessment task.

Verification:

Criterion	Scenario / method	Expected result
AC01	Compare the selected candidate with a documented baseline for the agreed task/data/runtime and retain the selection rationale.	The candidate/baseline comparison supports the recorded task, data and runtime selection rationale.

Decisions still required: See section 5.4: OPEN-03 and OPEN-08.

MD-AI-003 — Representative evaluation

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Evaluate model results against reviewed examples and agreed acceptance measures.

Verification:

Criterion	Scenario / method	Expected result
AC01	Run reviewed representative positive/negative examples; report false positives, misses and agreed task metrics by relevant field condition.	False positives, misses and applicable metrics are reported by the relevant field conditions.

Decisions still required: See section 5.4: OPEN-08 and OPEN-09; Model performance and improvement (PAR-06) parameters.

MD-AI-004 — Runtime model package

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Package an evaluated model for the intended runtime and hardware.

Verification:

Criterion	Scenario / method	Expected result
AC01	Run the approved model package on intended hardware/runtime and record compatibility, resource use and failure behaviour against agreed limits.	The package meets agreed compatibility/resource/failure limits on its intended hardware/runtime.

Decisions still required: See section 5.4: OPEN-03 and OPEN-10.

MD-AI-005 — Model history and rollback

Attribute	Specification
Status	Proposed
Provenance	Baseline Sources#SRC-04

Track model versions, evaluation records, and evidence for replacement or rollback.

Verification:

Criterion	Scenario / method	Expected result
AC01	Trace a deployed model to its approved evidence and execute a controlled rollback; verify results retain the producing version.	Deployment evidence and producing versions remain traceable through controlled rollback.

Decisions still required: See section 5.4: OPEN-10.

SRS-MLD-101 — Construction Activity Detection

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-020; URG-T16-R02.
Source modality	shall/may; all source conditions remain applicable.

Identify potentially threatening construction activity from approved inputs and preserve traceable observations.

Detection output

Clause	Specification
B01	For an approved sensor/camera or other approved data input, identify construction-related activity potentially threatening fibre, preserve the observation and produce a construction event containing activity class, source, time, location basis and available evidence/confidence.
B02	Keep unsupported or inconclusive observations available for review rather than invent a positive classification.
B03	Detection identifies potential risk; it does not establish damage or authorised-work status.
B04	Processing location and detector/model remain hardware-neutral until selected.

Supported construction indicators

Clause	Specification
B05	Review excavation, drilling, roadworks, heavy machinery, construction vehicles, activity inside fibre protection zones and change in activity over time as potential indicators.
B06	Include oversized vehicles and drainage works from the narrative scenario.
B07	For each record supported source, observable signature, monitoring conditions, limitation and evaluation case; the source says may include, so it does not mandate universal recognition of every example.
B08	Do not silently exclude an agreed scenario because a chosen device cannot see it.

Verification:

Criterion	Scenario / method	Expected result
AC01	Run representative reviewed positive and negative examples for every agreed indicator under its agreed conditions, retaining source observations and detector/version output.	Every agreed indicator has representative positive/negative evidence under agreed conditions, linked to observations and detector/version.
AC02	Include a harmless or distant construction example and a failed/unsupported sensing condition.	Harmless/distant construction and unsupported/failed sensing have explicit dispositions.
AC03	Document false positives, missed detections and limits against separately agreed metrics.	False positives, misses and limitations are measured against separately agreed metrics.

Decisions still required: See section 5.4: OPEN-03 and OPEN-09; Sensor coverage and detection (PAR-05) and Model performance and improvement (PAR-06) parameters.

SRS-MLD-102 — Unauthorised Activity Detection

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-030; URG-T17-R02.
Source modality	shall; all source conditions remain applicable.

Identify observations indicative of potential theft, vandalism or unauthorised access without presenting suspicion as proof.

Detection output

Clause	Specification
B01	Consume approved observations from registered equipment or approved source records and identify behavior indicative of potential theft, vandalism or unauthorised access.
B02	Produce a traceable event with scenario/type, time, location/asset, observation source and available evidence/confidence.
B03	Use potential/suspected labels; detection is not proof of a crime or identification of a perpetrator.
B04	Operator investigation records its own finding and does not overwrite the original detection.

Scenario applicability

Clause	Specification
B05	Review the narrative examples and local authorised-access context.
B06	Agree how each supported scenario is recognised, whether a supplied authorised-work list exists, the monitored period/area and the conditions that remain unsupported.
B07	A missing authorised-access record cannot itself prove unauthorised access.
B08	Coordinated theft requires agreed correlation evidence; no identity recognition or cross-site attribution capability is implied.

Verification:

Criterion	Scenario / method	Expected result
AC01	Run reviewed suspicious and benign/authorised examples for each agreed scenario.	Agreed scenarios include reviewed suspicious and benign/authorised examples.
AC02	Trace positive events to their actual observations, demonstrate an uncertain case and verify no automatic assertion of guilt.	Positive events trace to observations; uncertain cases do not assert guilt.
AC03	Evaluate false-positive/missed-event performance under the agreed conditions.	False-positive and missed-event performance is assessed under the agreed conditions.

Decisions still required: See section 5.4: OPEN-09.

SRS-MLD-103 — Suspicious Activity Classification

Attribute	Specification
Status	Proposed response
TM source	REQ-FUNC-032; URG-T17-R04.
Source modality	shall; all source conditions remain applicable.

Classify theft/vandalism detections against reviewed scenarios while preserving original and reviewed findings.

Classification output

Clause	Specification
B01	For each theft/vandalism detection apply the reviewed scenario definitions, retaining scenario identity/version, input evidence, resulting classification and supplied confidence/limitations.
B02	Proposed catalogue entries correspond to approved observable cases such as abnormal access, physical tampering/cable damage and coordinated suspicious activity; these are not approved detector classes until reviewed.
B03	Unmatched or ambiguous observations remain Unclassified/Needs review and are retained.

Review and configuration controls

Clause	Specification
B04	The operator may record a reviewed finding with reason and links while preserving the original classification.
B05	A scenario result feeds the configured risk rule; it does not automatically establish severity, authorise action or close a case.
B06	Configuration changes apply through versioned new evaluations, with historical classifications retained.
B07	Permission to view does not confer permission to correct classifications or publish scenario definitions.

Verification:

Criterion	Scenario / method	Expected result
AC01	Evaluate reviewed examples for each agreed class, an ambiguous example and a changed catalogue version.	Agreed, ambiguous and changed-version scenarios are evaluated against the reviewed catalogue.
AC02	Verify raw detection, classifier result and operator finding remain distinguishable; confirm old events retain their applied version and no unauthorised correction succeeds.	Raw detection, classifier result and operator finding remain distinct; old versions persist and unauthorised corrections fail.

Decisions still required: See section 5.4: OPEN-09.

SRS-MLD-104 — AI Monitoring

Attribute	Specification
Status	Proposed conditional response
TM source	REQ-OBS-004; URG-T29-R05.
Source modality	shall; all source conditions remain applicable.

Monitor deployed models using operational indicators and quality measures supported by verified outcomes.

Monitoring evidence and response

Clause	Specification
B01	For each deployed model/version expose inference volume, latency/errors, unavailable/low-quality input counts, confidence/risk distribution, freshness and drift indicators appropriate to its inputs.
B02	When independently verified labels/outcomes are available, calculate the applicable quality metrics on that labelled cohort and show sample size, period and label delay; unlabeled operational volume is not accuracy evidence.
B03	Separate construction, theft/vandalism and animal/rodent slices when supported.
B04	Alert authorised maintainers when configured degradation/data-quality thresholds are exceeded; preserve the prior result/version and degraded indication instead of silently substituting zero risk.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inject missing/stale inputs and changed feature/event distributions; compare monitoring totals with inference records and labelled evaluation fixtures; verify a configured threshold produces a traceable issue and no false accuracy claim for unlabeled data.	Monitoring reconciles to inference/labelled fixtures; configured issues are traceable and unlabelled activity does not imply accuracy.

Decisions still required: See section 5.4: OPEN-08; Model degradation threshold (PAR-07) parameters.

SRS-MLD-105 — AI/ML Architecture

Attribute	Specification
Status	Proposed conditional response
TM source	REQ-AIMLA-001; URG-T38-R02.
Source modality	shall; all source conditions remain applicable.

Record the selected processing placement and operating boundaries for each AI/ML use case.

Processing placement and boundaries

Clause	Specification
B01	Maintain a processing-placement record per AI/ML use case: detection/classification may use a selected device, edge runtime or central worker; historical/predictive risk is proposed as platform/central analytics using accepted TM data; any hybrid path shows both stages and transferred data.
B02	The proposed M4 read-only chatbot uses an LLM API and is a separate capability, not the selected detection model.
B03	State model/version, input dependency, runtime/compute, output schema, latency/resource assumptions and failure fallback for each placement.
B04	Decide placement from device capability, bandwidth, offline need and privacy/cost evidence, not a preferred algorithm name.

Verification:

Criterion	Scenario / method	Expected result
AC01	Trace representative input/output for every selected model location; disconnect its dependency and verify declared degraded/unavailable state without unapproved substitution or action.	Declared placement failures produce explicit degraded/unavailable states without unapproved substitution or action.
AC02	Retain deployment/model manifest and resource measurements.	Deployment/model manifests and resource measurements support selected placements.

Decisions still required: See section 5.4: OPEN-03, OPEN-10 and OPEN-11.

SRS-MLD-106 — Dependency

Attribute	Specification
Status	Proposed response
TM source	REQ-AIMLA-003; URG-T38-R04.
Source modality	shall; all source conditions remain applicable.

Identify model dependencies and govern inference, degraded operation and recovery against their availability and compatibility.

Dependencies and recovery

Clause	Specification
B01	For each model list data services and artefacts it requires: sensor/adapter availability, asset/deployment resolution, accepted incident/history import, feature/normalisation schema, labelled training/evaluation data, model registry/version, inference runtime and any external API.
B02	Record required/optional status, freshness/quality criteria, version compatibility and dependency owner.
B03	Missing critical inputs prevent or constrain inference; optional inputs may be omitted only under a documented model contract.
B04	Show stale/last-successful output separately from current output, monitor dependency failure and restore only after compatible input/model versions are available.
B05	No assumed access to TM production data or a third-party model API is embedded in the dependency graph.

Verification:

Criterion	Scenario / method	Expected result
AC01	Remove each critical dependency in turn and supply incompatible/missing/stale inputs; check explicit unavailable/degraded results, model lineage and recovery after valid inputs return.	Each critical/incompatible/missing/stale dependency produces explicit constrained/unavailable handling; valid compatible recovery retains lineage.
AC02	Retain dependency matrix and failure-test logs.	The dependency matrix and failure-test logs retain the observed evidence.

Decisions still required: See section 5.4: OPEN-07, OPEN-08 and OPEN-11.

SRS-MLD-107 — Additional Sensors

Attribute	Specification
Status	Clarification required
TM source	REQ-AIML-003; URG-T51-R04.
Source modality	shall/may; all source conditions remain applicable.

Evaluate applicable POC/Pilot use cases against agreed task metrics while retaining the unresolved source title conflict.

Source conflict

Clause	Specification
B01	Q05 remains open: the literal title is “Additional Sensors”, while the description specifies performance evaluation.
B02	This response implements the description as proposed evaluation scope and does not infer an extra-sensor purchase or silently correct the title.

Task evaluation

Clause	Specification
B03	For each applicable POC/Pilot use case, produce an evaluation report naming the task, model/version, dataset/labels, operational conditions, baseline, thresholds and results against the agreed criteria.
B04	For classification-based prediction, report overall Accuracy plus Precision, Recall and F1 Score.
B05	Report a confusion matrix and per-class/support counts as a proposed aid to interpreting those measures.
B06	Select ROC-AUC/PR-AUC for applicable scored classification, MAE/RMSE for applicable numeric prediction, and false-positive/false-negative rates with explicit denominators; the source’s optional metric list does not require meaningless metrics for every model.
B07	Record unevaluable metrics and why.

Acceptance boundaries

Clause	Specification
B08	Keep detector, predictor and conversational-assistant evaluations separate.
B09	Missing labels or agreed minimums yield an unresolved acceptance result, not an assumed pass.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect the report and recompute the selected metrics from retained predictions/labels.	Selected metrics reproduce from retained predictions/labels.
AC02	Check an imbalanced class, a class with no evaluable observations and false alarms/missed events.	Imbalance, empty classes, false alarms and misses have explicit support/denominator treatment.
AC03	Verify classification prediction contains all four required metrics and distinguishes measured results from agreed POC/Pilot minimums.	Classification prediction includes Accuracy, Precision, Recall and F1; measurements remain separate from agreed POC/Pilot minimums.
AC04	Formal passing depends on the applicable approved criteria.	Formal acceptance depends on the applicable approved criteria.

Decisions still required: See section 5.4: OPEN-12 / Q05; OPEN-08 / Q10; Model performance and improvement (PAR-06) parameters.

SRS-MLD-108 — Data Labelling

Attribute	Specification
Status	Proposed conditional response
TM source	REQ-MLDM-003; URG-T52-R04.
Source modality	shall; all source conditions remain applicable.

Where supervised learning is used, define and apply traceable labelling and label-quality controls.

Label definitions

Clause	Specification
B01	Where supervised learning is used, maintain task-specific label guidance stating class/outcome definitions, inclusion/exclusion criteria, ground-truth sources, labelling steps, handling of ambiguous events and labelled-data quality assurance.
B02	Separate observed threat class, incident cause, prediction target and intervention outcome; they are not interchangeable labels.

Label-quality controls

Clause	Specification
B03	Proposed initial process: a designated reviewer checks labels against original evidence/incident records, unresolved disagreements remain marked ambiguous, and a reviewed label change retains the prior value, reviewer, reason and time.
B04	Exclude ambiguous examples from hard-label acceptance metrics unless the evaluation protocol explicitly defines their use.
B05	Do not treat an operator’s acceptance of a prediction or an executed deterrent command as ground truth.
B06	For prediction, define when an outcome can be known and how unmatched incidents or uncertain no-event periods are handled.
B07	An external labelling worksheet/tool is sufficient; an in-platform annotation product is not assumed.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect guidance for all six required elements.	All six labelling-guidance elements are present.
AC02	Review labelled positive, negative and ambiguous examples; trace to evidence and adjudication.	Positive, negative and ambiguous labels trace to original evidence and adjudication.
AC03	Verify an unresolved label cannot silently become an accepted training/test label and that changes preserve history.	Unresolved labels cannot silently enter accepted training/test data; reviewed changes preserve history.
AC04	If supervised learning is not used, retain an explicit method/applicability decision.	Non-supervised use has an explicit method/applicability decision.

Decisions still required: See section 5.4: OPEN-08.

SRS-MLD-109 — Data Representativeness

Attribute	Specification
Status	Proposed response
TM source	REQ-MLDM-005; URG-T52-R06.
Source modality	shall; all source conditions remain applicable.

Assess whether development and validation data represent the intended operating conditions.

Coverage assessment

Clause	Specification
B01	Compare model-development and validation data coverage with the intended deployment conditions and record the result in the dataset/evaluation report.
B02	Proposed review dimensions are threat/cause and non-threat cases, site/location, time/season, lighting/weather, camera placement/distance or sensor configuration where relevant, network/asset characteristics and source-data completeness.
B03	Use only dimensions relevant to the selected model; their inclusion does not add sensors or new personal-data collection.

Gaps and mitigation

Clause	Specification
B04	State counts and known gaps for important conditions.
B05	Where coverage is weak, propose targeted collection/review, additional field evaluation, a narrower supported operating envelope or a conservative review-only mode with clear limitations.
B06	Synthetic or replayed data is labelled and cannot silently stand for actual-site performance.
B07	A controlled one-location demonstration does not establish representativeness for every deployment or the later two-state pilot.

Verification:

Criterion	Scenario / method	Expected result
AC01	Review the coverage comparison against the agreed operational scenario/site conditions.	Coverage comparisons address agreed deployment scenarios and site conditions.
AC02	Examine examples from relevant slices and a deliberately absent slice; verify the gap, impact, mitigation and validation status are visible.	Relevant and absent slices show their gaps, impacts, mitigation and validation status.
AC03	Check claims of generalisation are bounded by the evidence and any narrowed use needs an explicit disposition.	Generalisation claims remain evidence-bounded and narrowed use requires explicit disposition.

Decisions still required: See section 5.4: OPEN-02, OPEN-08 and OPEN-09.

SRS-MLD-110 — Human Approval

Attribute	Specification
Status	Clarification required
TM source	REQ-MLGRL-005; URG-T53-R06.
Source modality	shall; all source conditions remain applicable.

Retain the source representativeness obligation and separately address independently required action approval pending Q07.

Literal source obligation

Clause	Specification
B01	Q07 remains open: the source title is “Human Approval”, but the description repeats Data Representativeness.
B02	Retain and satisfy that description through the operational-coverage assessment and mitigation response at URG-T52-R06, preserving a separate source trace rather than merging the rows.

Independent approval controls

Clause	Specification
B03	Independently, approval of designated operational actions is required by REQ-FUNC-072 and REQ-WFO-003 and elaborated by the existing workflow requirements.
B04	Proposed review shows the prediction, evidence, intended action/target and blocking conditions to an authorised operator, records approve/reject with actor/time/reason and rechecks relevant restrictions before action delivery.
B05	Approval does not prove the prediction true and cannot lift maintenance, stale-action or other non-overridable restrictions.
B06	These approval details are a response to independently stated obligations and a proposal for the conflicting title, not an assertion that TM has corrected this row.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect representative-data evidence and mitigation under this literal row/locator.	Representativeness evidence and mitigation remain linked to this literal source row/locator.
AC02	Separately exercise designated approval/rejection, denied approval permission and changed restrictions after approval; retain their independent requirement links.	Approval/rejection, permission denial and changed restrictions have their independent requirement links.
AC03	Neither an approval demo alone nor the title alone closes this row’s description conflict.	Neither approval demonstration nor the title alone resolves the description conflict.

Decisions still required: See section 5.4: OPEN-12 / Q07; OPEN-04 and OPEN-09.

SRS-MLD-111 — Responsible AI

Attribute	Specification
Status	Proposed response
TM source	REQ-ETRES-001; URG-T54-R02.
Source modality	shall; all source conditions remain applicable.

Maintain a proportionate risk assessment and supporting controls for every deployed AI use case.

Risk assessment

Clause	Specification
B01	Maintain a concise AI risk assessment with intended use, affected operations, risk, mitigating control, evidence, residual limitation and responsible reviewer for each deployed AI use case.
B02	Cover all source concerns: inappropriate decisions, biased/unrepresentative data, incorrect predictions, excessive automation, inadequate explainability and inappropriate reliance on AI-generated recommendations.

Controls and review

Clause	Specification
B03	Proposed controls are representative-data/error review, explicit operating limits, understandable reasons, separation of prediction from action, approval/override paths, monitoring and controlled model replacement.
B04	For the assistant also test unsupported factual claims, malicious instructions inside retrieved text and unauthorised disclosure; enforce the read-only boundary outside the model.
B05	State limitations in the operational display/training material.
B06	Apply risk review before deployment and when material data/model/use-case changes occur.
B07	This is a proportionate POC/Pilot review, not a claim of certification or a new mandatory external standard.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect a risk/control/evidence entry for each of the six source concerns.	All six source concerns have risk, control and evidence entries.
AC02	Demonstrate one incorrect prediction, an unrepresented condition, a blocked unauthorised action and an explanation/override path.	Incorrect prediction, unrepresented conditions, blocked actions and explanation/override paths demonstrate relevant controls.
AC03	For delivered assistant scope, verify grounded/refusal and permission-abuse cases.	Delivered assistant scope passes applicable grounding/refusal and permission-abuse checks.
AC04	Review residual limitations before the relevant acceptance decision.	Residual limitations are reviewed before the relevant acceptance decision.

Decisions still required: See section 5.4: OPEN-08, OPEN-10 and OPEN-11.

3.6.3 Common model and prediction contract

Purpose: Define shared logical model/result information for the Data Dictionary and Interface Contracts without selecting a wire schema.

Logical record	Proposed information
Model package	Use case; unique version; input/preprocessing definition; intended runtime; data references; evaluation/baseline; approval state; limitations.
Prediction/result identity	Result ID and kind; model/configuration version; affected asset/location/segment.
Time meaning	Input/reference period; assessment time; future target/horizon when relevant.
Result	Result/category/score; confidence only when supported.
Evidence and controls	Supporting-record references; data coverage; guardrail/decision links.

Clause	Contract rule
B01	Historical indicator, observed detection, future prediction and recommendation remain distinct result kinds.
B02	Proposed result usability is valid, constrained or unavailable with a reason; exact encoded values remain for interface design.
B03	Usability describes fitness for the intended use, not threat severity or a new case lifecycle.
B04	Missing confidence does not equal zero; missing history does not equal low risk.
B05	Proposed M3 delivery includes initial future-risk prediction as well as historical ranking.
B06	Frequency, recency and severity/impact remain provisional historical factors.
B07	No predictor, detection algorithm, confidence scale, numeric target or processing location is selected here.

Decisions still required: See section 5.4: OPEN-07, OPEN-08, OPEN-10 and OPEN-11; Model performance and improvement (PAR-06) parameters.

4. Verification

The SRS states expected results; it does not report successful execution. Every requirement starts with verification status Not Run. A criterion with an unagreed parameter remains blocked for acceptance until its decision is recorded.

4.1 Verification scope and methods

• Verification covers the full agreed FALCON solution across all three threat families: construction, theft/vandalism and animal/rodent.

• It includes field devices and any selected edge functions, the FALCON IoT service, platform data and workflows, risk/AI functions, user access, operational controls and supporting deployment evidence.

• Milestone allocation determines when evidence is due; it does not remove an unanswered URG obligation.

• REQ-TEST-001 explicitly requires sensor testing, connectivity testing, data ingestion, AI/ML performance, alert generation, workflow execution, API functionality, security, performance and failure/recovery scenarios.

• The plan should identify cases for each category and connect them to relevant operational scenarios and SRS requirements.

• A category without a detailed requirement or test case remains a coverage gap.

Proposed methods are:

• Test: execute defined inputs and preconditions, including applicable negative, boundary, permission and recovery cases; compare observed results with agreed criteria.

• Demonstration: witness the representative operational flow and actual physical action where applicable, retaining correlated records rather than relying only on screenshots.

• Inspection: review versioned requirements, interface/schema definitions, permissions, configuration, site survey, installation/as-built records and operational procedures against their source obligations.

• Analysis: evaluate measured performance, sensing coverage, data suitability, model metrics/baselines, capacity, power and recovery evidence using a stated method and assumptions.

• Methods may be combined.

• Component tests or a visual prototype cannot substitute for the representative end-to-end flow required by REQ-TEST-002/N27.

• Simulated data and injected faults may support repeatable checks, but the evidence must label them and identify what was actually exercised.

• A simulated device response does not demonstrate physical deterrent execution.

• The current project boundary is standalone POC/Pilot operation with offline TM data imports and device interaction through the FALCON-developed IoT service.

• Do not assume live TM production access to execute tests.

• Preserve the unresolved disposition of URG enterprise-integration/initial-phase entries under Q09.

• Conditional AI/agent functions and later capabilities remain traceable until their applicability/allocation is agreed; M2/M3 evidence does not establish their completion.

4.2 Verification and Test Plan content

REQ-VER-001 requires a Verification and Test Plan. This section defines its proposed content and acceptance approach; it is not the executable test plan. The complete design-stage source mapping is in Requirements Traceability; actual results and acceptance evidence remain Not Run/not produced.

Plan content	FALCON-specific detail to record
Scope and coverage	Source/SRS revision, included requirement locators, scenario and milestone allocation, ten REQ-TEST-001 categories, applicability decisions, exclusions and unresolved dependencies.
Method, scenarios and cases	Chosen method for each obligation; actors, preconditions, inputs, steps, expected outputs/state changes, negative/failure paths and links from operational scenario to case. Specify real, replayed or simulated stimuli.
Environment and tools	Platform/IoT build and configuration, rule/model versions, selected devices/firmware/adapters, site/location, sensor placement/calibration where applicable, power/connectivity conditions, test instruments/tools and timestamp/clock basis. Record differences from the intended deployment.
Test data	TM import source/version and permitted use, record selection, expected valid/invalid/unmatched examples, device evidence, ground truth and labelling method where applicable. For model evaluation, identify the evaluation set, prediction unit/horizon, reference baseline and source ambiguities that affect interpretation.
Expected results and criteria	Observable results per case; target-register reference with values, units, measurement boundaries, workload, observation period and agreed decision rule. Preserve optional evidence and conditional source wording.
Evidence	Required records from each component and physical observation, correlation identifiers, artifact locations, result-record schema, reviewer access and applicable data-protection/retention controls.
Responsibilities	Named preparer, executor, technical reviewer, TM SRS reviewer, field/site participant and milestone acceptance authority; approval/decision references. Names and allocation To Confirm.
Defect handling and repeat verification	How to report, assess, correct and recheck defects; identify impacted requirements/configurations, regression scope, remaining exceptions and the authority for acceptance decisions. Severity definitions and acceptance rules To Confirm.

• Before field verification, link the site assessment and readiness evidence required by REQ-SITE-001/002 (URG-T44-R02/R03), with the agreed installation and commissioned-unit records.
• HW-TST-001/002 own the proposed unit/site test records; this section owns their relationship to system-wide verification.
• Safe test conditions, permitted physical actions, site access and participants remain To Confirm for the selected equipment/location.

4.3 Requirement traceability and evidence

• The traceability framework preserves 199 numbered source rows with 198 distinct literal source IDs, plus 28 narrative coverage entries.

• These are coverage inventories, not counts of answered or passed requirements.

• Each numbered row remains separately identifiable by source revision, literal TM ID, heading/title and URG-Txx-Rxx locator.

• Narrative N01–N28 are local locators, not TM IDs.

• Additional requirements use their own SRS IDs and provenance with “Not directly derived” where appropriate.

• In particular, retain both REQ-MLOP-004 rows: Model Degradation, URG-T56-R05, and Closed-Loop AI/ML, URG-T57-R05.

• Preserve literal IDs REQ-COMP003, REQ-ARCH -004, REQ-O&M-001 and REQ-O&M-002.

• Q01–Q03 govern source ambiguities; an alias must not replace or collapse the originals.

• Nested REQ-VER-002 examples, including REQ-WF-002 and REQ-API-002, are illustrations rather than additional numbered requirements (Q12).

Proposed RTM/evidence fields are:

Record group	Required mapping or proposed evidence fields
Source and response	Source revision/locator, literal ID and title, source modality/conditions; SRS IDs/section and origin; full/partial/unanswered response coverage; applicability, deviation or deferral with reason and decision reference.
Allocation and case	Milestone/component, scenario link, verification method, case ID/version, preconditions, expected result and acceptance/target reference. One source row may map to several cases; a shared case must identify the result supporting each obligation.
Execution identity	Run ID, execution date/time, executor/witness, environment/build/configuration, device/site, data/model/rule versions, tool versions and differences from the agreed setup.
Actual result and evidence	Observed result, measurements with units and stated clock basis, logs/screenshots/data extracts/analysis or physical-observation record, artifact references, and relevant event/alert/case/command/device correlation IDs.
Outcome and review	Execution status, defect/blocker reference, review result, reviewer, disposition authority/date/reference and retest evidence. Acceptance decision is recorded separately from test outcome.

• Proposed execution statuses are Not Run, In Progress, Passed, Failed and Blocked.

• “Not applicable” and “Deferred” belong to a reviewed applicability/allocation decision; neither is a passing execution result.

• Record the reason when a criterion is unagreed, a test dependency is unavailable or a result is inconclusive. Do not mark the test as passed.

• Earlier runs remain linked when corrected software/configuration is retested.

• For the field chain, evidence should connect the original observation and registered device/location through IoT receipt, platform event, rule/version and alert, any approval, the uniquely identified command, device-specific execution evidence, and the recorded response/outcome.

• The Data Dictionary distinguishes Requested, Sent, Confirmed, Failed, Expired and Unconfirmed command states; a receipt or dispatch record cannot establish device execution or threat resolution.

• Physical confirmation criteria remain device-specific and To Confirm.

4.4 Proposed M2 acceptance gate

• This is a candidate gate for TM review, based on the current M2 working checklist.
• Before using it for acceptance, agree the allocated requirement/case list, selected actual equipment, controlled location, allowed actions, device confirmation method, relevant targets, evidence and sign-off authority.
• All remain To Confirm where not already recorded as functional drafting direction.

Check group	Proposed observable result and evidence
Access and records	Representative Administrator, Operator and Viewer accounts demonstrate allowed/denied delivered actions. Offline assets and manually registered devices are distinct, linked to their locations/sites and visible on map/dashboard. Link import/registration records and permission checks to SH-ACC-001, PL-DAT-001/002, PL-GIS-001/002 and PL-DEV-001/002.
Actual-device chain	An actual detection device provides an event through the IoT service to the platform, with available evidence/status and device/location traceability. An authorised operator triggers an actual deterrent through the IoT service; record command progression and physical action/result. Distinguish this from a simulated event or UI-only interaction.
Basic live view	An actual supported camera supplies continuous on-demand live viewing through the agreed service path. Check Administrator/Operator access, Viewer denial, explicit start/stop, one camera per panel, configured inactivity termination and session audit. Saved event images/clips remain distinct.
Controlled setup and limits	Demonstrate at one controlled location while inspecting multi-site data associations. Record selected hardware/configuration, conditions, limitations, unmet criteria and follow-on allocation; review relevant component, security and failure evidence rather than relying on the happy-path demonstration alone.

Operator-triggered deterrence is sufficient for the user-confirmed M2 functional baseline; automatic detection-to-deterrent execution is not added as an M2 acceptance obligation. The HTML prototype does not satisfy actual-device evidence. M2 does not claim field-wide effectiveness, validated prediction, or completion of later pilot coverage.

4.5 Proposed M3 acceptance gate

• The proposed M3 gate extends the M2 evidence at an agreed field location using selected actual equipment and the agreed initial module functions.
• The detailed module checklist, field/site readiness, TM-data suitability, permitted action policy, numerical targets and acceptance authority remain To Confirm.
• M3 is not a substitute for the later URG pilot intent of two designated sites in two different states (N05).

Check group	Proposed observable result and evidence
Integrated field flow	Trace detection through the IoT service, validation/risk decision, configured alert/workflow, designated approval, permitted response, device result and operator-recorded outcome.
Integrated field flow	Use representative field conditions and the agreed capability; retain construction and theft/vandalism verification/allocation in the full-solution register.
Workflow controls	Cover record-only/unmatched/incomplete-input paths, retained separate detections with configured grouping, rule priorities/conflicts, maintenance prohibition, approval/rejection, pauses/expiry without withheld-command replay, cooldown and manual commands.
Workflow controls	Check decision-version history without historical replay.
Workflow controls	These verify PL-WFO-001–004 refinements; they do not introduce the rejected rule-testing product feature.
Failure and recovery	Verify service outage differs from device offline, with last-known/unverifiable status.
Failure and recovery	Exercise agreed retry/expiry/unconfirmed paths without independent platform action retries or duplicate physical execution.
Failure and recovery	For the selected buffering-capable configuration, reconnect with original timestamps and delayed-event labels; stale events do not automatically trigger actions.
Failure and recovery	Record unsupported capabilities/deviations rather than silently waiving URG obligations.
Data and risk	Reconcile valid/rejected/unmatched imports and repeat-import handling.
Data and risk	Show ranked historical risk with supporting records separately from initial future-risk prediction.
Data and risk	Evaluate prediction against the agreed dataset, horizon, baseline and metrics.
Data and risk	Insufficient TM data requires an explicit scope/acceptance decision; historical counts alone cannot pass the prediction criterion.
Operational response	Verify internal alert/acknowledgement/escalation and linked cases.
Operational response	Exercise Open, In Progress and Closed, one responsible operator, reassignment history, recorded field actions and operator closure with outcome/note; attachments remain optional.
Operational response	Field Team accounts are available in M3. Verify assigned-work access, progress/evidence submission, denied access to unrelated work, and Operator review before case closure.
Operational response	Sent/Confirmed commands and Closed cases do not automatically mean Threat addressed.
Live view, reporting and audit	Verify device/event live-view entry points, permissions, session termination/audit and separate event evidence.
Live view, reporting and audit	Reconcile site/date-filtered summaries and Excel/PDF exports with underlying records, distinguishing historical/predictive views and closure outcomes.
Live view, reporting and audit	Trace imports, configuration, approvals, commands/results, pauses, assignments and closure changes to actor/time/record audit evidence.

• Use these checks alongside the sensor, API, security, performance and failure/recovery tests in the Verification and Test Plan. They do not cover all 199 source responses.
• Model lifecycle, further threat capabilities, preventive action/resource mobilisation and the proposed M4 assistant retain their own allocation and evidence needs.

4.6 Defect disposition and acceptance ownership

The following disposition process is Proposed. No severity scale, tolerated defect count, automatic waiver or acceptance authority is established by this draft.

1. Record each defect or unresolved exception with source/SRS/case links, actual versus expected result, evidence, environment/version and impact on the intended milestone. Distinguish an implementation defect from missing data, an unagreed target, a source ambiguity or an unapproved scope deviation.
2. Propose correction and repeat verification, dependency resolution, clarification, or an explicit deviation/deferral. Record owner and intended disposition date as To Confirm until assigned. A missing device capability or failed test does not authorise changing the requirement.
3. After a change, retain the original result and link new execution evidence plus the impacted regression checks. A claim that the issue is fixed does not close the finding without verification evidence.
4. Present the milestone evidence and unresolved items to the authorised reviewer/acceptance authority. Any acceptance with outstanding items needs an explicit decision naming affected obligations, residual impact, conditions and follow-up responsibility. Unanswered proposals remain To Confirm; they are not accepted exceptions.

Responsibility	Proposed scope	Named owner / authority
Verification lead and case executors	Prepare the source-linked plan, coordinate platform/IoT/device/model cases and retain results.	To Confirm
Technical and field reviewers	Review architecture/interface, device/site, data/model and security evidence within assigned competence.	To Confirm
TM SRS reviewers	Review the requirement interpretation, source discrepancies and proposed criteria against the designated URG baseline.	To Confirm
Target agreement and exception authority	Agree applicable target conditions and decide scope deviations, applicability or deferrals within authorised scope.	To Confirm
Milestone acceptance authority	Make and record the M2/M3 acceptance decision against the agreed evidence package.	To Confirm

Review records should identify the person, role/authority, date, reviewed revision, decision and supporting evidence. Weekly Sprint Review feedback does not by itself constitute Milestone Sign-off. No deadline or named assignment is inferred from a source role label.

4.7 M5 assessment and handover verification

• Beyond the proposed M2/M3 gates, the verified delivery workbook lists M5 complete-MVP/UAT, performance/load/stress and VAPT reports with remediation/retest evidence, documentation and initial training.
• Preserve those source-listed proposed deliverables and their unresolved timing/readiness boundary in Delivery Allocation.
• Functional permission tests are part of security verification but do not by themselves establish completion of the separately listed vulnerability/penetration assessment.
• Approved scope, authorised test environment/activity, assessor and acceptance/disposition rules remain prerequisites.

4.8 Verification-plan source requirements

SRS-VER-101 — Architecture

Attribute	Specification
Status	Proposed conditional response
TM source	REQ-TEST-001; URG-T45-R02
Source modality	shall; source conditions remain applicable.

The Verification and Test Plan shall cover the applicable component and end-to-end verification categories.

Required coverage

Category	Coverage
Sensors	Range, coverage, calibration and false detections.
Connectivity	Connection, buffering and replay.
Ingestion	Valid, invalid and duplicate inputs.
AI/ML	Labelled evaluation and baseline comparison.
Alerts	Evidence sufficiency, grouping and latency.
Workflow	Priority, approval, restrictions, action and closure.
APIs	Every applicable interface contract.
Security	Authentication, authorisation and data protection.
Performance	Resource, load and response measurements.
Failure and recovery	Device, power, network, service, storage and restore failures.

Clause	Required behaviour
B01	Link every case to its source locator/literal ID and canonical SRS requirement.
B02	Record method, preconditions, environment/version, input/ground truth, steps, expected result/threshold, evidence, responsible tester and actual result/defect.
B03	Keep unknown thresholds and owners as blocked acceptance fields; do not assume a pass.
B04	Retain raw execution evidence, defects, retests and the separate acceptance decision.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect coverage in both directions between plan and SRS/RTM	Every applicable requirement and case maps to its source; omissions remain visible.
AC02	Execute approved cases with the appropriate verification methods	Raw results and evidence support the recorded outcomes; inspection, demonstration, analysis and measured tests remain identifiable.
AC03	Inspect a case with unknown threshold or owner	Acceptance remains blocked rather than assumed.

Decisions still required: Q10 and OPEN-16; see section 5.4.

SRS-VER-102 — Demonstration

Attribute	Specification
Status	Proposed conditional response
TM source	REQ-TEST-002; URG-T45-R03
Source modality	shall; source conditions remain applicable.

Demonstrate representative end-to-end flows with actual selected devices and supported data.

Clause	Required behaviour
B01	For construction, trace activity → detection → ingestion → applicable AI analysis → risk classification → alert → workflow → authorised preventive action/outcome.
B02	For animal/rodent activity, trace detection/classification → risk → alert → approved intervention/outcome.
B03	For theft/vandalism, demonstrate the corresponding detection and response chain.
B04	Identify sensor, model and Operator evidence separately at each stage.
B05	Include negative/ambiguous evidence, missing input, offline/delayed events, denied approval and failed/unconfirmed actions.
B06	Where real threats cannot ethically or safely be staged, use controlled safe stimuli or accepted recorded data and label simulation limits.
B07	Do not treat device execution or apparent retreat alone as proof of long-term prevention effectiveness.

Verification:

Criterion	Scenario / method	Expected result
AC01	Demonstrate each allocated scenario	Timestamped sensor evidence, model/rule/configuration versions and event/alert/case/command records establish the observed chain.
AC02	Review ground truth and conditions	The observed outcome is supported by ground truth and recorded environmental conditions.
AC03	Reconcile expected and observed results, including exception scenarios	Each result maps to its criterion and any defect; simulation and evidence limitations remain explicit.

Decisions still required: OPEN-02, OPEN-03, OPEN-04, OPEN-09, OPEN-16 and Q10; see section 5.4.

SRS-VER-103 — Verification Plan

Attribute	Specification
Status	Proposed response
TM source	REQ-VER-001; URG-T59-R02
Source modality	shall; source conditions remain applicable.

Prepare and submit a versioned Verification and Test Plan with measurable expected results and objective evidence.

Objective evidence

Evidence group	Records retained where appropriate
Execution	Logs, readings, API records and workflow records.
Models and configuration	Model evaluations and configuration/architecture records.
User and field observations	Screenshots/dashboards, field observations and incident records.

Clause	Required behaviour
B01	Cover verification scope/methodology, scenarios/cases, environment, data, tools, expected results, acceptance criteria, evidence, responsibilities and defect management.
B02	For each case, identify source locator/SRS link, applicable milestone, preconditions, actors/permissions, steps/stimuli, expected observable behaviour and evidence.
B03	Declare actual-device, replayed or simulated conditions. Retain test environment/build/model/rule/data versions.
B04	Cover sensor, connectivity, ingestion, AI/ML, alerts, workflow, APIs, security, performance and failure/recovery.
B05	Cover the full applicable detection-to-response/outcome/audit chain across all threat families.
B06	Use testing, demonstration, inspection, analysis and operational observation as applicable.
B07	Agree numerical criteria and authorities before interpreting a run as accepted.
B08	Record defects, dependencies and retest evidence. Missing criteria and simulated physical actions shall not become assumed passes.

Verification:

Criterion	Scenario / method	Expected result
AC01	Inspect the plan against the source	All twelve source headings, scenario/requirement coverage, assigned or explicitly pending responsibilities, measurable expected results and evidence access are addressed.
AC02	Execute representative approved cases	Actual results reconcile with expected results and retained evidence.
AC03	Review component-only and simulated tests	Component-only results do not close end-to-end obligations; simulated actions remain labelled.
AC04	Review the SRS and plan status	Draft plan requirements are not reported as completed test results.

Decisions still required: Q10 and OPEN-16; see section 5.4.

SRS-VER-104 — Requirement Traceability

Attribute	Specification
Status	Proposed response
TM source	REQ-VER-002; URG-T59-R03
Source modality	shall; source conditions remain applicable.

Maintain source-to-verification traceability without conflating response coverage, execution and acceptance.

Clause	Required behaviour
B01	Identify each source by revision, literal requirement ID, title and locator. Map every applicable requirement to verification method, test case, expected result, actual result, evidence, status and defect reference where applicable.
B02	Keep both REQ-MLOP-004 rows separate. Preserve unusual literal IDs and the Q05–Q07 conflicts.
B03	Treat nested REQ-WF-002 and REQ-API-002 as illustrations, not newly adopted source requirements.
B04	Proposed additional RTM fields distinguish SRS response coverage, applicability/conditionality, delivery allocation, test execution and authorised acceptance.
B05	Allow multiple cases per requirement. A shared case must provide an identifiable result for each supported requirement.
B06	Use Not Run, In Progress, Passed, Failed or Blocked for execution. Record approved not-applicable/deferred decisions separately; they are not passing tests.
B07	Preserve failed runs and links to retests.
B08	Include all 199 numbered rows/198 literal IDs and 28 narrative locators in coverage review. Extra requirements retain their own provenance.
B09	Treat this document as traceable draft responses, not a completed execution RTM.

Verification:

Criterion	Scenario / method	Expected result
AC01	Reconcile source and case registers	Source counts, IDs/locators and mandatory/conditional obligations match the response and case register.
AC02	Inspect executed and pending cases	Executed cases contain the seven required mappings; pending cases contain no invented actual results or evidence.
AC03	Sample shared cases, both duplicate-ID rows, an unresolved conflict, a defect/retest and an approved exception	Each relationship and disposition remains traceable without collapsing source identities or execution history.
AC04	Review acceptance reporting	Response coverage alone cannot establish acceptance.

Decisions still required: Q01–Q03, Q05–Q07, Q12, OPEN-12 and OPEN-16; see section 5.4.

4.9 Evidence and acceptance disposition

• For each executed check, record requirement and test IDs, build/configuration/model/device versions, site/dataset, approved parameters, steps, actual observations, evidence location, executor/date and result.

• Use Not Run, In Progress, Blocked, Passed or Failed for execution; use a separate approval/disposition record for acceptance.

• A documented deviation is not a passed original requirement.

• The detailed criterion following a requirement supplies its verification intent; create executable test cases with positive, denied/invalid and recovery paths where applicable.

• A proposed test reference is VT-<requirement ID> with suffixes for individual cases.

• These references are a naming convention, not evidence that test scripts exist or ran.

TM and the delivery team must agree the acceptance authority, defect severity/waiver rules, required evidence and numeric thresholds before deciding a milestone pass. Operational benefit, physical execution, model quality and software conformance need their own evidence. A deployed SRS website verifies document publication only.

5. Appendixes

5.1 Logical data dictionary

Device events

Logical field	Meaning and agreed treatment
Event ID	Identity used to distinguish a new detection from retransmission of the same event. Generation and uniqueness scope To Confirm.
Device ID	Originating registered/authorised device.
Event type	Event classification used for routing/grouping; taxonomy To Confirm.
Original event time	Time at the observation source, retained on delayed delivery; clock/timezone handling To Confirm.
Service receipt time	Time received by the IoT service, distinct from original event time.
Evidence	Available images/clips or their references, linked to the event. Format, size and retention To Confirm.
Confidence	Included only when provided by the detection source; absent confidence is not zero confidence. Scale and interpretation To Confirm.

• Initial device site/location is maintained in its registration record; per-event GPS transmission is not required.
• The platform associates events with that registered location.
• Existing PL-DEV-003 preserves deployment history and event-time coordinates on relocation; do not relink historical events to a device’s new placement.
• Exact delayed-event association rules remain To Confirm.

Retransmission of the same event shall not create duplicate event records. Genuine separate detections remain separately recorded even when they contribute to one grouped alert.

Device commands

Each command shall have a unique command ID carried through the platform and IoT service and correlated to supported device acknowledgements/results. If the device cannot echo that ID, the adapter correlation method must be defined; no unsupported device capability is assumed.

Status	Meaning
Requested	The authorised action request is recorded.
Sent	The IoT service reports the command dispatched to the device.
Confirmed	Execution is confirmed using the agreed device-specific evidence; service acceptance alone is insufficient.
Failed	A definitive delivery/execution failure is reported under the agreed failure rules.
Expired	The command is outside its permitted execution validity.
Unconfirmed	Execution could not be established from the available acknowledgement/evidence.

Status transitions, deadlines, late acknowledgements, retry interactions and detailed error codes remain To Confirm. These command statuses are distinct from case statuses Open, In Progress and Closed.

Recognising a retransmitted command shall prevent repeated physical execution of the same action. Device/adapter duplicate-execution controls must be validated before enabling the applicable automatic retry. The target behaviour does not establish exactly-once execution on every candidate device.

Proposed complete logical data model

PostgreSQL stores structured records; controlled bucket references identify files. Physical table layout, provider and database extensions remain To Confirm. Logical fields do not replace the original TM source schemas.

Identity time and validation conventions

Convention	Rule
Application identity	each persistent entity has an immutable opaque identifier.
Application identity	Preserve its original source identifier separately, with a source namespace.
Application identity	Human labels, camera names and mutable serial/display fields are not substitutes for application identity.
Application identity	UUID is a possible technical encoding, not a required version or vendor choice.
Record provenance	imported/derived records identify their source batch or producing event/model/rule, source record identifier where supplied, creation/receipt time and responsible actor/service.
Record provenance	Corrections create auditable revisions; historical references do not silently point to a different meaning.
Time	interchange instants use RFC3339 with an explicit UTC offset.
Time	Store an accepted normalised UTC instant plus the original source value/offset and clock-quality or uncertainty flag where available.
Time	Keep original observation, service receipt, platform receipt and processing times distinct.
Time	Display timezone is explicit; local rule windows use a configured site timezone.
Time	A timestamp without a known offset requires an approved source mapping, not a guessed UTC conversion.
Time	See RFC3339.
Missing values	absent confidence is unknown, not zero; absent incident impact is unknown, not no impact.
Missing values	Distinguish missing, invalid, not applicable and withheld fields.
Missing values	Preserve validation reasons and eligibility for each use.
Missing values	Display/export those distinctions rather than presenting a zero or empty-looking success.
Geometry	retain source coordinate reference system and geometry type.
Geometry	A reviewed import mapping may produce the display/analysis geometry, with transformation provenance.
Geometry	Invalid/out-of-range or ambiguous coordinates are flagged; a nearest asset is a candidate association, not automatically a confirmed match.
Geometry	Selected spatial conventions remain part of source/interface review.
Versions	retain rule, model, dataset, import-mapping and relevant configuration version references used for a result.
Versions	A newer version changes new evaluations only unless a separately authorised recalculation is explicitly requested and recorded.

Entity catalogue

Fields below are the proposed minimum logical information. Source-dependent fields may be unavailable; the validation/eligibility rules determine permitted use. Links are references, not duplicated copies of entire records.

Entity	Minimum information and relationships	Main rules and owner
Site	Site ID, name, location/zone definition, configured timezone, status, source/reference.	Multi-site data from the first increment; no invented locations. Shared by GIS/devices/operations.
TM asset	Application asset ID, source namespace/ID, asset type, source attributes, geometry/CRS, site or route association, import provenance and validation state.	Separate from FALCON device identity. PL-GIS-001; missing geometry prevents spatial calculations needing it.
FALCON device	Device ID, source/native identity, type/model when selected, supported capabilities, authorised/onboarding state, current deployment reference, latest contact/status and configuration reference.	PL-DEV-001/002; no implicit camera or command capability for every device. Secrets are protected credentials, not ordinary registry fields or exports.
Deployment	Deployment ID, device ID, asset/location/site, coordinates/CRS, effective start/end, planned destination/date where relevant, relocation reason, recorded outcome, recorder and audit reference.	PL-DEV-003: one active deployment; planning does not change current placement. Completing a move closes the previous interval and starts the new one.
Observation/event	Event ID and source identity, device, deployment/association status, type, original/receipt times, payload/schema version, available evidence/confidence, validation and delay flags.	PL-EVT-001 and earlier event fields; raw sensor observations may require selected processing before producing a classified event. Preserve both source observation and derived-event lineage where applicable.
Evidence object	Evidence ID, bucket object/version reference, media type, originating event/device/import, capture/receipt time, integrity metadata where available, access/retention class and availability state.	Store media once, link it from permitted records. Missing/deleted-by-policy media remains distinguishable from evidence never supplied; no public bucket assumption.
Import batch	Batch ID, source/file reference and content fingerprint, source namespace, mapping version, submitting Administrator, preview/application times, counts and run status.	PL-DAT-001/002; record source file/version and outcomes. Fingerprint helps repeat-file detection but does not identify duplicate real incidents by itself.
Import row/result	Batch+row locator, source key, proposed target ID/revision, accepted/rejected/unmatched disposition, validation/matching reasons and application result.	Preview changes to existing records before applying. Partial valid-row progress reconciles to counts; failures do not conceal skipped rows.
Historical incident/docket	Incident ID, source docket ID(s), event/record dates, threat/category, usable location, asset match and confidence/status, reported impact/severity if supplied, source batch and revision.	One source docket is not assumed to equal one distinct incident. Unmatched records remain available, excluded only from calculations needing the missing link.
Alert and event membership	Alert ID, type/zone/grouping-rule version, linked event IDs, risk/severity, current handling state, created/updated times, acknowledgement/routing history.	PL-EVT-002; grouping retains all event records/device identities. Exact transition proposal is in the functional response to REQ-FUNC-060–064.
Notification attempt	Notification ID, alert/workflow reference, intended internal recipient/destination, channel, requested/delivery state, attempt/error times.	Notification delivery is distinct from alert acknowledgement. M3 internal notifications first; no external channel is silently selected.
Rule version and evaluation	Rule/version ID, conditions/action references, priority, enabled/effective state, author, evaluation ID, event/input versions, result, reason and applied restrictions.	PL-WFO-001–004; historical decisions retain the applied version. Proposed fields document what was evaluated, not a new end-user rule-testing feature.
Approval and restriction	Approval ID/action target, authorised decider, decision/reason/time and validity; pause/maintenance records identify scope, creator, start/end/expiry and reason.	Rejection/pending approval cannot be interpreted as permission. A pause governs automatic actions within its scope; other restrictions remain after expiry.
Command and result	Command ID, originating action/evaluation or manual reason, device/target, action/parameter version, requester, approval/restriction references, validity, status history, adapter correlation and result evidence.	Preserve the six command states above. Each delivery attempt belongs to the same logical command; no independent platform action retry.
Case	Case ID, source alert/event/recommendation links, Open/In Progress/Closed, one responsible operator, assignment history, field-action records, closure outcome/note and optional evidence.	PL-CAS-001. Record assigned Field Team accounts separately from the responsible Operator. External responders may still be recorded by an Operator without an application account.
Case action and closure record	Case ID, action/response description, reported performer, recording user (Operator or assigned Field Team member), action/report times, outcome category/version, note and optional evidence.	Distinguish who performed an action from who entered it. Retiring a configurable outcome does not rewrite old cases.
Risk assessment/prediction	Assessment ID, type (historical or predictive), asset/location/segment and unit, assessed/prediction period, score/category, factors, source coverage, model/rule/dataset version and limitations.	PL-RSK-001; probability only when its semantics and calibration justify that label. A historical count is not a prediction.
Preventive recommendation	Recommendation ID, target location/asset, proposed action, reasons/evidence/risk, priority and rule version; operator accept/dismiss/defer decision/reason and linked follow-up case.	PL-PRV-002/003. Recommendation acceptance is not automatic physical execution.
Mobilisation/intervention	Responding team/contact, requested action, agreed mobilisation status; intervention action/date/responsible party/outcome, evidence if supplied and source links.	PL-PRV-004/005. M4–M5 split pending; no full rostering/scheduling subsystem implied.
Effectiveness review	Review ID, selected before/after periods, incident/risk measures, data coverage, interventions considered, limitations and reviewer observations.	PL-PRV-006. Different monitoring periods/exposure must be stated; association is not a causal claim.
Dataset/model/evaluation record	Dataset manifest/source/label versions and permitted use; model/version and task; evaluation method/data/metrics/baseline; deployment/monitoring/rollback references.	Existing model requirements and AI/ML response specifications. Logical records may be managed in a controlled registry/document repository; no separate MLOps product purchase is mandated.
User and permission assignment	Account ID, active/disabled state, assigned role/explicit capabilities and administrative audit.	SH-ACC-001. Five roles: Superadmin, Administrator, Operator, Field Team and Viewer. Apply section 2.2 access rules; no public registration. Secrets/tokens never enter business exports.
Audit entry	Actor/service, action, target IDs, timestamp, request/correlation ID, result and changed-version references or protected before/after details.	SH-AUD-001. Access and retention controlled; redact credentials and minimise personal content. Audit is separate from diagnostics and operational event evidence.
Live session	Session ID, actor, camera, authorisation decision, start/stop/timeout times and outcome/reason.	Viewing metadata only; no automatic continuous/manual video recording. Transport details and session limits remain selected-camera dependent.
Report/assistant output	Report ID/type, filters/period, data cutoff/version, creator/time, format and controlled output reference; assistant output also identifies sources, language and missing-information limitations.	Reports in Excel/PDF for M3; read-only on-demand assistant proposed M4. AI-summary export is not established.

Deployment and delayed-event association

• Prefer an authenticated deployment identifier where the adapter can supply it and verify that it matches the registered device.

• Otherwise use a trustworthy original event instant against the device’s deployment history.

• Proposed intervals include their start and exclude their end, so a boundary instant has one placement.

• Preserve a snapshot/reference of the historical geometry used for the event.

• If device time is unreliable, a placement interval is missing/overlapping, or source and registered deployment conflict, retain the event with association unresolved and the candidate information.

• Do not assign it to the current deployment merely because it arrived now.

• Block calculations or automatic actions that need a reliable location until resolved, while preserving other usable information.

• An authorised correction records old/new association, reason and actor; it does not erase the prior audit trail.

• Clock tolerances and who may approve a correction remain To Confirm.

Command lifecycle refinement

Proposed refinement of the existing states, subject to selected-device validation:

Current state	Permitted next observation/state	Guard and evidence
Requested	Sent, Failed or Expired	Sent requires IoT dispatch evidence; failure is definitive rejection/failure; expiry means validity elapsed before permitted dispatch.
Sent	Confirmed, Failed, Expired or Unconfirmed	Confirmed requires correlated device-specific execution evidence; elapsed waiting alone does not prove failure or success. Timeout/expiry meanings are defined per action/adapter.
Unconfirmed	Confirmed or Failed only after correlated reconciliation evidence; otherwise stays Unconfirmed	Retain prior uncertainty and receipt times. A repeated delivery is not a new logical command or evidence of execution.
Confirmed / Failed / Expired	Append late/contradictory evidence; review any correction with an audit record	No automatic new action, replay, case closure or history erasure. A late report of execution outside validity is a control exception to investigate, not normal success.

• Restrictions are evaluated before issuing an action and before retry eligibility.
• The physical device’s ability to enforce expiration, stop limits and duplicate suppression must be established; the central record cannot retroactively prevent an already dispatched physical action.
• Where safe confirmation/idempotency cannot be established, use the restricted device policy defined through verification rather than claiming exactly-once operation.

Data validation evidence

• Proposed cases cover identity collision across sources; repeat import with unchanged and changed records; missing confidence/impact/geometry; an unmatched incident with a usable location; genuine repeated detections versus retransmission; relocation boundary/late/uncertain-time events; command timeout and late acknowledgement; outcome retirement and historical report consistency.
• Expected results follow the rules above.
• Retention durations, field-size limits, allowed enumerations and source mappings require the selected TM/device data and applicable policy, and remain explicit configuration/acceptance decisions.

5.2 Recorded drafting decisions

The six latest decisions below are confirmed by the user for drafting; TM approval remains pending. Earlier recorded directions on roles, imports, IoT, commands, video, cases, reporting, preventive work and the assistant have been incorporated into their owning sections. Details added during consolidation remain Proposed.

Reference	Confirmed direction	Requirements
RWD-001	An authorised Operator may close a reviewed false alarm, duplicate or unverifiable alert without a case, with an outcome and note. Investigation, assignment or field intervention requires a case.	SRS-EVT-011/012; SRS-EVT-014 is a supporting refinement.
RWD-002	New alerts use a shared Operator queue. Acknowledgement records the Operator and time separately from case ownership.	SRS-EVT-008/009/010.
RWD-003	A linked alert displays the case’s responsible Operator; there is no separate alert assignee.	SRS-EVT-013.
RWD-004	Grouping uses a configurable fixed window starting at the first qualifying detection. Subsequent detections do not extend it.	SRS-EVT-015.
RWD-005	A new qualifying detection after closure creates a new alert and preserves closed-alert history.	SRS-EVT-016.
RWD-006	Case closure offers “Also close linked alert” and requires confirmation of the alert outcome when selected. Case closure alone does not close the alert.	SRS-EVT-017/018.

Role decisions agreed for drafting

Reference	Agreed direction	Status
ROLE-001	Add Superadmin for technical administration. Operational access requires a separately assigned role.	User agreed; TM review pending.
ROLE-002	Add Field Team accounts from M3, limited to assigned work, progress, evidence and completion submission.	User agreed; TM review pending.
ROLE-003	Operators retain case ownership, assign field work, review submitted results and close cases. Field Team completion does not close the case.	User agreed; TM review pending.

5.3 Proposed state and transition rules

This table shows details left unresolved by the six drafting decisions, separating agreed behaviour from proposed states. It does not establish TM approval of a new lifecycle.

Record and transition	Actor / trigger	Preconditions and recorded result	Authority
Alert creation	Platform, qualifying event	Record first detection, assessment/rule version and linked events; put in shared queue.	Existing drafting direction; detailed fields Proposed.
Alert acknowledgement	Authorised Operator	Record actor/time independently of case ownership; reject stale conflicting update.	RWD-002; concurrency treatment Proposed.
Alert assignment stage	Operator assigns linked case	Read responsible Operator from case; no independent alert assignee.	RWD-003; TM interpretation pending.
Alert escalation	Enabled rule or permitted Operator	Retain escalation rule/reason/recipient and time; escalation alone is neither resolution nor closure.	Proposed.
Reviewed alert → Closed without case	Authorised Operator	Outcome No threat found, Duplicate or Unable to verify; note required. No fabricated threat-resolved finding.	RWD-001; eligible source states To Confirm.
Case Open → In Progress	Responsible/permitted Operator	Record progress/action and actor/time; exact action permission and transition preconditions require review.	Three-state lifecycle confirmed for drafting; transition details Proposed.
Case Open/In Progress → Closed	Authorised Operator	Required outcome and note; attachments optional; default leaves linked alert unchanged.	Existing case direction and RWD-006.
Case closure with linked-alert closure selected	Authorised Operator	Require confirmed alert outcome and allowed alert state; retain distinct case and alert transitions. No silent partial-success message.	RWD-006; atomicity/partial-failure and cardinality To Confirm.
Closed alert + new qualifying detection	Platform	Create new alert ID; do not alter old history.	RWD-005.
Closed case/alert reopening	No default permission assumed	Reopening policy requires explicit approval; do not infer it from the presence of an edit action.	To Confirm.
Command Requested → Sent	IoT dispatch report	Preserve command ID and dispatch evidence.	Existing drafting direction.
Command Sent → Confirmed	Agreed device-specific execution evidence	Confirm the physical action under adapter semantics; no threat-resolution inference.	Existing drafting direction.
Command → Failed/Expired/Unconfirmed	Definitive failure / expiry / missing confirmation	Retain attempts and timing; show reason and prevent unsafe replay. Late acknowledgements need an agreed rule.	State meanings retained; transitions/limits To Confirm.
Device Unknown/Online/Offline	Registration/contact/timeout	Use approved thresholds and last contact; show IoT unavailability separately.	Existing drafting direction; thresholds To Confirm.

For repeated detections, the fixed grouping window is anchored at the first qualifying detection and does not slide. The treatment of exact boundaries, out-of-order delivery, uncertain clocks and competing alerts must be decided once and used in the rule engine, interface contracts and tests.

5.4 Open decisions and acceptance parameters

• A review draft can list unresolved decisions. Values still require TM or engineering agreement.
• The following decisions block the affected baseline or acceptance assessment, not the act of drafting.
• Suggested accountable roles are listed for routing only; named owners remain To Confirm.

ID	Decision required	Affected area	Suggested decision parties	Gate
OPEN-01	Agree standalone/offline scope disposition against live enterprise integration and initial-phase marks.	I-TM; source software interfaces; N06/N20	TM architecture/product and delivery lead	Scope baseline
OPEN-02	Identify Pilot sites in two states, equipment quantities, readiness and field constraints.	Field deployment, power, sensing, Pilot	TM site owner and engineering lead	Site design/installation
OPEN-03	Select devices, supported sensing/deterrent commands and physical execution/stop evidence.	IoT, active control, edge and sensors	Hardware/IoT leads and TM operations	Operational activation
OPEN-04	Agree rule priorities, action approval catalogue, maintenance/pause permissions and retry/cooldown/expiry/stale-age values.	Workflow/commands	TM operations and platform/IoT leads	Enable automatic actions
OPEN-05	Agree grouping clock, exact end boundary, late arrival and competing matches.	Events and alerts	TM operations and platform lead	Alert acceptance
OPEN-06	Agree alert source states, case/alert cardinality, combined-closure failure policy and reopening.	Events/cases/state model	TM operations and BA	Lifecycle baseline
OPEN-07	Agree input schemas, matching identities, coordinate mapping and quality/exclusion rules.	Imports, GIS and risk	TM data owners and data lead	Import/model acceptance
OPEN-08	Agree prediction objective, geographic unit, horizon, dataset suitability, baseline and pass thresholds.	Historical/predictive risk and models	TM SMEs and AI/data leads	Model acceptance
OPEN-09	Agree supported classes/conditions and order of construction versus theft/vandalism capability.	Threat detection and milestones	TM SMEs and delivery lead	Capability baseline
OPEN-10	Agree hosting, security policies, identity technology, data classes, retention and recovery targets.	Security, compliance and operations	TM security/data/architecture	Environment/acceptance approval
OPEN-11	Decide assistant applicability/allocation, LLM processing provider/region/data/retention and evaluation.	AI assistant and conditional agents	TM product, security and AI leads	AI data processing
OPEN-12	Resolve original version discrepancy, FALCON terminology, duplicate REQ-MLOP-004, missing REQ-FUNC-011 list and conflicting AI titles/descriptions.	Source register and related responses	TM requirement owner	Source interpretation baseline
OPEN-13	Agree notification recipients, escalation timing, repeat policy and any external channels.	Alerts/notifications	TM operations	Notification acceptance
OPEN-14	Agree live-view timeout, quality, transport and concurrency; no recording expansion implied.	Camera/IoT	TM operations and engineering	Video acceptance
OPEN-15	Agree report layouts, time bases, availability denominator and export limits.	Reporting	TM operational/reporting reviewers	Report acceptance
OPEN-16	Name SRS owner/reviewers/signatories, milestone authority, waiver rules and handover responsibilities.	Governance/acceptance	TM sponsor and delivery lead	Baseline/sign-off
OPEN-17	Agree lifecycle-cost horizon, costing basis/currency/tax, selected service tiers, supplier terms, allowances and exit obligations. No purchase is authorised.	Cost evaluation and delivery	TM commercial/technical reviewers and delivery lead; named authority To Confirm	Cost/design review

Source clarification register

All Q01–Q14 items below remain To Confirm and sit under the applicable OPEN decision above. No clarification is treated as an amendment to the TM source.

Ref	Affected source	Observation	Required clarification or treatment
Q01	REQ-MLOP-004	Two different rows use this ID: Model Degradation and Closed-Loop AI/ML.	Confirm the intended distinct identifiers; retain both source rows using section, title and locator.
Q02	REQ-COMP003; REQ-ARCH -004; REQ-O&M-001; REQ-O&M-002	ID syntax differs from the common pattern.	Retain literal IDs; ask whether TM intends editorial corrections before changing aliases.
Q03	3.5.14; 3.6.6; 4.2	These section numbers each occur for different headings.	Always include heading text and table locator. Confirm corrected numbering in the next TM revision.
Q04	REQ-FUNC-011	Description ends at “At minimum, the solution shall support:” with no following list.	Confirm the intended categories; do not silently complete the source using other rows.
Q05	REQ-AIML-003	Title says Additional Sensors; description specifies AI/ML performance evaluation.	Propose mapping by description to model evaluation and request title confirmation.
Q06	REQ-MLDM-004	Title says Training, Validation and Test Data; description repeats REQ-AIML-004 Baseline Comparison.	Confirm whether data split/leakage controls were intended, or whether both obligations apply.
Q07	REQ-MLGRL-005	Title says Human Approval; description repeats REQ-MLDM-005 Data Representativeness.	Retain both meanings as an unresolved conflict. Human approval remains independently covered by REQ-FUNC-072 and REQ-WFO-003.
Q08	Source cover and Document Control	Cover states Version 1.0 / Release 0.1; control table says version 0.1 and contains approval placeholders.	Confirm the source revision label and formal approval state. User has designated this file as the baseline regardless of its draft label.
Q09	2.6 Apportioning of Requirements; 1.3 TM Production Environment and POC Environment	Initial-phase marks include enterprise integration, knowledge retrieval, AI Agent and advanced predictive models; glossary describes isolated POC/Pilot without TM production integration unless agreed.	Confirm actual interface boundaries and release allocation. Do not silently defer marked capabilities or commit production integration.
Q10	3.3; REQ-PERF-001 to 004; REQ-AVAIL-001; REQ-REL-003; REQ-SENS-003; REQ-AIML-003	Several measurable targets and test conditions are left for POC or agreement.	Agree target-setting owner and stage; record numeric criteria and representative load/environment before acceptance.
Q11	REQ-SITE-001; REQ-TEST-001; REQ-REL-003	Generic titles Architecture or Data Protection obscure site assessment, test planning or recovery content.	Map using description; confirm editorial titles without altering the source extract.
Q12	REQ-VER-002 nested example table	Examples include REQ-WF-002 and REQ-API-002, which are not requirement-row IDs in the source.	Treat example rows as illustrations, not new requirements. Request correct cross-references.
Q13	1.4 Document Overview; section 5 reference	The document describes appendixes in section 5, but no section 5 heading is present in the extracted body.	Confirm whether appendixes or referenced architecture/data artifacts are supplied separately.
Q14	REQ-SEC, REQ-COMP, REQ-INTSW, REQ-CCP and 2.5	Policies, source access, data samples, hosting approval and some external interfaces depend on TM inputs.	Request applicable policy versions, named data/system owners, sample data, approved environment and access arrangements.

Numerical parameters

• No numeric performance or acceptance values are assigned here.
• Each entry needs its value/unit, applicable requirement and milestone, workload/site/dataset, measurement method, acceptance decision rule, named owner/reviewer, agreement date and source reference. All values and named owners in this register are To Confirm. The proposed timing is before the relevant acceptance test is judged; exploratory POC measurements may inform the agreement but are not automatically acceptance criteria.

Parameter ref	Target or condition	Source / owning requirement	Definition still required
PAR-01	Event processing time	REQ-PERF-001, URG-T25-R02; SH-PER-001	Start/end measurement points, event/evidence mix, arrival load, target and treatment of delayed events. Source target is TBD during POC.
PAR-02	Alert latency	REQ-PERF-002, URG-T25-R03; SH-PER-001	Measure from receipt of sufficient evidence to classify the event, as stated by URG; define that boundary, destination, load and target. Do not silently substitute original observation time.
PAR-03	Monitored capacity and dashboard response	REQ-PERF-003/004, URG-T25-R04/R05; SH-PER-001	Locations/devices/assets, event/data volumes, users, dashboard actions and normal operating conditions; capacity and response targets.
PAR-04	Availability and recovery	REQ-AVAIL-001/002, URG-T28-R02/R03; REQ-REL-001–003, URG-T27-R02–R04; SH-REL-001	Operational/measurement period, maintenance-window treatment where applicable, failure scope, recovery time and permitted data loss.
PAR-05	Sensor coverage and detection	REQ-SENS-002/003/005, URG-T33-R03/R04/R06	Designated risk area, range, field of view, sensitivity, detection frequency, sampling, accuracy and false-positive/false-negative characteristics where applicable; environmental and calibration conditions.
PAR-06	Model performance and improvement	REQ-AIML-003/004, URG-T51-R04/R05; PL-RSK-001	Applicable POC/Pilot minimums, reference baseline, dataset/ground truth, prediction horizon/unit and measurable improvement. Classification-based prediction must report Precision, Recall and F1 Score as well as overall Accuracy; other listed metrics apply where appropriate.
PAR-07	Model degradation threshold	REQ-MLOP-004, Model Degradation, URG-T56-R05	Monitoring period/data, material-degradation threshold and alert/notification test. Keep separate from conditional closed-loop REQ-MLOP-004, URG-T57-R05.
PAR-08	Workflow and alert timing	PL-WFO-001–004; PL-EVT-001/002	Grouping window/zone, rule time basis, cooldown, pause duration, permitted event age, approval/notification/escalation timing and boundary behaviour.
PAR-09	Commands and connectivity recovery	Interface Contracts; HW-CON-001/002; PL-DEV-002	Retry attempts/intervals, command expiry/confirmation timeout, offline/service thresholds, buffering capacity and overflow/reconnect conditions, device-specific duplicate-execution controls.
PAR-10	Live-view quality and sessions	Interface Contracts; HW-SEN-001; SH-ACC-001/SH-AUD-001	Resolution/frame rate, latency/bandwidth, concurrent streams/users and inactivity definition/timeout. One camera per panel is an initial presentation constraint, not a system-wide concurrency target.
PAR-11	Power and sustained operation	HW-PWR-001/002; HW-TST-001	Preserve the existing confirmed overnight-operation requirement; agree duration, duty cycle, workload, initial battery/power condition, site environment and interruption behaviour. Do not infer a fixed number of hours or select solar by this register.
PAR-12	Retention, backup and reporting scale	SH-REL-001; SH-AUD-001; PL-RPT-001; REQ-COMP-004, URG-T30-R05	Retention by data/evidence class, backup scope/frequency and restoration data; report time basis, volume/download limits and device-availability calculation.

OPEN-12 includes AI title/description conflicts. Retain the unresolved wording when designing evaluation; do not treat REQ-MLDM-004 as an agreed data-split policy or REQ-MLGRL-005 as a resolved human-approval specification. Independently stated approval obligations still apply. Applicable TM policies and data/hosting approvals remain dependencies under OPEN-10.

Detailed review questions

These questions preserve unresolved details from the requirements and author review. They do not add approved scope. Every entry is To Confirm; named owners, review outcomes and agreement dates remain to be recorded. OPEN references identify the parent topic where available; PAR references identify shared numerical conditions.

Detail ref	Requirement / review context	Question or agreement to record
DET-001	SH-ACC-001 — Role and action permissions	Confirm the remaining To confirm entries in section 2.2, including downloads, audit access and Administrator operational permissions.
DET-002	SRS-ACC-001 — Suspend access	Agree active-session revocation timing.
DET-003	SRS-ACC-101 — Authentication	Agree identity integration, TM security requirements, session expiry/revocation and service credentials. TM SSO access is not assumed.
DET-004	SRS-ACC-103 — Data Access	Agree the active-session policy for role changes and revocation.
DET-005	SRS-DAT-102 — Multi-Source Data Ingestion	Confirm supplied sources, approved mappings and retention; source candidates do not establish approval.
DET-006	SRS-DAT-103 — Data Correlation	Agree mapping profiles and the distinct-incident rule for multiple dockets.
DET-007	SRS-DAT-106 — Additional Data Sources	Approve any connected production integration and the relevant source profile.
DET-008	SRS-GIS-102 — Fibre Network Visualisation	Agree coordinate reference system, map provider and display of positional uncertainty.
DET-009	SRS-GIS-103 — Fibre Proximity Assessment	Agree coordinate system, spatial method and measurement tolerance; no alarm-distance threshold is presumed.
DET-010	SRS-GIS-105 — Hotspot Identification	Agree spatial grouping, recurrence criterion and distinct-incident policy.
DET-011	SRS-GIS-109 — Geographical View	Agree basemap licensing, coordinate system and any spatial extension such as PostGIS. No distance threshold is presumed agreed.
DET-012	SRS-DEV-101 — Device Identification	Confirm registration and relocation authority in the final role matrix.
DET-013	SRS-DEV-102 — Device Health	Agree freshness interval and contact timeout.
DET-014	SRS-DEV-103 — Loss of Connectivity	Offline deterrence remains To Confirm; buffering support does not establish offline deterrence.
DET-015	SRS-DEV-109 — Full Diagnostics	Agree diagnostic retention policy.
DET-016	PL-RSK-001 — Explainable risk priorities	Agree the prediction evaluation dataset, horizon and baseline.
DET-017	SRS-RSK-101 — Risk Identification	Agree method, weights and thresholds after inspecting TM data; provisional factors do not establish final values.
DET-018	SRS-RSK-102 — Risk Classification	TM must supply the missing minimum category list. The interim taxonomy is a proposed interpretation, not a correction to REQ-FUNC-011.
DET-019	SRS-RSK-103 — Risk Level	Agree assessment unit, factors, missing-data rules, level labels, threshold equality behaviour and validation examples with TM.
DET-020	SRS-RSK-104 — Rodent Risk Identification	Agree and validate elevated-risk factors and thresholds during POC.
DET-021	SRS-RSK-105 — Preventive Alert	Confirm threshold comparison and grouping configuration; agree the specific M3 automatic action policy.
DET-022	SRS-RSK-106 — Fibre Fault Risk Prediction	Agree target, horizon, spatial unit, factors, output interpretation, refresh trigger and acceptance measures. No predictive acceptance claim precedes agreed measures/results.
DET-023	SRS-RSK-108 — Prediction Confidence	Define confidence interpretation and validation in the model specification; no universal scale or calibration target is assumed.
DET-024	SRS-RSK-109 — Risk Scoring	Agree weights, bands and thresholds after examining TM files; current factors are provisional.
DET-025	PL-WFO-002 — Rule conditions	Agree availability and semantics of site/device and detection-confidence conditions before treating those refinements as accepted scope.
DET-026	PL-WFO-003 — Manual automatic and hybrid execution	Action policy remains To Confirm.
DET-027	PL-WFO-004 — Traceable response sequence	Detailed workflow lifecycle remains To Confirm.
DET-028	SRS-WFO-102 — Automated Workflow	For the selected device/action agree safe operating conditions, designated approval need, command expiry, cooldown scope/start/reset, retry eligibility/limits, pause bounds and physical confirmation. Offline deterrence remains To Confirm pending device selection.
DET-029	SRS-EVT-006 — Cross-device alert grouping	Exact grouping boundary, late-arrival and competing-alert rules remain in section 5.3.
DET-030	SRS-EVT-017 — Optional linked-alert closure	Combined case/alert closure transaction policy remains To Confirm; this requirement does not prescribe atomicity.
DET-031	SRS-EVT-101 — Threat Classification	Detailed subcategories, whether one record can carry multiple families, and correction permissions remain To Confirm.
DET-032	SRS-EVT-111 — Alert Lifecycle	The proposed transition table in section 5.3 supplies the review baseline; allowed source states, combined-closure transaction policy and exceptional reopening remain To Confirm.
DET-033	SRS-EVT-112 — Duplicate Events	Event-time membership is a proposal pending clock and late-arrival agreement. Exact window-end inclusion, competing matches and events that occurred before closure but arrived afterwards remain To Confirm.
DET-034	SRS-EVT-113 — Escalation	Specify timer start/pause/stop rules, business-time versus elapsed-time behavior, severity criteria, permitted manual escalation and each recipient before activation. Numerical thresholds and role assignments remain To Confirm.
DET-035	SRS-EVT-114 — Incident History	Retention and backup/recovery values remain To Confirm, and evidence may become unavailable only under an approved policy with that limitation visible.
DET-036	SRS-DET-003 — Stop and fault response	Device-specific operating limits remain To Confirm.
DET-037	PL-CAS-003 — Case states	Reopening and automatic-closure policy remain To Confirm.
DET-038	PL-PRV-001 — Additional detailed work planning	Adoption, scope and allocation of this additional detailed-planning proposal remain To Confirm.
DET-039	SRS-PRV-101 — Resource Mobilisation	Confirm which basic states/fields arrive in M4 versus M5, eligible responding parties, contact handling and any approved communication channel.
DET-040	PL-RPT-001 — Operational summaries and exports	The measures remain subject to agreement.
DET-041	SRS-RPT-101 — Trend Analysis	Selectable time buckets are proposed and need to suit the available history.
DET-042	SRS-RPT-102 — Operational Reporting	Confirm the availability denominator; treatment of unknown, offline and service-outage states; response-time boundaries; template layouts; download permissions and volume limits. Report metadata remains a proposed detail.
DET-043	SRS-RPT-103 — Threat Reporting	The disclosure treatment for non-additive groupings is proposed.
DET-044	SRS-RPT-104 — Management View	Agree the prevention evidence definition, incident counting rule, comparison periods, monitoring coverage and emerging-threat criteria. Initial management measures remain proposed.
DET-045	SRS-AUD-101 — Audit Trail	Agree the critical-action policy for logging failures. The application permission controls are proposed.
DET-046	SRS-AUD-104 — Auditability	Agree the retention/hold policy.
DET-047	SRS-AUD-106 — Audit Trail	Agree retention policy and approve any protected-input reproducibility limitations or retained snapshots.
DET-048	PL-AST-003 — English and Bahasa Malaysia	Evaluation dataset and quality thresholds are To Confirm.
DET-049	PL-AST-006 — LLM API failure isolation	LLM provider selection and processing approval remain unresolved, together with the module-level region, retention and evaluation decisions.
DET-050	SRS-MED-004 — Retention and preservation	Agree the data-class retention schedules and preservation restrictions before accepting expiry behaviour.
DET-051	SRS-NTF-002 — Escalation execution	Agree the qualifying states, timer basis, recipients, priorities and stop conditions for enabled rules.
DET-052	SRS-CFG-002 — Parameter change validation	Agree numerical defaults and applicable parameter validation rules.
DET-053	I-IMPORT; SRS-INT-101/105/106	OPEN-07 / Q14 — Import accepted formats, encoding, maximum size/rows, matching keys, source permissions and accepted/rejected/unmatched code list after TM profiling.
DET-054	I-OBS/I-HEALTH/I-CMD/I-RESULT	OPEN-03 / Commands and connectivity recovery — Selected broker/protocol version/topics/QoS remain unselected; qualify native identity, sequence/clock, command correlation, duplicate control and physical execution evidence.
DET-055	I-OBS/I-HEALTH/I-CMD/I-RESULT	OPEN-03 / Commands and connectivity recovery — Record buffering capacity, overflow/drop and recovery behaviour.
DET-056	Interface safety boundary; SRS-INT-103	OPEN-04 / Commands and connectivity recovery — Agree command expiry, stop behaviour, cooldown, permitted event age, confirmation timeout and bounded retry/backoff; selected-device safety review governs further action after unconfirmed/late result.
DET-057	Interface acceptance; SRS-INT-104–107	OPEN-07 / OPEN-16 — Release exact technical endpoints/topics/payloads, named owners, schema compatibility/deprecation and adapter limits before integration readiness; logical SRS contracts do not select these designs.
DET-058	Protected interface paths; SRS-SEC-101	OPEN-10 / Q14 — Approve encryption profiles, key custody/rotation, residency and data classification against TM policy before operational-data deployment; choose credential provisioning/revocation and identity provider.
DET-059	I-MEDIA/I-LIVE	OPEN-10 / OPEN-14 — Agree media provider/upload mechanisms, formats/integrity/retention, retrieval/link mechanism and expiry; choose live transport, quality, bandwidth, inactivity and concurrency values.
DET-060	I-AI; SRS-SEC-109	OPEN-11 — Approve provider/model, data classes, permitted purposes, processing region/retention, provider-training use, TM processing approval, cost and evaluation before external operational-data use.
DET-061	I-REPORT	OPEN-15 / Retention, backup and reporting scale — Agree report layouts, export access, row/size limits and synchronous/asynchronous execution.
DET-062	SRS-PER-105/106	Q10 / Monitored capacity and dashboard response — Agree expanded site/device/source profiles, resource/cost triggers and tier boundaries; record synthetic representativeness, currency/rate basis, BOM/service rates and uncertainty.
DET-063	SRS-MNT-101/102	OPEN-10 / OPEN-16 / Availability and recovery — Agree maintenance emergency exception/approval process, windows and overrun treatment; retain runbook ownership, supported-version/license and spare/replacement constraints.
DET-064	MD-PRED-003/006; SRS-PRD-101/102/107; SRS-MLD-108	OPEN-08 / Model performance and improvement — Training reproducibility tolerance; scoring schedule/triggers; input missing-value/imputation and eligibility policy; explanation availability/release policy; frozen split protocol and small-data limitations; label adjudication, outcome availability and no-event ground truth.
DET-065	SRS-PRD-108/113/114; SRS-MLD-104	OPEN-08 / Model degradation threshold — Drift reference profiles, review windows, material-change criteria, sample sufficiency, labelled monitoring cohorts and notification review rules; distinguish drift from verified degradation.
DET-066	SRS-PRD-111/112/116/117	OPEN-10 / OPEN-16 — Model release authority, change window, handling of in-flight work, retained compatible rollback packages and fallback/retirement evidence.
DET-067	SRS-PRD-111/115/116/119	OPEN-11 / OPEN-08 — Hosted or closed-model retraining alternative, available revision pinning and previous-version fallback; explicit TM disposition for any unmet retraining or rollback obligation.
DET-068	SRS-PRD-109	OPEN-04 / OPEN-08 — Workflow-specific corroboration applicability; sufficiency of contextual history versus contemporaneous evidence; correlation and freshness requirements.
DET-069	SRS-MLD-102/103	OPEN-09 — Supported theft/access scenario evidence, supplied authorised-work context, coordinated-activity correlation and classification-correction permissions.
DET-070	SRS-ARC-113; SRS-DEL-101; REQ-COST-001/003	OPEN-17 — Agree lifecycle-cost evaluation horizon, costing basis/currency/tax, selected subscription/service tiers and current supplier terms, including unknown pricing/allowances and exit obligations.
DET-071	SRS-ARC-113; SRS-DEL-101; REQ-COST-001/003	OPEN-17 — The SRS authorises no purchase or subscription.
DET-072	SRS-DEL-102; REQ-DEPL-001	OPEN-16 / Q09 — Resolve inconsistent source milestone dates across workbook tabs and name the authoritative approved schedule; reconcile older Case/Preventive deferrals with current user-confirmed M3 cases/M4 preventive direction without treating them as TM approval.
DET-073	Source-listed M5 performance/load/stress/VAPT deliverables in 3.5.11	OPEN-10 / OPEN-16 / PAR-03 — Agree authorised assessment environment/targets, scope, method, assessor/independence if applicable, permitted activity, data handling, disruption limits, severity/disposition rules and audience; retain numeric load/acceptance thresholds and TM sign-off authority as unagreed.
DET-074	Source-listed M5 performance/load/stress/VAPT deliverables in 3.5.11	OPEN-10 / OPEN-16 / PAR-03 — No paid assessor, certification or test authorisation is implied.
DET-075	SRS-PWR-104; REQ-PEM-004	OPEN-03 / OPEN-04 / PAR-11 — Confirm critical-device designation and device/site safe behaviour during brownout and power restoration.
DET-076	Account and role administration; SRS-ACC-001/101/102	Agree who provisions Superadmin accounts, which account types each administrator can manage, who grants additional roles, and the review required for privileged role changes.

5.5 Glossary

• This section preserves the designated URG’s table 6 definitions and usage.

• The identical original DOCX was rechecked on 9 October 2026 MYT; source identity is in Source and Research Register.

• Repeated FCAPS is consolidated into one entry because both expansions are identical and both usages concern applicable infrastructure/solution management.

• No TM terminology correction is inferred.

• The source expands FALCON differently in section 1.2 (“Fibre Analytic Cognitive solutioNs”) and table 6 (“Fibre Analytics, Learning and Cognitive Operations Network”).

• This draft uses the neutral name FALCON and retains the table definition below; the formal expansion is To Confirm .

• “Asset” is broad in the source; the implementation-facing logical model distinguishes TM infrastructure assets from FALCON device records without narrowing the source concept.

Source definitions

Term	Definition	Source interpretation and usage
AI	Artificial Intelligence	Refers to computational techniques that enable the solution to perform tasks such as analysis, prediction, classification, reasoning or decision support.
AI/ML	Artificial Intelligence / Machine Learning	Used collectively to refer to AI and machine learning capabilities incorporated into the FALCON solution.
API	Application Programming Interface	A defined interface that enables systems, applications or services to exchange data and invoke functions.
Asset	A physical or logical resource that is monitored, managed or associated with the solution	May include fibre infrastructure, network assets, sensors, IoT devices, locations and other relevant resources.
Alert	A notification generated when a defined condition, event, risk or threshold is detected	Used to notify relevant users or systems of potential or actual fibre-related threats or incidents.
AI Agent	A software component capable of interpreting information, reasoning over defined objectives, retrieving information and/or invoking authorised tools or actions	Where proposed, AI agents may support operational analysis, recommendations and controlled workflow execution.
CFSB	Cradle Fund Sdn Bhd	Refers to Cradle Fund Sdn Bhd, the programme partner for the BIG initiative.
Dashboard	A visual interface that presents operational information, status, alerts, trends and other relevant data	Used for centralised monitoring and decision support.
Data Pipeline	A sequence of processes used to acquire, validate, transform, enrich, process and store data	Used to support data ingestion and preparation for analytics and AI/ML processing.
ETL	Extract, Transform, Load	A data processing approach for extracting data from sources, transforming it into a required format and loading it into a target system or repository.
FCAPS	Fault, Configuration, Accounting, Performance and Security	Refers to the functional areas used for management and monitoring of applicable solution components.
FALCON	Fibre Analytics, Learning and Cognitive Operations Network	Refers to the proposed solution/initiative for predictive and proactive fibre fault prevention and mitigation.
Fibre Fault	A condition affecting fibre infrastructure that results in, or may result in, degradation or interruption of service	Includes actual faults and potential threats that may lead to fibre damage or service disruption.
GIS	Geographic Information System	A system used to capture, manage, analyse and visualise geographically referenced information.
HITL	Human-in-the-Loop	An operational approach in which human review, approval or intervention is incorporated into an automated or AI-assisted process.
IoT	Internet of Things	Refers to connected physical devices, sensors and equipment used to collect, transmit or process operational data.
KPI	Key Performance Indicator	A measurable indicator used to assess the performance or effectiveness of the solution or a defined operational process.
MLOps	Machine Learning Operations	Practices and processes for deploying, monitoring, maintaining, versioning and managing machine learning models throughout their lifecycle.
Model	A computational representation developed using data to perform a defined analytical or predictive task	In this SRS, generally refers to an AI/ML model used for detection, prediction, classification or risk assessment.
NFR	Non-Functional Requirement	A requirement specifying a quality attribute, constraint or performance characteristic of the solution rather than a specific business function.
POC	Proof of Concept	A controlled implementation used to demonstrate technical feasibility and validate defined solution capabilities before Pilot deployment.
Pilot	A controlled deployment of the solution in designated operational locations to validate its capabilities under representative conditions	For FALCON, the Pilot is intended to cover two designated sites located in two different states.
Predictive Analytics	The use of historical and current data, statistical methods and/or machine learning to estimate future events, conditions or risks	Used to identify potential fibre threats or faults before they occur.
RAG	Retrieval-Augmented Generation	An AI approach that retrieves relevant information from defined knowledge sources to support generation of responses or recommendations.
Risk Assessment	A process of evaluating the likelihood and potential impact of a threat or event	Used to determine the level of risk associated with potential fibre damage or service disruption.
SRS	Software Requirements Specification	The document defining the functional, non-functional, technical, AI/ML, compliance and other requirements of the FALCON solution.
UI	User Interface	The interface through which users interact with and access the solution’s functions and information.
Workflow	A defined sequence of activities, decisions and actions performed to achieve a specific operational outcome	Used for alert handling, escalation, preventive action, mitigation and other operational processes.
Workflow Orchestration	The coordination and execution of multiple activities, systems, users and services according to a defined workflow	Used to automate and coordinate operational responses to identified risks or events.
Threat	A condition, activity or event that has the potential to cause damage to fibre infrastructure or disrupt services	FALCON primarily considers construction activities, theft/vandalism and animal/rodent activities.
Construction Activity	Construction, excavation, infrastructure or civil works that may cause physical damage to fibre infrastructure	Includes excavation, drainage works, road works, heavy vehicle activity and other relevant activities.
Theft / Vandalism	Unauthorised removal, interference with or intentional damage to fibre infrastructure or associated assets	Includes cable theft, manhole/cabinet tampering and deliberate or opportunistic damage.
Animal / Rodent Activity	Animal or rodent activity that may cause damage to fibre infrastructure	Includes recurring animal-related or rodent-related damage, particularly at identified hotspots.
Hotspot	A geographical or operational area exhibiting a relatively high concentration or recurrence of defined events, faults or risks	Used to identify locations requiring enhanced monitoring or preventive intervention.
Preventive Action	An action taken in advance to reduce the likelihood or impact of a potential fibre fault	May include notification, mobilisation, physical intervention, reinforcement or other approved mitigation measures.
Mitigation Action	An action taken to reduce the impact or consequences of an identified or occurring threat or incident	May be initiated through automated or human-approved workflows.
Guardrail	A control mechanism that limits, conditions or prevents an AI/ML prediction or recommendation from resulting in an unauthorised or inappropriate action	May consider confidence, data quality, risk severity, business rules and human approval requirements.
Human Approval	Explicit authorisation by an authorised user before a defined action is executed	Used for operational actions designated as requiring human intervention.
Model Drift	A change in data or operational conditions that causes an AI/ML model’s performance to deteriorate over time	Used in the context of AI/ML model monitoring and lifecycle management.
Model Retraining	The process of updating or rebuilding an AI/ML model using new or updated data	Used to maintain model performance when required by monitoring or operational conditions.
Model Version	A uniquely identifiable version of an AI/ML model and its associated configuration	Used for traceability, deployment control, monitoring and rollback.
Closed-Loop Workflow	A workflow in which an event or prediction initiates an action and the resulting outcome is subsequently monitored and recorded	Used to demonstrate the complete detection-to-action-to-outcome lifecycle.
End-to-End (E2E)	Covering all relevant stages of a process from its initial trigger through to its final outcome	Used for end-to-end data, workflow and operational verification.
Centralised Management	Management and monitoring of distributed solution components through a common platform or interface	Used for monitoring multiple sites, devices and operational activities from a central location.
Remote Operations	The ability to monitor, configure, administer or manage applicable solution components without requiring physical presence at the deployment site	Used particularly for geographically distributed field devices and sites.
Scalability	The ability of the solution to accommodate increases in sites, assets, sensors, users, data volume or processing requirements	Used when considering expansion beyond the initial POC/Pilot deployment.
Portability	The ability to deploy or replicate the solution, or relevant components, across additional locations or supported environments without fundamental redesign	Used to assess the solution’s suitability for wider deployment.
Interoperability	The ability of different systems, applications, devices or services to exchange and use information effectively	Used particularly for APIs, external systems, IoT devices and future TM integration.
Lifecycle	The complete period from solution design and deployment through operation, maintenance, upgrades and eventual replacement or retirement	Used when assessing maintainability, cost, hardware and change management.
TM	Telekom Malaysia Berhad	Refers to Telekom Malaysia Berhad, the organisation commissioning the FALCON solution.
TM Production Environment	TM’s operational environment supporting live production systems and services	The POC and Pilot are intended to operate in an isolated environment and do not require integration with TM production systems unless otherwise agreed.
RFI	Request for Information	A formal request used to obtain information from potential solution providers during the information-gathering or market-engagement stage.
RFP	Request for Proposal	A formal procurement document inviting proposers to submit technical and commercial proposals against defined requirements.
SLA	Service Level Agreement	An agreed level of service performance, availability or support between relevant parties.
POC Environment	The isolated technical environment established for demonstrating and validating the POC	Used to validate technical feasibility without integration into TM’s production systems.

Project operational terms

These are proposed clarifying definitions for consistent SRS interpretation, not corrections to TM wording.

Term	Meaning in this draft
Observation	Source measurement or captured indication; it may require validation/processing before a classified event exists.
Event	Individually retained detection/occurrence record with source identity and time. Grouping does not remove it.
Grouped alert	Handling record linking qualifying events under the configured event-type, zone and time-window rules.
Notification	Delivery attempt informing a recipient about an alert/work item; it is separate from alert acknowledgement.
Case	Operator-managed investigation/assignment/response record with Open, In Progress and Closed states.
Command	One uniquely identified request for a permitted device action, with status/evidence independent of case outcome.
Confirmed command	Execution supported by agreed device-specific evidence; it does not establish that a threat was resolved.
Deployment	Time-bounded placement of a device at an asset/location, preserved through relocation.
Unmatched incident	Imported incident retained without a confirmed asset association; usable location/data can remain available.
Historical risk indicator	Assessment of past incident/activity evidence for a stated unit/period.
Prediction	Estimate of a future target/outcome over a stated horizon, evaluated separately from historical summaries.
Draft response	Proposed SRS answer to a source obligation, including any conditional/deviation/clarification treatment. It is not a test result.
Review complete	All designated source rows/narrative entries have a reviewable response and decisions are recorded; this does not establish TM approval.
Acceptance	An explicit authorised decision for identified requirements/deliverables and evidence, distinct from a passed test or attended demonstration.

Shall, should and may retain the source meanings: mandatory, recommended and optional respectively. Source applicability/feasibility qualifiers remain attached to their obligations. Proposed local refinements are labelled and decision-logged; they do not retroactively change a source modality.

5.6 Traceability and source records

The active coverage record is the current mapping. Every numbered source row maps to a unique source-response requirement; supporting local and detailed requirements retain their own IDs and provenance. The complete original source text remains in the TM requirement extract (internal reference) and TM Word baseline (internal reference).

The Decision Log (internal reference) records user agreements. The Review Register (internal reference) tracks unresolved reviews. The previous RTM and previous full draft remain historical comparison material; they do not govern this edition’s test results.

5.7 Narrative source responses

N01–N28 are source locators for narrative obligations, not invented numbered TM requirement IDs. The response below is part of this review draft. Allocation exceptions and conditional capabilities retain their stated disposition.

N01 Document identity and approval

Attribute	Specification
Source	Cover and tables1–3, Document Control, Revision History and Approval Record.
Disposition	Proposed response; source version/approval unresolved.

Response:

Item	Proposed response / constraint
R01	Document Control identifies the active SRS, source hash, review revision and separate source/SRS approval states.
R02	Preserve the cover1.0/release0.1/control0.1 discrepancy under Q08.
R03	Original placeholder names/signatures are not approvals.
R04	Record actual named authority, reviewed revision, decision and date only when supplied.

Verification:

Reference	Method	Review check
VN-N01	inspection	reconcile the source identity/hash and control fields; confirm no placeholder is promoted to a name or approved state.

N02 Purpose and full-solution scope

Attribute	Specification
Source	Sections1.1–1.2.
Disposition	Proposed response; targets pending.

Response:

Item	Proposed response / constraint
R01	Scope defines fibre-fault prevention/mitigation and restoration-cost objectives, the intended lifecycle audiences and full software/data/security/AI/operations coverage.
R02	Separate technical capability measures from operational/cost benefit.
R03	Report limitations where cost baseline or comparable data is absent; do not promise an unsupported reduction percentage.

Verification:

Reference	Method	Review check
VN-N02	inspection/analysis	match stated objectives and boundaries to all domains, and check that each success measure has a proposed data/evaluation method.

N03 Eleven in-scope domains

Attribute	Specification
Source	Section1.2/table4.
Disposition	Proposed response with integration/AI decisions pending.

Response:

Item	Proposed response / constraint
R01	Scope explicitly answers core intelligence/workflow/visualisation, user interfaces/APIs, systems/integration, data, AI/ML/agents/RAG, security, operations, verification, data scouting, governance and asset protection/mobility/inventory.
R02	The owning module requirements and shared sections specify the behaviour.
R03	Live TM access and conditional agent scope have explicit dispositions rather than silent omission.

Verification:

Reference	Method	Review check
VN-N03	inspection	trace every table4 domain to a response and verify that a missing deployment dependency is not treated as a scope deletion.

N04 Exclusions

Attribute	Specification
Source	Section1.2/table5.
Disposition	Proposed response.

Response:

Item	Proposed response / constraint
R01	Retain legal/prosecution action and financial reconciliation/fraud-misconduct investigation exclusions.
R02	Operational evidence and cost/effectiveness reporting do not authorise prosecution or financial investigation.
R03	The blank third row is not filled with an invented exclusion.

Verification:

Reference	Method	Review check
VN-N04	inspection	compare exclusions with source and check related theft/reporting/diagram interpretations for contradiction.

N05 Pilot locations

Attribute	Specification
Source	Section1.3/table6 Pilot definition.
Disposition	Proposed response; sites/criteria pending.

Response:

Item	Proposed response / constraint
R01	Retain pilot intent of two designated sites in two different states.
R02	M2’s controlled location and M3’s integrated field demonstration are earlier increments, not substitutes for pilot coverage.
R03	Site identity, readiness, equipment quantities and the operating/assessment period require agreement and survey evidence.

Verification:

Reference	Method	Review check
VN-N05	inspection/demonstration	the pilot plan and eventual as-built/test records identify both approved sites/states and criteria; earlier demonstrations are labelled by their actual scope.

N06 Isolated POC and production boundary

Attribute	Specification
Source	Section1.3/table6 TM Production Environment and POC Environment definitions.
Disposition	Proposed deviation pending TM.

Response:

Item	Proposed response / constraint
R01	Use the standalone POC/Pilot and FALCON-developed IoT service; accept TM exports offline.
R02	Live production integration is excluded from the proposed delivery boundary.
R03	Preserve table10’s initial enterprise-integration mark and numbered interface obligations as an explicit Q09 proposed deviation/interpretation for TM.
R04	No modification to live network infrastructure is assumed.

Verification:

Reference	Method	Review check
VN-N06	inspection/interface tests	demonstrate documented field/offline paths and review the unimplemented production interface disposition. Do not mark live integration passed from a file import.

N07 Glossary

Attribute	Specification
Source	Section1.3/table6.
Disposition	Proposed response; terminology correction pending.

Response:

Item	Proposed response / constraint
R01	Glossary preserves all55 distinct source terms, consolidates duplicate FCAPS and labels local operational definitions separately.
R02	Retain the different FALCON expansions in section1.2/table6 as a terminology question.
R03	Source Asset includes a broad resource class; the logical data model still separates TM assets and FALCON devices.

Verification:

Reference	Method	Review check
VN-N07	inspection	compare each original term/definition and confirm no changed formal expansion.

N08 Normative language and controlled change

Attribute	Specification
Source	Section1.4.
Disposition	Proposed response.

Response:

Item	Proposed response / constraint
R01	Preserve shall/should/may and source qualifiers.
R02	Existing PL/HW/SH/MD/FE IDs remain immutable.
R03	Locator-based response sections retain every literal TM ID and source identity, including anomalies.
R04	Record material change rationale/impact on data/interfaces/allocation/tests and the decision authority; draft proposals are separated from approved changes.

Verification:

Reference	Method	Review check
VN-N08	inspection	audit source modality and IDs, check each material new choice has a review decision, and sample cross-artifact impact linkage.

N09 Enterprise context and closed-loop operation

Attribute	Specification
Source	Section2.1 Solution Perspective and Scenarios.
Disposition	Proposed response with Q09 integration disposition.

Response:

Item	Proposed response / constraint
R01	System Context maps source/data, processing, intelligence, workflow/integration, user interaction and governance responsibilities onto the lightweight FALCON application/IoT/analytics boundaries.
R02	Keep Data → Intelligence → Decision → Action → Monitoring → Feedback traceability without requiring every event to execute an action.
R03	Reuse approved enterprise capability where practical, while preserving the current isolated boundary and future integration decision.

Verification:

Reference	Method	Review check
VN-N09	architecture inspection/end-to-end demonstration	trace the relevant observation to decision/action/outcome and audit, including record-only/uncertain paths.

N10 Three threat scenarios

Attribute	Specification
Source	Section2.1/table7.
Disposition	Proposed response; Capability2/3 order and evaluation conditions pending.

Response:

Item	Proposed response / constraint
R01	Operational Scenarios and functional responses retain construction (oversized vehicles/drainage/excavation), animal/rodent (monkey drop-fibre and recurring rodent damage), and theft/vandalism (manhole/cable damage, mistaken copper theft and coordinated activity).
R02	Define supported observable criteria with SMEs and selected sensing; example motives/impacts are not machine-proven facts.
R03	No source example selects an algorithm, species list, external authority or deterrent.

Verification:

Reference	Method	Review check
VN-N10	scenario inspection/test/demonstration	represent each agreed scenario and its non-threat/uncertain conditions; document untested variants explicitly.

N11 Acquisition scouting and lineage

Attribute	Specification
Source	Section2.2.1.
Disposition	Proposed response.

Response:

Item	Proposed response / constraint
R01	Data Integration responses and the Data Dictionary specify source discovery/permission, relevance/quality, approved intake, validation/transformation/enrichment, consolidation and lineage.
R02	Reviewed offline TM files and actual-device data are initial paths.
R03	Structured and applicable unstructured sources receive source-specific mapping; no blanket integration with every potential system is committed.
R04	Invalid/unmatched data remains visible with use-specific eligibility.

Verification:

Reference	Method	Review check
VN-N11	inspection/import tests	reconcile source inventory, permitted-use records and lineage; use mixed valid/invalid/unmatched/repeated imports.

N12 Intelligence and analytics

Attribute	Specification
Source	Section2.2.2.
Disposition	Proposed response with conditional assistant/timing.

Response:

Item	Proposed response / constraint
R01	Distinguish descriptive/historical views, prediction, classification/anomaly/risk identification and recommendations.
R02	M3 future-risk prediction needs its own target/horizon/baseline/evaluation; history alone does not satisfy it.
R03	Where AI/ML is used, provide versioned evaluation, monitoring, governance and oversight.
R04	Knowledge-grounded responses are handled by the separately proposed M4 assistant, subject to allocation reconciliation.

Verification:

Reference	Method	Review check
VN-N12	analysis/test	compare known historical and future-risk results; inspect model/data evidence and verify the assistant’s source/uncertainty controls if adopted.

N13 Conditional agent capabilities

Attribute	Specification
Source	Section2.2.3.
Disposition	Proposed conditional response; Q09 allocation/action scope pending.

Response:

Item	Proposed response / constraint
R01	Initial assistant proposal retrieves permitted FALCON records and generates read-only recommendations/summaries; it cannot mutate cases/rules or command devices.
R02	The source may permit broader agents where applicable, including approved tools/authorised tasks/escalation.
R03	Retain those capabilities as a scope decision, not silently classify them as unrelated extras.
R04	Any later action-capable agent needs an explicit tool/action catalogue, identity/permissions, approval/guardrails, failure limits and audit before activation.

Verification:

Reference	Method	Review check
VN-N13	permission/adversarial tests and inspection	initial assistant cannot execute operational writes, even when retrieved text requests them. Evaluate broader actions only if expressly adopted with an approved boundary.

N14 Workflow orchestration

Attribute	Specification
Source	Section2.2.4.
Disposition	Proposed response; action policies/parameters pending.

Response:

Item	Proposed response / constraint
R01	PL-WFO and functional responses define event triggers, conditional/manual/automatic/hybrid execution, status, approvals, exceptions and escalation.
R02	Parallel or sequential activities may be composed where a use case requires them; a general graphical workflow-designer product is not implied.
R03	Platform owns business policy; IoT service owns bounded device delivery, with outcomes linked to cases/interventions.

Verification:

Reference	Method	Review check
VN-N14	workflow tests	trace applicable task order/dependencies, approval/rejection, conflict/maintenance/pause, retry exhaustion and outcome/audit records.

N15 User interaction and decision support

Attribute	Specification
Source	Section2.2.5.
Disposition	Proposed response; conversational allocation pending.

Response:

Item	Proposed response / constraint
R01	Provide role-appropriate dashboards/maps, searchable records, alerts, recommendations, task/approval and reports.
R02	Conversational/search/knowledge interfaces apply through the read-only M4 proposal rather than becoming necessary for ordinary operations.
R03	Display freshness, missing data and distinction between factual records and interpretations.
R04	English/Bahasa Malaysia is agreed for assistant outputs, not automatic whole-application localisation.

Verification:

Reference	Method	Review check
VN-N15	UI/API tests	exercise permitted/denied actions, no-data/stale/error conditions and supporting-record navigation; test both assistant languages if adopted.

N16 Monitoring and feedback

Attribute	Specification
Source	Section2.2.6.
Disposition	Proposed response.

Response:

Item	Proposed response / constraint
R01	Monitor service/device health, workflow completion/failure, data quality, model performance and usage/operational measures.
R02	Link diagnostic signals to actionable review without conflating telemetry with audit evidence.
R03	Retain user/field outcome feedback and corrective-action history; a new label/model release follows controlled evaluation rather than automatic unreviewed learning from any closed case.

Verification:

Reference	Method	Review check
VN-N16	failure injection/analysis	produce a stale device, failed workflow, quality anomaly and model-monitoring condition; inspect visibility, correlation and follow-up evidence.

N17 Technical security AI and operational constraints

Attribute	Specification
Source	Section2.3.
Disposition	Proposed response with policy/hosting dependencies.

Response:

Item	Proposed response / constraint
R01	Use approved hosting/standards and practical enterprise reuse where applicable; enforce role/privilege boundaries, protected storage/transmission, approved authentication and audit.
R02	AI outputs cannot bypass authorisation or required human validation; uncertainty/unsupported requests are handled explicitly.
R03	Operate within available support/infrastructure and consider interface availability/performance/maintenance.
R04	Process/system changes require appropriate approval.
R05	Applicable policy versions, hosting and operational limits remain explicit dependencies under Q14.

Verification:

Reference	Method	Review check
VN-N17	inspection/security/failure tests	check policy-to-control mapping, permitted interfaces, role denials, protected data and AI guardrails; record missing policy approvals as unresolved.

N18 Seven user classes

Attribute	Specification
Source	Section2.4/table8.
Disposition	Proposed response.

Response:

Item	Proposed response / constraint
R01	Map the seven TM user classes to the five application roles or review duties. Technical administration belongs to Superadmin; field updates belong to assigned Field Team members.
R02	Job titles do not confer privileges; named people and acceptance authority remain To Confirm.
R03	Field Team members report assigned work directly from M3. Operators review the results and close cases.

Verification:

Reference	Method	Review check
VN-N18	inspection/permission tests	all seven classes have an interaction/responsibility treatment and least-needed permissions; no unapproved new role/site restriction is assumed.

N19 Assumptions and dependencies

Attribute	Specification
Source	Section2.5/table9.
Disposition	Proposed response; external inputs pending.

Response:

Item	Proposed response / constraint
R01	Scope and Delivery identify system/API owners, TM data, platform capacity/hosting, security approval, SMEs and AI services, with required inputs and impact/mitigation.
R02	Source role labels remain categories until named assignments are accepted.
R03	Unavailable source data, device capability or security clearance triggers a documented scope/acceptance decision rather than silent substitution or unauthorised access.

Verification:

Reference	Method	Review check
VN-N19	inspection	each dependency has impact, mitigation, needed evidence and a named-owner field explicitly pending or sourced. Confirm no source role is mistaken for an assigned person.

N20 Initial and future requirement allocation

Attribute	Specification
Source	Section2.6/table10.
Disposition	Proposed deviation/conditional allocation pending TM.

Response:

Item	Proposed response / constraint
R01	Delivery Allocation reproduces all nine initial and three future/deferred areas with their source marks and proposed local treatment.
R02	Do not hide enterprise integration, knowledge retrieval, AI Agent or advanced prediction because they differ from the current staged scope.
R03	The “Full vs Focused predictive model based on areas” future wording is retained pending interpretation.
R04	Dates and release commitments depend on the separately identified workbook conflicts and TM decisions.

Verification:

Reference	Method	Review check
VN-N20	inspection	compare every original table10 row/mark and proposed disposition; no initial-marked area is silently dropped or claimed delivered.

N21 Requirement registry and complete coverage

Attribute	Specification
Source	Section3 preamble and3.0.
Disposition	Proposed response.

Response:

Item	Proposed response / constraint
R01	The canonical requirements and RTM cover199 numbered rows/198 literal IDs plus28 narrative entries, preserving duplicate IDs through locators.
R02	Requirements support the three threat families through sensing/data/AI/workflow/human intervention and prevention/response.
R03	Old scaffold counts or prototype screens are not evidence of source compliance.

Verification:

Reference	Method	Review check
VN-N21	automated identity/count/link checks plus semantic review	each source locator appears once in the response catalogue and once in the RTM; each has a proposed verification record and honest disposition.

N22 External interface boundaries

Attribute	Specification
Source	Section3.1 and introductory hardware/software lists.
Disposition	Proposed response with selected-adapter detail pending.

Response:

Item	Proposed response / constraint
R01	Interface Contracts identify direction, selected protocol family, logical data/version/authentication/error semantics and dependencies.
R02	Candidate hardware/software lists require relevance/capability/approval assessment rather than an obligation to integrate every named technology.
R03	No underlying TM network change is assumed.
R04	Field communication is IoT-mediated; imports and assistant API are separate interfaces.

Verification:

Reference	Method	Review check
VN-N22	interface inspection/test	catalogue every adopted interface, review excluded/conditional candidates, and trace each source/software access approval; verify no direct-device bypass.

N23 Measurable quality attributes

Attribute	Specification
Source	Section3.3 preamble.
Disposition	Proposed response; numerical agreement pending Q10.

Response:

Item	Proposed response / constraint
R01	Verification defines the measurable-target register for latency, capacity, availability/recovery, sensing/model quality, workflow timing, video and other applicable conditions.
R02	Record units, boundaries, workload/site/dataset, observation period and decision rule.
R03	Values may be established during POC as the source permits; acceptance cannot be fabricated by choosing a favorable observed value after the fact.

Verification:

Reference	Method	Review check
VN-N23	inspection/measurement	every applicable quality test identifies its agreed criterion or explicit blocker, with no assumed zero/default/pass.

N24 Architecture narrative and prospective diagram

Attribute	Specification
Source	Section3.5.1 and embedded prospective architecture image.
Disposition	Proposed response; selected topology pending.

Response:

Item	Proposed response / constraint
R01	System Context and technical responses map the source’s field/connectivity/edge/platform/AI/application/workflow layers and data-to-action-to-feedback flow onto FALCON’s proposed components.
R02	Preserve its architecture purpose without interpreting illustrative drones, external authorities, hourly cadence or history labels as adopted commitments.
R03	Final topology and technology justification follow selected data/device/site assessment and recorded decisions.

Verification:

Reference	Method	Review check
VN-N24	architecture inspection	each applicable logical layer/component and flow has a responsibility and requirement link; compare diagram examples against adopted scope and recorded exceptions.

N25 Hardware necessity and lifecycle

Attribute	Specification
Source	Section3.5.2 preamble.
Disposition	Proposed response; equipment selection pending.

Response:

Item	Proposed response / constraint
R01	Technical responses require each selected field component to be justified by monitored risk, coverage, operational value, reliability, serviceability, power/security/environment and lifecycle cost.
R02	Survey existing capabilities and lower-hardware alternatives; do not treat a prior Jetson/solar/roller/drone candidate as mandatory.
R03	Include failure/replacement, updates, maintenance/calibration and eventual retirement in evidence.

Verification:

Reference	Method	Review check
VN-N25	design/cost inspection and field qualification	each BOM item has rationale, alternatives and lifecycle/support assumptions linked to the site/use case.

N26 AI methods and guardrails

Attribute	Specification
Source	Section3.6 and3.6.3 preambles.
Disposition	Proposed response with applicability/criteria pending.

Response:

Item	Proposed response / constraint
R01	Select and justify the detection/prediction method against task/data/field constraints and an appropriate baseline; no algorithm is mandated without TM direction.
R02	AI/ML responses specify data-to-decision-to-action-to-outcome traceability, data-quality/confidence/risk/approval guardrails and model governance.
R03	Initial read-only assistant remains bounded; operational model deployment and physical action require their own authorisation.

Verification:

Reference	Method	Review check
VN-N26	model analysis/guardrail tests	compare task-appropriate baselines, uncertainty/invalid input, human approval, monitoring and feedback; retain source modality and Q05–Q07 conflicts.

N27 Objective evidence and end-to-end verification

Attribute	Specification
Source	Section4.1 and4.2/table58.
Disposition	Proposed response; execution/acceptance pending.

Response:

Item	Proposed response / constraint
R01	Verification and the design-stage RTM require mandatory-obligation traceability to verification activities, objective evidence and complete operational flow beyond component tests.
R02	Evidence may include test results, logs, screenshots, dashboards, readings, API responses, workflow/model/configuration/architecture records, demonstrations, field observations and incident records as relevant.
R03	Representative conditions and actual-device evidence are required where the claim concerns physical operation.
R04	Current planned cases are Not Run, not passed demonstrations.

Verification:

Reference	Method	Review check
VN-N27	inspection plus eventual end-to-end demonstration	sample source-to-case-to-result-to-evidence links and trace detection through response/outcome/audit, including negative/failure paths.

N28 Authoring checklist and baseline readiness

Attribute	Specification
Source	SRS Authoring & Review Checklist and table60.
Disposition	Proposed response; baseline approval pending.

Response:

Item	Proposed response / constraint
R01	Document Control and the review decision register cover the review topics listed below.
R02	A comprehensive review draft is not formally baselined while essential targets, authority, source interpretations or exceptions remain unresolved.
R03	Record any acceptance of residual issues explicitly rather than leaving a checkbox ambiguous.

Baseline review topics

Topic	Coverage
Scope and sources	Scope/boundary; immutable source references; exclusions.
Requirement quality	Testability/traceability; functional/NFR separation; interfaces.
Controls and change	Security/observability/compliance; installation/change.
Delivery	Component/release allocation; dependency owners; stable artifacts.
Verification	Evidence and ownership.
AI	Model lifecycle and agent boundaries.

Verification:

Reference	Method	Review check
VN-N28	structured baseline review	inspect each checklist topic and record result/open decision against the exact SRS revision. No approval inferred from this drafting exercise.