Area 01 Active
Learning & Careers
Academy pathways, capability tracks and career progression aligned to the competency framework. Competency scale: C0–C5.
Open AcademyOne institution · Multiple centres of excellence · One strategic purpose
Platform · Workspaces Home / Platform
One institution. Role-based workspaces.
The functional areas of the AMS platform layer, the role-based workspaces they serve, and the content lifecycle that governs them. Every status below reflects verified capability only — nothing is presented as operational until it is enforced and tested.
Status vocabulary
Verified complete
Implemented · testing required
Partially implemented
Blocked by dependency
Not implemented
01 — Functional areas
The nine principal areas
Each area carries a status against verified capability. Where a public destination exists on this site, the card links to it; where the capability is not yet operational, the status states so plainly.
Area 02 In development
Authors
Authoring workspace and review workflow. Configurable workflow labels are preserved as terms; no meanings are invented.
Academy contextArea 03 In development
Trainers & Assessors
Delivery quality, assessment and evidence review. Competency verification follows assessment and evidence requirements — not course completion alone.
Academy contextArea 04 Blocked by dependency
Learners
Learner workspace, progress and evidence submission require an authenticated backend and secure records, which this static layer does not provide.
Requires backendArea 05 Active
Work & Earnings
Opportunity and engagement routes, commercial activation and lifecycle services across the programme architecture.
Open programmesArea 06 Planned
Phygital Marketplace & Workplace
Marketplace and workplace discovery. Orders, payments, logistics and inventory integrations are not configured and are not claimed as active.
Portal architectureArea 07 Verified
Sectors & Capabilities
Capability catalogue and product families across the operating domains, with evidence status stated per capability.
Open capabilitiesArea 08 Active
Governance & Quality
Institutional governance, controls, quality and audit. Administrative actions remain permission-controlled and auditable.
Open governanceArea 09 Planned
Insights & Community
Technology, engineering and research notes, plus community and collaboration. No fabricated engagement metrics or member counts.
Reports & publications02 — Role-based access
Who each workspace serves
Users must only access the records, actions and workspaces authorised for their roles, with multiple roles supported per user where appropriate. Enforcement must be server-side; a static front end cannot provide it.
Role
Workspace scope
Enforcement
Public visitor
Public institutional information and discovery
Open
Registered member
Account, profile and role selection
Requires backend
Learner / candidate
Learning progress, assessments and evidence
Requires backend
Author · trainer · assessor
Authoring, delivery, assessment and review workflows
Requires backend
Professional / service provider
Profiles, opportunities, engagements and deliverables
Blocked by dependency
Employer · customer · partner
Requirements, proposals, milestones and closeout
Blocked by dependency
Administrator · governance
Users, content, frameworks, audit and configuration
Requires backend
03 — Content lifecycle
Governed from draft to retirement
Every content object moves through one lifecycle. Ownership, review responsibility, version history and publication status are recorded; retired content is not presented as current.
Configurable workflow labels
LAB LEAP COLLATE PAVER HCF LMS EMS
These labels are preserved as configurable terms. No expansions or meanings are invented here.
- Step 01
Draft
Authored and owned.
- Step 02
Review
Reviewed against standard.
- Step 03
Validate
Evidence and criteria checked.
- Step 04
Approve
Named approval recorded.
- Step 05
Publish
Status visible to authorised users.
- Step 06
Monitor
Quality issues reported and assigned.
- Step 07
Revise
Versioned revision.
- Step 08
Retire
Withdrawn from current view.
04 — Implementation status
Stated against verified capability
This public layer is a static site. Capabilities that require a trusted backend, secure records or third-party integrations are marked accordingly and are not presented as operational.
Verified complete
Public institutional information architecture, navigation, responsive layout, accessibility and the 26-chapter library.
Implemented · testing required
Portal navigation between AMS and the customer-facing commercial platform, with secure external-link handling.
Partially implemented
Capability directory, programmes and governance content — published as information, not yet as governed transactional records.
Blocked by dependency
Authentication, role-based access control, enrolment, assessment and evidence, engagements and marketplace orders — all require a trusted backend.
Not implemented
Payments, credentials issuance, logistics/inventory, and connected AI services. No simulated results are shown for any of these.
AI-assisted functions
Until an AI service is configured, AI-assisted features are unavailable or pending configuration, not simulated. Consequential decisions remain subject to human review.
5W1H control documentation
Process and control documents use a single 5W1H structure, so every governed task states the same six fields before approval.
What
The competency unit and task standard.
Why
The operational outcome and control objective.
Who
The authorised practitioner and approver.
Where
The workplace, lab or controlled environment.
When
The lifecycle stage and review cadence.
How
The workflow and evidence required.
05 — Separation of responsibilities
Two authorities, one controlled interface
AMS and Yantra Semitech remain separate applications. They share a common ecosystem language but are connected only through controlled, documented interfaces — never merged into a single site or a single commercial system.
Architecture principle: AMS is the institutional and technical authority; Yantra Semitech is the commercial operating authority. Separation of responsibilities is structural, not stylistic.
| Responsibility | AMS — institutional authority | Yantra Semitech — commercial authority |
|---|---|---|
| Institutional governance | Owns | Does not own |
| Research and technology development | Owns | Consumes approved outputs |
| Manufacturing governance | Owns | Coordinates commercial fulfilment |
| Technical validation and evidence | Owns | Uses authorised evidence |
| Institutional learning and competency standards | Owns | Uses verified credentials |
| Customer accounts and relationships | No | Owns |
| Sales, quotations and orders | No | Owns |
| Commercial marketplace | No | Owns |
| Commercial fulfilment coordination | Provides institutional inputs | Owns customer-facing coordination |
| Commercial revenue reporting | No | Owns |
| Interoperability | Provides approved institutional data | Consumes approved data and returns authorised commercial information |
Capability & facility status labels
Proposed Under development Installed Tested Qualified Operational Temporarily unavailable Retired
A capability or facility is not presented as operational without supporting evidence. Status labels are recorded, not implied.
Next step
Access is governed, not assumed
Platform workspaces are released progressively and protected by authentication once the backing service is provisioned. Until then, request access and we will route the engagement through the correct institutional channel.
Commercial enquiries — quotation, RFQ, sourcing and orders — are handled through the customer-facing commercial platform, not through AMS.