WHPS × Wipro AI SDLC deep dive
Technical reference

WHPS AI SDLC operating model

Policy becomes executable while the work is still forming.

Seven lifecycle planes move one bounded work order toward release. Thirteen gates control progression; independent verifiers intervene while prevention or correction can still change the outcome.

Observability tells you what happened. A control plane determines what is allowed to happen.

Governance sets the rules; the control plane enforces them.
Follow the release contract Open technical reference
Orthographic release lattice Seven phases. Thirteen gates. One accountable release decision.
WHPS AI SDLC release lattice Seven lifecycle planes carry work through thirteen numbered control gates. Preventive controls bound the start, an inline verifier blocks and corrects work during formation, a gate verifier withholds release, evidence accumulates on a central spine, named human release authority makes the release decision, and continuous verification observes after release.
  1. BeforePreventive
  2. DuringInline
  3. Before releaseGate
  4. After releaseContinuous
Independent verification Evidence at every transition Human authority outside the verifier

Documented operating standard with applied WHPS proof; activation depth varies by workstream.

Seven-phase operating contract

Every phase bounds the AI role and ends in a human-controlled evidence handoff.

Agents accelerate execution. People retain product, architecture, risk, and release authority.

Inspect the named owners and exit criteria A failed verifier or gate creates correction, hold, or escalation work under the same accountable owners.

Agent deployment architecture · Documented standard

Agents receive a bounded work order—not standing permission.

The documented runtime separates identity, data, models, tools, workspace, and evidence from the agent that performs the work.

Governance boundary Policy · risk tier · delegation · named owner
  1. 01Work orderGoal, scope, data class, acceptance criteria
  2. 02OrchestratorRoutes tasks, budgets, dependencies, and time
  3. 03Scoped agentRole instructions with no standing production access
  4. 04Model gatewayApproved models, routing policy, usage record
  5. 05Tool gatewayAllowlisted tools, arguments, credentials, logs
  6. 06Isolated workspaceBounded files, network, runtime, and data
  7. 07Evidence streamDiff, tests, provenance, verifier dispositions
Release boundary Independent verification → evidence gate → named human decision
  • IdentityRun-specific service context
  • CredentialsTime-bound and least privilege
  • DataClassified sources and egress rules
  • ToolsAllowlist and argument policy
  • LimitsBudget, time, retries, and escalation
  • RecordMaterial actions require a recorded disposition

Verification Control Plane

Observability tells you what happened. A control plane determines what is allowed to happen.

Governance sets the rules; the control plane enforces them. Independent checks act while prevention, correction, or withholding can still change the outcome.

  1. 01Before generation
    PreventiveThe agent cannot.

    Makes prohibited actions unavailable through policy, scope, identity, or architecture.

    Blocks
  2. 02During generation
    InlineChecked while working—not after.

    Tests partial work, blocks the run, and returns a specific correction signal.

    Blocks + corrects
  3. 03Before release
    GateNothing ships unverified.

    Withholds progression until required checks and human dispositions are complete.

    Withholds
  4. 04After release
    ContinuousThe last line—not the control.

    Finds drift, regression, misuse, and operating variance after release.

    Observes
Zero-trust independenceNo agent verifies its own output. Use a different model lineage or deterministic tool, enforced through segregation of duties.
Fusion ruleAlgorithmic + agentic verification—never either/or.
Enterprise gapInline verification is the control most delivery systems lack.

Evaluation harness

Known conditions and semantic intent converge into one recorded disposition.

A verifier is a named, independently owned check with a defined trigger, scope, authority to block, and recorded disposition.

Test inputs
  • Acceptance scenarios
  • Regression corpus
  • Adversarial prompts
  • Privacy + security cases
  • Business outcome checks
Algorithmic evaluator Known conditions

Tests, schemas, scanners, policies, thresholds, contracts, and deterministic checks.

Independent agentic evaluator Intent + semantics

A separately owned evaluator on a different model lineage tests requirement alignment, reasoning gaps, edge cases, policy meaning, and adversarial conditions.

Fusion decision Policy + evidence + disposition
  1. Pass
  2. Correct
  3. Hold
  4. Escalate
Run receipt What ran · version · result · owner · artifact · waiver, if allowed
Three verification loops 01 Inner agentic while work is forming 02 Continuous integration verification before integration and release 03 Maintenance after release findings

The harness is the documented operating pattern. Specific evaluator activation and blocking authority are registered per verifier and workstream.

Thirteen control gates

Governance provides the mandate. Gates control progression and preserve evidence.

The Verification Control Plane layers across these gates; it does not create an eighth lifecycle phase.

01–04Intake + design assurance
  • 01 Initiation
  • 02 Architecture review
  • 03 Threat modeling
  • 04 Secure design validation
OwnerProduct · Architecture · Security
05–08Build + runtime security
  • 05 Code and build security
  • 06 Infrastructure security
  • 07 Dynamic testing
  • 08 Penetration testing
OwnerEngineering · Platform · Security
09–12Access + operations
  • 09 Identity and access review
  • 10 Data protection review
  • 11 Logging and monitoring
  • 12 Incident response readiness
OwnerPlatform · Operations · Product
13Final risk assessment
  • Evidence completeness
  • Open-risk disposition
  • Release and rollback record
  • Named human release decision
OwnerRelease authority
Authority remains with accountable people and governance bodies. The control plane provides the mechanism—not the mandate.

Operate + improve · Documented standard

Observability closes the learning loop after release. It does not replace controls before release.

In the operating standard, runtime evidence detects variance, routes response, and strengthens the next controlled run.

Signals
  • Behavioractions · tools · exceptions
  • Qualityaccuracy · grounding · regressions
  • Securityabuse · leakage · access variance
  • Operationslatency · availability · cost
  • Businessoutcomes · adoption · service impact
  1. 01DetectThreshold or finding
  2. 02TriageClassify impact and owner
  3. 03ContainSuspend, revoke, or roll back
  4. 04RemediateCorrect under the same controls
  5. 05Re-evaluateRun the required harness
  6. 06StrengthenAdd or tighten a verifier
Recorded outcome Telemetry · incident · disposition · remediation · verifier change
Continuous verification observes. Preventive, inline, and gate verifiers are what control progression.

Demonstration pattern + applied record

Show the work, the intervention, the decision, and the evidence—not only the framework.

The sequence is the documented demonstration pattern. The proof board separates what WHPS has applied from what remains open.

  1. 01Classify the changeRequirement source, data boundary, risk, owner
  2. 02Issue the work orderScope, tools, acceptance criteria, limits
  3. 03Trigger an inline verifierPartial work fails a named condition
  4. 04Correct in the loopSpecific signal, bounded remediation, recheck
  5. 05Hold at the evidence gateIndependent results and open gaps reviewed
  6. 06Record the human decisionRelease, hold, rollback path, and operating owner
Applied WHPS proof Evidence vault · MarketLink traceability spine (21 mapped rows; coverage is not completion) · thirteen control gates · penetration test complete · evidence packaged per gate · named release authority
Current MarketLink boundary Production-ready · CMS APIs exercised successfully in CMS user acceptance testing (UAT) · audit cycle in progress · 0 export-ready · 1 review candidate · 11 pending captures · 1 source-pending case
Adoption path Map policy → register verifiers → run one bounded pilot → inspect dispositions → expand by evidence
Inspect the operating contracts Inspect the verifier register Inspect applied evidence
AI SDLC deep dive

Choose a chapter.