MP2X Software Specification
Version Control
| Version | Date | Changes |
| 0.1 | May1, 2011 | Initial Draft |
Product Overview
The Micro Prediction Market Project (MP2X) is a tool to take submitted ideas, assign a value for an idea based on a small group’s analysis, and present a dynamic view of values compared to all other issues under consideration. MP2X is, essentially, a Prediction Market tool for small groups. A Prediction Market is essentially, a tool for comparing the relative importance of a select number of issues based on values placed on those issues by users, usually in a market based method using credits that are used to “buy” issues, “sell” issues, with a market value being calculated for each issue, which correlates to the issues potential for success.
Traditionally, Prediction Markets are products of large corporations, industries, or even crowd-sourcing projects. One of the earliest examples of a prediction market is The Hollywood Stock Exchange (www.hsx.com), which allowed anyone to sign up for free and participate in a simulated stock market that traded in upcoming movies, tying their value to expected revenue from movies coming out. HSX.com is able to make remarkably accurate predictions about the success of upcoming movies based on the movement and expected valuations of movie “stocks” that they track between users, though they are not without critics.
What if you want the wisdom of the group, but you don’t have a group of thousands? There are dangers in relying on the wisdom of a small group. Studies have shown that individual decision makers can be more reliable than decisions that are made through small group consensus. The reason for this is the distortion of individuals who can influence those in the group that are naturally conflict averse. If there is not a careful system of controls introduced to ensure that all individual inputs are equally weighted, then a system that relies on the wisdom of crowds can become quickly twisted inside out.
A key step in any decision making process is the ability to define the problem, review all viable options on an equal footing, and then make a selection based on defined success criteria. MP2X helps to provide this by presenting issues abstracted from their proponents or sponsors, allowing individuals to analyze the value of an issue, and apply a price to that issue relative to all issues under consideration. The reason for this need to maintain integrity between users that are buying and selling issues is to ensure that no single user, or a small block of users, don’t “game the system” by artificially downgrading issues they don’t favor or artificially inflating the value of issues they favor. This would derail the impartial value of the MP2X application from being able to accurately measure individual’s input into the process of deciding which issues will hold the greatest chance of success.
MP2X is designed to give small groups a tool to make better decisions, but it must be used with an understanding of human nature and decision making dynamics, otherwise the administrator of MP2X runs the risk of being another fool with a tool. All participants in a decision making process need to be given equal time to process the options in a decision, and then submit their choices for group review without fear of repercussion. A natural dynamic in group decision making processes that corrodes the ability of small groups to make optimal decisions is the bias of vocal, strong willed individuals to cause the rest of the group to gravitate toward their point of view, regardless of its merits.
Product Features
MP2X Core - Connects all of the MP2X modules together, presents the central interface, and performs error checking between modules.
Submission Engine - MP2X Allows proposed ideas to be presented in a neutral framework, abstracting the ideas from the presenter of the idea.
Ticker Engine - Matrix of active issues and their values where all users can see the status of active issues
Bid Engine - Portal that allows individuals to view their account of points (a generic unit of transaction, related to the value of an issue), and “buy” and “sell” a share in the future of an issue.
Administrative Console - The administrative console that allows issues to be placed into the market, issues to be killed, and issues to be selected for implementation.
Project Schedule Summary and Timeline
● Draft Design of Modules complete by May 1, 2011
● Working Alpha of Modules complete by May 7, 2011
● Completed Project Delivered by May 15th, 2011
Software Design
Functional Requirements - MP2X must be able to provide an interface for:
○ Introducing new issues for consideration
○ Managing the application
○ Viewing the value of all issues in relation to each other4
○ Providing a bid process to allow individual users to provide weight to each issue relative to all other issues.
○ Providing reporting on the results of multiple issue comparison to allow a group to act on their analysis.
Hardware Requirements
MP2X is designed to fit inside the footprint of Amazon’s Elastic Compute Cloud Micro Instance, a free/low-cost cloud based computing option. The requirements for this OS are:
● 613 MB RAM
● 64 Bit OS
● 1 vCPU
● 10 GB Storage
Installation
MP2X is designed to be installed as an Ubuntu installation package that will install all binaries for MP2X in the correct directories, as well as any necessary installation scripts.
Client-Server Diagram -
There are two separate interfaces for interacting with the MP2X server: The User Interface, and the Administrator Console. The entire infrastructure can be hosted either in an internal network, or can be hosted via a cloud infrastructure, with server and data separate from users and administrators.
New issues are submitted by users, approved by a central administrator, and then placed into a marketplace for bidding and selling to determine their relative value. The administrator is a facilitator in getting an accurate assessment of the market’s relative values for issues, not a bidder, seller, or an influence in the marketplace.
Program Flow Chart
The primary process modules for the MP2X application are:
● The Admin Console
● The Submission Portal
● The Ticker Interface
● The Bid Console
● The MP2X Core
There are additional modules used for authentication, internal accounting, and user interfacing. The Bid Engine, during development, has been separated from the sales process into a separate module, for ease of troubleshooting and future changes.
Below is a more detailed listing of the separate modules, with detail on each modules key functions. Each module is color coded for ease of association.
Each section of modules will be detailed below.
Authentication
In keeping with the design philosophy of this application to keep honest people honest, a means of authenticating users is needed to ensure that outcomes of issue comparison are not being “gamed”. MP2X can either keep user names and passwords in a simple local data file, or it can perform LDAP look-up functionality for environments that have an existing Active Directory infrastructure. In the Administrative console, in advanced settings, there is the ability to set a value of “1” for the LDAP configuration variable. If this is set, then LDAP becomes the primary means of authenticating users. If it is not set, then the user-name and password is performed against a local data file. Once this process is complete, for the user session involved, a value of “Yes” is stored for the UserAuthenication variable, the Authentication module exits, and control is returned back to the User Interface module.
User Management
The User Management module is related to the Administrative module, and is where user accounts are added or deleted.
When new users are added, it is necessary to re-calculate the total market value, based on the default number of credits that are issued to each user. As more users are added, each user becomes a smaller minority in the market, therefore new users have the effect of diluting all other user shares of the market. When a new user account is created, the user name and password is passed back to the Authentication module for storage in the authentication database.
Deletion of users has the additional process of creating a validation step and dialog with the administrator before deleting a user account. Once the decision to delete an account is finalized, then it is removed from the Users Database, the total number of users is decremented by one (this is used in market value calculations), and a request is sent to the Market Value Engine to recalculate total market value based on a smaller number of users.
Issue Administration
The third main task for the administrator is management of issues being put before the group for review. This module involves adding new issues to the market for consideration, and removing issues from consideration.
When adding a module, the administrator is presented with an Issue Review screen, where all current active issues are displayed, along with submitted issues in the submission queue. Administrators do not create new issues, but they are responsible for adding them to the market. This acts as a check and balance to ensure that one person cannot remove an issue from consideration by replacing it with an obviously unpopular issue.
A process that utilizes the functions of the Issue Administration module, but does not require administrator input is when an issue reaches the end of its life. Every issue is launched with a given lifetime for consideration, to prevent an issue from being endlessly considered. At the end of its lifetime (which can be adjusted in the Administrator console, advanced menu), an Issue Termination Signal is sent to the Administrative Console module to remove the issue from teh Issue Database, recalculate total market value, and send an email via SMTP (Simple Mail Transfer Protocol) to all subscribed users of this instance of MP2X.
MP2X Core Process
The MP2X Core Process module involves no user or administrator input, but rather manages a number of looping process that checks for the presence of new issues in the issue submission queues, and when an issue is detected, an email is sent to the administrator asking for approval of the submitted issue. This module is also responsible for maintaining the countdown timers for all of the submitted issues.
User Interface Process
The User interface involves a log-on process that captures a user’s name and password, sending it to the Authentication module, and returning either an error screen, or presenting the user with a series of menus (View Ticker, Bid Menu, Sell Issue, or Exit).
Ticker Engine
The Ticker Engine is responsible for displaying all of the active issues under consideration in a grid, with issues displayed vertically, and their values being populated in rows. The Ticker Engine dynamically recalculates the view of the issues/value grid based on the number of active issues being displayed. There are a fixed number of issue for consideration, but that number can be changed in the Administrative Console. There is also the possibility that there are fewer issues than slots available. The Ticker Engine also has a process loop that waits a defined period of time (also configurable in the Administrative Console - Advanced menu) and then initiates a refresh of the Ticker, ensuring an accurate display.
Bid Engine
The Bid Engine is called from the User Menu when a users wishes to utilize their credits to bid on individual issues. Authentication is validated within this module at the beginning of the process, and then a query is sent to the Accounting Engine to determine how many credits the user has to bid with. There is an error checking process to determine that more than zero credits exist (resolving problems with no or somehow negative credits). A display of active issues is presented to the user, and input on which one to bid on is received, along with a request for the amount bid. This is all captured in a predefined input form that is archived after each bid. A validation step to ensure that the values entered into the Bid Form are correct, and then the accepted bid information is displayed. The record is sent to the Bid Archive, and a request is sent to the Market Value engine to recalculate total market value, based on the reduced number of credits available in the market as a result of this purchase, and as a result of the increased share of interest in the issue that was bid upon.
Sell Engine
The sell engine re-utilizes much of the code from the Bid Engine, including the process of validating authentication with a call back to the Authentication module. The sell engine lists the issues that are actively owned by the user, and requests that the user select one of their issues for sale. It lists the current market value of the issue to be sold, and before the sale is accepted, inserts an error control step requesting the user validate that everything is correct before final sale. Once the sale is validated, the sale is sent to the SaleRecord archive, and a request is sent to the Market Value Engine to recalculate total market values.
Submission Engine
The Submission Engine module is a simple, forms based process to capture all of the relavant information for each issue that a user wants to submit for consideration in the MP2X marketplace. Once an issue is submitted into the Issue Submission queue for administrator approval, the module closes out and returns the user to the User Interface menu.
Market Value Calculator
The Market Value Calculator is part of the MP2X core functionality, but for the purposes of granularity, it is set up as a separate module. There are a number of events that can launch a recalculation of market value, including a change in the number of issues under consideration (either through an issue reaching the end of its life, or when new issues are administratively approved), or when a user bids on or sells an issue. When any of these events happen, the Market Value Calculator module is called. The algorithms for how much a change in an issue’s value or in total market credits available are functions of multiplier variables that are set in the Administrative Console, advanced section. These multiplier variables can be set to cause larger or smaller changes in total market value based on buys and sells. This is necessary due to make sure that a small number of players can’t cause unsustainable large market swings, or that in markets with a large number of players, bids and sells are not insignificant in effect.
Accounting Module
The Accounting Module is responsible for calculating the value of individual user’s worth in the MP2X market, as well as the total value of all credits in the market. These calculations are then fed into the MarketValue engine to calculate market value. When total market value is changed in the MarketValue engine, input is received to recalculate the total number of credits available in the market. This information is then sent to be recorded against each users account, so that users can see the ratio of their credits versus total credit available on the market (seeing their credits relative value on the market will assist users in making valid decisions when deciding to bid or sell). Within the accounting module are error checking features to ensure that users are valid users. If users are not valid, entries are made to the AccountingError Log, and a message is sent to the administrator via email alerting them to an accounting error.
Design and Implementation Constraints
There are a number of limitations with MP2X as currently designed:
● Scalability - MP2X, in its current iteration, is not designed to be highly scalable. It is projected to support from 5-100 users and 10-100 issues, with performance expected to drop off significantly as the number of users and issues increases. If this application were needed to scale beyond this number of users, the flat data arrays used to store user credentials, user credits, bid and sell records would need to be changed over to some type of relational database such as MySQL or similar.
● Application Security - MP2X, in spite of the leveraging of LDAP for user authentication, is not currently designed to be a highly secure application, and should not be relied upon for sensitive decision making processes. Some steps that could be taken in the future to harden MP2X from security exploits would be a comprehensive review of all code to ensure there are no areas vulnerable to stack overflows, injection exploits, or any other common hacking techniques.
● Client-Server Security - There has been no effort made in this iteration of MP2X to encrypt communication between client workstations and the MP2X server. In the future, it would be important to encrypt all communication between the client web browser and the MP2X server with an SSL tunnel authenticated by an SSL certificate for the MP2X server.
● Basic Interfacing - The current iteration of MP2X relies on very basic option menus, with no attempt to create more advanced context sensitive menus.
● Game Theory Testing - A game with complex rules will inherently create an environment that will invite clever means of circumventing the intention of the game (cheating), whether consciously, or via an expression of bias. Extensive user testing has not been accomplished to determine optimal weighting of the market calculation functions, to ensure that a single user cannot sway the market unfairly.
Assumptions
Networking - This application assumes the presence of high speed, low latency networking is available between clients and the MP2X server.
Security - This software is assumed to be used for low security applications. It has not undergone a code review for application security.
Hardware - The hardware for the MP2X server is assumed to be at least as capable as an Amazon EC2 Micro-Instance (see hardware requirements earlier in this post)
Web Browser - The web browser used by administrators and users to connect to MP2X is assumed to comply with modern web standards. Installation Package - It is assumed that the MP2X server is being installed on a current version of Ubuntu, and that supported installation package management software is being leveraged.
User Interfaces
This section describes the main user interface screens, their menus, and any key aspects of their interfacing.
Login Screen
Two entry text boxes are displayed:
● User Name
● Password
Administrator Console
The Administrator Console has the following menu structure:
● Review Issues Screen
○ Select Issues for Review
● Change Values Screen
○ Change Issue Multiplier
● User Management
○ Add User
○ Delete User
● Advanced Options
○ Enable LDAP
○ Issue Default Lifetime
○ Multiplier Variable
○ Ticker Engine Refresh Period
User Interface
The User Interface has the following menu structure:
● Submission Menu
○ Submit Issue
■Submission Input Form
○ Queue Issue
● Sell Menu
○ Select Issue Menu - Selects issue from user's portfolio of issues
○ Sale Form
○
● Bid Menu
○ Bid Issue Menu
○ Bid Menu
■Bid Form
● Ticker Interface - Select option to go to Ticker Interface
Ticker Interface
The ticker interface - Interface is arrayed as a matrix of issues vertically with the following arrayed in horizontal rows:
● Issue Name
● Value
● Date Released
● Date Expiring
● Issue Narrative
The only user input in the Ticker Interface Menu is the Return to Menu button that is used to return to either the User Interface or the Administrative Interface, whichever the user entered the Ticker Interface from.
Operating Environment(s)
Server - The server operating environment is a lean instance of a current version of Ubuntu server (currently version 10.10).
Documentation
This section is for the detailed MP2X application documentation. As the application undergoes further development, this section will be further developed in tandem. In the current version of MP2X (0.1), there is a minimal amount of documentation available.
Change Log
Current Version of MP2X software - Version 0.10 - Initial Alpha Build
This is the initial build of the MP2X software, before any initial user testing. No interface, security review, or other functionality testing has taken place.
Help File
Once all modules for MP2X have been completed and initial interface testing is complete, a Help file will be written for each of the interface screens. Context sensitive help is planned for the next version of MP2X
Glossary
Administrator - Central person charged with managing the MP2X server. This person is usually a semi-technical administrator with an interest in the outcomes of the MP2X decision making process.
Bid - The process where a user will use their personal credits (assigened by the Administrator) to “buy” shares of an idea that they believe will be successful in the marketplace.
Issue - An idea for consideration that takes up a pre-defined number of slots in the MP2X application that will be presented for bidding and sale by users to determine its value relative to other issues under consideration.
LDAP - Lightweight Directory Access Protocol is used to communicate with a directory services database to authenticate user authenticity by comparing an inputted user name and password against the directory services database.
Market Factor - The multiplier that is applied to each user’s credits to determine an issue’s total market value. The multiplier can be set higher or lower, based on the number of users on the system. The purpose of this is to prevent a single user from being able to dominate voting, while ensuring that a single user in a system with a large number of users still has enough weight in the process to make a selection that can move the value of issues on the market.
MP2X - Micro Prediction Market Project, an open source project designed to provide prediction market capabilities to small groups.
Sell - The process of removing an issue from a user’s personal portfolio, and returning a number of credits back into their account equivalent to current total market value
Ticker - A grid interface showing all issues, their values, and giving a brief narrative of the issue.
Ticker Refresh - The rate at which the Ticker Interface refreshes the view of issues under consideration.
Total Market Value - The value of an individual issue, in credits, multiplied by a factor set by the administrator based on the number of participants in an MP2X decision making process.
User - A participant in the MP2X decision making process who “buys” and “sells” issues to reflect their belief in the value of an issue relative to other issues presented.
Issues List
There are currently no issues in this initial build documentation. Issues with the MP2X application will be tracked here in the following format:
X.YYY.MMDDYYYY
X - Issue Type
○ U - User Interfacing
○ A - Administrator Interfacing
○ E - MP2X Interfacing
○ L - LDAP service
○ M - SMTP service
○ X - Algorithm issues
YYY - Serialized issue Number
MMDDYYYY - Month, Day, and Year of issue entry into this documentation.
Release Notes
Additional Release Notes on the MP2X application will be maintained in this section.
The initial build of this application was designed, written, and coded by Jon A. Hallgrimsson.
