Appearance
Coverage and verification
OSERP Academy is a living reference. This founding edition describes the repository baseline 0.4.0. A hosted application may run a different release.
Coverage measures
| Measure | Count | Meaning |
|---|---|---|
| Application pages discovered | 87 | Includes setup and sign-in pages |
| ERP page files | 82 | Page-level inventory, not distinct business processes |
| Extracted labelled controls | 940 | Screen occurrences; the same business field can appear more than once |
| Controls needing manual identification | 428 | Dynamic or ambiguous bindings; not silently counted as documented |
| Database models inventoried internally | 189 | Includes system models; not all are public business entities |
| API operations inventoried internally | 685 | Controller declarations, not independently exercised operations |
| Authored academy pages | 27 | Guides, reference chapters, and learning material |
| Runtime-verified academy walkthroughs | 0 | No operational walkthrough is claimed as runtime-tested in this edition |
How to interpret evidence
Reviewed guide: written after inspecting named implementation sources. Useful operating guidance, but it can still require a demonstration against the deployed release.
Extracted reference: literal screen labels and declared constraints obtained from source. It does not infer missing limits or prove the effects of a setting.
Runtime verified: reserved for a documented walkthrough completed against an identified release using demonstration data, including its resulting records. No entry currently carries this status.
Planned: educational or product capability that is not available yet. Future certification and international recognition belong here.
Remaining work before exhaustive coverage
- Resolve every ambiguous or dynamically generated field.
- Join each field to its actual request validation, saved default, and storage constraints.
- Trace consequential settings through every consuming workflow.
- Execute positive and negative cases for every operation and role.
- Capture demonstration screenshots and Arabic/RTL walkthroughs.
- Review accounting and region-specific material with appropriate subject specialists.
- Recheck differences between this baseline and the published application.
The screen directory provides the module-by-module work list. The internal audit retains source hashes so changes can be detected without publishing private implementation files.