Rohan Qevmarsi

Areas of practice

Systems that retain the meaning of a transaction

01

Catalogue editions that preserve the invitation

I help auction owners distinguish a current inspection from the edition on which a participant was invited to act. The distinction becomes practical when a description changes after publication: someone must retain the earlier basis, explain the amendment and decide the commercial consequence. My own catalogue error showed why keeping only the newest text is inadequate. I work with operations to define the states a system should preserve and the evidence needed to reconstruct them when something goes wrong. Where an earlier version cannot be established, I keep that limitation visible instead of backfilling an apparently certain account. The useful result is a record on which authorised commercial owners can decide whether to amend, reoffer or withdraw a lot. It is not an IT opinion on vehicle condition, value, title or the legal effect of a particular auction term.

02

Bidder identity beyond a contact record

A bidder's email, representative and contracting entity are related facts, but they do not mean the same thing. I design workflows that let appropriate owners distinguish routine contact maintenance from a proposed change in the participant behind an existing bid. In our fictional review, thirty-one requests concerned the same entity and eleven introduced a different one. Treating all forty-two as an address-book exercise would have obscured a commercial decision. My contribution is to preserve the original participant, the proposed change and its approval state so an operator cannot accidentally transfer a transaction by editing a field. Relevant commercial and qualified identity-review colleagues retain their judgement. I do not describe the workflow as proof of statutory compliance or assume that a technically valid record establishes a participant's authority to act.

03

Recovery that respects the auction decision

I separate restoring a service from deciding whether the interrupted auction should continue. Engineers can establish that the platform is available and explain which activity was preserved. Commercial owners must consider the affected participants, timing, terms and proposed next step. The twenty-seven-minute interruption in this profile led to a pause and next-day reoffer of forty-eight lots, even though restoring the platform was technically possible sooner. I help teams prepare that separation before an incident so a health check cannot restart a commercial process by default. The response also needs consistent notices, a record of the chosen treatment and clarity about costs. I discuss recovery as a joint operating arrangement, with IT accountable for its evidence and service work, rather than claim that uptime proves the commercial outcome was fair or complete.

04

Sensitive changes with distinct decision owners

Seller settlement details and retained auction records require different authority from routine platform administration. I work with treasury and appropriate professional colleagues to make those differences explicit in system states and access. A bank-detail change may remain held even after its format is valid, and a file may remain preserved even after its normal housekeeping date. The system should show what has been decided, by whom and what remains open, without exposing unnecessary sensitive material to every operator. My remit includes implementing the agreed workflow and explaining its limits. It does not include releasing seller funds or determining a legal retention period. I judge the design by whether the responsible person can make and evidence the actual decision, including a deliberate decision to wait, rather than by the number of changes processed automatically.

How I lead

I once let the latest inspection replace the catalogue record without preserving the edition bidders had seen. A more current screen had become a less faithful account of the transaction. I now ask which version, identity and commercial decision the system must preserve before asking how quickly it can refresh.

In practice

Decisions and their consequences

Case 01

The current catalogue had erased an earlier invitation

In 2019, while I was IT director, an inspection update replaced the published descriptions of thirty-nine lots within a 240-lot catalogue. The other 201 descriptions were unchanged. I had approved a design that prioritised the latest record and did not preserve each published edition. When commercial colleagues needed to establish what participants had originally seen, a current description could not answer the question. The failure belonged in my account, even though my team had implemented the approved design correctly.

One proposal was to rebuild the earlier catalogue from the inspection team's recollection and continue with an explanatory notice. That would have avoided a new offering process and reduced disruption to the yard schedule. I opposed treating recollection as an established earlier edition. We needed to distinguish a supported reconstruction from an assumption, then let commercial owners decide the consequence for each lot. The business could not recover the missing evidence simply by making the application look complete again.

We funded ₹42 lakh of repair work and examined the retained material with operations. Twenty-seven previous descriptions could be reconstructed from supported records. Twelve could not. The replacement design retained publication editions separately from later inspection updates and made amendments visible to the responsible operating team. I explained the uncertainty to Maya and Arun without claiming that version history could retrospectively repair the decision already presented to bidders. The commercial owners then reoffered nine of the twelve lots through fresh invitations and withdrew three.

The result was deliberately uneven: twenty-seven reconstructed editions, nine new offers and three withdrawals. It was not a claim that all thirty-nine original invitations had been recovered, that no participant had been inconvenienced or that IT had determined the legal effect of the earlier terms. The ₹42 lakh was programme cost, not a quantified recovery of value. Our agency did not become the owner or certifier of the vehicles because it had improved the catalogue record.

I learned that current data and faithful transaction evidence serve different purposes. A design review should ask what a participant was invited to rely on and what must remain available after a correction. I now want the commercial owner in that discussion before the field is made editable. Where the record is incomplete, the system must preserve the gap rather than let a plausible reconstruction masquerade as the event that actually occurred.

Case 02

A bidder contact change concealed a different participant

In 2022 our operators reviewed forty-two requests described as bidder-detail updates. Thirty-one involved a new contact or representative for the same participating entity. Eleven proposed a different entity. The existing maintenance route presented both as changes to a bidder record, which risked making an existing bid appear to belong to someone other than the participant who had submitted it. The request count therefore did not describe a single kind of work, even though it arrived through one service queue.

The convenient option was to let the operator update the current record and retain a general audit log. Its supporters wanted to avoid delaying legitimate contact corrections during an auction cycle. I agreed that ordinary maintenance should remain usable, but an audit log alone would not establish whether an existing transaction could transfer to a different entity. That question belonged with the appropriate commercial and identity-review owners. A system that silently attached old bids to a new participant would decide more than its operator intended.

We committed ₹71 lakh to a workflow programme that separated the proposed change from the original participant record. Operators could route the thirty-one same-entity requests through the relevant contact process, while the eleven entity-change proposals required distinct review. Existing bids retained their original association until an authorised commercial decision established the next treatment. The system displayed the unresolved state rather than treating a submitted request as an approved replacement. Qualified colleagues retained responsibility for assessing identity and authority; my team implemented the agreed decision path.

The immediate outcome was a clearer account of the forty-two requests, not a claim that every new entity was accepted or that a particular statutory obligation had been satisfied. We did not publish sensitive identity material in the general operations view. The programme cost was explicit, and the additional review introduced waiting time that the service team had to explain. Keeping an unresolved request visible was preferable to reporting a fast completion that concealed an unmade commercial decision.

This case changed how I discuss apparently small maintenance features with senior colleagues. A field can be easy to edit while the relationship it represents is consequential. I ask which earlier transactions depend on that relationship, who can authorise a change and what the user should see while the answer remains open. The lesson is not to block all contact updates; it is to avoid letting their familiar appearance hide a different participant.

Case 03

Restoring the platform did not restart forty-eight auctions

A twenty-seven-minute platform interruption in 2023 affected forty-eight lots during an auction session. The engineering team worked to restore availability and establish which activity remained supported by the system record. Commercial colleagues faced a separate question: what should happen to the affected offers and participants once the service returned? A green technical status could not establish that the auction should resume from the point at which the application had stopped displaying activity.

One option was to restart the existing clocks as soon as the platform recovered. That would have preserved the day's planned sequence and reduced disruption for sellers and yard teams. Its weakness was that the technical restart did not settle how participants should be treated after an interruption. I advised against making the application health check the default commercial decision. Arun and the auction owners needed the affected scope, surviving activity and practical alternatives before choosing the treatment, with appropriate advice where the terms required it.

The commercial decision was to pause and reoffer all forty-eight affected lots the following day. IT supported the chosen state, retained the incident record and helped ensure that notices reflected the same decision across the channels in use. The response included ₹14 lakh in buyer-fee credits and ₹63 lakh of recovery and notice work. Those were separate costs, not a measure of lost vehicle value or a claim that every participant's inconvenience had been compensated. We preserved the distinction between the interruption period and the longer commercial consequence.

The platform became available again, but the meaningful operating outcome was that no automatic restart displaced the authorised reoffer decision. We did not infer winners, ownership transfers or acceptable terms from uptime. The agency's role remained auction and yard administration rather than statutory title determination. I retained responsibility for explaining the system evidence and the recovery work, while the auction owners retained responsibility for the treatment they communicated to participants.

The lesson was to prepare two connected decisions before a disruption: technical restoration and commercial continuation. A useful recovery rehearsal should reveal who can keep a process paused after the service is healthy, how that state reaches every relevant screen and what participants will be told. Without that preparation, the apparent urgency to restore service can make an unexamined business decision seem like a routine technical step.

Case 04

A valid bank field was not a settlement instruction

In 2024 a review of twenty-four seller bank-detail change requests exposed a gap between our record-maintenance process and treasury's settlement decision. Nineteen changes could be confirmed through the appropriate owner review. Five remained held for further work. The application could validate the form of an account field, but that said nothing about whether the requested change had been authorised for a particular seller relationship. A tidy queue could therefore create an impression of readiness that treasury had not actually established.

Some colleagues proposed allowing validated changes into the live seller record immediately, with treasury reviewing exceptions before payment. They wanted to avoid maintaining two versions and reduce manual follow-up. I was concerned that the changed field might be consumed elsewhere as an approved instruction before that later review happened. The application would have made the unconfirmed state hard to recognise. I proposed retaining the requested details separately from the currently authorised settlement record until the responsible owner had made the decision.

We allocated ₹54 lakh to the workflow and access changes. Treasury and the appropriate reviewing colleagues defined the approval route; IT implemented the separation, visible status and record of the decision. The nineteen confirmed requests could progress through that route. The five held requests remained distinguishable rather than appearing as completed updates. My team did not release seller funds, decide a banking requirement or declare that a suspicious request was fraudulent. Those conclusions would require evidence and authority outside a field-format check.

The change increased the amount of pending work visible to service operators. That was a real operating cost, because a seller enquiry now required an explanation of the unresolved decision instead of a simple confirmation that the details had been changed. We preferred that friction to a system that obscured treasury's position. The review did not prove that future requests would be safe, and the programme cost was not presented as prevented loss. Its bounded result was a more faithful distinction between proposed details and authorised instructions.

I took from this case a wider discipline for systems leadership: do not let a shared master record erase the status that makes a fact usable for a particular purpose. The same bank detail can be present, syntactically valid and still not approved for settlement. A CIO should help the enterprise preserve those distinctions without becoming the person who makes the treasury decision.

Case 05

A retention date could not release a qualified hold

In 2025 we examined seventy-four auction files approaching a housekeeping decision. Nineteen were subject to holds established through the appropriate qualified process. Fifty-five were available for review under the relevant retention policy. A uniform date-based job would have treated the files alike, even though the authority to decide their next treatment differed. The problem was not simply storage capacity; it was whether the system could distinguish an ordinary review date from a continuing reason to preserve a record.

The lowest-effort option was to exclude the whole seventy-four-file group indefinitely. That avoided an immediate deletion risk but left the enterprise without a clear account of which material needed preservation and which required a normal policy decision. Another proposal was to let IT administrators remove holds when the originating team did not respond quickly. I opposed that shortcut. Delay did not transfer the underlying authority to a system operator, and a file's age did not settle the professional question behind the hold.

We funded ₹28 lakh of controls that separated the hold state, the responsible owner and the ordinary policy-review workflow. The nineteen held files remained preserved until an authorised release could be recorded. The fifty-five other files moved to the appropriate review process; that count did not mean all fifty-five were immediately deleted. Administrators could identify stalled decisions and escalate them without inventing a retention period or assuming permission from silence. Access to the underlying material remained limited to the purposes and roles agreed by the responsible colleagues.

The result was a more accurate operating list, with nineteen continuing holds and fifty-five policy reviews. It was not a statement that one retention period applied to every auction record or that the company had achieved universal compliance. The programme cost remained ₹28 lakh, and the business still had to supply timely decisions and appropriate advice. A system can preserve an unresolved obligation faithfully while the substantive work remains unfinished; concealing that unfinished work would make the dashboard cleaner but the decision less dependable.

This case reinforced the difference between administering a record and owning the reason it must exist. I want technology teams to make responsibilities visible, including the point at which they must stop and seek an authorised decision. The discipline helps the enterprise avoid both indiscriminate deletion and indefinite accumulation without turning a CIO's maintenance preference into a legal judgement.