Requirements's intellectual property is the differentiable data structure, a concept that merges vector calculus with data science to produce a systemaccounting function.

Rather than software engineers, systemaccountants are primarily physics-minded data scientists who serve to increase the public's understanding of how an economy relates to the Physical Universe.

To begin modeling an economy the same way the Physical Universe does, software must be produced that transmits, records, and publishes differentiable database objects. Below are the requirements & repositories for the production of a publicly-accessible systemaccounting application operating from the cloud.

Members of the public seeking an expedient deployment of systemaccounting are welcome to participate. If you're not experienced with any of the relevant fields, or cannot afford the time, you may still contribute via the Financial Support page.

Public Repository:
Task List: .../issues
Live URL:


How do I submit a feature request to systemaccounting?

I require a service for my business, government, or personal use that does not yet exist. How do I submit a feature request to systemaccounting?


Aside from its security layer, systemaccounting code is public for the principal reason that transparency begets trust. Also, encouraging public involvement raises the demand for technical people in government & commerce—an intended consequence since internally developing all features for all users isn't practical for an operation primarily concerned with educating the public on the principles, tools, and benefits of pursuing physics through data science.

You are therefore invited to independently produce whatever feature you wish, then submit a pull request that contains a comprehensive list of the feature's test cases. Features affecting a systemaccounting-hosted interface must be proposed with links to publicly-shared visual elements, style-guide-annotated mock screens, and wire-frames (use Google Drive, Dropbox, etc.). Additional formatting guides will be published for the public's assistance.

Systemaccounting does not accept software requirements in document format since 'Product Requirements' = 'Expected Results'. The preference to skip over high-level requirement documentation is justified by recognizing that code is only marked 'Deployment-Ready' when testing proves 'Observed Results' = 'Expected Results'. Therefore, designers must produce a rigorously-researched and comprehensive list of positive & negative expected results before observed results are produced*. Test cases will be submitted by including a single file formatted according to TestRail's XML bulk import tool in the pull request (JSON-formatted files will be accepted after an 'add_cases' POST method becomes available in the TestRail API). All cases will be located in the '/test/requirements' directory of the project and will be updated regularly with expected & unexpected (identified by bugs) cases. With few exceptions, cases must be automated.

Test case fields using the createAccountDebitSequence as an example:

<title>Selecting createButton on landingScreen displays selectFundingSourceScreen</title>
<references> Pull request ID</references>
     1. Navigate mobile web client to http://URL.
     2. Select the createButton after the landingScreen is displayed.
<expected>The selectFundingSourceScreen is displayed.</expected>
     [Link to visual elements](http://URL)
     [Link to style-guide-annotated mock screens](http://URL)
     [Link to wire-frames](http://URL)

All screens, buttons, and other design elements will receive a camelCase name and be entered into a publicly-accessible product dictionary to maintain product definition stability, e.g. createButton, landingScreen, selectFundingSourceScreen. Links to publicly-shared visual elements, style-guide-annotated mock screens, and wire-frames will be listed in the supplementary_requirements field according to TestRail's editor guide. Specify names of column families where there is a create, update, and delete dependency. Separately, specify names of column families where there is a read dependency. API dependencies must also be specified.

Once a proposed feature passes a review of its i) test cases, ii) code (unit tests included), and iii) design assets, the feature will undergo testing. Code will be prioritized for deployment after it passes its automated and/or manual tests.


*Note: Systemaccounting advises the public to always offer software engineers what some may wish to deny students, i.e. enable them to code to the test. Supplying engineers the answers to the test before coding begins wards off ambiguity and wasted time since their primary duty is to convert human language into machine language; not predict the yet-to-be formed ideas in other people's minds. Just as incomplete code may reveal a careless and/or unskilled engineer, incomplete requirements tend to reveal a lazy and/or indecisive product designer (often found advocating that passion may be substituted for well-thought-out ideas, thus shifting away the liability of an undiscovered fatal flaw to others, and leaving much of the intellectual work to be completed by individuals who acquired the discipline of completing their homework assignments & studying for exams in school). Stated plainly, product designers who fail to task engineers with test cases pose as much risk to a project as engineers who fail to test their own code. 

How is capital raised in systemaccounting?


Create a composite script that offers the sale of your account's future earnings.

See createCompositeRuleSequence - webClient -

Do overdrafts occur within systemaccounting?


Not physically possible, but another user may offer the purchase of a transaction rule that automatically funds an account if it attempts to fulfill a transaction that will change its balance to less than zero. The rule will likely be a composite script that requires the receiving account to accept a new rule that pays a fee to the creditor.

Systemaccounting only measures activity and does not finance it. If users are measured to perform on their contracts between one another, both buyers and sellers of financial instruments will experience a reduction in friction to liquidity.

Was this helpful?