One event. A whole new perspective.

Create, edit, draft and publish event details in the existing workspace.

Type-specific conference, exhibition and other event templates are planned.

Start/end dates and an event timezone support events spanning multiple days; session programming is planned.

Local Node APIs cover forms, categories, free registration, signed QR issuance and revocation; this marketing demo does not connect them.

Published event pages use event details and a brand accent. Full site builders, white-label sites and custom domains are planned.

Local venue/hall metadata APIs exist; floor-plan byte upload, geometry and routing are not connected.

Existing APIs enforce scoped membership; broader staff administration and invitations need frontend integration and completion.

A unified registration, entry and reporting console is planned beyond the current event overview.

Per-event form/category APIs exist locally; the new public preview uses sample categories.

The local owner uses transactional capacity and unique attendee registration; this preview saves nothing.

The local registration owner issues event-scoped QR tickets. Public QR demonstration data is not a usable ticket.

An audited idempotent local backend revocation slice exists; frontend management is not connected here.

Payment-provider onboarding, paid inventory, transfers, refunds and reconciliation remain incomplete.

Issuance does not establish gate authorization; authoritative validation, policy and passage handling are separate work.

Organizer-approved onboarding, company profiles and assets are planned.

Local APIs import and verify stall labels. Unknown availability must not be interpreted as available.

Assignment, reservations, booking availability and concurrency controls are not implemented by the label-import slice.

The browser sample demonstrates selection; surveyed geometry and published routing maps remain planned.

Event-scoped staff credentials and exhibitor allocation policies are planned.

Sponsor packages, asset approvals and placements are planned.

Only permitted lead sharing and appropriately consented aggregate visit insights are in scope; raw attendee or location data is not an unrestricted lead list.

Local signed QR issuance and ticket revocation exist; authoritative gate validation is not yet connected.

Supported tag types, secure messaging and exact reader compatibility require hardware validation; a UID is not a secret.

Reader/gateway SDKs, calibration, signed observations and field acceptance are required.

Assignment, reassignment, suspension, replacement and device propagation are planned for physical credentials.

Authenticated provisioning, key rotation, firmware, heartbeat and clock-drift handling depend on the approved device stack.

Sensor detections need direction and passage evidence; they do not independently grant access or prove attendance.

Bounded signed leases, buffered observations, duplicate handling and conflict recovery require a separately accepted offline risk policy.

Production byte upload and serving are not implemented. The local studio can preview an image in this browser only.

Calibrate scale, set north/orientation and validate against a surveyed venue before publishing.

Define graph geometry, searchable destinations and non-routable obstacles; label metadata alone is not geometry.

Configure registration origins, direction-aware connectors and hall access points.

A step-free routing option must exclude unsuitable edges and be validated on site.

The browser demo searches sample destinations and computes a route from a declared registration point, not a measured visitor location.

Use connectors between halls and explicitly identify transitions in the directions.

Review and publish map revisions; the studio models versions locally without uploading or saving.

The local graph can remove a blocked passage and recompute a route; production updates require a published venue service.

No live indoor positioning is available here. Any future RFID-derived zone inference needs hardware calibration, privacy review and accuracy evidence.

Signed issuance exists separately; authoritative scan validation and admission are not connected.

Physical credentials and supported readers remain hardware-gated.

Versioned event-specific rules govern roles, zones, direction and permitted factors.

Atomic, idempotent decisions and anti-passback need concurrency and outage acceptance tests.

Confirmed passage and direction feed authoritative attendance; an allow decision or RFID detection alone is not passage.

Provide an assisted and non-biometric path when a factor is unavailable or uncertain.

Live gate state, controller acknowledgements, heartbeat and safety behavior require validated devices.

Record reason, policy version, event, gate, device and decision references without leaking credential secrets.

Event purpose, required assurance, consent, provider availability and manual alternatives must be approved.

These are proposed document categories for authorized providers or approved trained review; no live provider support is claimed.

Unavailable for selection until current UIDAI eligibility, permitted purpose, onboarding, notice and alternatives are evidenced and approved.

Production encrypted capture, malware scanning, restricted object access and transient storage are not connected. The preview accepts no real ID.

OCR extracts candidate fields. Extraction and MRZ checks do not independently establish authenticity.

Each provider, legal basis and permitted document method needs explicit onboarding and approval.

Represent pending, needs-review, rejected and unavailable outcomes with an assisted alternative.

Purpose-limited consent and approved retention/deletion policies apply across every store; no sensitive ID values belong in webhooks.

Enrollment is optional and purpose-bound; no silent crowd identification or face-collection search.

Lighting, pose, framing and representative quality thresholds require a validated capture workflow.

A liveness result is probabilistic and provider-dependent; it is not proof of government identity.

Compare only against the resolved, approved reference after credential and consent checks; no one-to-many surveillance.

Phone, kiosk and assisted-desk capture require approved devices, provider session design and accessible guidance.

Face evidence informs the authoritative access policy; it does not independently open a gate.

QR/manual pathways remain available when a person declines, a device is offline or a result is uncertain.

Restricted biometric access, consent withdrawal, transient evidence and deletion receipts require end-to-end implementation and validation.

Authoritative passage-based projections are planned; the marketing dashboard is fixed sample data.

Measured passage rates, heartbeat and controller status need connected, validated hardware.

Calibrated detections can support approximate zone/proximity inference, not pinpoint tracking.

Dwell is inferred from observations and gaps; uncertainty and calibration must remain visible.

Aggregate density is estimated; sparse or missing detections must not be presented as exact crowd counts.

Consent-aware aggregate activity and permitted leads are planned, not unrestricted visitor trails.

Registration and billing slices are incomplete inputs; the sample revenue chart is not a connected financial report.

Existing signup creates an organization workspace and owner membership.

Select authorized workspaces and manage multiple events through existing APIs.

Foundation membership/event scopes are enforced; broader role/team administration needs connection and completion.

A local billing owner implements plan revisions, trial entitlement and cancellation; paid activation, renewal and invoices remain incomplete.

Local idempotent usage/quota mechanisms exist; commercial rating, charging, tax and reconciliation remain planned.

Event accent branding is available; full white-label hosting and custom-domain publication are not connected.

Broader event, assurance, integration and branding policy configuration is planned.

A platform-wide administration console is separate from the current organization workspace and remains planned.

Local Node contracts cover public event, venue, stall and registration slices; availability depends on the active gateway and deployment.

Local event-scoped keys support registration.write, one-time display, expiry and revocation. Real keys belong only on a client server.

The guide specifies HMAC-SHA256 over timestamp + period + raw body; no webhook dispatcher is claimed as deployed.

Authenticate provider callbacks, bind them to a job and handle duplicates. No arbitrary unsigned browser callback is trusted.

Stable event IDs, redacted attempts, bounded backoff and manual replay are planned; the new console is a local simulation.

The demo is browser-local, not a deployed sandbox. A real self-service integration sandbox is planned.

Read-only snapshots of implemented local key, registration and venue/stall contracts are provided; proposed interfaces remain labeled.

Use scoped REST and safe event outcomes for client systems; no named native CRM/ERP connector is claimed.

Foundation APIs enforce organization membership and scoped queries; complete multi-owner deployment isolation requires release validation.

Existing workspace authorization and TOTP setup/sign-in protect the foundation; broader permission administration is partial.

Per-device keys, signed scans, rotation and revocation depend on a validated device agent and deployment.

Existing MFA material has protected storage. Document/biometric encryption, key policies and retention are broader planned controls.

Some local lifecycle and review actions have audit records; complete access/integration audit views remain planned.

Verification purpose, optional enrollment, withdrawal and sharing notices require approved policies and an implemented consent ledger.

Cross-store deletion receipts and approved retention jobs remain delivery requirements, not a claim about a deployed pipeline.

Separate stores, purpose/role checks and minimal outcomes depend on approved verification rollout.

Foundation health/metrics exist locally; complete alerts, incident runbooks, recovery and production evidence remain to be validated.