Refactor inputs/outputs JSON format?

[sierscse]

Post-MVP work

How should inputs be structured? Ideas include

• restructure it to align with Open Fisca format
• add relationships and marital status to help with determining benefit households
• add citizenship, expenses, and resources formats

For now a basic format was added for the low-income and senior tax freeze benefits in Philly, to include boolean values for primary, married, and spouseOfPrimary.

[prestoncabe]

The more I think about it, the more I think it would be best to support input/output compatibility with OpenFisca and/or PolicyEngine. Even though PolicyEngine is derived from OpenFisca, they have drifted in some ways from the OpenFisca base (I don't know how much in regard to I/O).

Why?

• We haven't fully invented an I/O format that will cover all the benefit scenarios we want to support (and OpenFisca/PolicyEngine presumably have). Let's not reinvent the wheel.
• It would probably make our project more compelling if people could plug it in to one of these other projects which have gained traction. Our project's reason to exist is to explore how to make it easier to create rules and screeners, not define JSON interfaces.

Why not?

• Maybe the OF/PE JSON format is too cumbersome to model in DMN naturally?
• Maybe the PolicyEngine format is more natural for policy scenario work than individual eligibility screening? I think this is being proven wrong by PE's use in tools like LA's Benefit Navigator
• Might distract from our main goals in the short term.

I have talked about this idea w/ our friend Nick at Claimant, and he has done some initial experimenting with interoperability with PolicyEngine, but nothing to show for it yet.

This will take some dedication and focus to experiment and come up with a way forward. (It may involve rewriting an extensive amount of our DMN, and/or perhaps supporting "adapters" for converting from one format to another).