Integrated visitor and park operations platform
Verdara consolidates ticketing, events, maintenance, safety, commerce, sustainability and governance for large public parks onto a single data model. It is delivered as a visitor mobile application, a public web portal and an offline-capable staff field application, with documented APIs on every module.
All modules read and write through the same core services. No module holds a private copy of identity, location, workflow or master data.
Who it is for
Four groups usually take part in the decision to buy a park platform. Each one worries about different things and sees something different on day one.
Vendor landscape
Park authorities often assemble this capability set from several separate products. The table below describes what each category typically covers.
| Capability | Ticketing and admission systems | Recreation management software | Enterprise asset management | GIS platforms | Visitor mobile apps | Verdara module set |
|---|---|---|---|---|---|---|
| Timed-entry ticketing and gate validation | Core scope | Add-on or integration | Outside typical scope | Outside typical scope | Outside typical scope | Core scope |
| Visitor application and wayfinding | Add-on or integration | Outside typical scope | Outside typical scope | Add-on or integration | Core scope | Core scope |
| Event, venue and programme management | Add-on or integration | Core scope | Outside typical scope | Outside typical scope | Outside typical scope | Core scope |
| Asset register with GIS location | Outside typical scope | Outside typical scope | Core scope | Core scope | Outside typical scope | Core scope |
| Preventive and corrective work orders | Outside typical scope | Add-on or integration | Core scope | Outside typical scope | Outside typical scope | Core scope |
| Offline field operation | Add-on or integration | Outside typical scope | Add-on or integration | Add-on or integration | Add-on or integration | Core scope |
| Incident intake, dispatch and escalation | Outside typical scope | Outside typical scope | Add-on or integration | Add-on or integration | Outside typical scope | Core scope |
| Vendor contracts and SLA measurement | Outside typical scope | Outside typical scope | Add-on or integration | Outside typical scope | Outside typical scope | Core scope |
| Sustainability and utility reporting | Outside typical scope | Outside typical scope | Add-on or integration | Add-on or integration | Outside typical scope | Core scope |
| Single reporting layer across all of the above | Usually separate reports per system | Core scope | ||||
How to read the table. Core scope means the category is built mainly for that capability. Add-on or integration means it is usually sold as an extra module or reached through a connection to another product. Outside typical scope means it is not usually part of the category.
Categories described. Ticketing and admission systems, recreation management software, enterprise asset management, GIS platforms and visitor mobile apps. The last column shows what the Verdara module set covers.
This table is a general description, not a scored review of named products. Scope varies by vendor and edition. This table describes categories, not named products.
Scope reflects standard product capability rather than custom development. Categories are often sold as separate products. Integration between categories is usually possible and is often budgeted as a separate line item.
Functional scope
Seven modules share one identity layer, one map, one workflow engine and one data model. Phase I delivers the visitor-facing ecosystem and the incident channel. Phase II adds operational, commercial and sustainability depth on the same architecture.
How to read this page: each capability shows its delivery status.
The visitor-facing surface: a native application for Android and iOS, a progressive web app for visitors who do not install, and the public portal that shares the same backend.
Geo-referenced layers covering zones, attractions, toilets, drinking water, first aid, food outlets, gates and parking. Search, filtering and walking directions from the visitor's current position. Accessible routes are identified separately for wheelchair users and elderly visitors.
Entry and experience tickets are sold online and at counters, each issued as a unique QR code. Capacity is configurable per time slot. Gate validation runs on handheld or fixed scanners, operates offline and synchronises when connectivity returns.
Season and annual passes, group and school bookings, concessional categories and free categories. All tickets and passes are held in an offline wallet inside the application.
AR overlays and narrated audio at cultural zones, replica monuments and heritage installations. Content is triggered by location or by scanning a marker at the attraction, and is available for offline download.
English and Hindi at launch. Further regional languages are configured through the content model without a code release. Visitor-facing text, notifications and guide content use a translation-ready structure.
Geo-tagged submissions with photographs are routed to the team responsible for the relevant zone. Each submission receives a ticket number with status tracking, escalation timers and a closure notification to the visitor.
Operating hours, announcements, zone-level crowd status, weather and air quality advisories, and the day's event schedule. Push notifications cover bookings, event reminders and safety alerts.
Screen reader support, scalable text and high-contrast mode in the applications. Developed against WCAG 2.1 AA and, for Indian government deployments, GIGW 3.0. Accessibility testing is one of the test types in the client-approved test plan, and the results are shared with the client.
Self-service ticket kiosks and staffed counter point of sale work on the same time slots and QR codes as online sales.
Visitors join a waitlist for a sold-out slot. When a place is released, it goes to the next visitor in line.
Park staff update tours, trails and notices through the portal without a code release.
Scheduling, approval and delivery of every programme the park hosts, from a daily yoga session to a multi-day festival.
A single calendar of all events across all venues and lawns, visible to staff and, once published, to the public. Venue records hold capacity, facilities and availability. Conflict checks prevent double booking.
External organisers submit booking requests through the portal with supporting document upload, and track application status without contacting the park office.
Organiser request, department review, management approval and publication. Steps and approvers are configured rather than coded. Every approval and amendment is recorded in the audit trail.
Approved events publish to the application and portal with ticketing or registration enabled according to the event configuration.
Festivals, fairs, marathons, exhibitions, cultural performances and special events. Per-event ticket categories, capacity limits, entry QR codes and gate validation. Participant registration supports bib and entry numbers for sporting events.
Scheduling for school tours, guided walks, yoga sessions and cultural programmes, with group booking for schools and institutions and allocation of guides.
Volunteer registration, shift scheduling, attendance recording and recognition tracking.
Membership tiers, renewals, digital membership cards in the application wallet, and member benefits applied at ticketing and at vendor points of sale.
Day-to-day running of the park, worked primarily through the staff field application. Core field workflows are offline-capable.
One master record per physical asset, covering built-up areas, restaurants and kiosks, park inventory, lighting, pumps, toilets, bridges, signage, rides and other installations. Each record holds GIS location, specifications, photographs, installation date, warranty, AMC vendor and maintenance history.
Physical QR tags on assets open the corresponding record directly from the field application, removing manual asset code entry.
Preventive schedules are defined by asset type and frequency and generate work orders automatically. Corrective work orders are raised by staff, by visitor complaints or by incident records. Every work order carries a priority, assignee, target completion time and escalation rule.
Work orders are delivered to the assignee's device with asset details and the applicable SOP. Geo-fencing restricts job start and closure to the asset's location boundary. Before and after photographs are mandatory, time-stamped and geo-tagged. Closure requires supervisor verification.
Every maintenance contract is registered with scope, period, value and SLA terms. Response and resolution times are measured automatically against SLA, with renewal alerts and vendor performance scorecards.
Cleaning rosters by zone and shift with checklist-based rounds, QR check-in at each facility with photographic proof, and visitor cleanliness ratings captured at toilet blocks. Reporting is available by zone, shift and facility.
Plant and tree inventory by zone with species, planting date and health status. Irrigation schedules, pruning, fertilisation and replacement records. Seasonal planting plans and nursery stock tracking.
Usage is recorded against each job, producing cost per asset and cost per zone as standard reports.
Checklist rounds against the client's applicable standard, with photographs, findings and corrective work orders, built on the existing inspection engine.
A single intake and dispatch channel for every incident type, from lost property to medical emergencies.
Visitors report through a one-tap SOS or a categorised report in the application. Staff report through the field application. Control room operators log telephone calls. All three routes create records in the same queue, capturing category, severity, location, photograph or video and reporter details.
Incidents are logged and classified by category and severity. The nearest responders and the quick response team vehicle are alerted by push notification, SMS and messaging. Responders acknowledge and update status from the scene. Unacknowledged or overdue incidents escalate automatically. Resolution is recorded with notes and evidence, and closure is reviewed by the shift supervisor.
Alerts and metadata from the park's existing VMS, such as intrusion, crowding or loitering events, are ingested as incidents with the camera reference and a snapshot attached. Cameras and the VMS remain the client's systems.
Pre-recorded and live announcements are triggered to one zone, several zones or the whole park. Emergency templates are maintained for evacuation, weather and missing person alerts.
Register of found items with photograph and location, visitor claims through the application, and matching and handover records. The missing person workflow links incident management with public address in a single action.
Live incident map, open incidents by severity, response and resolution times, and hotspot analysis by zone and time of day.
A large-screen live view of incidents, crowd status and open work orders for the control room.
Vendor administration and revenue accounting, built on the payment infrastructure established for ticketing in Phase I.
Online application for food stalls, kiosks, experience operators and service vendors. Compliance documents are uploaded and verified, including food safety licence, tax registration, insurance and police verification of staff. Expiry alerts are issued and vendors with lapsed documents are flagged automatically.
Contract and licence register recording term, fee structure, location allotted and conditions, with renewal reminders, digital acceptance and renewal history.
Payment gateway integration covering ticketing, vendor POS and all commercial transactions, with UPI, cards, net banking and wallets. Daily settlement and reconciliation reports. Licence fee and revenue share collection from vendors.
Pricing for paid experiences such as boating, skywalks and guided tours is configured by day, time slot, season, visitor category or demand. Authorised staff make price changes without a code release, and every change is written to the audit log.
Footfall-to-revenue ratios and variance flags, including tickets sold measured against gate scans, surfaced as exceptions in the daily report.
Inventory of advertising sites, digital advertisement slots in the application and portal, and event sponsorship packages, each with booking, contract, billing and revenue tracking.
Revenue by zone, attraction, vendor, channel and period, with comparison against the prior period and the same period in the previous year.
Rules are configured per ticket type and per event and applied consistently across counter, application and portal, with automatic reconciliation.
Environmental performance reporting against prescribed norms. Data is captured through meter readings, staff entry on the field application and automated feeds from existing meters and systems where available.
Volume treated, quality parameters, treated water reused for irrigation, and compliance status against prescribed norms.
Waste generated by zone and type, segregation audits with photographic checklists, and collection and disposal records against each contractor.
Solar energy generated, grid energy offset and estimated carbon offset, reported against targets.
Water quality readings, water levels, and cleaning and treatment activity logs raised through the same work order engine used by operations.
Water and power consumption by zone and facility, with anomaly alerts for unusual consumption patterns.
Dashboards present trends, targets and exceptions, and export in the formats the client already submits to regulators.
Documented APIs allow real-time sensor feeds, smart meters and IoT gateways to be connected in a later phase without re-architecture.
Canopy coverage by zone, species diversity, survival rate on new plantation and estimated sequestration, derived from the horticulture inventory maintained by the operations module.
The management layer for park leadership and the client authority, including the reporting required for statutory and internal governance.
A distinct dashboard per management level carrying footfall, revenue, incidents, maintenance backlog, cleanliness and sustainability indicators, with drill-down to the underlying record.
Standard operating procedures are published to the staff applications against the task they relate to, under version control.
Role-based training modules for park staff with completion tracking and refresher reminders, reportable at audit.
Inspection checklists, findings, corrective actions and closure tracking, with each finding linked to the asset, zone or vendor concerned.
All park contractors and vendors in a single register, with SLA performance measured by the platform from recorded response and resolution times.
Operating and capital expenditure against budget, by head and by zone, reconciled against the work orders and purchases that generated it.
Staff and contractor worker master records, roles, shift rosters, attendance and training records. Payroll remains in the client's existing system.
Scheduled and on-demand reports in the client's prescribed formats, generated from live data with an audit trail behind every figure.
Planned: a condition grade for each asset, rolled up into a replacement and budget view by zone.
Contracts, permits and SOP acknowledgements with a signature trail.
Shared spatial layer
Visitor navigation, the asset register, work order geo-fencing, incident location and horticulture inventory all reference one set of geo-referenced layers. Toggle the layers below to see what sits on the shared base map.
Illustrative screen. Layer symbology, zone definitions and attribute schema are set during the data setup stage against the client's own GIS data.
Cross-module workflow
A worked example of a single record moving through four modules. No step requires re-entry of data captured at an earlier step.
A drinking water unit is not dispensing. The visitor submits one photograph through the application. Location is captured automatically.
GIS places the submission inside Zone C and matches the nearest asset record, which already carries warranty, AMC vendor and service history.
The workflow engine creates a corrective work order at priority P2, assigns the Zone C plumbing crew, sets the target completion time and attaches the SOP for that asset type.
The technician starts the job inside the geo-fence, records the spare consumed, and uploads before and after photographs that are time-stamped and geo-tagged.
The shift supervisor verifies the closure. The visitor receives a closure notification against the ticket number issued when the report was submitted.
Response and resolution times post to the AMC vendor's SLA scorecard. The spare cost posts to the Zone C budget line. Both appear in the next governance report without manual compilation.
Zone C, Rose Garden walk. Raised from grievance GRV-8820.
Checklist 7 of 9 complete. QR check-in recorded 12:10.
Next due today 17:00. 212 trees on this schedule.
Staff field application. Core workflows operate without connectivity and synchronise on return.
Outcomes
Each outcome comes from the worked example above. No figures are quoted here, because results depend on each park's starting point.
The visitor report, the asset, the work order, the evidence and the vendor score stay linked as one record. Nobody types the same details twice.
Each job closes with before and after photographs that are time-stamped and geo-tagged. A supervisor verifies the closure before the visitor is told.
Response and resolution times post to the vendor's scorecard as the work happens. Nobody builds the report by hand.
Response times and spare costs reach the governance report from the same records, so every figure can be traced back to its source.
Extended capabilities
These capabilities share the same data model. Each card shows whether it is a scoped extension, can be demonstrated, or is on the roadmap.
How to read this page: each capability shows its delivery status.
Planned capability. People counters, camera analytics and gate scans are intended to resolve into a single density figure per zone, to drive slot capacity, cleaning frequency, patrol allocation and the crowd status shown to visitors.
Planned capability. Failure patterns from work order history, asset age and run hours are intended to adjust preventive schedules. Models would be trained on the client's own maintenance history.
Canopy coverage, species diversity, survival rate on new plantation and condition grading, maintained on the same tree records used by the horticulture team.
Trails are held as managed assets with surface, grade, length, difficulty and closure state. A closure recorded by operations removes the route from visitor navigation immediately.
Barrier control at parking gates, live bay availability in the application, EV charging bays, and tracking of shuttles and battery-operated vehicles inside the park.
Number-plate recognition (Roadmap) Reading number plates at parking gates is planned and is not yet available.
In-park ordering with counter collection. Vendor point of sale, order queue and the park's revenue share settle through the same ledger as ticketing.
Filming, photography, drone, research and community use permits are applied for online, routed through the events approval engine, and visible to gate staff on the day.
Adoption of trees, benches, flowerbeds or animals, with plaque records, renewal cycles, receipts and a reporting view for corporate donors.
Class and course registration, coaching batches, court and pitch booking, waitlists and refunds, for parks that also operate a sports and recreation calendar.
Each park runs as its own tenant under one authority console. Each tenant keeps its own zones, assets, vendors, content and branding, and the console reports across the estate.
Planned capability. Operational questions could be asked in plain language against the reporting store, with responses that cite the underlying records and respect the user's role-based access.
Ticket delivery, slot reminders, safety alerts and a multilingual assistant delivered over SMS and messaging platforms for visitors who do not install the application.
Air quality and heat index by zone, automatic advisory banners in the application, and triggers that open drinking water and shade points or relocate scheduled events.
Step-free and shade-aware routing, sensory-friendly hours, accessible toilet and parking availability, and assistance requests raised in advance of arrival.
Documented APIs on every module, with an optional public data view of footfall, green cover and service levels published at the client's discretion.
Cycles, boats, pavilions and equipment can be offered for booking, with scheduling, deposits and return checks.
Vouchers, gift cards and loyalty rewards extend the membership programme in the Events module.
Core platform
Identity, workflow, spatial services, the data model, notifications and offline synchronisation are implemented once and consumed by every module. This is what allows a record created in one module to be read in another, and what makes a second park a configuration exercise.
| System | Direction | Modules served |
|---|---|---|
| Video management system Alert and metadata ingestion as incident records with camera reference and snapshot. Cameras and the VMS are not supplied. | Inbound | Safety |
| Public address system Zone, multi-zone and park-wide announcements with emergency templates. | Outbound | Safety, Events |
| Payment gateway Ticketing, vendor point of sale and commercial transactions, with refunds and settlement data. | Bidirectional | Visitor, Events, Commerce |
| SMS and messaging services One-time passwords, confirmations, responder alerts and visitor communication through the notification service. | Outbound | All modules |
Each integration is built against documented APIs, tested in isolation, and its test report submitted to the client before user acceptance testing. Further integrations identified in the approved requirement specification are implemented on the same terms. The client provides system access, API documentation and vendor cooperation.
| Area | Status |
|---|---|
| GIS (open formats and ArcGIS-based setups) Geo-referenced layers and attributes exchanged with the client's own GIS data. | Scoped extension |
| Finance and ERP Budget and cost postings exchanged with the client's finance system. Full accounting stays in the client's systems. | Scoped extension |
| HR and payroll Staff and contractor records exchanged with the client's HR system. Payroll remains in the client's existing system. | Scoped extension |
| Single sign-on providers Staff sign in through the client's identity provider. | Configured |
| Sensors and IoT gateways Real-time sensor feeds, smart meters and IoT gateways connect through the documented APIs. | Scoped extension |
| BI and data export Reports and data leave the reporting store through documented APIs, and in the formats the client already submits. | Scoped extension |
Status shows how each area is delivered. Named product integrations are confirmed in the requirement study and are not claimed here.
Assurance
Numeric targets for availability, response time and recovery are fixed in the approved system requirement specification and measured throughout the operations and maintenance term. The table below states the approach applied to each parameter.
| Parameter | Approach |
|---|---|
| Hosting and residency | Can be deployed on a cloud service provider empanelled in the client's jurisdiction, with data resident in that jurisdiction. For Indian deployments, data is held in India. Separate development, staging and production environments. |
| Availability and scale | Sized for peak event footfall, with autoscaling and performance and load testing completed before go-live. |
| Offline operation | Work orders, housekeeping rounds, horticulture logs and incident capture operate without connectivity. Visitor ticket display and gate validation also operate offline. |
| Backup and recovery | Daily backups with tested restore. Documented disaster recovery arrangement with stated recovery point and recovery time objectives. |
| Application security | Developed against OWASP standards, with hardened servers and databases, encryption in transit and at rest, and secrets held in a managed vault. |
| Independent testing | Vulnerability assessment and penetration testing by an empanelled third-party auditor before go-live and annually thereafter, with critical and high findings closed before release. |
| Logging and monitoring | Logs retained for 180 days with clocks synchronised to national time sources. Security incidents reported within the window prescribed by the applicable authority. |
| Personal data | Consent capture, purpose limitation, data minimisation, retention rules and breach notification. Visitor personal data is collected only as required for ticketing, feedback and safety. Camera-derived data is handled under applicable surveillance norms. For Indian deployments, developed against the Digital Personal Data Protection Act, 2023. |
| Accessibility | Developed against WCAG 2.1 AA and, for Indian government deployments, GIGW 3.0. Accessibility testing is one of the test types in the client-approved test plan, and the results are shared with the client. |
| Languages | English and Hindi at launch for Indian deployments. Further languages are configured through the content model. |
| Licensing and handover | Open-source or licence-free components used wherever feasible. Any licensed component is declared, with licence ownership transferring to the client. Source code, build files, databases, data dictionaries, APIs, configurations and deployment scripts are handed to a client-controlled repository at go-live. |
| Standard | Status |
|---|---|
| ISO 9001:2015 | Certified |
| ISO/IEC 27001:2022 | Certified |
| SOC 2 Type 2 | In progress |
| ISO/IEC 42001 | In progress |
| ISO 22301 | In progress |
| ISO/IEC 20000-1 | In progress |
| CMMI Level 3 | In progress |
Certifications are held by SDLC Corp operating entities. Certificates are available on request. Items marked in progress are not represented as held.
| Framework | Applies to |
|---|---|
| OWASP application security standards | All surfaces |
| WCAG 2.1 Level AA | Portal and applications |
| GIGW 3.0 | Indian government deployments |
| Digital Personal Data Protection Act, 2023 | Indian deployments |
| CERT-In directions | Logging, clocks, incident reporting |
| Regional variants | For deployments outside India, the applicable framework set (for example GDPR principles, Section 508 and ADA practice) is confirmed in the requirement study. |
Applicable frameworks are confirmed per engagement during the requirement study and recorded in the approved specification.
Support
Verdara is built and supported by SDLC Corp. Certificates are held by SDLC Corp operating entities, as set out under Organisational certification.
| Stage | What is provided |
|---|---|
| Hypercare | Hypercare is the first two months after go-live. It is provided at no additional cost and covers defects, performance, configuration issues and user problems identified by the client. |
| Operations and maintenance | Operations and maintenance then runs for 36 months. All documentation, including the requirements traceability matrix, user and operations manuals and runbooks, is kept current throughout the term. |
| Service levels | Response and recovery targets are fixed in the approved system requirement specification and measured throughout the operations and maintenance term. |
| Ownership | The client owns the source code and the data. Both are handed to a client-controlled repository at go-live. |
Engagement
Development begins only after the client signs off the requirements and the design. A requirements traceability matrix links every requirement to its design element, build output and test case, and is maintained for the life of the contract.
| Stage | Activity | Deliverables and gates |
|---|---|---|
| 1 Study and design | Existing park operations, facilities, operating agencies and systems in use are studied across every stakeholder group. Functional and system requirement specifications are produced through structured workshops with the client and its user groups. | FRS and SRS signed off. High-level and low-level design. Clickable prototypes for key journeys. Requirements traceability matrix opened. |
| 2 Phase I build | The minimum viable visitor ecosystem is built first, together with the incident channel and a basic administration portal, so that public-facing capability is live before operational depth is added. | Visitor application, public portal and GIS map. QR ticketing, time slots and passes. Events core and approvals. Incident reporting. Phase I goes live within 3 months of award. |
| 3 Data, testing and go-live | Master data is loaded against a client-approved data setup document. Testing runs against a client-approved test plan with cases traced to the matrix, covering unit, system, integration, performance and load, security, regression and accessibility. | Role-based training for every user group. Pre-go-live readiness assessment. Go-live certificate. Hypercare is the first two months after go-live. It is provided at no additional cost. |
| 4 Phase II and O&M | Operational, commercial and sustainability modules are added on the same architecture, followed by the operations and maintenance term with documentation kept current throughout. | Operations, commerce, sustainability and full governance modules. CCTV and public address integrations. Phase II completes within 6 months of award. Operations and maintenance then runs for 36 months. |
Fees are set per engagement as an implementation fee covering Phase I and Phase II and an annual operations and maintenance fee, with licence costs declared separately where any licensed component is used, and sizing depends on footfall, asset count, number of parks and integration surface.
Indicative model. Phase II completes within 6 months of award. Operations and maintenance then runs for 36 months. Stage durations are fixed against the approved specification for each engagement.
Buyer guide
Eight questions to put to any vendor. Each one has Verdara's short answer and a link to where this page backs it up.
One central data model and one identity layer serve all seven modules. See the core platform
Work orders, housekeeping rounds, horticulture logs and incident capture work offline. So do ticket display and gate validation. See the field app
You do. Both move to a client-controlled repository at go-live. See licensing and handover
Video management, public address and payment systems stay in place and connect through documented APIs. See the integrations
Accessibility testing is one of the test types in the client-approved test plan, and the results are shared with you. See accessibility
An empanelled third-party auditor runs vulnerability and penetration tests before go-live and every year after. Critical and high findings are closed before release. See independent testing
Hypercare is the first two months after go-live. Operations and maintenance then runs for 36 months. See the support model
From go-live you hold the source code, the data and the current documentation, so nothing has to be handed over at the end. See licensing and handover
Procurement questions
The core platform, the seven modules and the three client surfaces are productised and configured for each engagement. The requirement study, design sign-off, integrations to the client's existing video management, public address and payment systems, and the data setup are engagement-specific. This structure is what lets an engagement reach Phase I while still matching the client's own operating model. Phase I goes live within 3 months of award.
Verdara is built for large public parks, botanical gardens, zoos and municipal park authorities. It suits operators that want ticketing, events, maintenance, safety, commerce, sustainability and governance run as one operation on one data model.
Core field workflows continue to operate. Work orders, housekeeping rounds, horticulture logs and incident capture are written locally and synchronised with conflict-safe resolution when connectivity returns. Visitors can display tickets offline from the wallet, and gate scanners validate offline and synchronise afterwards. Offline operation is a constraint on the architecture rather than a feature added later.
No. Verdara integrates with them through documented APIs. Cameras and the video management system are not supplied. Alerts and metadata are ingested as incident records, announcements are sent to the existing public address system, and the client's payment gateway processes transactions. Each integration is tested in isolation and its test report is submitted before user acceptance testing begins.
Verdara covers ticketing, work orders and GIS inside one data model. Where a system you already run should stay, it connects through documented APIs. Further integrations identified in the approved requirement specification are built on the same terms as the mandatory ones: tested in isolation, with the test report shared before acceptance testing. In the demonstration we identify which of your existing platforms should remain in place.
Yes. Each park is a tenant with its own zones, assets, vendors, content and branding, under an authority-level console that reports across the estate. Adding a park is a configuration and data setup exercise rather than a re-architecture, which matters for authorities standardising across a portfolio of sites.
Yes. Each park runs as its own tenant under one authority console, so you can start with one park and add others later. Delivery is also phased. Phase I covers the visitor-facing ecosystem and the incident channel. Phase II adds the operational, commercial and sustainability modules on the same architecture.
The client. At go-live, source code, build files, databases, data dictionaries, APIs, configurations, deployment scripts, credentials and any licences procured are handed to a client-controlled repository. Open-source or licence-free components are used wherever feasible, and any licensed component is declared with licence ownership transferring to the client.
For each system that will connect, the client provides system access, API documentation and vendor cooperation. Park teams take part in the requirement workshops, and the client signs off the requirements and the design before development begins. Master data is loaded against a client-approved data setup document, and the client's own GIS data is used where it exists.
Developed against WCAG 2.1 AA and, for Indian government deployments, GIGW 3.0. Accessibility testing is one of the test types in the client-approved test plan, and the results are shared with the client. The other test types are unit, system, integration, performance and load, security and regression testing, each with a documented pass criterion. On the visitor side this also appears as product capability: accessible routes on the map, step-free routing, scalable text and high-contrast mode.
Data stays resident in the client's jurisdiction, on a cloud service provider empanelled there. It is encrypted in transit and at rest. Access is role-based by role, zone and module, privileged users use multi-factor authentication, and every change is written to an audit trail. Backups are daily with a tested restore. Independent vulnerability and penetration testing runs before go-live and every year after. Visitor personal data is collected only as required for ticketing, feedback and safety.
Hypercare is the first two months after go-live. It is provided at no additional cost and covers defects, performance, configuration issues and user problems identified by the client. Operations and maintenance then runs for 36 months. During that term all documentation, including the requirements traceability matrix, user and operations manuals and runbooks, is kept current.
From go-live the client holds the source code, build files, databases, data dictionaries, configurations and deployment scripts in its own repository, and documentation is kept current throughout the term. Nothing has to be handed over at the end, so continuing, extending or changing support arrangements is the client's decision.
Next step
We will walk the seven modules against your current operations and systems, and identify which of your existing platforms should remain in place. Allow forty minutes.
Choose Capability pack if you would like the written capability summary instead of a call.
Prefer to write? Email sales@sdlccorp.com.
Thank you. We have your request and will reply to the email address you gave.