The GVS Framework

► View as a slide presentation

Vision, mission, service tiers, workflow, the recruitment manifesto, the lifecycle doctrine, the knowledge hub, and the GVS manifesto — the working doctrine behind every GVS engagement, drawn from 25 years of delivery and refined on every build.

// Chapter 1 — vision, mission, ground rules

// Chapter 2 — the holistic view

Two legs, one doctrine. The Platform leg runs the intelligence layer — recommendations, predictions, automation across every module. The Service leg treats every resource as an asset, from Collect Requirements to Deliver Service. Operating contract: Approved Input → Automated Execution → Desired Output → DONE.

// Chapter 3 — three types of living

People live in different modes; software must meet each where they are. Every GVS product ships all three.

// Chapter 4 — manifesto

Five commitments of the recruitment framework

1. Requirement to offer letter — one accountable pipeline, every industry.
2. Project requirements collected as inputs — hiring-plan portfolio, ramp-up plan, resource allocation.
3. Templates, guidelines & process — industry-specific (FMCG, BFSI, Telecom) and country-specific, tracked by RAG status report.
4. Tools & techniques as add-ins and plug-ins — the framework extends, never forks.
5. Predictive analytics — expected hiring closures, support required, current status, next steps.

Workflow — hiring pipeline

Office Work as a Service — run a role, not just a tool

Any operational office role can be productised end-to-end. Worked example from Tier-1 heritage — Fault Manager:

// Chapter 5 — the lifecycle doctrine: every system is born, battles, and retires

The reference model for every GVS build and deployment. Nothing we ship is exempt: each build is born under observation, fights its battle in production, creates its successor, and ends with dignity. Refinement is the constant.

LIVE PROOF: IAS Vault lineage z33 → z39 — every build born under a full test regime, battling in production, succeeded by the next. No version dies without an heir.

// Chapter 6 — knowledge hub: field notes from 25 years of OSS

Written from delivery, not from a marketing calendar. Replace each stub with the published piece as it goes live.

Want these when they publish? Email to be notified →

// Chapter 7 — the GVS manifesto: growth, value, standards

The same three letters that spell the name — Growth, Valuable, Standards — read as a living framework across three layers: Manifesto is the why, Portfolio is the what, Roadmap is the how.

Manifesto — the why

Portfolio — the what

Roadmap — the how

Direction of travel, not a commitment with dates — held to the same honesty standard as every other roadmap item on this site.

// Chapter 8 — ATDLC: the automation testing & delivery lifecycle

Every build runs the same spine: Requirements → Design (HLD/LLD) → Development → Testing → Deployment → Delivery, Support & Operations → Customer Feedback. Testing itself splits into two tracks, each scored at component and system level.

This is the exact taxonomy GVS QAS scores against as its "Test Strategy & Tooling" gate category — the doctrine and the tool are the same rubric, not two versions of the truth.

// Chapter 9 — What GVS builds: product, service, support

GVS operates as both a Product Developer and a Service Provider — and keeps the two distinct so neither gets diluted.

The tool map behind that split

// Chapter 10 — Dashboards, KPIs & reporting

Every GVS tool feeds the same reporting taxonomy, so a report from QAS and a report from CRM read like they came from one system, not five.

// Chapter 11 — Day-to-day operations, and the IAS family

Two threads that run underneath everything else: how GVS actually executes day to day, and how the IAS product family fits together.

Day-to-day operational task execution

Split across Personnel and Official channels, every operational task runs the same seven-point discipline:

1. Challenges to resolve, tracked to actual resolution — not just logged.
2. Expectations managed to retain motivation across the team.
3. Constraints identified down to the root cause of the problem.
4. Dependencies mapped to get the support and service actually required.
5. Risks matched to a mitigation plan for each one, not a generic risk register.
6. Status updates given on an end-to-end view of progress made.
7. An automation wizard suggested, based on the user's own pattern of work.

The IAS family — one umbrella, three products

IAS — Intelligence Assessment System — covers recruitment, credential/asset security, and asset lifecycle, each shipped as its own standalone tool:

// Chapter 12 — Case study: a Chief Delivery Officer's first 90 days on GVS

A composite case study — no client named — showing how a newly-appointed Chief Delivery Officer can run an entire 30-60-90 day plan on the GVS Framework, using its own tools as the evidence base instead of slides and memory.

Days 1–30 — establish foundation

Business immersion, stakeholder engagement, and a first quick win, all logged rather than assumed:

Days 31–60 — drive alignment

The quick win becomes a portfolio-wide practice, and the framework becomes the team's shared language:

Days 61–90 — deliver impact

Process discipline, client engagement, and talent development all run through the same tool set:

// Chapter 13 — The CDO Command Center: six pillars, nine KPIs

The case study above is now a running tool, not just a narrative. GVS CDO Command Center turns the role charter into an editable role charter, a deliverables checklist, and a nine-KPI executive scorecard — every status computed on-device from the number you enter, exactly like every other GVS tool.

The six delivery pillars

The nine executive KPIs

Every KPI has a fixed target range; the Command Center computes Green/Amber/Red from it, so the number in front of Top Management is never a judgment call.

// Chapter 14 — IAS Office: office work as a service ROADMAP

Every tool in this doctrine so far — QAS, PMS, CRM, the CDO Command Center — is deliberately zero-server: nothing leaves your browser except a direct call to an AI provider you've configured yourself (Anthropic for every tool — disclosed in-app, never routed through GVS). IAS Office is the one deliberate exception, and it's labelled ROADMAP rather than LIVE because of it: it needs real, live sync with Calendar, Email, Phone, and Documents, and that requires OAuth applications and a backend holding tokens — something a static offline file cannot do. Building it as anything else would mean either lying about what it does, or not syncing at all.

A Hiring Organization defines a role — its responsibilities, its daily task types, and the KPIs it's measured against — starting from a pre-loaded Recruitment/HR Operations example, editable into any other function. IAS Office keeps that role's Calendar, Email, Phone, and Documents synced through real OAuth connectors (Google Calendar/Microsoft Graph, Gmail/Graph Mail, Twilio/Zoom Phone, Drive/SharePoint), scores the day's activity against the role's KPI targets with the same glass-box, deterministic-status principle every other GVS tool uses, and — the part most office dashboards skip — opens a Corrective and Preventive Action (CAPA) ticket automatically the moment a KPI breaches its threshold, with an owner, a due date, and a required verification step before it can close. KPI results roll up into the Chapter 13 Command Center's Strategic Portfolio view alongside delivery and strategic KPIs, rather than living in a tool nobody revisits.

// Chapter 15 — the benchmark standard: what every GVS tool owes its user

The Standards pillar of the manifesto isn't a slogan — it's a checklist, and is where that checklist got written down in working code. Every data set a GVS tool holds — Reports, a KPI Dashboard, day-to-day Input Data, Export Data, and the option lists and targets that configure them — has to support the same four operations, at any point in time, with no exceptions carved out because a feature was "just a dashboard" or "just a list": Add, Modify, Delete, and Export/Import. A tool that lets you log data but not correct or remove it isn't a system of record — it's a form with a memory leak.

The five pillars, as implemented in the Platform

Auto-Backup, honestly explained

"Zero-server" and "automatic backup to a central location" pull in opposite directions — a real central backup needs somewhere off-device to write to, and the entire GVS architecture deliberately has no server to be that somewhere. Rather than quietly break the zero-server promise to get this feature, Auto-Backup uses what the browser itself can offer: the File System Access API lets a page write directly to a folder on your device (or a folder that syncs to the cloud on its own, like OneDrive, Google Drive, or Dropbox) once you grant permission — no GVS server ever sees the file. Connect a folder from any GVS tool and every other GVS tool on the same domain reuses that same connection automatically, because the permission is stored in this browser's IndexedDB, shared by origin.

// Chapter 16 — GVS VMS: vendor management & the 6-stage sourcing pipeline

GVS VMS is the newest tool built to the Chapter 15 benchmark from day one, not retrofitted to it. It runs a Vendor Master, a six-stage sourcing pipeline, Contracts, a five-KPI dashboard, and Closure Reports — the same browser-native, zero-server, Anthropic-key-only pattern as every other GVS tool, covering procurement sourcing end to end.

The six-stage sourcing pipeline

Every sourcing event moves through the same fixed sequence, and Cycle Time is measured across it start to finish:

The five KPIs

Every number is computed deterministically in JS from Vendor Master, Sourcing Pipeline, and Contracts data — glass-box, no model judgment in the figure. The two AI-assist points (drafting RFI/RFP evaluation questions, drafting Closure Report summaries) are pure narrative generation and never touch a KPI.

Benchmark standard, applied

// Chapter 17 — GVS Daily Task: a CDO-style personal task log, RAID plan & KPI dashboard

GVS Daily Task generalises a hand-sketched "office work as a service" workflow — input data, a release-wise tracking pipeline, a RAID plan, report generation — and retargets its task categories at the ten responsibility areas from the Chapter 12 CDO role: Delivery Governance, Program & Portfolio Management, Financial Oversight, Risk & Issue Management, Stakeholder Alignment, KPI & SLA Monitoring, Team Leadership & Capability Building, Vendor & Partner Management, Technology & Process Innovation, and Strategic Transformation Leadership. It is built to the Chapter 15 benchmark from day one, like GVS VMS before it.

The seven-stage tracking pipeline

Every task moves through the same "release-wise" sequence from the source sketch, and stage-entry dates are stamped automatically the first time a task reaches each stage:

RAID Plan & the five KPIs

A RAID Log (Blockers, Constraints, Dependencies, Risks/Impacts, Support Required, Challenges Foreseen) runs alongside the task pipeline, optionally linked to a specific task, exactly as the source sketch separates the "RAID Plan" from the release-wise flow. Every KPI is computed deterministically in JS — glass-box, no model judgment in the figure. The one AI-assist point (drafting Daily/Weekly/Closure report narratives) is pure narrative generation and never computes a number.

Benchmark standard, applied

// Chapter 18 — GVS VVQ: Verification & Validation Qualification

GVS VVQ answers a broader question than any single-deliverable tool before it: across every deliverable GVS Technologies ships — product, support, or service — how is it actually qualified end to end, and how does that roll up into revenue and work performance at every level from a Project Manager to the CXO? It combines a Q-Gate of acceptance criteria, the CI/CD way of working behind a deliverable, the eight-stage ATDLC verification & validation pipeline, functional and non-functional Application Under Test qualification, and a multi-level KPI dashboard, in one glass-box tool. It is built to the Chapter 15 benchmark from day one, like GVS VMS and GVS Daily Task before it.

The Q-Gate: acceptance criteria every deliverable passes through

Three weighted categories, each with its own configurable checklist, reviewed Pass / Fail / N/A with an evidence note per item:

CI/CD way of working

The DevOps model behind the deliverable — container, Docker image, and CI/CD pipeline status — reviewed the same Pass/Fail/N/A way as the Q-Gate:

The ATDLC verification & validation pipeline

Eight stages, tracked Not Started / In Progress / Done — the two testing stages carry an additional Component Level / System Level toggle:

Application Under Test: functional & non-functional qualification

The same Pass/Fail/N/A gate mechanism, applied to the test evidence itself, plus the testing-tool stack and the stability numbers it produced:

Glass-box qualification score & the multi-level dashboard

The QUALIFIED / CONDITIONALLY QUALIFIED / NOT QUALIFIED verdict is a weighted average across all seven gate categories above, computed entirely on-device — Claude only writes the plain-language risk commentary for items that failed or were marked N/A, and the executive summary. The Dashboard & Report step then rolls the deliverable up into eleven KPI metric categories (Product, Project, Service, Program, Quality, Operational, Customer, Team, Individual, Organisational, Business) plus Reports (Invoices, Feedback) and Renewals (Contract Agreements, Contract Renewals), scoped to the six-level decision-making hierarchy the deliverable is mapped to: CXO Level, Business Leadership, Operational Leadership, Director, Project Manager/Hiring Manager, and TAM (HR).

Benchmark standard, applied

// Chapter 20 — GVS Service Hub: Demand & Delivery Management

GVS Service Hub closes the loop the rest of the suite assumes: a client asks for something, GVS Technologies has to decide whether it's product, service, support, or program work, plan it against real dates, and prove it actually met the bar before calling it delivered. It runs a business-requirement register scored MoSCoW-style, a weighted demand-triage scorecard across four demand lines, a seven-stage delivery-milestone pipeline with on-device planned-vs-actual date logic, a weighted quality gate, and a glass-box delivery-readiness verdict — the same benchmark, the same on-device scoring discipline as GVS VVQ before it.

Business requirement collection

Every requirement raised, tracked through a register with a MoSCoW priority (Must / Should / Could / Won't), a category (Functional, Non-Functional, Compliance & Regulatory, Integration), and a review status (Draft, Reviewed, Approved, Rejected). The Requirement Approval Rate is the share marked Approved.

Demand triage: Product, Service, Support, Program

Four weighted demand lines, each a configurable checklist reviewed Pass / Fail / N/A — the same split GVS Technologies actually delivers against:

Delivery plan & on-time milestones

Seven stages, tracked Not Started / In Progress / Done: Intake Confirmed → Scoping & Estimation → Resourcing & Kickoff → Build/Configuration → Testing & Validation → UAT & Sign-off → Go-Live/Fulfilled. Each stage carries a Planned date and, once done, an Actual date — On Time, Late, and At Risk status is computed on-device by comparing the two, never entered by hand.

Quality gate: the bar before "done"

Four weighted categories, reviewed Pass/Fail/N-A the same way as every other GVS gate:

Glass-box delivery-readiness score & the KPI dashboard

The READY TO DELIVER / AT RISK / NOT READY verdict is a weighted blend of four on-device scores — Requirement Approval Rate (25%), Demand Triage Readiness (20%), Milestone On-Time Rate (25%), and Quality Gate Score (30%) — computed entirely in JS. Claude only writes remediation commentary for late or at-risk milestones, plus the executive summary. The Dashboard & Report step then rolls the engagement up into a KPI grid, a printable delivery record, and a milestones-at-risk count.

Benchmark standard, applied

// Chapter 21 — GVS Email Validator: on-device email risk scoring

GVS Email Validator answers the question every inbox eventually forces: is this message safe to act on? It connects to Gmail using client-side Google sign-in — no backend, the token never leaves the browser — lets you select messages individually or all at once, and scores each one against nine deterministic signals. It is built to the Chapter 15 benchmark, with one deliberate addition: nothing is ever removed without an explicit confirmation step, because a false positive here can cost more than a missed newsletter.

The nine-signal scoring engine

Every signal is weighted, tunable, and shown in full alongside the verdict — nothing is a black box:

Three verdicts, one gate

The weighted score maps to a verdict and a recommended action — thresholds are yours to tune, not fixed by GVS:

Benchmark standard, applied

// Chapter 23 — Setu eProcurement: tender, inspection and third-party assurance

Setu eProcurement covers the leg Chapter 16 stops short of. VMS runs sourcing up to contract signing; this runs what happens after a purchase order exists and something physical has to be inspected before it is accepted — tenders for goods, works and services, bid submission and evaluation, inspection scheduling, third-party inspection, Inspection & Test Plans with a reusable template library, inspection certificates, and a compliance dashboard over the whole register.

// Chapter 24 — Vortex Sales & Delivery: the order-to-delivery record

Vortex carries an order from configuration and pricing through a multi-stage approval and delivery workflow to bill submission, with an activity log, comments and attachments against each order, freight options, bulk add/modify/delete by CSV, and an email-notification log. Where Chapter 10 asks what a business measures, Vortex is the record those measurements are taken from on the revenue side: the stages an order actually passed through, when, and who approved each one.

// Chapter 25 — Stock Dashboard and Task Manager: the survival-mode pair

Two small tools that exist to prove a claim made in Chapter 3 and again in the verticals chapter — that the same architecture serves a shop with no IT budget as honestly as it serves an operator. Neither is a cut-down edition of anything. They are simply the whole of what a small restaurant, kitchen or store actually needs.

Both were retro-fitted with the shared auto-backup engine and verified against their own pre-existing restore functions, in both the new and the original backup formats. That verification mattered more here than elsewhere: these are the users least able to absorb a data loss and least likely to have a second copy anywhere.

// Chapter 26 — The portfolio register: every tool, and what is honestly true of it

A framework that documents only its best-looking products is marketing with chapter numbers. This is the whole build, including the parts that are unfinished, the one that needs a server GVS does not run, and the one that is a prototype. Status uses four words and they mean exactly what they say: LIVE — runs end to end in a browser today. PREVIEW — real and usable, but a stated part of it is not built. PROTOTYPE — the shape exists, the substance does not. STANDALONE — real, but needs a server, so it is not on this site at all.

What the register is for

Three uses, in order of importance. First, a customer can read one table and know what they are actually being offered, including the two entries that are not offers at all. Second, it makes drift visible: the Email Validator sat in a slide-mode folder for a full release, documented in one copy of this framework and missing from the other, reachable only by guessing a URL — a register would have caught that in a week rather than a quarter. Third, it is the honest denominator behind every count claimed elsewhere on this site, so a number on the homepage can be checked against a list rather than trusted.

// Chapter 27 — the three verticals: Commercial, Social, Economical

Chapter 3 described how people live — premium, balanced, survival — and committed every GVS product to shipping all three modes. This chapter is the operating consequence of that commitment: GVS Technologies is organised into three verticals that share one framework, one codebase and one architecture, and differ only in who pays, how much support is attached, and how much of the work is done for you. The public statement of this sits at the three verticals.

The four rules that hold the boundary

Where the money actually comes from

The marginal cost of one more browser-native user is close to zero — no application server, no stored records, no per-user hosting — so charging for access would be charging for a cost that does not exist. What cannot be given away is a person's time and accountability, which is why assessments, advisory, delivery leadership and configuration are the only priced items. That makes this deliberately a small business, and the constraint is real rather than rhetorical: if the Commercial vertical stays small, the pace of everything below it stays slow.