Efficient access of chainable records

1. A system comprising:

at least one processor;

an event graph storing event blocks, each event block including a group identifier, content, and a hash;

memory storing event access policies, each event access policy including at least one field identifier, wherein a first event access policy of the event access policies includes a first field identifier;

an event access table storing access records generated by applying the event access policies to transactions to capture a field value for field identifiers in the event access policies, each access record having a group identifier and a field value, wherein at least one of the access records has a field value for the first field identifier; and

memory storing instructions that, when executed by the at least one processor, cause the system to perform operations including:

providing a user interface configured to manage the event access policies,

receiving, via the user interface, a second field identifier and storing the second field identifier as a second event access policy in the event access policies, and

responsive to storing the second event access policy, applying the second event access policy in addition to the first event access policy to incoming transactions to generate additional event access records, so that at least a first additional event access record has a field value captured from the incoming transactions for the second field identifier and at least a second additional event access record has a field value captured from the incoming transactions for the first field identifier,

wherein additional event blocks are written to the event graph for the incoming transactions, independent of applying the second event access policy in addition to the first event access policy.

2. The system of claim 1 , wherein applying the second event access policy to a particular incoming transaction of the transactions includes:

receiving the particular transaction;

generating a group identifier for the particular transaction;

determining whether the first event access policy applies to the particular transaction;

adding, in response to determining that the first event access policy applies, a first new event access record to the event access table, the first new event access record having the group identifier for the particular transaction and a value captured from the particular transaction for the first field identifier;

determining whether the second event access policy applies to the particular transaction; and

adding, in response to determining that the second event access policy applies, a second new event access record to the event access table, the second new event access record having the group identifier for the particular transaction and a value captured from the particular transaction for the second field identifier.

3. The system of claim 1 , wherein the operations further include:

receiving a query with a query parameter;

identifying a record in the event access table that is responsive to the query parameter, the record including a group identifier and a field matching the query parameter;

locating potential responsive blocks, the potential responsive blocks being event blocks in the event graph that include the group identifier, each of the potential responsive blocks also including content and a hash of a predecessor block;

identifying a first block of the potential responsive blocks that has content that includes the field matching the query parameter; and

providing the first block as a response to the query.

4. The system of claim 1 , wherein the operations further include:

providing a query user interface configured to expose accessible fields for querying,

wherein subsequent to storing the second event access policy, the query user interface is configured to expose the second field for querying.

5. The system of claim 4 , wherein a group identifier is not an accessible field for querying.

6. The system of claim 1 , wherein the operations further include:

receiving an event type with the second field identifier; and

storing the event type with the second field identifier in the second event access policy.

7. The system of claim 6 , wherein applying the second event access policy to incoming transactions includes capturing a value for the second field from a transaction responsive to the transaction including an event of the event type.

8. The system of claim 1 , wherein applying the second event access policy to incoming transactions includes capturing a value for the second field from a transaction responsive to the transaction including the second field.

9. The system of claim 1 , wherein the event graph is an audit blockchain.

10. The system of claim 1 , wherein the operations further include:

receiving, via the user interface, removal of the first field identifier; and

responsive to receiving the removal, deleting the first event access policy from the event access policies,

wherein responsive to deleting the first event access policy from the event access policies, applying the event access policies to incoming transactions will not generate additional event access records that include the first field.

11. A method comprising:

applying event access policies to incoming transactions to generate event access records, wherein:

event blocks are written to an event graph for the incoming transactions, each event block including a group identifier, content, and a hash,

each event access policy in the event access policies includes at least one field identifier, wherein a first event access policy of the event access policies includes a first field identifier, and

at least one of the event access records generated has a field value captured from a transaction of the incoming transactions for the first field identifier and a group identifier generated for the transaction;

providing a user interface configured to manage the event access policies;

receiving, via the user interface, a second field identifier;

storing a second event access policy in the event access policies, the second event access policy identifying the second field identifier; and

responsive to storing the second event access policy, applying the second event access policy to incoming transactions to generate additional event access records, so that at least a first additional event access record has a field value captured from the incoming transactions for the second field identifier and at least a second additional event access record has a field value captured from the incoming transactions for the first field identifier.

12. The method of claim 11 , further comprising:

using the event access records to identify event blocks from the event graph in response to a query specifying a value for the first field or for the second field.

13. The method of claim 11 , further comprising:

receiving a query having a query parameter;

identifying an event access data record responsive to the query parameter, the identified event access data record including a group identifier and a field matching the query parameter;

locating potential responsive blocks, the potential responsive blocks being event blocks in a chain that include the group identifier, each of the potential responsive blocks also including content and a hash of a predecessor block;

identifying a first block of the potential responsive blocks that has content that includes the field matching the query parameter; and

providing the first block as a response to the query.

14. The method of claim 11 , further comprising:

providing a query user interface configured to expose accessible fields for querying,

wherein subsequent to storing the second event access policy in the event access policies, the query user interface is configured to expose the second field for querying.

15. The method of claim 14 , wherein a group identifier is not an accessible field for querying.

16. The method of claim 11 , further comprising:

receiving an event type with the second field identifier; and

storing the event type with the second field identifier in the second event access policy.

17. The method of claim 16 , wherein applying the second event access policy to incoming transactions includes capturing the second field from a transaction responsive to the transaction including an event of the event type.

18. The method of claim 11 , wherein applying the second event access policy to incoming transactions includes capturing a value for the second field from a transaction responsive to the transaction including the second field.

19. The method of claim 11 , wherein the event graph is an audit blockchain.

20. The method of claim 11 , further comprising:

receiving, via the user interface, removal of the first field identifier; and

deleting the first event access policy from the event access policies,

wherein responsive to deleting the first event access policy from the event access policies, applying the event access policies to incoming transactions will not generate additional event access records that include the first field.