1.
Create a User Guide for the below video
Instructions:
Create a separate word document with cover and end page.
Create styles.
Use screenshots for better usage.
Write a procedure on different ways to create a Fact Type
2. Modify the below paragraph
Please edit the paragraph below for spelling, grammar, and improved readability. The focus is on
writing clarity and grammar, so feel free to make assumptions on the system behavior as required to
improve clarity of the paragraph.
Background information on MIO for understanding paragraph to edit below (do not edit this
section)
The paragraph explains the algorithm for the Sapiens Decision Minimized Input Optimization (MIO)
API that is used in conjunction with Decision logic to determine the next minimal set of Fact Type
inputs to determine a conclusion. The algorithm considers the Input Fact Types provided and based
on their values returns a conclusion or the next set of minimal Fact Types required to arrive at a
conclusion. Essentially the MIO API provides a question scripting approach where a user can provide
question answers and based on the provided values be asked the next minimal set of questions to
arrive at a conclusion, working iteratively to provide the user with the next set of questions or a
decision conclusion.
Some abbreviations are used in the paragraph below that can help in restructuring and improving
the paragraph:
DV = Decision View (A Decision model of decision logic made up of a hierarchy of Rule Family Views)
FT = Fact Type (A data input value)
Persistent FT = Input data value
Interim FT = Logic derived data value
RFV = Rule Family View (A decision table of logic that is a subset of the Decision model providing the
result for an interim conclusion value in the Decision Model)
MIO = Minimized Input Optimization
Paragraph to improve
The general method is to establish a questionaire per DV, where the questions on the questionaire
are derived from the interim FTs and to develop an execution mode where, upon each answer
supplied by the user, you can test whether a specific RFV is determinative, and if it is, whether that
causes the DV to become determinative.
Each persistent FT is assumed to be represented by a question on that page (the questions could be
contained, e.g., in the model mappings). The questions may appear based on the DV, multiple or one
at a time. If the processing of an RFV is not complete, and a additional RFV is required, then the
questions for that RFV as added to the existing page. These are implementations details to be
considered.
Within each RFV the questions – the FT’s – are not ordered; any order will do. Within the DV, MIO
starts processing the Decision RFV and descend the hierarchy, one branch at a time until the branch
is complete; then descend the hierarchy of the next branch. There is no order to the branchesany
branch can be selected based on the least row ID of the RFV if there is a tie between the rows. Once
the branch is selected, that hierarchy must be completed before the next hierarchy chosen. This
remains true for every level of every hierarchy.
The general method is that as question is answered, MIO execute that RFV to establish whether
answer given renders RFV as determinative; if it is then, application executes the DV to determine
whether it is determinative (the exception to this is last question answered. This leads to
determinative DV, ending the process).
If the RFV is not determinative, application proceeds to the next FT in the RFV, present it on the page
as the question to be answered, or if there are no further FTs in that RFV, move onto the next RFV in
the hierarchy, or if at the end of a hierarchy (i.e. branch to a level the DV), to a new Hierarchy.
If the RFV is determinative, but not the DV, it means MIO completed processing the RFV and moves
to the next RFV; if the DV is determinative, application completes the questionnaire.