Privacy notice | 513technology

Last updated: 22 August 2026

1. Who this notice covers

513technology is responsible for the information described in this notice when people use this website or choose to engage us about software development or technology consulting.

Business address2A Olanrewaju Ninalowo Cres, Lekki Phase 1, Lekki 106104, Lagos

A travel agency using software built by 513technology remains responsible for its own customers, licences, supplier contracts, travel services and lawful handling of traveller information. The responsibilities for any client platform will be defined in the applicable project agreement and data-processing agreement.

2. The consultation brief

The consultation brief currently available on this website is a browser-based planning tool. The information entered into it is used on your device to create a summary. The brief is prepared locally and is not submitted to 513technology or stored by this website.

If you select the WhatsApp hand-off, your browser opens WhatsApp for the 513technology business number, +234 816 326 0992. When a brief is short enough to prefill, opening that link shares its text with WhatsApp and Meta so they can prepare the message composer. A long brief instead opens a short introductory message and asks you to copy and paste the brief yourself.

Opening WhatsApp does not send a message to 513technology. You can review or edit the text, and 513technology receives it only if you press Send. WhatsApp and Meta process the link data, message and related account or technical information under their own terms and privacy practices.

Do not enter traveller records, passport details, payment data, confidential supplier credentials or other sensitive information into the brief or WhatsApp message.

3. The signed-in AgencyOS Core Pilot

The Core Pilot is restricted to expressly allowlisted accounts and uses Sign in with ChatGPT to identify the person opening the workspace. The hosting service may provide a stable account identifier, email address and, when available, display name so the session can be authenticated. 513technology does not receive your ChatGPT password.

An allowlisted user may create or join one controlled agency workspace. The workspace stores an agency name, membership role, fixed operational-or-summary access mode and status, invitation email, membership and invitation timestamps, and an accountable team-event history. A stable account identifier is used to enforce membership; email is used to match an invitation to the exact approved sign-in account and to identify a teammate in the team view. The pilot does not send an invitation email, so the agency owner must notify the invited person separately. The invited account can review who prepared the invitation and accept or decline it. An account can belong to only one active pilot agency at a time.

Bounded Team Access History keeps the main Team & Access response to the current roster only: the owner, active operational members and summary viewers and, for the owner, unexpired pending invitations. Revoked memberships and expired invitations remain stored as accountable records but are not returned in an unbounded roster. Operational members never receive team-event history, and summary viewers do not receive the Team view. An owner requests that history separately in newest-first pages of no more than 25 summaries and may explicitly choose Load earlier access history. The displayed count covers only entries loaded in that browser view and is not an exact event total.

Each owner-visible history summary contains the event action, a bounded target label, the recorded-by staff email and timestamp, plus a derived invitation expiry when applicable and a pseudonymous page-item key used only for stable loaded-list rendering. Neither that key nor its continuation cursor repeats a raw stored event identifier, including an account-derived legacy identifier. The key is not an agency, account or membership identifier and cannot select another record. The summary contains no raw event details or internal agency, account or membership identifiers. Every history request derives active agency membership and the owner role before inspecting the opaque pseudonymous positional cursor. Owner-only team actions apply the same authority check before inspecting an invitation email, workspace-name change, membership identifier or version. A newer event does not shift or duplicate an in-progress earlier-page walk; refreshing the newest page is required to see it. Ordinary history failures preserve the current roster, loaded history and open owner form for retry. Viewer or access changes clear the loaded history. Migration 0010 adds and backfills one non-business public-key column with a required unique 32-character lowercase hexadecimal value per team event while the internal primary key remains private. It rebuilds only the existing team-event table to enforce that non-business key, preserves every event's business content, and adds the timestamp-and-public-key and expiry-aware membership indexes. It adds no new table, binding, analytics or storage system and deletes no event. To remain Sites-parser-safe, migration 0010 contains no trigger DDL. After the rebuild, each allowed workspace entry awaits the retry-safe access-time Team-event guard installer before any workspace record is read or written. The installer restores the append-only update and delete triggers. If guard installation fails, that access fails closed and the failed cached state clears so a later request can retry. No membership or event record is archived or given a retention rule, and the release adds no invitation email, export, message, notification or external action.

The workspace may also store owner-managed agency settings: a primary colour, an accent colour, a default currency selected from NGN, USD, GBP, EUR, GHS, KES or ZAR, and a default validity period of 7, 14, 21 or 30 days for new quote drafts. Active operational members may view those settings, but only the owner may change them. Settings changes are retained in a separate append-only agency settings history with the signed-in staff account and time. Staff email addresses and agency settings are agency-internal personal or business data and should be visible only to authorised members. Staff account identifiers, membership identifiers and display names are agency-internal personal data under the same boundary.

A new enquiry draft begins with the saved default currency. A new quote draft first uses the enquiry's supported budget currency and otherwise uses the agency default; its validity date uses the saved default validity period. These defaults do not rewrite existing enquiries, saved quotes or quote revisions. The internal client preview may display the agency name and restrained colour accents. It does not create a customer or agent portal, public sharing link, logo upload, custom domain, PDF or other download, email or WhatsApp delivery, or any send or publish action. The settings do not guarantee a translation or right-to-left interface, obtain a live foreign-exchange rate, make a live booking, move money, or create an invoice, receipt, ticket or document.

Enquiry records created in the Core Pilot are stored in the website database. A record may include an enquiry title, source, destination, travel window, budget and currency, status, next action, notes, an optional assignee membership identifier, timestamps and an activity history. Server-side checks restrict each detailed record to active operational users of the same agency workspace. Those users can see the agency's shared enquiries, quotes, operations records and activity history, while activity entries identify the account that performed each recorded action.

Every new enquiry is unassigned by default. Any active owner or operational member may later assign it to one active operational membership in the same agency, reassign it or return it to Unassigned. The enquiry and assignment activity retain the opaque membership identifier without copying the assignee's email or account identifier. If that membership is later revoked, the stored reference remains for historical accountability. Pipeline and Command Centre responsibility labels then show only “Former team member — reassign”. The agency owner can still review the existing accountable identity and access history in the owner-authorised Team & Access view. The existing enquiry version check protects assignment, status, dates and other fields from a stale competing edit. Assigning an enquiry is internal planning only: it sends no message or notification, changes no status or follow-up date, and does not contact a customer or supplier, make a booking, charge or refund a customer, move money or begin an external workflow.

A Core Pilot quote may include a quote reference, title, summary, validity date, revision number and status; itinerary dates, locations and descriptions; cost-line categories, descriptions, original amounts and currencies; a quote currency; manual exchange-rate snapshots with their source and capture time; markup, service-fee and rounding inputs; server-calculated totals; inclusions, exclusions and client-facing notes; and timestamps. Activity records may show that a draft was updated, a revision was recorded as presented or superseded, or an acceptance or decline was recorded, together with the signed-in account and time.

Presented, accepted and declined are manual business records made by the signed-in user. The Core Pilot does not send or share a quote, invite a customer to view it, verify that a customer accepted it, access live supplier inventory, book travel, issue an invoice or ticket, or process or settle a payment. Do not enter supplier credentials or treat a saved rate snapshot as a live foreign-exchange or supplier price check.

After an accepted quote is recorded, an active operational agency member may start a manual operations ledger. It may store non-sensitive fulfilment task titles, categories, statuses, due dates, notes and an optional assignee membership identifier, plus manual payment or refund records containing an amount, accepted quote currency, date, method label, optional external reference, notes, status and void reason. The website calculates recorded payments, refunds, net recorded value and balance from those entries. These are internal business records only: the Core Pilot does not contact a supplier, reserve inventory, charge or refund a customer, verify provider settlement, or issue an invoice or receipt.

Bounded Manual Payment History returns the selected operation's payment and refund records separately in newest-first pages of no more than 25. Load earlier payment records appends one older page. The displayed count covers only records loaded in that browser view and is not an exact ledger total. The opaque continuation cursor is a list position only: it cannot select an agency, member, enquiry, operation or arbitrary record, and each request derives active membership and the immutable agency record scope again before checking the selected enquiry and operation.

Exact recorded-payment, refund, net and balance figures are calculated across all scoped records, rather than from the visible page, and voided entries remain stored but do not contribute to active totals. The existing atomic 100-record capacity includes voided records. Core operations and task responses do not expose the complete payment history, while a successful create or one-way void returns only the affected record plus refreshed totals and capacity state. The response adds no staff, account or membership identifier. Each new-record attempt sends one random opaque record key in its POST body and the server stores it as the manual record ID. Exact replay reuses that key and creates no duplicate row or activity. Authenticated payment-page and exact-record responses return it as the row ID, and the accountable payment activity keeps it as an internal record association. While an outcome is unknown, the browser retains it only in viewer-, enquiry- and operation-scoped memory so Check latest and any reviewed retry use the same frozen request. Blind retry remains blocked until that review. The interface does not render the key, and the key contains no query, business or staff data. Reconciliation and void requests put it only in the scoped payment-record path, never in a query parameter or address-bar page URL. It is not written to browser storage or cookies or sent to analytics or telemetry. Query and draft content remain out of URLs. A newer record does not shift or duplicate an in-progress earlier-page walk. Ordinary errors preserve tasks, exact totals, loaded records, retry position and open create or void drafts; viewer, enquiry or access changes abort and clear the loaded history.

Migration 0011 changes only the payment-history lookup index and runs database optimisation. It creates no table or column and deletes or rewrites no business record. Bounded paging is not a retention or deletion policy. This release adds no history search, filter, exact record total, export, archive, deletion, new payment action, analytics, automation, message, notification or external action. It does not charge or refund a customer, move money, verify settlement, or issue an invoice or receipt.

An operations task is either unassigned or assigned to one active operational membership in the same agency. Every active owner or operational member may assign or reassign it; summary viewers are excluded from the assignment roster. The task and assignment activity store the membership identifier without copying the assignee's email. The authorised workspace resolves an active teammate's label from the team record. If that membership is revoked later, the stored reference is retained for historical responsibility. Task and Command Centre responsibility labels then show only “Former team member — reassign” rather than the former identity. The agency owner can still review the existing accountable identity and access history in the owner-authorised Team & Access view. A successful assignment change is recorded with the signed-in account and time; the task version check rejects a stale competing edit.

The read-only Operational Command Centre derives bounded agency-wide summaries and attention lists from the agency's existing enquiry, quote, operations-task and manual payment or refund records when an active operational member opens the view. The summary-viewer variant returns totals without item-level attention detail. The operational view may show enquiry and task responsibility within its existing limit of 50 attention records, but it does not calculate assignment totals or create a separate reporting record. Amounts remain separated by their recorded currency rather than being converted or combined. Voided manual payment or refund entries remain part of the accountable history but are excluded from active command-centre totals. These figures are manually recorded and unverified; they are not revenue, profit, cash, bank, settlement, provider-confirmed or accounting data.

The personal My Work Snapshot is a separate, server-derived and read-only view for the signed-in operational member's current active membership. It contains assigned open enquiries, including an enquiry whose next action is missing, and assigned open or in-progress operations tasks. It does not accept a teammate selector from the browser or store a separate personal queue. On manual refresh, Africa/Lagos dates group records as overdue, due today, next seven days, later or unscheduled. The first page loads automatically and an explicit action may append later pages of no more than 50 records each. Its shown and urgency counts describe only the pages loaded in the browser; the service does not calculate an exact all-work total. The snapshot response does not contain assignee or staff identifiers, record notes or financial fields and provides no teammate comparison. It does not itself provide the separate agency-wide Needs an Owner Snapshot. Refreshing it creates no activity record and sends no notification or message, starts no automation, makes no booking or supplier action, moves no payment, and creates no portal or export.

The Needs an Owner Snapshot is a separate, agency-wide and read-only view available to active operational members. The server derives the current active agency access and returns open enquiries and open or in-progress tasks that are unassigned or whose saved teammate responsibility no longer resolves to an available active teammate. The response uses only generic Unassigned or Needs reassignment labels; it does not contain a membership identifier, staff identity, record notes or financial fields. On manual refresh, Africa/Lagos dates group a first page of no more than 50 displayed records as overdue, due today, next seven days, later or unscheduled. Explicit continuation can append later bounded pages. Shown, responsibility and urgency counts describe loaded pages only. A page marker may indicate that more records exist, but this is not a complete inbox, export, exact agency total or staff-performance comparison. It stores no separate queue and offers no inline assignment. Opening an item loads the latest underlying record before a member uses the existing version-protected assignment control. Viewing or refreshing the snapshot creates no activity record and sends no notification or message, starts no automation, makes no booking or supplier action, moves no payment, and creates no portal or export.

Claim for me is a separate internal responsibility change for one eligible uncovered open record. The server derives the signed-in user's current active membership and accepts no agency, membership, user, assignee or arbitrary-teammate selector from the browser. At commit time it checks the latest agency scope, open status, responsibility and version, so it cannot take work that still has an available active teammate responsible. A successful claim assigns only the current membership, advances the record version and creates one attributable activity entry. A stale, ineligible or competing request changes nothing and creates no activity. The success response contains no membership, user, assignee or other staff identifier. Claim for me does not operate in bulk or automatically, send a message or notification, change a status or date, contact a customer or supplier, make a booking, move a payment, create a portal, or produce an export.

Work Handoff & Return Path is an interface-only continuation of that existing claim flow. After a successful claim, the current signed-in viewer can see a confirmation for the claimed record and choose to open its latest record, view My Work or continue triage. When the viewer opens a record from Command Centre attention, My Work or Needs an Owner triage, the interface can also keep a return path to that originating view. The confirmation and return context remain only in the current viewer's workspace session: they are not written to the website database or browser storage, sent to a new endpoint, shared with another member or used to create a separate queue. They are hidden and cleared when the signed-in viewer changes, and are cleared when their Pipeline or report source detects an access error. This local navigation layer stores or returns no staff identifier and adds no claim, assignment or other business mutation. It sends no message or notification, starts no automation or external action, contacts no customer or supplier, makes no booking, moves no payment, creates no portal and produces no export.

Plan my next step is a separate, one-record internal planning action for an open enquiry follow-up shown in My Work. The current member may provide a bounded next-action description and an optional due date only while that enquiry is assigned to the same active membership and still has no next action. The service derives the current membership and rechecks the agency scope, self-assignment, open status, missing plan and record version before saving. A successful request changes only the enquiry's next action and optional due date, advances its version and creates one attributable activity entry. A stale, ineligible or competing request makes no partial change and creates no activity. The action cannot update an operations task, plan another member's work, replace an existing plan, or change status, responsibility or notes. It creates no AI suggestion, reminder, message, notification, booking, payment, portal or external action and adds no database schema or migration. Use only fictional or non-sensitive business-planning text.

Progress my task is a separate, one-record internal status action for an operations task shown in My Work. The current member can move an assigned open task to in progress or an assigned in-progress task to done. The service derives the current active membership and rechecks the agency scope, self-assignment, saved status and record version before committing exactly one permitted step. A successful request changes only task status, advances the version and creates one attributable operation-task activity with the saved from-status and to-status. A stale, reassigned, completed, skipped or competing request makes no partial change and creates no activity. The command accepts no teammate selector, title, category, due date, notes or other task content. It cannot create, delete, broadly edit or reopen a task, operate in bulk, generate an AI suggestion, create a reminder, send a message or notification, contact a customer or supplier, make a booking, move a payment, create a portal or start an external action. It adds no database schema or migration.

Agency-wide Find & Open replaces the earlier loaded-only Find & Focus discovery limit. In Find across Pipeline, typing stays local to the current browser. Only the explicit Search all agency records action sends a same-origin POST. Its request body contains the exact bounded query and the query is never placed in the URL. The service establishes the signed-in account's allowlist admission, active membership and agency record scope before it reads or validates that body. It then transiently scans no more than 500 same-tenant enquiry summaries across all Pipeline stages, comparing only title, destination, source and next-action text. It returns no more than eight matches plus only an indication that the member should refine when further matches exist. It returns no exact total and does not echo the submitted query.

Choosing a search result uses the existing in-progress-save and unsaved-work guards, then requests the latest authoritative tenant-scoped detail. A result outside the loaded Pipeline pages is not inserted into that page cache and does not change the selected stage or any loaded-only count. An ordinary search failure preserves loaded pages, selected detail and drafts; a viewer or access change aborts and clears the transient query and results. Neither query nor result state is written to D1, browser storage, a cookie or the URL, and it is not sent to analytics or telemetry. Search creates no activity, mutation, message, notification, automation or external action. It adds no database table, column, schema migration, index, binding or storage system.

Mobile Pipeline Handoff changes only how the existing Pipeline list and selected detail are presented at viewport widths of 850 pixels or less. The normal mobile Pipeline entry shows the list, and every supported explicit open shows the latest authoritative detail. Back to Pipeline list returns without a request, mutation or discard and preserves selected detail and drafts, loaded pages, stage, local and agency-wide Find state, the result shelf, page cursor and source-return context in the current viewer's workspace session. A commit in flight blocks the handoff, and an existing source-return control remains available in mobile detail. Wider desktop layouts continue to show list and detail together. This interface-only release adds no API, schema, migration, database or browser storage, cookie, URL state, analytics, activity, automation, message, notification or external action. It collects, exposes and shares no additional personal data and changes no privacy boundary.

The v2.97 Draft Navigation Shortcut Return release derives one transient local fixed shortcut target from existing section metadata after explicit selection. The target includes no entered value, selected currency or internal row key and is not retained. Returning adds no request, payload field, record, browser storage, cookie, URL state, analytics or telemetry and changes no collection, use, sharing, permission or real-data approval.

The v2.96 Draft Section Missing-Input Navigation release derives transient local labels and targets from existing section, field, stable-row and current row-position metadata. The labels include no entered value, selected currency or internal row key, are not retained and add no request, payload field, record, browser storage, cookie, URL state, analytics or telemetry. The focus action remains inside the current unsaved form and changes no collection, use, sharing, permission or real-data approval.

The v2.95 Draft Required-Input Destination Clarity release derives one transient local destination label from existing section, field and current row-position metadata. It includes no entered value, selected currency or internal row key, is not retained and adds no request, payload field, record, browser storage, cookie, URL state, analytics or telemetry. It changes no collection, use, sharing, permission or real-data approval.

The v2.94 Draft Required-Input Section Progress release derives transient numeric counts by grouping the existing current-draft required-input descriptors into their five rendered editor sections. The counts contain no entered wording, are not retained and add no request, payload field, record, browser storage, cookie, URL state, analytics or telemetry. They assess presence only and do not change collection, use, sharing, permission or real-data approval.

The v2.93 Draft Required-Input Navigation release derives one transient local target from the first whitespace-only required value in the current unsaved quote draft. That target uses the same ordered field descriptors as the existing presence count and contains no entered wording. It is not retained and adds no automatic focus, validation, request, payload field, record, browser storage, cookie, URL state, analytics or telemetry. Explicit navigation changes no collection, use, sharing, permission or real-data approval.

The v2.92 Draft Required-Input Progress release derives transient numeric counts from whether the currently rendered required quote inputs contain a nonblank value. The summary displays no entered wording, is not retained and adds no request, payload field, record, browser storage, cookie, URL state, analytics or telemetry. It does not assess validity or approval; existing Check, Save and server verification remain authoritative. No additional collection, use, sharing, permission or real-data approval is added.

The v2.91 Draft Required-Input Clarity release adds visible guidance and native required metadata to quote inputs that existing Check and Save rules already require. It does not inspect, insert, rewrite, derive or retain an entered value, and it adds no request, record, browser storage, cookie, URL state, analytics or telemetry. Optional fields remain optional, valid payloads stay unchanged and the server keeps final verification. No additional collection, use, sharing, permission or real-data approval is added.

The v2.90 Draft Calculation-Bounds Check release derives transient BigInt calculation-range values from the existing unsaved quote draft during local Check and Save preparation. It mirrors the server's existing conversion, subtotal, markup, service-fee and rounding bounds only to stop a request that is guaranteed to fail. Those derived values and any aggregate total are not rendered, retained as editor state, saved as a record, shared, persisted in browser storage, placed in a URL or sent to analytics or telemetry. Draft inputs and valid outgoing payloads remain unchanged, and the server performs the authoritative calculation. No additional collection, persistent storage, sharing, permission or real-data approval is added.

The v2.89 Draft Current-Time Checks release samples the browser's current time only during local Check and Save preparation, after existing static validation passes. It compares the unsaved Valid until date with the current UTC date and manual-rate observation times with the current instant plus the existing exact five-minute clock-skew allowance. The clock sample is not retained after validation. The local result remains only in current editor memory; neither is saved as a record, shared, persisted in browser storage, placed in a URL or sent to analytics or telemetry. Draft values are not rewritten. The server independently verifies time when saving. No additional collection, persistent storage, sharing, permission or real-data approval is added.

The v2.88 Draft Pricing Value Checks release compares existing unsaved rate, source-cost, service-fee and rounding values with the server's established input limits before save evidence or a request is prepared. That release does not store the check result, rewrite the draft or add an aggregate-range preflight or displayed total. Valid payloads and server-side verification stay unchanged. No additional collection, persistent storage, sharing, permission or real-data approval is added.

The v2.87 Draft Rate Usage Checks release derives reference counts from existing draft price-item currencies and checks unused rates locally before save evidence or requests are prepared. It creates no stored count or additional record and does not automatically remove rates. Guidance stays outside the wording review; valid payloads remain unchanged. No additional collection, persistent storage, sharing, permission or real-data approval is added.

The v2.86 Draft Calendar Date Checks release compares existing quote-expiry and itinerary dates with the server’s calendar rule inside local Check and Save preparation. It reads no current clock, does not rewrite dates and preserves valid outgoing payloads. Field guidance stops invalid dates before save evidence or requests. No additional collection, persistent storage, sharing, permission or real-data approval is added.

The v2.85 Draft Text Limit Checks release compares existing quote text with current saved-length limits inside local Check and Save preparation. Normalized length is used only for comparison; draft wording and valid outgoing payloads are not rewritten. Failures identify fields without echoing their contents and stop before save evidence or requests. No additional collection, persistent storage, sharing, permission or real-data approval is added.

The v2.84 Draft Note Line Checks release compares prepared inclusion and exclusion lines with existing saved-line limits inside the editor’s local Check and Save preparation. Draft text is not rewritten, and valid outgoing arrays remain unchanged. Limit failures are shown locally before save evidence or requests are prepared. No additional collection, persistent storage, sharing, permission or real-data approval is added.

The v2.83 Draft Text Length Guidance release displays counts of existing unsaved text beside editor fields. Counts are derived in the editor without additional collection, stored state or requests. The summary input allowance is aligned with the existing 1,000-character server rule without shortening draft text. Counters remain outside the wording review; existing pricing exclusions, privacy boundaries and real-data restrictions remain unchanged.

The v2.82 Draft Wording Entry Navigation release moves between existing service or itinerary inputs and their unsaved wording. It changes focus and native disclosure visibility only, creating no stored return point or snapshot and sending no request. Draft content, pricing exclusions and existing privacy boundaries remain unchanged. No additional collection, persistent storage, sharing, permission or real-data approval is added.

The v2.81 Draft Wording Review release displays existing unsaved wording within the same quote editor. It renders selected wording and date fields, not internal pricing fields or revision notes; free text is not automatically redacted. The native disclosure creates no stored snapshot and sends no request. No additional collection, persistent storage, sharing, permission or real-data approval is added.

The v2.80 Draft Check and Save Navigation release moves focus between existing editor sections, check results and the quote action area. It adds no stored state and sends, copies or collects no data. Draft content, search and the temporary removal Undo record stay unchanged. No collection, sharing, permission or real-data approval is added.

The v2.79 Draft Rate Removal Undo release uses the existing temporary editor-memory Undo record for a removed manual rate. Restoration returns its original values without sending or storing additional data. The latest removal is available only before another edit or Save, and closing the editor clears it. No new collection, sharing, permission or real-data approval is added.

The v2.78 Draft Add Entry Handoff release temporarily identifies the newly added row and its field in editor memory so focus moves only after the draft update is accepted. It uses the existing draft-edit path and sends or stores no additional data. No new collection, sharing, permission or real-data approval is added.

The v2.77 Draft Entry Search release searches price-item and itinerary wording already held in the current quote editor. Search text stays in temporary editor memory and is not sent, saved in a quote, placed in a URL or stored as a browser preference. Closing the editor clears it. This adds no collection, sharing, permission or real-data approval.

The v2.76 Draft Input Check release holds a local check result against the current unsaved draft, editor mode and loaded base revision in memory. Checking sends nothing and does not save a record, browser preference or interaction history. Edits, Save, editor exits and access cleanup clear the result. No new collection, sharing, permission or real-data approval is added.

The v2.75 Draft Validation Shortcuts release temporarily associates an existing client-validation message with its rejected draft and field or section in editor memory. It sends no additional data and stores no browser preference or interaction history. Accepted edits, Save, editor opening, cancellation and access-change cleanup clear the temporary issue. No new collection, sharing, permission or real-data approval is added; existing data restrictions remain unchanged.

The v2.74 Draft Section Navigation release moves focus between the five sections of the current quote editor. Counts use entries already held in the unsaved draft. Navigation transmits nothing, adds no stored preference or interaction history, and changes no draft content or removal Undo opportunity. No new collection, sharing, permission or real-data approval is added; existing data restrictions remain unchanged.

The v2.73 Draft Removal Undo release temporarily holds the latest removed price item or itinerary entry in the current editor's memory. Undo restores its exact contents and position before another edit or Save attempt. Leaving the editor clears the opportunity. It transmits nothing and adds no persistent storage or multi-step interaction history. Only an explicit quote save submits the current draft through the existing flow. No new collection, sharing, permission or real-data approval is added.

The v2.72 Draft Item Duplication release copies an existing price item or itinerary entry within the current unsaved draft. Copying transmits nothing and adds no browser storage or interaction history. An explicit quote save includes the separate copied entries through the existing save flow. Draft keys are not submitted. No new collection, sharing, permission or real-data approval is added; existing data restrictions remain unchanged.

The v2.71 Draft Item Order release rearranges existing price items and itinerary entries within the current unsaved draft. Moving an entry transmits nothing and adds no browser storage or interaction history. Only an explicit quote save submits the chosen order through the existing save flow. Entry contents and the existing data restrictions remain unchanged; no new collection, sharing or real-data approval is added.

The v2.70 Compact Proposal Review Tools release groups existing reset and panel controls inside a native disclosure. Opening or closing it is local browser presentation only, with no stored preference, interaction history, request or transmission. The same loaded proposals and review choices remain intact. No collection, sharing, cookie, analytics, permission or real-data approval is added.

The v2.69 Proposal Change-Review Controls release opens or closes existing native review panels within the already-loaded comparison. It stores no additional state, content or interaction history and transmits nothing. Hidden panels, local search choices and entry filters remain unchanged. It adds no request, collection, sharing, cookie, analytics, permission or real-data approval.

The v2.68 Proposal Review Reset release clears temporary local search, scope, section-filter and entry-filter choices and closes inner review panels without discarding the two loaded proposals. A local reset counter recreates only the section subtree; it is never stored or transmitted. This is not record deletion or a new read. It adds no collection, sharing, cookie, analytics, request, permission or real-data approval.

The v2.67 Proposal Search Section Shortcuts release uses existing section labels, revision numbers and local highlighted-passage counts to move focus within already-loaded proposals. It reuses the temporary navigation position and creates no stored history, copied content, request or transmission. The optional shortcut list resets with search navigation. No collection, sharing, analytics, permission or real-data approval is added.

The v2.66 Proposal Revision Search Scope release keeps one temporary local choice of which already-loaded proposal to search. It changes local matches, highlights and navigation only. Clearing the phrase retains this choice; existing comparison invalidation discards it. No scope choice, query or additional content is stored or transmitted, and no collection, sharing, cookie, analytics, permission or real-data approval is added.

The v2.65 Proposal Search Highlight Navigation release keeps a temporary local last-visited position and rendered-element reference for the active proposal search. Search or changed-only changes reset this navigation; existing comparison invalidation discards it. No navigation history, query, content or position is stored or transmitted. It adds no request, collection, sharing, cookie, analytics, permission or real-data approval.

The v2.64 Proposal Entry Source Navigation release uses already-visible source sides and saved positions to move focus between an entry review and the complete original proposal. It opens only the relevant local disclosures and creates no stored navigation history, URL state, request, copied content, analytics or additional collection or sharing. Permissions and real-customer-data approval remain unchanged.

The v2.63 Focused Proposal Entry Review release keeps one temporary local filter choice for each entry review. It hides only exact-match alignment rows, while the complete original proposals remain available. Choices are discarded with the existing comparison lifetime and are never stored or transmitted. No additional data, cookie, analytics, sharing, permission or real-customer-data approval is introduced.

The v2.62 Proposal Service and Itinerary Content Review release compares already-loaded proposal fields locally. Services include category, title and description; itinerary entries include date, title, location and details. Exact alignment excludes IDs, prices, quantities, rates and internal notes. Larger entries remain complete and source-labelled. It sends, stores, collects and shares nothing new, and adds no cookie, analytics, permission or real-customer-data approval.

The v2.61 Proposal Inclusion and Exclusion Changes release compares the already-loaded inclusion and exclusion strings locally. Its temporary alignment retains exact text and saved positions, not record identities. Larger lists remain complete and source-labelled without alignment. No data is sent, stored, collected or shared, and no cookie, browser or database storage, analytics, permission or real-customer-data approval is added.

The v2.60 Proposal Wording Changes release compares the already-loaded client-summary and client-note strings locally. A transient derived comparison is reused while those strings are unchanged. It sends, stores and collects nothing, and introduces no cookie, browser or database storage, analytics, sharing or permission. Original saved fields remain intact, including when larger fields require complete-text comparison. Real-customer-data approval remains unchanged.

The v2.59 Proposal Section Navigation release adds local jumps among the currently shown comparison sections and returns to their section list. It changes native disclosure state and focus only, without copying proposal content, changing the query or filters, adding a URL fragment, or making a request. Nothing is persisted, collected, shared or added to analytics, and no permission or real-customer-data approval changes.

The v2.58 Proposal Search Match Highlights release visually marks matching text within the already-loaded searchable proposal fields. It uses the existing local query and preserves the original text without adding a stored copy, preference, request, collection, sharing, analytics or permission. Generated placeholders and excluded internal fields are not highlighted. Clearing search removes the marks; real-customer-data approval remains unchanged.

The v2.57 Compared Proposal Content Search release keeps one local search string of at most 160 characters inside the mounted comparison. It searches explicit displayed content fields in the two loaded proposal snapshots, not pricing, identifiers, internal revision notes or other quote history. No query or result is sent to a server, stored by the application in browser or database storage, shared or added to analytics. Clearing search changes only that string; comparison invalidation or a new pair resets it. The release adds no collection, permission or real-customer-data approval.

The v2.56 Proposal Review Disclosure Controls release adds local controls that open or close the currently shown proposal sections. Native section state stays in the mounted comparison; hidden sections retain their existing state. The controls do not copy proposal content, persist a preference or add a request, cookie, browser or database storage, collection, sharing, analytics, permission or real-customer-data approval.

The v2.55 Focused Proposal Content Review release adds an optional changed-sections filter to the existing verified proposal comparison. A single local boolean preference controls which of the six sections is shown. It neither changes nor copies the loaded snapshots and is not stored in a cookie, URL, browser storage or database. A new comparison pair or invalidation resets the preference. This presentation change adds no request, collection, sharing, analytics, permission or real-customer-data approval.

The v2.54 Loaded Quote Proposal Content Comparison release compares six client-preview sections from the revisions opened by a successful swap. One immutable projection of the previously open proposal is retained in the existing transient opening intent. It includes client summary, proposed services, itinerary, inclusions, exclusions and client notes, plus the quote and enquiry identity needed to bind the comparison to its viewer and exact revision pair.

Source costs, quantities, rates, pricing rules, service/itinerary identifiers and internal revision notes are excluded. Ordinary opens, latest reads, reference changes, access/context changes and mutation/recovery applications invalidate the pair. Exact retry uses the original captured source. This feature adds no request, browser or database storage, collection, sharing, permission or real-customer-data approval. The snapshots are not a fresh read; real customer data remains blocked.

The v2.53 Loaded Quote Comparison Swap release lets an operational user open an already-loaded fixed reference's full quote detail and compare back to the previously open revision. It reuses the existing exact-revision read; comparison selection changes only after a verified successful response.

The existing transient opening intent holds the two revision numbers and viewer/enquiry scope for exact retry. Failed opens keep the prior detail and reference; ordinary opens, latest loads and access/context changes invalidate the swap intent. Find, preview mode and history remain unchanged. The release adds no collection, endpoint, storage, schema, disclosure, permission or real-customer-data approval, and real customer data remains blocked.

The v2.52 Loaded Quote Comparison Reference release lets an operational user select any already-loaded quote revision as a fixed reference for the same five-field summary comparison. Automatic current remains the default. A numbered reference stays fixed as other quotes are opened, while identical or missing references are explained without another lookup or automatic substitution.

One transient selection is scoped to the current viewer and enquiry and resets when that context or access changes. Choosing a reference leaves the open quote, Find, preview mode, loaded history and retry context unchanged and sends no request. The release adds no collection, endpoint, storage, schema, disclosure, permission or real-customer-data approval, and real customer data remains blocked.

The v2.51 Loaded Quote Find Preview Review release lets an operational user open a named newer or earlier shown match directly beside the verified quote preview. Targets and position come from the same already-loaded result page. Each deliberate action uses the existing guarded exact-revision request; it does not load hidden result pages or earlier history automatically.

Search, filters, result page, preview mode, loaded history and cursor remain in place. The existing transient opening origin also identifies preview review so successful exact retry can return to the requested verified preview. Busy, recovery, identity and mounted-revision checks still apply. The release adds no collection, endpoint, storage, schema, disclosure, permission or real-customer-data approval, and real customer data remains blocked.

The v2.50 Loaded Quote Find Preview Navigation release lets an operational user move focus between an active loaded quote Find and the verified full quote preview already rendered in the same workspace. The destination identifies the exact selected revision and current preview mode. A missing or filtered-out summary does not require another lookup when the full preview is already loaded.

Both directions preserve the query, filters, result page, quote detail, preview mode, history cursor and retry context. Loading, error, editor, busy, recovery and identity boundaries remain enforced. The release adds no state, timer, request, collection, endpoint, storage, schema, disclosure, permission or real-customer-data approval, and real customer data remains blocked.

The v2.49 Loaded Quote Find Open Revision Return release lets an operational user locate the open revision within the existing filtered, loaded quote summaries. Its match position and result page are derived locally. The interface separately identifies an open revision excluded by the filters or absent from loaded history, without requesting additional detail or clearing filters.

A deliberate return changes only the existing local result page when needed and moves focus to the exact selected summary. Search, filters, open quote, preview, history cursor and recovery details remain in place. The release adds no collection, endpoint, storage, schema, disclosure, permission or real-customer-data approval, and real customer data remains blocked.

The v2.48 Loaded Quote Find Result Pages release lets an operational user browse every match already present in the loaded quote summaries, in pages of at most eight. Filtering precedes paging, and range and page counts refer only to that loaded set. Changing a result page sends no request and does not open another quote or fetch earlier history.

One transient result-page number is kept only in the current interface. It resets with changed query or filters, cleared Find, viewer, enquiry or access changes and successful history replacement. Earlier-history append and ordinary failed refresh preserve the current page. This release adds no collection, endpoint, storage, schema, disclosure, permission or real-customer-data approval, and real customer data remains blocked.

The v2.47 Loaded Quote Find Review Navigation release lets an operational user move between adjacent shown matches in the existing loaded-only quote Find. The position and exact neighbouring revision numbers derive only from the first eight shown results. A deliberate open uses the same authenticated, tenant-scoped detail route and returns the same quote fields; no hidden results or earlier pages are fetched automatically.

A transient opening-origin marker returns successful Find opens and their exact retries to the confirmed review position or Find status. It is not persisted or transmitted and resets with latest-quote loading, viewer or enquiry changes and access loss. Query, filters and loaded history remain in place. The release adds no collection, endpoint, storage, schema, disclosure, permission or real-customer-data approval, and real customer data remains blocked.

The v2.46 Loaded Quote Revision Retry Continuity release gives an operational user one named recovery action when an exact saved quote revision does not open. The retry sends only the same revision number through the existing authenticated, tenant-scoped quote-detail route and returns the same privacy-reviewed quote detail fields; it does not refresh revision history or start automatically.

The previously open quote, loaded summaries, transient Find query and filters, comparison and preview remain in place until the same-viewer, same-enquiry response is verified. The release adds no collection, endpoint, background scan, storage, schema, disclosure, permission or real-customer-data approval, and real customer data remains blocked.

The v2.45 Loaded Quote Find Continuation release lets an operational user deliberately load one bounded earlier quote-revision summary page from an active loaded-only Find with fewer than eight matches. The existing private quote-history route receives only its existing opaque cursor and returns the same privacy-reviewed summary fields.

Each action loads one page only and preserves the transient query, status and validity filters, selected quote detail, comparison and summaries already loaded in the browser. It adds no automatic scan, new collection, endpoint, storage, schema, disclosure, permission or real-customer-data approval, and real customer data remains blocked.

The v2.44 Loaded Quote Comparison Continuation release lets an operational user deliberately load one bounded earlier quote-revision summary page when a selected historical comparison cannot yet see the current summary. The existing private quote-history route receives only its existing opaque cursor and returns the same privacy-reviewed summary fields.

Each action loads one page only and preserves the selected historical detail, transient Find state and summaries already loaded in the browser. It adds no automatic scan, new collection, endpoint, storage, schema, disclosure, permission or real-customer-data approval, and real customer data remains blocked.

The v2.43 Loaded Quote Revision Decision Deltas release derives three selected-to-current movements only when the historical and current privacy-reviewed quote summaries are already loaded in the browser. It uses quote currency and saved total, valid-until date and status; it reads no line items, itinerary, notes, rates, staff identity or other exact quote detail.

Same-currency amount movement uses exact saved minor units. A currency change is named without conversion or subtraction, date movement uses UTC calendar days and expiry remains a loaded point-in-time state rather than a saved edit. The summary adds no request, collection, storage, disclosure, permission or real-customer-data approval, and real customer data remains blocked.

The v2.42 Loaded Quote Revision Find & Open release lets an operational user search and filter only the bounded quote revision summaries already loaded in the current browser. It uses revision number, title, status, saved date, quote currency and total, valid-until date and expiry state and shows no more than eight matches.

The query and fixed status and validity filters are transient, clear when the viewer, enquiry or access changes and are not persisted, sent to an endpoint or used to load earlier pages automatically. Result opening reuses the existing guarded detail request. The release adds no new collection, disclosure, permission or real-customer-data approval, and real customer data remains blocked.

The v2.41 Loaded Quote Revision Comparison release compares one selected historical quote revision with the current revision only when both privacy-reviewed summaries are already loaded in the current browser. It uses only revision number, title, status, quote currency and total, valid-until date and expiry state. It does not expose line items, itinerary, notes, rates, staff identity or an exact history total.

The comparison adds no automatic request, endpoint, write, database or browser storage, cookie, schema, analytics, telemetry or external disclosure. If the current summary is on an earlier page, the user must load it deliberately. Opening the current revision reuses the existing guarded detail path. No personal-data or real-customer-data permission changes, and real customer data remains blocked.

The v2.40 Readiness Sequence Return Phase Order Context release adds Phase order: Define → Control → Operate → Approve to the existing approval-sequence return description. The value derives from the established ordered public readiness-phase labels and contains no customer or record data.

The context adds no script, focus management, request, browser or database storage, analytics or external action and changes no gate, phase, route permission, position, status, evidence, approval or personal-data permission. Real customer data remains blocked.

The v2.39 Readiness Sequence Return End Context release adds Ends with Approve · Gate 7 of 7 to the existing approval-sequence return description. Both values derive from the final established public readiness phase and contain no customer or record data.

The v2.38 Readiness Sequence Return Start Context release adds Starts with Define · Gates 1–2 of 7 to the existing approval-sequence return description. Both values derive from the first established public readiness phase and contain no customer or record data.

The v2.37 Readiness Sequence Return Context release gives the existing Back to approval sequence route one visible 4 approval phases · 7 gates destination description. Both values derive from the existing public readiness collections and contain no customer or record data.

The v2.36 Readiness Status Guide Sequence Return release adds one native fragment link from the existing named gate status guide to the approval sequence below. Its fixed visible and accessible wording contains no customer or record data.

The link adds no script, focus management, request, browser or database storage, analytics or external action and changes no gate, phase, route permission, position, status, evidence, approval or personal-data permission. Real customer data remains blocked.

The v2.35 Readiness Sequence Status Guide Link release adds one native fragment link from the approval-sequence Status definition to the existing named gate status guide. Its fixed visible and accessible wording contains no customer or record data.

The v2.34 Readiness Sequence Status Definition release adds one exact Status term to the approval-sequence guide. It explains that Status describes a gate's current evidence and approval state in the existing status guide and remains part of the same named guide for all seven sequence destinations.

The added definition contains no customer information or record content. It adds no script, request, browser or database storage, analytics or external action and changes no gate, phase, route, position, status, evidence, approval or personal-data permission. Real customer data remains blocked.

The v2.33 Readiness Register Position Definition release adds one exact Register position term to the approval-sequence guide. It explains where a destination or phase range sits in the fixed seven-gate readiness register and remains part of the same named guide for all seven sequence destinations.

The v2.32 Readiness Approval Phase Position Definition release adds one exact Approval phase term to the approval-sequence guide. It explains that the label describes where a phase sits in the fixed four-phase approval sequence and remains part of the same named guide for all seven sequence destinations.

The v2.31 Readiness Sequence Gate Approval Phase Positions release gives every continuing approval-sequence gate destination its parent phase's exact position within the established four-phase sequence. Each visible and accessible Phase N of 4 value reuses the same mapped position already shown by its phase-start destination.

The added position contains no customer information or record content. It adds no script, request, browser or database storage, analytics or external action and changes no gate, phase, route, position, status, evidence, approval or personal-data permission. Real customer data remains blocked.

The v2.30 Readiness Gate Navigation Approval Phase Positions release gives every previous-gate and next-gate destination its parent phase's exact position within the established four-phase sequence. Each visible and accessible Phase N of 4 value derives from the same fixed phase order used by the approval overview.

The added position contains no customer information or record content. It adds no script, request, browser or database storage, analytics or external action and changes no gate, phase, route, direction, status, evidence, approval or personal-data permission. Real customer data remains blocked.

The v2.29 Readiness Status Gate Approval Phase Positions release gives every status-grouped Matching gates destination its parent phase's exact position within the established four-phase sequence. Each visible and accessible Phase N of 4 value derives from the same fixed phase order used by the approval overview.

The added position contains no customer information or record content. It adds no script, request, browser or database storage, analytics or external action and changes no gate, phase, route, status group, count, evidence, approval or personal-data permission. Real customer data remains blocked.

The v2.28 Readiness Index Approval Phase Positions release gives every fixed Jump to gate destination its parent phase's exact position within the established four-phase sequence. Each visible and accessible Phase N of 4 value derives from the same fixed phase order used by the approval overview.

The added position contains no customer information or record content. It adds no script, request, browser or database storage, analytics or external action and changes no gate, phase, route, status, evidence, approval or personal-data permission. Real customer data remains blocked.

The v2.27 Readiness Gate Approval Phase Positions release gives every detailed readiness gate header its parent phase's exact position within the established four-phase sequence. Each visible Phase N of 4 value derives from the same fixed phase order used by the approval overview.

The added position contains no customer information or record content. It adds no script, request, browser or database storage, analytics or external action and changes no gate, phase, route, status, evidence, approval or personal-data permission. Real customer data remains blocked.

The v2.26 Readiness Approval Phase Positions release gives every approval phase its exact position within the established four-phase sequence. Each visible Phase N of 4 value and exact accessible name derive from the same existing phase order and total.

The added position contains no customer information or record content. It adds no script, request, browser or database storage, analytics or external action and changes no phase range, gate, route, status, evidence, approval or personal-data permission. Real customer data remains blocked.

The v2.25 Readiness Approval Phase Register Ranges release gives every approval phase its exact first-to-last range within the fixed seven-gate register. Each visible Gate N–N of 7 or Gate N of 7 range and exact accessible name derive from the same existing phase group.

The added range contains no customer information or record content. It adds no script, request, browser or database storage, analytics or external action and changes no gate, route, phase, position, status, evidence, approval or personal-data permission. Real customer data remains blocked.

The v2.24 Readiness Approval Sequence Register Positions release gives every phase-start and continuing-gate destination its exact position within the full seven-gate register. The visible Gate N of 7 value and accessible name derive from the same fixed public register.

The added position contains no customer information or record content. It adds no script, request, browser or database storage, analytics or external action and changes no gate, route, phase, status, evidence, approval or personal-data permission. Real customer data remains blocked.

The v2.23 Readiness Gate Navigation Register Positions release gives every previous-gate and next-gate destination its exact position within the full seven-gate register. The visible Gate N of 7 value and accessible name derive from the same fixed public register.

The added position contains no customer information or record content. It adds no script, request, browser or database storage, analytics or external action and changes no gate, route, phase, status, evidence, approval or personal-data permission. Real customer data remains blocked.

The v2.22 Readiness Status Gate Register Positions release gives every status-grouped Matching gates destination its exact position within the full seven-gate register. The visible Gate N of 7 value and accessible name derive from the same fixed public register.

The added position contains no customer information or record content. It adds no script, request, browser or database storage, analytics or external action and changes no status group, gate, route, phase, status, count, evidence, approval or personal-data permission. Real customer data remains blocked.

The v2.21 Readiness Index Register Positions release gives every fixed Jump to gate destination its exact position within the full seven-gate register. The visible Gate N of 7 value and accessible name derive from the same fixed public register.