The state of educational affairs threatens to ruin the lives of millions of children in Karnataka and much larger numbers across the country, and it would not be entirely out of place if we were to say that the the failure of the schools is gradually destroying democracy. The often repeated rhetoric of elementary education being a fundamental right ( now further enshrined in the Right to Education Bill 2009) seems to be accompanied by an inability to make the schools work for the children. It is true that over the past ten years enrollment has increased but enrollment does not mean attendance. Further attendance does not imply learning, for in many schools across the state, pupil-teacher ratios are very high and given the fact that teacher absenteeism is greater than 25%, these ratios get further skewed against children. Single teacher schools are common; multi-grade teaching even more so.

The recent EFA Global Monitoring Report titled "Overcoming inequality: why governance matters" makes, among many others, the following policy recommendations that we believe are crucial to make the school system work:

  1. Fix ambitious long-term goals supported by realistic planning and sufficient medium-to-long term budgetary allocations to ensure progress.
  2. Support equity for girls, disadvantaged groups and under-served regions.
  3. Raise quality while expanding access.
  4. Ensure that all children attending primary school for at least 4-5 years acquire the basic literacy and numeracy skills that they need to develop their potential
  5. Develop the capacity to measure, monitor and assess education quality.

It is our belief that civil society can bring about effective governance and that governance results from partnerships and civic engagements which are crucial in stimulating innovation, participation and empowerment. We will address item 5 above which is - can we and how do we develop the capacity to measure, monitor and assess education quality. We believe this can be done as long as all of civil society works together to make it happen

What gets Measured gets Done

Here are some of the issues that we believe would be useful to address so that we get a 360 degree view of every child :

  1. In the primary school system, there is a definite need to track children’s migration issues. For example, children may be enrolled in a rural school and during difficult times the family may migrate to urban areas for livelihood reasons - this means that the child will also be enrolled in an urban school and therefore counted twice. Quantification of this issue is somewhat hazardous but most construction sites in large cities like Bangalore use a migrant labour force and the children of these workers are probably enrolled in two schools or they may not be enrolled at all if they are in the age group of below 6 years.
  2. In the primary school system, there is a need to track attendance of both children and teachers on a regular basis. It is not uncommon to find out when you visit a school that declared enrollment / attendance is higher than actual. Attendance for both children and teacher communities need to be tracked.
  3. Remedial interventions are required to bring what the system calls “slow learners” to the mainstream levels. This means that we need to know who needs help and this is possible only by administering diagnostic baseline tests and logging this data on a child- by-child basis. This has to be taken across the state - the basis for this should be the number of children who need help. Currently, what happens in the government’s Parihara Bodhane programme is that teachers are asked to identify “weak” children and the number of children in these initiatives is limited by the budget. Moreover, children are not tracked because this is considered to be a burden on the teacher community . We think it is important for us to have an audacious goal of ensuring that within the next 3-5 years all children should be at mainstream levels and this will be possible through budgetary support for planned remedial interventions accompanied by teacher training and teacher support for this programme and finally, with continuous child-by-child tracking of outcomes.
  4. Once remedial efforts are completed children need to be tracked so that we can en-sure that their acquired 3R skills are not lost. Libraries are a great vehicle to track children's proficiencies.
  5. Finally, there are many spin-offs for this tracking methodology which could feed into the government budgets - one could track how effective the Mid-Day Meal Scheme is ; or outlays for innovative Government schemes like scholarships, cycles and free books distribution. Multiple civil society players could use the database (and not have to reinvent the wheel) to do their assessments and post their data onto the Karnataka Learning Partnership site for dissemination.

Karnataka Learning Partnership (KLP)

The objectives of Karnataka Learning Partnership:

  1. Create a space where all information pertaining to all children across the state should be made available. This means that it will be our endeavour to work closely with a large number of “local” NGOs across the state so that they become the channel to collect and update information on a regular basis.
  2. Get all children in Karnataka on this database within the next 3-5 years in a phased manner.
  3. Give other NGOs the ability to input data pertaining to their programmes as a layer of information on the KLP site. For example, Agastya International and Akshaya Patra both serve the same constituency as Akshara does - if they have access to child databases, then we avoid duplication of efforts and they can use the data for their own interventions and share it on the KLP site.
  4. Prepare constituency-wise reports for every elected representative - Members of Parliament, Members of the Legislative Assembly ; Corporators and Panchayat members. This will enable these elected representatives push for an effective agenda for education across the state.
  5. Help teachers and head-teachers generate accurate data for DISE reports in a timely manner. This would cover infrastructure of the schools / centres and also the learning outcomes for children.
  6. Provide the average citizen adequate information on issues pertaining to education in the state. It is our expectation that those who are on-line and visitors to KLP will find this site informative and that they would be enthused enough to add more data to the site. Over time, we hope that the participation of the community would help in catalyzing and driving demand for quality in education throughout the state.
  7. Provide good data to decision makers in government for making effective decisions on investments required for schools across the state. Also, help decision makers at various levels determine where remedial help is required the most and what capacity building needs to be done at different levels.
  8. Engage the academic community to use the data and provide analyses that would help in driving policy reforms to provide effective and inclusive education to all children.

We believe that if we all work together, it is possible for us to bring in higher levels of quality in our primary education system through a comprehensive use of governance. Nearly 80% of the children in our state use the government primary school system and it is here that, with all our support, we can ensure maximum public good.

KLP: The Vision

The Karnataka Learning Partnership will be a partnership of all NGOs across Karnataka that work with children.

We like to be honest with ourselves as to efficacy and impact of our programmes and the best way that we have found is to collect hard assessment data that we subsequently analyse. This is a challenging task as it requires technology as well as some robust, yet simple processes around the technology.

Since 2006, the Akshara Foundation has become increasingly experienced on how best to perform the task laid out above. We are now in a position to design an MIS platform that is sufficiently generic to be used in other organisations in the education sector and perhaps even other sectors.

The platform is structured as shown in the diagram below.

Open architecture

All data input to the system is via an interface which isolates the implementation of the data store from the implmentation of an MIS frontend. Similarly, data output is also via an interface.

The reasoning behind this architecture is that it make it possible to accomodate more than one organisation in one data store. We feel this is of great value in increasing the quality of the data that is collected. As the number of touchpoints for a datum increases, the better you can trust that datum. In other words, the more frequently the data is exercised, the better is its quality.

Making the aggregated data available via a webservice allows for third-parties to create mashups that look at the data in new and interesting ways. KLP's involvement need not be sought in the implementation. The model is similar to the open government initiatives of the US and the UK governments.

Use Cases

  1. Administrative
    1. Login
    2. Recover password
    3. Create users
    4. Assign privileges to users.
    5. Rollback
  2. Institutions
    1. Create
    2. Delete
    3. Merge
    4. Edit
    5. Create component
  3. Individuals
    1. Create
    2. Delete
    3. Edit
  4. Programmes
    1. Create programme
      1. Create assessment
      2. Delete assessment
      3. Group individuals into arbitrary groups
    2. Associate assessment (with individuals or institutions)
    3. Perform assessment
    4. Manage paper forms
      1. Generate forms
      2. Update received (from the field) register
      3. Assign forms to DEO. DoubleEntry aware.
    5. Create programme hierarchy
  5. Boundaries
    1. Create
    2. Merge
    3. Edit
    4. Create hierarchy
  6. View usage statistics
    1. Personal statistics
    2. Programme statistics (to be used as a progress report)

A more detailed description of each use case is below.

KLP EMS Components


Choice is PostgreSQL. The idea is that the database choice is independent of the MIS platform. This is the reason we need the API as well. An ORM can be used to further insulate the DB from design choices.



There is no hierarchy of users but a set of privileges which can be assigned (which is a privilege too) to users. The privileges are applicable to an aggregation of individuals or institutions and not globally. A user is associated to a programme and the time validity of the user will be conterminous with the programme time period.

  1. Unified Login
  2. A "My Work" component that shows aggregates of what a data entry operator (DEO) has done within a user specified time frame.
    1. A required feature, at an Administrator level (Admin), is the creation of efficiency statistics that will use the above data along with data from the double entry system to determine operator efficiency and accuracy.
    2. A useful feature at the admin level is a progress report of sorts. It could be pulled out of the "My Work" component of the users said admin manages. It will be a handy way of an overview of what is happening.
  3. A "Feedback" system, at a per page level across the system is required such that a user may suggest improvements, point bugs etc. The data so received needs to be logged with the DEO name and from which page it was triggered along with date etc. See ticket:89
  4. An audit trail is required along with revision history for all data created/modified/deleted by a DEO. For version 1, we can go with a simple revision history that does not capture changes on complex data types. See AuditTrails
  5. UserRoles
  6. System wide authentication system on the domain. Oauth, Google Connect etc. to be looked at. This is not just for the EMS but any component running on this domain including email, git, wikis etc. The idea is that a username/password combination needs to be valuable enough to not share.


  1. An admin user should be able to create, modify and delete boundaries.
  2. It should be remembered that a unit (say a school) can be referred to by multiple boundaries – for ex. School boundaries, MLA/MP boundaries.

Creation of boundaries will involve an additional step of associating existing aggregations (geographies/institutions/individuals) to the newly created boundaries. This association will imply a move and not a copy. For version 1, the boundary hierarchies to be considered are:

  1. Education -- district-block-cluster
  2. ICDS -- district-project-circle
  3. MP constituencies
  4. MLA constituencies


The minimal set of attributes that are required when creating a institution are specified in the interface specification.

The edit function will be the means of editing the owner, members and customers of an institution, assuming that the required privilege has been granted.

  1. Should be able to create, modify and delete Institutions.
  2. Should be able to bulk create Institutions.
  3. Should be able to change Institution boundaries either individually or as a group of schools. See BoundaryMapping
  4. Should be able to merge Institutions. The merging operation will require a comment that will be saved as part of the revision history.

An institution is a school or anganwadi. The types are based on the DISE categorisation.

Institution Members

The minimal set of attributes that are required when creating a individual are specified in the interface specification. These are immutable and mapped to database constraints.

  1. Should be able to create, modify and delete Institution Members.
  2. Should be able to bulk create Institution Members.
  3. Should be able to change Institution Member boundaries either individually or as a group of Institution Members – for example, transfer of Institution Members.
  4. Should be able to bulk promote Institution Members (say, students) every academic year but with granularity - some Institutions (schools)/all Institutions (schools) etc.

Institution Owners

  1. Should be able to create, modify and delete Institution Owners.
  2. Should be able to bulk create Institution Owners.
  3. Should be able to change Institution Owner boundaries either individually or as a group of Institution Owners – for example, transfer of teachers.


  1. Two supersets: Programs and Surveys
    1. Programs
      1. Generally, recurring.
      2. Association with Institution Members at center (ad hoc level of aggregation. Could be across classes and has a teacher/s assigned.), class, school/s.
      3. Has major program groups – English, Math etc.
      4. Each major program group has sub-programs – English 1, Math 1, Math 2 etc.
      5. Each sub program has assessments.
    2. Surveys
      1. Generally, one-off.
      2. Association could be with Institution Members at center (ad hoc level of aggregation. Could be across classes and has a teacher/s assigned.), class, school/s. Or with Institutions (classes, schools, other boundaries) only.
  2. The idea is that a program co-ordinator should be able to use this to define a program and the assessments as well using a program builder tool. The tool should allow for the association of the program with the hierarchies above as well as be able to define the association with the Institution Members/Institutions? and also design the assessment along with the validation required at the time of data entry for either the whole assessment or parts thereof. The entire assessment or specific fields therein could be marked for double entry. This feeds in to Forms, below.

Association of programmes to individuals/institutions is problematic. Programme co-ordinators can be presented with a list of their geographies or institutions in a treeview and selecting a node will automatically select all leaves under that node.

Screens for entry of assessments will be generated from the programme creation specification.

A preview of the paper forms associated with the programme will be generated when a programme is created. Generation of the full set of forms will have to be an offline activity and a notification will be sent to the requester when the generation is complete along with the instructions of where to obtain the forms. The form generation step will populate the formids that are associated with the programme assessment and will be used for the form receipt register.

Forms that have been updated as received in the form receipt register will be available for assignment to DEOs. The assignment will be DoubleEntry aware.


  1. The purpose of this module is to create printed forms, pre-populated with children as have been selected above, to conduct the assessments on the field.
  2. A form creator, for creating/modifying the forms that have been created in the program component. Also see FormValidation
  3. To create a unique, global and non-recurring Form ID per assessment sheet.
  4. To create PDF files as outputs, sorted by Institution (eg. school, cluster, block or similar hierarchies) as so decided in the program creation.
  5. To create blank versions of the above, with no Institution Member/boundary information, as well as a PDF.
  6. A form receiving component
    1. To log the receipt of the printed forms that have a form ID against a user.
    2. To log receipt of blank forms, that have been manually numbered, against a user and a set of boundaries that can be inherited if forms with a form ID are submitted with the same boundary. If not, then the boundaries need to be selected.
    3. The logging in this case is two fold, one against the receiver and against the giver.


  1. This is the component used to enter data so collected from the field. While it refers to assessments the use case is to enter any data in to the system where there is a linkage with paper.
  2. The idea here is that forms so received, above, are allocated to a DEO by form ID by an admin user.
  3. The DEO enters the form ID and it brings up the relevant data entry screen because of the linkage of form ID to form to program and a form ID can be queried to figure out what needs to be populated. In cases where a blank form or one with a form ID is only partially entered, it brings up the same screen and the DEO can continue working on it. However, this should not be the only way of entering data, if need be a DEO can access the assessment screen using the traditional boundary hierarchies as well.
  4. Data entry can happen in two ways.
    1. Single entry.
      1. This is straight forward. Enter the data once.
    2. DoubleEntry
      1. Double entry needs to be optional
      2. Can be the same user or different users. If different users, the data they can bring up is tied to the form IDs that have been allocated to them.
      3. It can be all data to be entered or only some. It can inherit this from the Program design component.
  5. Assessments should be lock-able. That is, once an assessment is locked, and this can be at the Program level, no modifications should be possible.
  6. The link between children and a program and an assessment should be dynamic (live) and not static. Which is to say, if the assessment for a program consists of all children in class 2 of a set of schools, any new children so collected, via the blank form, and created should populate in the assessment screen once created without the need to run any mapping scripts.
  7. Validation needs to be a mixture of client and server side.

General Note: The idea is that the design of the program/assessment is then inherited by both the form design (paper) and assessment design (on screen) components. We have been looking at xForms for this. See wikipedia and devenablers. The talk page has some discussion too.

Usage statistics

The personal statistics are read from the AuditTrails. Programme statistics will read from the form receipt register, form assignment register and the generated formids of the programme and display the current state of the programme.


  1. Sufficient checks need to be in place to ensure that deletes do not delete active children or children with assessments, schools, teachers. Or can only be done with elevated privelages. Also, there needs to be a difference between deleting and inactivating these units.




This hinges on a choice between federated versus centralised model for partners. We are tending to the federated model, even if we have to fake it, for multiple reasons and we can always move from a federated system to a centralised model.

The way we currently see it is that all of the above functions need to be able to done via the API as well. However, we can do this in a staggered manner. We'd also want for the MIS to read and write to the DB via this API and the KLPWWW to read and write to the DB from this API.

See OpenArchitecture

IV. Business Intelligence

Integrating Pentaho. See Also, DataMining.

V. Online Help

Online context sensitive help system. User manual.

Last modified 8 years ago Last modified on 03/17/10 21:01:35

Attachments (1)

Download all attachments as: .zip