Funding Infrastructure – Letter to Editor

Many people opposed to Light Rail complain about the debt that taxpayers will have to service.  They are right to complain but they should also complain about all Government debt. The way ACT Treasury handle debt is unfair on existing residents. In the case of the Cotter Dam, with an expected life of 100 years, existing residents are paying 99 times more in interest than residents in 100 years time.  This was pointed out by the Independent Competition and Regulatory Commission (ICRC) who recommended that we change the way we repay loans.

If we take a Crowdsourcing variation of the ICRC recommendation and obtain the funds from today’s residents the total cost to the Community of the Cotter Dam will be 25% of debt financing and the funding profit will go to residents.  This assumes an interest rate of 4% over the 100 years.

For Light Rail with an expected life of 33 years the cost will be half the cost of using debt. Using this approach we can afford to have Capital Metro cover the whole of the ACT.

Single Customer View with Direct Connections

Kevin Cox and Lisa Schutz

The Problem – Billions In Misdirected Activity

The problem of not having a clear view of customers across organisations or groups of organisations such as Government departments, costs billions a year. The cost occurs in three ways, the billions in misdirected services that could be saved if the right people had the right information. The costs can be human lives, time wasted and organisational costs in cleaning up data and cleaning up messes after data gets mismatched. Single Customer View is an unfortunate phrase, because it misspecifies what is at stake here – nothing less than getting the job done right (whatever it is) first time.

Traditional Indexes Take Effort

Traditional approaches to achieve a single view of the customer relationship (or the citizen) work on very old school models of database management. Think of a library with an old fashioned card based catalog. If you go to a journal and want to read one of the citations you have to physically go back to the central catalog and if lucky, and it is well maintained, then it will direct you to where the citation reference is physically housed. The central catalogs are typically held at the library.  You can then go to the new location and retrieve the citation. If the location is a library that you cannot physically visit you contact the library and get an inter-library loan. Ouch. Of course anyone under 35 will probably have no idea about card catalogs. Go look them up and then ponder why in these advanced times we basically use database approaches that are about as inefficient and clunky as that!

Create a different structure – Links to similar information

So what is the alternative? Think of how you might browse journals these days. You expect a citation to have a hyperlink embedded within it. It’s like being on the equivalent of a magic carpet, being transported from citation to citation. The hyperlinks contain the knowledge of where the journal referenced is stored. In other words, hyperlinks are links in context to other relevant material.

Abstracting from this very old world analogy, what we are talking about is essentially linking of relevant ideas. And, if we set the hyperlinks up to link by content rather than location then we can create a structure that makes hyperlinks far more efficient.

If you can retrieve relevant data efficiently, then of course you can assemble information to any purpose coherently. From single customer view to identification and so forth.

So technically, what does this look like?

With Welcomer, database records have additional hyperlinks that connect similar data items for the same person in two other databases.  The databases are created by different applications and organisations who are charged with only releasing information to authorised people.  As the data is about the person and it is linked to the same data the person is authorised to access it. The application the person is using to access the data has also been authorised by the organisation responsible for the data.

This gives rise to the following data structure.

Screen Shot 2015-08-30 at 8.27.08 am (1)

This structure is different to an index structure.  It is an abstraction that creates a set of links that we can consider as a whole. Instead of thinking about each individual elements across all the databases as separate elements we can label the polygon ABCDE as the NAME of a person.  The value of the NAME will vary across the different databases, but the whole polygon is still considered a NAME.  In one database it might be Lisa, in another Lisa Schutz, in another it is misspelled as liza Schutz, in another misspelling it is Lisa Schultz and in another the NAME is Schutz.

These databases will have other information in them.  In A, B and C we might have ADDRESS.  In D and E we might have SALARY.  ADDRESS and SALARY will have their own polygons of connections to other databases.

If these data elements are connected for the same person it can be visualised as a set of polygons that together create a polyhedron.

Screen Shot 2015-09-02 at 11.20.17 am

This data structure gives us an abstraction to reason with and implement as program code. The approach is a general approach to connecting distributed data and brings structure and modelling to hyperlinked systems.

It can work for any real world thing be it information about people, cars, houses. Whatever.

Making It Real – Keeping Addresses Up To Date

The unfortunate fact for IT teams is that people change address. As a result of this unfortunate fact, a high proportion of address data is today out of date and inconsistent because people tend to not notify every organisation or database they interact with of a change of address.

A “home address” can be a data element within a Welcomer connected database and all the “home addresses” can be linked by a Welcomer polygon.  Each of the “home addresses” reside in their own, respective databases which might include Government tax records, drivers registration, insurance policies and doctors records. The “home address” might be the place the person lives, the place to deliver parcels, or the place they lived when the transaction that created the “home address” was made.  At each database the rules for changing the “home address” are specified and defined as part of the local database.  When any “home address” in any of the databases changes then a message can be sent along the polygon path with the changes and each database makes its own decision using predefined rules on whether or not to update the “home address”.

Importantly the decision made on address is a characteristic of each database and the decision for each database is made asynchronously and independently of any other database.  No other database knows if any of the other databases changed the address.  All they know is that somewhere the address was changed.  In other words we have a distributed database function where each distributed component acts independently. This requires no coordination across databases.  It means that when data is changed in one database the same data held in other databases is changed, if required, but only at the time needed.

Making it Real – Verification of Identity

In many societies Electronic Proof of Identity is provided by a person proving they have possession of documents that show they are uniquely identified by organisations.  Examples are an ID card, a driver’s license, a passport, a relationship with a financial organisation. When a person wishes to uniquely identify themselves to another organisation they use one or more of these documents to prove their uniqueness. The organisation gives them another unique id so the organisation can retrieve information they store about the person when the person identifies themselves to the organisation.

With Welcomer Enabled databases a similar process is used except that the unique ids established with each connected organisation are used to establish new unique ids for other organisations. This contrasts with using the same physical ids for each new organisation.

A person goes to the new organisation (let’s call it bank D). They assert that they have a prior relationship with Organisations B, C and E. They give permission for D to use its already established organisational links with B, C and E to check if they do have those relationships and if so, then D creates a unique ID that is only known to D. And, in turn the person takes their unique ID for the organisation and adds it to their personal polyhedron. Now, if the person goes to another participating organisation, they can assert that they have unique IDs with B,C,E and D.

A Welcomer ID is an emergent property of the connected polygon of unique ids created for Welcomer enabled databases. A personal ID polyhedron if you will.

The advantage of this method is that like the internet, as long as there is an intermediate linkage(s) no two organisations need to be directly connected. And, the raw data typically used for verification of identity can be used as a secondary confirmation. The approach relies on the fact that all entities have allocated unique IDs to other entities to which they are connected and the fact that the unique ids are connected through a unique ID polygon.

Screen Shot 2015-08-27 at 2.07.02 pm (1)

In the diagram the entities A, B, C, D and E are represented by bubbles. A is a person. B,C,D and E are organisations. The lines represent connections between entities.

To take you through the example above, again, more technically, now that A is entering into a banking relationship with Bank D, the link AD is to be added. For AD to be created the rule specified by D is that there be 3 confirmations that A is unique with three other trusted entities. The person A also sets the rule that it wants D to be uniquely identified by three other entities.  A sends a message around its polygon of unique ids and asks if at each entity there is a relationship with D. D sends a message around its polygon of unique ids and finds the number of unique instances of A.

If both A and D establish that the other has three instances from the messages sent back to them then the link AD is established by each putting its unique id for the party in its own polygon of unique ids.

It is important that the ID that A gives D is only known to A and the ID that D gives to A is only known to D.  Public key pairs for identity overcome the problem of passing unique IDs around the system.

The approach works for other entities such as companies, trusts, not for profits, etc. as A, B, C, D, or E can be any type of entity.  The system also works for other things such as a motor car, a house, a computer, or any object in the Internet of Things. The graph of interconnecting identities is not just for people. It means that any type of entity can act as verifying identity for any other entity. This means if a person owns a house and the ownership of the house is recorded in a Welcomer connected database the house can be used to verify the identity of the house owner.

The number of unique IDs can vary with the confidence required.  A newborn baby may initially be linked to just one parent, then other people and other organisations can be linked.

The database of common identity information and links to other unique ID polygons for an individual will initially be stored in Verification of Identity application databases but there is no logical reason why every person could not move their database of connections and ID information and store it on their own phone where the phone becomes the electronic representation of the person.

A person can have many separate polygons of unique IDs.  It may be that a person wants to have different IDs for social connections, for family connections and for business connections. All these can be kept independent and separate from each other.

Verification of identity is a continuous process.  Each new verification strengthens the trust in the existing verifications.  It means that anomalies in behaviour can be detected and confirmation of identity can be required if fraud is suspected.

This form of identity verification can be deployed rapidly in any society by making existing large databases of personal data Welcomer Enabled.  If births, deaths and marriages, passports, social security IDs, tax records, drivers licenses, visas, bank accounts were Welcomer Enabled then this would be sufficient to cover most people.  People could create their polygons of unique ids the first time they accessed any services by any of these organisations. They could later use their official identities to create other trusted identities for other purposes.

Making it Real with Biometric Authentication

Biometrics are a convenient simple way for a physical person to be authenticated (linked to a computer record).  Assume Welcomer is used to verify the identity of a person and voice authentication is wanted to confirm it is the same person using the verified identity.  To do this a voice print can be part of each unique id record.  When a new connection is made a voice print for the person can be combined with all the other existing voice prints across all the unique ids. The new connection is not made unless the voice print, or an alternative authentication, is established.  Each time the voice is used in any application it strengthens the combined voice print across all applications.

Making it Real with Programs

The Welcomer links are not synchronous in the sense of database records where all the data elements in a record are retrieved when a record is read.  Welcomer communication is achieved by passing messages along links and communication is asynchronous.  The system addresses records by content rather than by location.  An index or ID for a record asks for a particular data record to be retrieved.  With Welcomer messages a value of a data element is retrieved by broadcasting a message along connected links and asking for the record with given content to respond. This approach is implemented with reactive programming technology where the Open Source Welcomer software provides APIs to applications to add a new data link and to retrieve data element values via these data links.

Linking database records with the same data elements reduces the potential hyperlink address space and makes the approach scalable, relatively easy to program and makes it possible to optimise performance.

Welcomer is implemented with the use of Akka programming framework from TypeSafe.

Making it Real by Connecting Applications

Organisations control the reuse of data by defining the data elements linked across applications.  Applications call Welcomer APIs to access the data and the data linkages are defined when the applications are deployed.  Welcomer publishes a list of APIs, and a list of data element definitions in Welcomer Enabled applications.  The organisation deploying an application specifies the data elements it thinks are the same in other applications.

The WelcomerAboard application has a different database for each form that is filled out.  It publishes the following table on the Welcomer website and it publishes an XML definition of each data entry in each of the different forms.

Personal Details Employee Contract Superannuation Choice
Personal Details Employee Contract Superannuation Choice
Public Key ID Public Key ID Public Key ID
Name Name Name
Phone Number
Bank Details
Tax File Number
Signature Signature
Super Account
Conditions applied for a person to access the data
Email authenticated Email Authenticated Email Authenticated
Rules on Update and notification through Welcomer
Three connections
required for update
of any items
No changes allowed Super Account, Name
Change Allowed.
Application Conditions for access
Any application White List White List
Organisational Restrictions for access
White List Black List White List

Different rules associated with WelcomeAboard application are applied as shown.  For example, each organisation can have a Black List of organisations to which it is unwilling to share data and a White list of applications with which it is prepared to share data.

Verifier for Income has a data base that includes, Public Key ID, email, address, name, bank account, salary.  When Verifier is deployed it says that the Public Key ID is the same as the Public Key ID in the WelcomeAboard data definitions and matches up other data items that it believes are the same.  These definitions are used by Welcomer to reuse and change data values.

To Know More

Welcomer is committed to deploying the connections with open source software and invites anyone to contribute to and use the code. Using it in applications will enable the data stored and accessed by the application available to any other application that uses the code.  Using the approach within an organisation will save much money and remove the need for other approaches to providing a single customer view as an alternative or in parallel to Single Signon.  Used widely the software will reduce the cost of building and operating computer systems by billions of dollars each year. To know more about the approach and see examples of Welcomer at work visit

Gunsmoke Article – Investing in Canberra

Article published in the Gungahlin Community Newsletter Gunsmoke 139.

Residents of Canberra cannot invest directly in Canberra infrastructure. This privilege is given to merchant bankers and overseas investors. It doesn’t have to be this way. The ACT government could provide ways for residents to invest in infrastructure. For example in many countries locally issued bonds are used to finance capital works.

Bonds and other forms of money debt are a method of providing credit through the creation of money and then selling the newly created money.  People who purchase bonds are purchasing new money that has been created as debt rather than investing directly. This is a relatively expensive method of providing credit because creating new money is risky and its value varies with changing interest rates.

There are other ways that we can issue credit without creating new money. The most common one is where we pre-purchase goods or services for later delivery.  This is used widely in everyday business.  People typically get a return on their money through discounts.  Discounts do not require the creation of any new money and hence are less expensive.  

An increasingly popular method of pre-purchasing goods or services is called CrowdFunding. Here investors give a business or person money and in return they get goods and services at some later time.

The ACT government could CrowdFund infrastructure and could start with Light Rail.  Residents of Canberra  could be invited to prepay their future rates and taxes by purchasing vouchers. These vouchers are to buy land from the ACT government, or pay their rates and taxes, or pay for rides on the Light Rail.  As with other prepayments the ACT government could give a discount depending on how long the voucher has been held.  The ACT government could also adjust the value of the voucher to account for inflation.

The vouchers could be made transferrable so that if a person purchased more vouchers than they needed they could sell them to someone else.  Vouchers issued at 8% discount per annum with the voucher face value being adjusted each year for inflation would be a very attractive investment for Canberra residents – particularly self managed super funds.  8% was chosen because it costs the same in interest forgone as 4% interest compounded over 33 years. Interest payments are taxable.  Discounts are not taxable. The value of vouchers will remain stable and fixed. They will not be subject to the whims of the financial markets.

Because they are an attractive investment the ACT government could issue every man woman and child in the ACT with a transferrable right to purchase vouchers.  The value of vouchers issued would be enough to pay for the Capital Cost of Light Rail.  This means that everyone in Canberra will benefit from the construction of Light Rail. If a resident did not want to purchase the vouchers they could sell their rights.  If they sold their rights they would pay tax on the increase in value from the time of purchase.

Vouchers are a low risk strategy for the ACT government because it would not have to find money each year to pay off loans and pay interest.  Instead the vouchers will be used to pay for goods and services. If the ACT government does not supply enough goods and services then it will need to find more goods and services to sell, or increase taxes. The ACT government will know precisely how much of the credit issued for Light Rail has been repaid and this will make for responsible fiscal management.