The GVS Framework
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
Standardised, AI-native operations for every enterprise function — from requirement to delivery, without heroics.
Convert client requirements and business demand into delivered product through guidelines, frameworks, methodologies, strategies, and protocols.
Real metrics only. Every delivery accounts for software used, cost, effort, testing, SLA compliance and challenges faced — with recovery and rollback plans in place before go-live.
// 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.
Requirements
Input
Execution
Quality
Service
Outcome
// Chapter 3 — three types of living
People live in different modes; software must meet each where they are. Every GVS product ships all three.
- High-profile, hassle-free about cost
- High risk appetite, celebrates every moment
- Wants white-glove: done-for-you, always available
- GVS mode: dedicated advisory & managed service
- Frugal mode, manages cost, balanced mindset
- Mid risk taker, independent life seeker
- Aligned with career and family growth
- GVS mode: full-featured self-serve platform
- Manages time, simple mode, zero complexity
- Ease of use above all; seeking support
- Emotions and trust matter
- GVS mode: assisted simplicity — live proof: IAS Vault Elder Mode (தமிழ்/EN, one-touch)
// Chapter 4 — manifesto
Five commitments of the recruitment framework
- Requirement to offer letter — one accountable pipeline, every industry.
- Project requirements collected as inputs — hiring-plan portfolio, ramp-up plan, resource allocation.
- Templates, guidelines & process — industry-specific (FMCG, BFSI, Telecom) and country-specific, tracked by RAG status report.
- Tools & techniques as add-ins and plug-ins — the framework extends, never forks.
- 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.
Learning
- Requires: attention
- Challenge: needs support
- Risk control: high monitoring & observability
- Constraint: age limit — incubation is timeboxed
- Next: ready for battle
Thinking & execution
- Requires: a mentor
- Support: moderate — it stands on its own
- Focus: high visibility
- Constraint: cost limit — it earns its keep
- Next: create the successor
Accepting
- Motivation: needs service, not features
- Profile: low visibility, high support
- Constraint: time limit — retirement is scheduled
- Next: end with dignity — users migrated, data exported, successor live
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.
Why closed-loop automation stalls at L3
The TM Forum maturity ladder is easy to draw and hard to climb. What actually blocks operators between assisted and conditional autonomy — and what it costs to unblock.
Glass-box AI in hiring: scoring you can defend
Every hiring score traces back to a question and an answer. How explainability was designed in, and why an opaque score is a liability in a regulated hire.
Born, battle, sunset: a lifecycle contract for software
The GVS doctrine written up as a working method — with the IAS Vault z33→z39 lineage as the worked example.
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
We create opportunities for investors and entrepreneurs — symbolised by the leaf & dollar: prosperity and sustainable success.
We deliver benefits for customers and venture capitalists — represented by the rising arrow: progress and shared growth.
We uphold quality deliverables with world-class support and service — embodied by the gold form: stability and trust.
Portfolio — the what
Investor programmes, entrepreneur incubation, and prosperity-driven projects.
Customer-centric solutions, venture partnerships, and progress-focused services — the live product console is the current expression of this.
Quality-assurance frameworks, global support systems, and trust-building deliverables — see the doctrine above.
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.
Expand investor networks, launch entrepreneur accelerators, and scale prosperity-driven initiatives.
Enhance customer experience, strengthen venture collaborations, and drive measurable progress.
Implement advanced QA systems (QAS), elevate global support, and reinforce trust through consistent delivery.
// 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.
System acceptance, key functionalities, and the entire workflow — checked at both component level and system level before anything moves to deployment.
Load, stress and performance — against a documented load model covering burst, peak and spike conditions, plus a dedicated endurance test.
k6 + Grafana + Prometheus for load/performance, Playwright for UI/E2E automation. Every run produces a Functional Test Report and a Stability Test Report (RPS/TPS).
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.
R&D-specific, domain-specific, technology-specific, process-holder-specific, project-specific — built once, run everywhere it fits.
All kinds of service work, shaped by market demand and project demand — the consulting and delivery leg of the business.
Support that responds to customer demand, business demand, global demand and organisational demand, all at once — not a one-size ticket queue.
The tool map behind that split
End-to-end entrepreneur automation with AI, and a helping-mindset layer for professionals navigating a layoff — built once, not client-commissioned.
· CAS Renewal · GVS PMS · GVS CRM — the office-work-as-a-service layer, one tool per operational role.
// 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.
Product, project, service, programme, quality, operational and customer metrics — plus team, organisational, individual and business metrics for people-facing tools.
Invoices and feedback — the two report types every engagement eventually produces, whether it's an interview, a quality gate, or a renewal.
Contract agreements and contract renewals — CAS Renewal's native domain, tracked the same way IAS Asset tracks personal and business asset expiry.
// 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:
- Challenges to resolve, tracked to actual resolution — not just logged.
- Expectations managed to retain motivation across the team.
- Constraints identified down to the root cause of the problem.
- Dependencies mapped to get the support and service actually required.
- Risks matched to a mitigation plan for each one, not a generic risk register.
- Status updates given on an end-to-end view of progress made.
- 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:
Hiring from all types of industries — conduct interviews, select candidates, report to HR, close the loop with an organisational feedback assessment.
Passwords, phone numbers and credentials, plus insurance policy renewals and password-expiry alerts & renewals — encrypted on device. Open →
Property, government IDs/proofs, and education & certification records — tracked with the same renewal-and-expiry discipline as the Vault. Open →
// 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:
Every inherited programme gets a GVS PMS entry — baseline milestones and a first RAID pass, on day one.
Every stakeholder becomes a GVS CRM account; every meeting is logged with a next action, building a real engagement history.
One live workstream gets a full GVS QAS gate scoring pass — an evidence-based GO/CONDITIONAL/NO-GO stands in for the usual "quick win" slide.
Days 31–60 — drive alignment
The quick win becomes a portfolio-wide practice, and the framework becomes the team's shared language:
QAS scoring extends across every workstream in PMS — a portfolio GO/CONDITIONAL/NO-GO map replaces a gut-feel status read.
The Chapter 10 KPI taxonomy is codified per team, then tracked live through PMS and check-ins.
PMS RAG status, CRM account health, and the QAS portfolio map combine into one evidence-based midpoint report for leadership.
Days 61–90 — deliver impact
Process discipline, client engagement, and talent development all run through the same tool set:
Defect and fault data run through the Chapter 8 ATDLC / RAID-governed pipeline — improvement is visible in PMS, not asserted in a memo.
CRM pipeline reviews use weighted opportunity value and risk flags — a High-risk account never reaches day 90 as a surprise.
// 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
On-time delivery rate, budget adherence, project success index — gauge charts + trend lines. Fed by GVS QAS and GVS PMS.
Cycle time reduction, resource utilization, process throughput — bar charts + heat maps. Fed by GVS PMS.
Automation coverage, workflow standardization, error reduction — donut charts + progress bars. Fed by GVS QAS and Chapter 8.
Client retention, NPS, executive satisfaction index — line graphs + sentiment indicators. Fed by GVS CRM.
Productivity per FTE, training completion, attrition rate — stacked bars + trend arrows. Fed by.
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.
| Category | KPI | Target |
|---|---|---|
| Delivery Excellence | Project Delivery Success Rate | ≥ 95% |
| Operational Efficiency | Delivery Cycle Time Reduction | ≥ 30% YoY |
| Automation & Process Maturity | Automation Coverage | ≥ 90% |
| Stakeholder Alignment | Executive Satisfaction Index | ≥ 4.5 / 5 |
| Client Engagement | Client Retention Rate | ≥ 95% |
| Team Performance | Delivery Team Productivity | ≥ 20% improvement |
| Quality & Compliance | Defect Density | ≤ 2 per 1000 |
| Innovation & Scalability | New Delivery Initiatives | ≥ 3 per quarter |
| Leadership Visibility | Reporting Cadence | Weekly updates + monthly reviews |
// 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
Every record — Demand, Candidate Pool, Recruiting Costs, Invoice rows — has Add, Edit, and Delete, not just Add. Nothing is create-only.
Assessment history isn't a write-once log: reports can be viewed in full, manually logged for work done outside the tool, edited, and deleted, with the same rendering path serving both a live report and a historical one.
Targets (RAG thresholds) are user-owned and editable, not hardcoded — the five KPIs (Time to Hire, Cost per Hire, OAR, Quality of Hire, Source of Hire) compute deterministically from Input Data, glass-box, no model judgment in the number.
CSV is bidirectional (import and export) on every entity — the tested, universal path for Day-1 bulk loads. XLSX is export-only, by disclosed design: parsing arbitrary real Excel files needs a library or a working build sandbox, neither of which this zero-dependency, offline app relies on.
Option lists (statuses, criticality, pipeline stages, source channels), KPI targets, and operational defaults live in one governed Parameters panel — addable and deletable at any time, with a protected "core" subset that KPI math keys off by name, so customizing the tool can't silently corrupt its own metrics.
Every save writes a fresh backup automatically to a folder you choose once — no manual export required to stay safe. See below for how, and the honest limits of what a zero-server browser app can actually do here.
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.
After every save, and again every ~60 seconds while the tool is open, it writes a "-latest.json" file plus a rotating timestamped snapshot (last 10 kept, older ones pruned automatically) into your connected folder.
Chrome, Edge, and Brave support silent folder writes. Safari and Firefox don't implement the File System Access API — there, the same tools fall back to a periodic auto-download into your regular Downloads folder instead.
Point the folder picker at a cloud-synced folder once, and that folder — and every tool's latest backup in it — is already on your next device before you open a single GVS tool there. Restore from inside each tool, using its own Restore data button.
// 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 demand is scoped — what's needed, budget estimate, and a manual "PO/ERP reference" text field for tying the event back to a live purchase order or ERP system, since no ERP is wired in.
Request for Information — vendor capability discovery, with an optional AI-assisted first draft of evaluation questions.
Request for Proposal — vendors respond with approach and solution detail, scored against the same AI-drafted question set.
Request for Quote — commercial terms are collected; this is the denominator for Contract Award Rate.
A contract record is created and date-stamped — the numerator for Award Rate, and the finish line for Cycle Time.
A Closure Report captures outcome, final contract value against budget, and a renewal decision, with an optional AI-drafted summary narrative.
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.
| KPI | Formula |
|---|---|
| Cycle Time | Days elapsed from Requirement Definition to Contract Signing, per sourcing event. |
| Cost Savings % | Average of (budget − final value) ÷ budget × 100, across every sourcing event that has both a budget estimate and a finalized value. |
| Contract Award Rate % | Events with a contract date stamp ÷ events that reached RFQ. |
| Vendor Performance Score | Average rating across every vendor whose status is Active. |
| Spend by Vendor Category | Contract value summed and grouped by the awarded vendor's category. |
Benchmark standard, applied
Vendor Master, Sourcing Pipeline events, Contracts, and Closure Reports all support Add, Edit, and Delete — nothing is create-only.
CSV is bidirectional on every entity; XLSX is export-only, disclosed the same way as every other GVS tool.
Vendor Category, Vendor Status, Sourcing Stage, and Contract Status are all Add/Modify/Delete option lists, with a protected core the KPI math and pipeline key off by name.
One-file backup and restore of everything the app has stored, plus per-entity CSV/XLSX export — the same data-portability guarantee as the Platform.
// 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:
The item is logged — what's reported, tracking & tracing mode, linked meeting notes.
A correction plan is set against an SLA target date — the deadline Cycle Time and SLA Adherence are measured against.
The fix or output is verified before it moves further down the pipeline.
The verified item is deployed or delivered into its target environment.
Progress is captured for the next status update — the same data a Daily/Weekly report draws from.
Stakeholder sign-off is requested and recorded — Approval Rate is measured across items that reach this stage.
The task reaches closure — the finish line Cycle Time is measured against.
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.
| KPI | Formula |
|---|---|
| Cycle Time | Days elapsed from first stage-stamp to Final Delivery Plan, per task that has reached closure. |
| SLA Adherence % | Tasks closed on or before their SLA target date ÷ tasks that have both a target date and a closure stamp. |
| Approval Rate % | Tasks marked approved ÷ tasks that required approval. |
| RAID Closure Rate % | RAID items with status Closed ÷ all RAID items logged. |
| Task Volume by Category | Task count grouped by the ten CDO responsibility areas. |
Benchmark standard, applied
Daily Tasks, RAID Log entries, and Reports all support Add, Edit, and Delete — nothing is create-only.
CSV is bidirectional on every entity; XLSX is export-only, disclosed the same way as every other GVS tool.
Category, Tracking Stage, RAID Type, and Status are all Add/Modify/Delete option lists, with a protected core the KPI math and stage-tracking key off by name.
One-file backup and restore of everything the app has stored, plus the shared Auto-Backup engine — same folder, same "-latest.json" convention as every other GVS tool.
// 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:
Workflow defined per user/role, responsibilities documented, approval chain identified end to end.
Delivery/activity scheduling confirmed, milestone dates agreed, dependencies and blockers identified up front.
Deliverable mapped to the correct dashboard level, a decision-making owner identified, an escalation path defined.
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:
Container defined where applicable, Docker image build process documented, OS/OEM/Product baseline confirmed.
Continuous Integration and Continuous Deployment pipelines configured and passing, image file versioned and stored.
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:
What the deliverable needs to satisfy is captured and agreed.
High-level and low-level design produced against the requirements.
The deliverable is built against the design.
System Acceptance, Key Functionalities, and the entire workflow are verified, at Component and System level.
Load, stress, and performance are verified against burst/peak/spike/endurance conditions, at Component and System level.
The verified deliverable is deployed into its target environment.
The deliverable reaches the customer and enters support/operations.
Feedback is captured and loops back into the next Requirements stage.
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:
| Item | Covers |
|---|---|
| Functional Test | System Acceptance, Key Functionalities, entire workflow tested end to end. |
| Non-Functional Test | Load, Stress, Performance — burst, peak, spike, and endurance load conditions documented. |
| Testing tools used | K6, Grafana, Prometheus, Playwright, UI Load Test — recorded per deliverable. |
| Reports | Functional Test Report and a Stability Test Report carrying RPS and TPS. |
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
Every category score and the overall verdict are computed in JS from your own gate results — never decided by the model.
Full qualification record exportable as JSON; printable as a standalone report.
Every category and its checklist items can be toggled off or extended per deliverable — weights rebalance automatically.
One-file backup and restore of everything the app has stored, plus the shared Auto-Backup engine — same folder, same "-latest.json" convention as every other GVS tool.
// 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:
New build or feature request, product-market fit, roadmap alignment, licensing/IP considerations.
Managed-service scope, SLA expectations, service transition plan, staffing/skills availability.
Support tier (L1/L2/L3), ticket/incident history, root-cause vs. symptom-fix, escalation path.
Program/portfolio linkage, cross-team dependencies, budget & funding, executive sponsor.
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:
Every requirement traced to a delivered feature, sign-off captured, change requests logged and approved.
Functional coverage complete, no open Severity-1/2 defects, regression passed, performance/load criteria met.
UAT completed with the customer, acceptance criteria signed off, feedback incorporated.
Solution documentation complete, support/runbook handover done, training/knowledge transfer complete.
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
Every category score and the overall verdict are computed in JS from your own requirement, demand, milestone, and quality-gate data — never decided by the model.
Full engagement record exportable as JSON; printable as a standalone report.
Every demand line and quality-gate category can be toggled off or extended — weights rebalance automatically.
One-file backup and restore of everything the app has stored, plus the shared Auto-Backup engine — same folder, same "-latest.json" convention as every other GVS tool.
// 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.
gmail.modify scope requires the connecting account to be registered as a test user until the app completes Google's OAuth verification review. See the tool's own Setup panel for the exact steps.
The nine-signal scoring engine
Every signal is weighted, tunable, and shown in full alongside the verdict — nothing is a black box:
SPF, DKIM and DMARC results, read directly from the message's own Authentication-Results header — the same signal your mail server already computed.
Reply-To domain mismatches and display-name brand impersonation — a message claiming to be your bank from a domain that isn't.
IP-literal URLs, shortened links, punycode domains, and typosquatted brand look-alikes, scored by edit-distance against a configurable watch list.
Executable and double-extension attachments, plus urgency, credential-harvesting and payment-request phrase detection in the subject and body.
Three verdicts, one gate
The weighted score maps to a verdict and a recommended action — thresholds are yours to tune, not fixed by GVS:
Below the Suspicious threshold. No action taken — left in the inbox.
Between the two thresholds. Moved to Spam via the Gmail API — never permanently removed.
At or above the Dangerous threshold. Moved to Trash — recoverable, not permanently destroyed, in case the score was wrong.
Benchmark standard, applied
Every point in every verdict is computed on-device and listed in full — the AI-explain step only translates an already-final score into plain language.
The validation log exports to CSV; the full record — log, weights, thresholds, lists — backs up and restores as one JSON file.
Scoring weights, verdict thresholds, trusted domains and watched brand names are Add/Modify/Delete, with sensible defaults on first run.
Unlike the rest of the suite, backup today is manual download/upload rather than the shared folder-connected Auto-Backup engine — not yet wired in, stated plainly rather than implied.
// 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.
Premium · Luxury mode. Operators, banks, government bodies and enterprise delivery organisations. They buy judgement and accountability — fixed-scope assessments, retained advisory, delivery leadership, platform deployment inside their own perimeter, and Office Work as a Service. The public statement of this vertical, including its recourse terms, is at commercial.html. Telecommunications is the only sub-vertical with delivered Tier-1 engagements behind it; Banking, Government, Healthcare and Manufacturing are stated as architecture fit, which is a weaker claim and is meant to read as one. This vertical funds the other two.
Standard · Balanced mode. MSMEs, startups, NGOs, academic institutions and independent professionals — the same governance problems, none of the budget. They get the full self-serve platform with no feature withheld for a paid tier, bring their own model key so the variable cost of intelligence is paid to the provider at cost, and pay GVS only where a person is genuinely required: configuration, training, a scoped review. No SLA, no named contact, no custom development inside the free tier.
Economy · Survival mode. People, not organisations. IAS Vault and IAS Asset, free, with no account, no email address and no server to upload to — plus Elder Mode (தமிழ்/EN, one-touch) and mentoring given through IEEE FNEM and Agency B. The honest condition attached: GVS cannot recover this data, because nobody but the user holds it. Export a backup; it is the only protection that exists.
The four rules that hold the boundary
Commercial fees fund the Social vertical. Commercial clients receive nothing derived from Social users, because nothing derived from Social users exists — no telemetry, no usage analytics, no aggregate insight product.
No tool gets worse, slower or more limited to make a paid engagement attractive. Features move down the verticals, never up and out of reach. There is no paid tier for the Social tools, now or planned.
All three verticals get the same architecture — on-device storage, glass-box scoring, no GVS server holding records. A fee buys a named person, an agreed response window and contracted remediation. Privacy was never the upsell.
Every tool exports its full record as one JSON file, per the Chapter 15 benchmark. Nothing is held hostage by format, and there is no data of yours GVS could withhold even if it wanted to.
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.