regsim-in 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- regsim_in-0.1.0/MANIFEST.in +1 -0
- regsim_in-0.1.0/PKG-INFO +324 -0
- regsim_in-0.1.0/README.md +316 -0
- regsim_in-0.1.0/pyproject.toml +26 -0
- regsim_in-0.1.0/regsim/__init__.py +0 -0
- regsim_in-0.1.0/regsim/cli.py +107 -0
- regsim_in-0.1.0/regsim/commands/__init__.py +0 -0
- regsim_in-0.1.0/regsim/commands/simulate.py +5 -0
- regsim_in-0.1.0/regsim/core/__init__.py +3 -0
- regsim_in-0.1.0/regsim/core/evaluator.py +65 -0
- regsim_in-0.1.0/regsim/core/fields.py +29 -0
- regsim_in-0.1.0/regsim/core/simulation.py +110 -0
- regsim_in-0.1.0/regsim/core/validators.py +9 -0
- regsim_in-0.1.0/regsim/engine.py +55 -0
- regsim_in-0.1.0/regsim/errors.py +0 -0
- regsim_in-0.1.0/regsim/parser.py +36 -0
- regsim_in-0.1.0/regsim/schemas/input.schema.json +4 -0
- regsim_in-0.1.0/regsim/schemas/output.schema.json +92 -0
- regsim_in-0.1.0/regsim/schemas/rule.schema.json +90 -0
- regsim_in-0.1.0/regsim/utils/__init__.py +9 -0
- regsim_in-0.1.0/regsim/utils/extract_call_args.py +10 -0
- regsim_in-0.1.0/regsim/utils/extract_dic.py +11 -0
- regsim_in-0.1.0/regsim/utils/get_func_name.py +8 -0
- regsim_in-0.1.0/regsim_in.egg-info/PKG-INFO +324 -0
- regsim_in-0.1.0/regsim_in.egg-info/SOURCES.txt +29 -0
- regsim_in-0.1.0/regsim_in.egg-info/dependency_links.txt +1 -0
- regsim_in-0.1.0/regsim_in.egg-info/entry_points.txt +2 -0
- regsim_in-0.1.0/regsim_in.egg-info/requires.txt +1 -0
- regsim_in-0.1.0/regsim_in.egg-info/top_level.txt +1 -0
- regsim_in-0.1.0/setup.cfg +4 -0
- regsim_in-0.1.0/tests/test_simulation.py +46 -0
|
@@ -0,0 +1 @@
|
|
|
1
|
+
recursive-include regsim/schemas *.json
|
regsim_in-0.1.0/PKG-INFO
ADDED
|
@@ -0,0 +1,324 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: regsim-in
|
|
3
|
+
Version: 0.1.0
|
|
4
|
+
Summary: Regulatory Simulation CLI for Indian Backend Systems
|
|
5
|
+
Requires-Python: >=3.9
|
|
6
|
+
Description-Content-Type: text/markdown
|
|
7
|
+
Requires-Dist: jsonschema>=4.0.0
|
|
8
|
+
|
|
9
|
+
# RegSim-IN
|
|
10
|
+
|
|
11
|
+
**Regulatory Simulation & Failure Memory CLI for Indian Backend Systems**
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## What is RegSim-IN?
|
|
16
|
+
|
|
17
|
+
**RegSim-IN** is a **developer-first CLI** that simulates Indian regulatory rules (TDS, GST, RBI-style constraints) against backend data flows **before production**.
|
|
18
|
+
|
|
19
|
+
It helps backend teams **detect, explain, and remember regulatory failures** early — during development, testing, and CI — instead of discovering them during audits or incidents.
|
|
20
|
+
|
|
21
|
+
RegSim-IN treats regulation as **executable rules**, not PDFs.
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## What Problem Does This Solve?
|
|
26
|
+
|
|
27
|
+
Backend teams frequently:
|
|
28
|
+
|
|
29
|
+
* Ship compliant-looking code that fails under real regulatory edge cases
|
|
30
|
+
* Discover issues late (audits, settlements, reversals)
|
|
31
|
+
* Repeat the *same regulatory mistakes* across services and teams
|
|
32
|
+
|
|
33
|
+
RegSim-IN exists to:
|
|
34
|
+
|
|
35
|
+
* Shift regulatory failures **left**
|
|
36
|
+
* Make rules **explicit and testable**
|
|
37
|
+
* Prevent **repeat regulatory incidents**
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## What RegSim-IN v1 Does
|
|
42
|
+
|
|
43
|
+
Version 1 focuses on **deterministic rule simulation**.
|
|
44
|
+
|
|
45
|
+
RegSim-IN v1 can:
|
|
46
|
+
|
|
47
|
+
* Load regulatory rules defined in **JSON**
|
|
48
|
+
* Run those rules against input payloads (also JSON)
|
|
49
|
+
* Evaluate pass/fail conditions
|
|
50
|
+
* Emit **machine-readable JSON output**
|
|
51
|
+
* Explain *why* a rule failed
|
|
52
|
+
|
|
53
|
+
This makes RegSim-IN suitable for:
|
|
54
|
+
|
|
55
|
+
* Local development checks
|
|
56
|
+
* CI/CD gates
|
|
57
|
+
* Backend design validation
|
|
58
|
+
* Regulatory edge-case exploration
|
|
59
|
+
|
|
60
|
+
---
|
|
61
|
+
|
|
62
|
+
## Example: Detecting a Missed TDS Deduction
|
|
63
|
+
|
|
64
|
+
Consider a backend payout flow where a contractor payment is executed without deducting TDS.
|
|
65
|
+
|
|
66
|
+
**Input payload:**
|
|
67
|
+
```json
|
|
68
|
+
{
|
|
69
|
+
"payment": {
|
|
70
|
+
"id": "pay_1029",
|
|
71
|
+
"amount": 45000,
|
|
72
|
+
"vendor_type": "contractor",
|
|
73
|
+
"tds_deducted": false
|
|
74
|
+
}
|
|
75
|
+
}
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
**Simulation result:**
|
|
79
|
+
|
|
80
|
+
```json
|
|
81
|
+
{
|
|
82
|
+
"status": "FAIL",
|
|
83
|
+
"violations": [
|
|
84
|
+
{
|
|
85
|
+
"rule_id": "TDS_194C_THRESHOLD",
|
|
86
|
+
"severity": "HIGH",
|
|
87
|
+
"message": "TDS must be deducted under section 194C"
|
|
88
|
+
}
|
|
89
|
+
]
|
|
90
|
+
}
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
This allows teams to catch deduction timing and threshold violations **before** payouts reach production systems.
|
|
94
|
+
|
|
95
|
+
---
|
|
96
|
+
|
|
97
|
+
## What RegSim-IN Explicitly Does NOT Do
|
|
98
|
+
|
|
99
|
+
To avoid misuse or false confidence, RegSim-IN v1 does **not**:
|
|
100
|
+
|
|
101
|
+
* Provide legal, tax, or regulatory advice
|
|
102
|
+
* File or generate GST / TDS / RBI reports
|
|
103
|
+
* Integrate with government, bank, or tax APIs
|
|
104
|
+
* Automatically update rules from circulars
|
|
105
|
+
* Fully simulate async systems (queues, retries, persistent state)
|
|
106
|
+
|
|
107
|
+
**This is a simulation tool, not a compliance authority.**
|
|
108
|
+
|
|
109
|
+
---
|
|
110
|
+
|
|
111
|
+
## Supported Languages
|
|
112
|
+
|
|
113
|
+
* **Python** (v1)
|
|
114
|
+
|
|
115
|
+
The CLI is language-agnostic, but rule evaluation currently targets Python-style backend data models.
|
|
116
|
+
|
|
117
|
+
---
|
|
118
|
+
|
|
119
|
+
## Rule Format
|
|
120
|
+
|
|
121
|
+
Rules are defined in **JSON**.
|
|
122
|
+
|
|
123
|
+
Design goals:
|
|
124
|
+
|
|
125
|
+
* Explicit structure
|
|
126
|
+
* Deterministic evaluation
|
|
127
|
+
* Easy diffing & review
|
|
128
|
+
* CI/CD friendliness
|
|
129
|
+
|
|
130
|
+
### Example Rule
|
|
131
|
+
|
|
132
|
+
```json
|
|
133
|
+
{
|
|
134
|
+
"rule_id": "TDS_194C_THRESHOLD",
|
|
135
|
+
"rule_version": "1.0",
|
|
136
|
+
"effective_from": "2024-04-01",
|
|
137
|
+
"description": "TDS applies if contractor payment exceeds threshold",
|
|
138
|
+
"condition": {
|
|
139
|
+
"field": "payment.amount",
|
|
140
|
+
"operator": ">",
|
|
141
|
+
"value": 30000
|
|
142
|
+
},
|
|
143
|
+
"action": {
|
|
144
|
+
"type": "FAIL",
|
|
145
|
+
"message": "TDS must be deducted under section 194C"
|
|
146
|
+
},
|
|
147
|
+
"source_reference": "Income Tax Act - Section 194C"
|
|
148
|
+
}
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
---
|
|
152
|
+
|
|
153
|
+
## Input Format
|
|
154
|
+
|
|
155
|
+
Inputs represent **backend payloads or traces**, also in JSON.
|
|
156
|
+
|
|
157
|
+
---
|
|
158
|
+
|
|
159
|
+
## Output Format
|
|
160
|
+
|
|
161
|
+
All outputs are **JSON only**.
|
|
162
|
+
|
|
163
|
+
Example failure output:
|
|
164
|
+
|
|
165
|
+
```json
|
|
166
|
+
{
|
|
167
|
+
"status": "FAIL",
|
|
168
|
+
"violations": [
|
|
169
|
+
{
|
|
170
|
+
"rule_id": "TDS_194C_THRESHOLD",
|
|
171
|
+
"severity": "HIGH",
|
|
172
|
+
"message": "TDS must be deducted under section 194C"
|
|
173
|
+
}
|
|
174
|
+
],
|
|
175
|
+
"metadata": {
|
|
176
|
+
"engine": "regsim-in",
|
|
177
|
+
"engine_version": "0.1.0",
|
|
178
|
+
"rule_snapshot": "2024-04-01",
|
|
179
|
+
"applied_rules": [
|
|
180
|
+
{
|
|
181
|
+
"rule_id": "TDS_194C_THRESHOLD",
|
|
182
|
+
"rule_version": "1.0",
|
|
183
|
+
"effective_from": "2024-04-01",
|
|
184
|
+
"source_reference": "Income Tax Act - Section 194C"
|
|
185
|
+
}
|
|
186
|
+
]
|
|
187
|
+
}
|
|
188
|
+
}
|
|
189
|
+
```
|
|
190
|
+
|
|
191
|
+
This makes RegSim-IN suitable for automation and tooling.
|
|
192
|
+
|
|
193
|
+
---
|
|
194
|
+
|
|
195
|
+
## Error Output
|
|
196
|
+
|
|
197
|
+
Errors are always returned as JSON and never include a Python traceback:
|
|
198
|
+
|
|
199
|
+
```json
|
|
200
|
+
{
|
|
201
|
+
"status": "ERROR",
|
|
202
|
+
"message": "Rule validation failed: missing field 'action'"
|
|
203
|
+
}
|
|
204
|
+
```
|
|
205
|
+
|
|
206
|
+
---
|
|
207
|
+
|
|
208
|
+
## Installation (Early Prototype)
|
|
209
|
+
|
|
210
|
+
```bash
|
|
211
|
+
pip install regsim-in
|
|
212
|
+
```
|
|
213
|
+
|
|
214
|
+
> RegSim-IN is under active development.
|
|
215
|
+
|
|
216
|
+
---
|
|
217
|
+
|
|
218
|
+
## Usage (v1)
|
|
219
|
+
|
|
220
|
+
```bash
|
|
221
|
+
regsim-in simulate \
|
|
222
|
+
--rules rules/ \
|
|
223
|
+
--input input.json
|
|
224
|
+
```
|
|
225
|
+
|
|
226
|
+
Current v1 behavior:
|
|
227
|
+
|
|
228
|
+
* CLI initializes correctly
|
|
229
|
+
* Rules are parsed and validated
|
|
230
|
+
* Simulation runs deterministically
|
|
231
|
+
* JSON output is emitted
|
|
232
|
+
|
|
233
|
+
---
|
|
234
|
+
|
|
235
|
+
## Project Layout (Current)
|
|
236
|
+
|
|
237
|
+
```
|
|
238
|
+
regsim/
|
|
239
|
+
cli.py
|
|
240
|
+
commands/
|
|
241
|
+
simulate.py
|
|
242
|
+
core/
|
|
243
|
+
evaluator.py
|
|
244
|
+
fields.py
|
|
245
|
+
simulation.py
|
|
246
|
+
validators.py
|
|
247
|
+
schemas/
|
|
248
|
+
```
|
|
249
|
+
|
|
250
|
+
The CLI stays thin, while core rule evaluation lives under `regsim/core/`.
|
|
251
|
+
|
|
252
|
+
---
|
|
253
|
+
|
|
254
|
+
## Rule Versioning & Regulatory Drift
|
|
255
|
+
|
|
256
|
+
RegSim-IN v1 supports **explicit rule versioning**:
|
|
257
|
+
|
|
258
|
+
* Rules declare:
|
|
259
|
+
|
|
260
|
+
* `rule_version`
|
|
261
|
+
* `effective_from`
|
|
262
|
+
* `source_reference`
|
|
263
|
+
* No rule updates happen implicitly
|
|
264
|
+
* Simulations are always tied to a known regulatory snapshot
|
|
265
|
+
|
|
266
|
+
This ensures:
|
|
267
|
+
|
|
268
|
+
* Reproducibility
|
|
269
|
+
* Reviewability
|
|
270
|
+
* Trust
|
|
271
|
+
|
|
272
|
+
---
|
|
273
|
+
|
|
274
|
+
## CI/CD Usage Example
|
|
275
|
+
|
|
276
|
+
```bash
|
|
277
|
+
regsim-in simulate --rules rules/ --input payload.json || exit 1
|
|
278
|
+
```
|
|
279
|
+
|
|
280
|
+
A failing rule causes a non-zero exit code.
|
|
281
|
+
|
|
282
|
+
---
|
|
283
|
+
|
|
284
|
+
## Roadmap (Explicit, Not Promised)
|
|
285
|
+
|
|
286
|
+
Planned future directions include:
|
|
287
|
+
|
|
288
|
+
* Regulatory failure memory & correlation
|
|
289
|
+
* Safer rule authoring workflows
|
|
290
|
+
* Async system modeling hooks
|
|
291
|
+
* Community-contributed rule sets
|
|
292
|
+
|
|
293
|
+
These are **not part of v1**.
|
|
294
|
+
|
|
295
|
+
---
|
|
296
|
+
|
|
297
|
+
## Philosophy
|
|
298
|
+
|
|
299
|
+
* Simulation over certification
|
|
300
|
+
* Explicit rules over implicit assumptions
|
|
301
|
+
* Deterministic behavior over magic
|
|
302
|
+
* Memory over repetition
|
|
303
|
+
|
|
304
|
+
---
|
|
305
|
+
|
|
306
|
+
## Disclaimer
|
|
307
|
+
|
|
308
|
+
RegSim-IN is a **developer simulation tool**.
|
|
309
|
+
It does **not** guarantee legal or regulatory compliance.
|
|
310
|
+
|
|
311
|
+
Always consult qualified professionals for real-world compliance decisions
|
|
312
|
+
|
|
313
|
+
---
|
|
314
|
+
|
|
315
|
+
## Exact Commands
|
|
316
|
+
|
|
317
|
+
# Run against JSON payload
|
|
318
|
+
regsim-in simulate --rules rules/ --input payload.json
|
|
319
|
+
|
|
320
|
+
# Run against Python service
|
|
321
|
+
regsim-in simulate --rules rules/ --input src/
|
|
322
|
+
|
|
323
|
+
# CI usage
|
|
324
|
+
regsim-in simulate --rules rules/ --input src/ --snapshot-date 2024-04-01
|
|
@@ -0,0 +1,316 @@
|
|
|
1
|
+
# RegSim-IN
|
|
2
|
+
|
|
3
|
+
**Regulatory Simulation & Failure Memory CLI for Indian Backend Systems**
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## What is RegSim-IN?
|
|
8
|
+
|
|
9
|
+
**RegSim-IN** is a **developer-first CLI** that simulates Indian regulatory rules (TDS, GST, RBI-style constraints) against backend data flows **before production**.
|
|
10
|
+
|
|
11
|
+
It helps backend teams **detect, explain, and remember regulatory failures** early — during development, testing, and CI — instead of discovering them during audits or incidents.
|
|
12
|
+
|
|
13
|
+
RegSim-IN treats regulation as **executable rules**, not PDFs.
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## What Problem Does This Solve?
|
|
18
|
+
|
|
19
|
+
Backend teams frequently:
|
|
20
|
+
|
|
21
|
+
* Ship compliant-looking code that fails under real regulatory edge cases
|
|
22
|
+
* Discover issues late (audits, settlements, reversals)
|
|
23
|
+
* Repeat the *same regulatory mistakes* across services and teams
|
|
24
|
+
|
|
25
|
+
RegSim-IN exists to:
|
|
26
|
+
|
|
27
|
+
* Shift regulatory failures **left**
|
|
28
|
+
* Make rules **explicit and testable**
|
|
29
|
+
* Prevent **repeat regulatory incidents**
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
## What RegSim-IN v1 Does
|
|
34
|
+
|
|
35
|
+
Version 1 focuses on **deterministic rule simulation**.
|
|
36
|
+
|
|
37
|
+
RegSim-IN v1 can:
|
|
38
|
+
|
|
39
|
+
* Load regulatory rules defined in **JSON**
|
|
40
|
+
* Run those rules against input payloads (also JSON)
|
|
41
|
+
* Evaluate pass/fail conditions
|
|
42
|
+
* Emit **machine-readable JSON output**
|
|
43
|
+
* Explain *why* a rule failed
|
|
44
|
+
|
|
45
|
+
This makes RegSim-IN suitable for:
|
|
46
|
+
|
|
47
|
+
* Local development checks
|
|
48
|
+
* CI/CD gates
|
|
49
|
+
* Backend design validation
|
|
50
|
+
* Regulatory edge-case exploration
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## Example: Detecting a Missed TDS Deduction
|
|
55
|
+
|
|
56
|
+
Consider a backend payout flow where a contractor payment is executed without deducting TDS.
|
|
57
|
+
|
|
58
|
+
**Input payload:**
|
|
59
|
+
```json
|
|
60
|
+
{
|
|
61
|
+
"payment": {
|
|
62
|
+
"id": "pay_1029",
|
|
63
|
+
"amount": 45000,
|
|
64
|
+
"vendor_type": "contractor",
|
|
65
|
+
"tds_deducted": false
|
|
66
|
+
}
|
|
67
|
+
}
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
**Simulation result:**
|
|
71
|
+
|
|
72
|
+
```json
|
|
73
|
+
{
|
|
74
|
+
"status": "FAIL",
|
|
75
|
+
"violations": [
|
|
76
|
+
{
|
|
77
|
+
"rule_id": "TDS_194C_THRESHOLD",
|
|
78
|
+
"severity": "HIGH",
|
|
79
|
+
"message": "TDS must be deducted under section 194C"
|
|
80
|
+
}
|
|
81
|
+
]
|
|
82
|
+
}
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
This allows teams to catch deduction timing and threshold violations **before** payouts reach production systems.
|
|
86
|
+
|
|
87
|
+
---
|
|
88
|
+
|
|
89
|
+
## What RegSim-IN Explicitly Does NOT Do
|
|
90
|
+
|
|
91
|
+
To avoid misuse or false confidence, RegSim-IN v1 does **not**:
|
|
92
|
+
|
|
93
|
+
* Provide legal, tax, or regulatory advice
|
|
94
|
+
* File or generate GST / TDS / RBI reports
|
|
95
|
+
* Integrate with government, bank, or tax APIs
|
|
96
|
+
* Automatically update rules from circulars
|
|
97
|
+
* Fully simulate async systems (queues, retries, persistent state)
|
|
98
|
+
|
|
99
|
+
**This is a simulation tool, not a compliance authority.**
|
|
100
|
+
|
|
101
|
+
---
|
|
102
|
+
|
|
103
|
+
## Supported Languages
|
|
104
|
+
|
|
105
|
+
* **Python** (v1)
|
|
106
|
+
|
|
107
|
+
The CLI is language-agnostic, but rule evaluation currently targets Python-style backend data models.
|
|
108
|
+
|
|
109
|
+
---
|
|
110
|
+
|
|
111
|
+
## Rule Format
|
|
112
|
+
|
|
113
|
+
Rules are defined in **JSON**.
|
|
114
|
+
|
|
115
|
+
Design goals:
|
|
116
|
+
|
|
117
|
+
* Explicit structure
|
|
118
|
+
* Deterministic evaluation
|
|
119
|
+
* Easy diffing & review
|
|
120
|
+
* CI/CD friendliness
|
|
121
|
+
|
|
122
|
+
### Example Rule
|
|
123
|
+
|
|
124
|
+
```json
|
|
125
|
+
{
|
|
126
|
+
"rule_id": "TDS_194C_THRESHOLD",
|
|
127
|
+
"rule_version": "1.0",
|
|
128
|
+
"effective_from": "2024-04-01",
|
|
129
|
+
"description": "TDS applies if contractor payment exceeds threshold",
|
|
130
|
+
"condition": {
|
|
131
|
+
"field": "payment.amount",
|
|
132
|
+
"operator": ">",
|
|
133
|
+
"value": 30000
|
|
134
|
+
},
|
|
135
|
+
"action": {
|
|
136
|
+
"type": "FAIL",
|
|
137
|
+
"message": "TDS must be deducted under section 194C"
|
|
138
|
+
},
|
|
139
|
+
"source_reference": "Income Tax Act - Section 194C"
|
|
140
|
+
}
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
---
|
|
144
|
+
|
|
145
|
+
## Input Format
|
|
146
|
+
|
|
147
|
+
Inputs represent **backend payloads or traces**, also in JSON.
|
|
148
|
+
|
|
149
|
+
---
|
|
150
|
+
|
|
151
|
+
## Output Format
|
|
152
|
+
|
|
153
|
+
All outputs are **JSON only**.
|
|
154
|
+
|
|
155
|
+
Example failure output:
|
|
156
|
+
|
|
157
|
+
```json
|
|
158
|
+
{
|
|
159
|
+
"status": "FAIL",
|
|
160
|
+
"violations": [
|
|
161
|
+
{
|
|
162
|
+
"rule_id": "TDS_194C_THRESHOLD",
|
|
163
|
+
"severity": "HIGH",
|
|
164
|
+
"message": "TDS must be deducted under section 194C"
|
|
165
|
+
}
|
|
166
|
+
],
|
|
167
|
+
"metadata": {
|
|
168
|
+
"engine": "regsim-in",
|
|
169
|
+
"engine_version": "0.1.0",
|
|
170
|
+
"rule_snapshot": "2024-04-01",
|
|
171
|
+
"applied_rules": [
|
|
172
|
+
{
|
|
173
|
+
"rule_id": "TDS_194C_THRESHOLD",
|
|
174
|
+
"rule_version": "1.0",
|
|
175
|
+
"effective_from": "2024-04-01",
|
|
176
|
+
"source_reference": "Income Tax Act - Section 194C"
|
|
177
|
+
}
|
|
178
|
+
]
|
|
179
|
+
}
|
|
180
|
+
}
|
|
181
|
+
```
|
|
182
|
+
|
|
183
|
+
This makes RegSim-IN suitable for automation and tooling.
|
|
184
|
+
|
|
185
|
+
---
|
|
186
|
+
|
|
187
|
+
## Error Output
|
|
188
|
+
|
|
189
|
+
Errors are always returned as JSON and never include a Python traceback:
|
|
190
|
+
|
|
191
|
+
```json
|
|
192
|
+
{
|
|
193
|
+
"status": "ERROR",
|
|
194
|
+
"message": "Rule validation failed: missing field 'action'"
|
|
195
|
+
}
|
|
196
|
+
```
|
|
197
|
+
|
|
198
|
+
---
|
|
199
|
+
|
|
200
|
+
## Installation (Early Prototype)
|
|
201
|
+
|
|
202
|
+
```bash
|
|
203
|
+
pip install regsim-in
|
|
204
|
+
```
|
|
205
|
+
|
|
206
|
+
> RegSim-IN is under active development.
|
|
207
|
+
|
|
208
|
+
---
|
|
209
|
+
|
|
210
|
+
## Usage (v1)
|
|
211
|
+
|
|
212
|
+
```bash
|
|
213
|
+
regsim-in simulate \
|
|
214
|
+
--rules rules/ \
|
|
215
|
+
--input input.json
|
|
216
|
+
```
|
|
217
|
+
|
|
218
|
+
Current v1 behavior:
|
|
219
|
+
|
|
220
|
+
* CLI initializes correctly
|
|
221
|
+
* Rules are parsed and validated
|
|
222
|
+
* Simulation runs deterministically
|
|
223
|
+
* JSON output is emitted
|
|
224
|
+
|
|
225
|
+
---
|
|
226
|
+
|
|
227
|
+
## Project Layout (Current)
|
|
228
|
+
|
|
229
|
+
```
|
|
230
|
+
regsim/
|
|
231
|
+
cli.py
|
|
232
|
+
commands/
|
|
233
|
+
simulate.py
|
|
234
|
+
core/
|
|
235
|
+
evaluator.py
|
|
236
|
+
fields.py
|
|
237
|
+
simulation.py
|
|
238
|
+
validators.py
|
|
239
|
+
schemas/
|
|
240
|
+
```
|
|
241
|
+
|
|
242
|
+
The CLI stays thin, while core rule evaluation lives under `regsim/core/`.
|
|
243
|
+
|
|
244
|
+
---
|
|
245
|
+
|
|
246
|
+
## Rule Versioning & Regulatory Drift
|
|
247
|
+
|
|
248
|
+
RegSim-IN v1 supports **explicit rule versioning**:
|
|
249
|
+
|
|
250
|
+
* Rules declare:
|
|
251
|
+
|
|
252
|
+
* `rule_version`
|
|
253
|
+
* `effective_from`
|
|
254
|
+
* `source_reference`
|
|
255
|
+
* No rule updates happen implicitly
|
|
256
|
+
* Simulations are always tied to a known regulatory snapshot
|
|
257
|
+
|
|
258
|
+
This ensures:
|
|
259
|
+
|
|
260
|
+
* Reproducibility
|
|
261
|
+
* Reviewability
|
|
262
|
+
* Trust
|
|
263
|
+
|
|
264
|
+
---
|
|
265
|
+
|
|
266
|
+
## CI/CD Usage Example
|
|
267
|
+
|
|
268
|
+
```bash
|
|
269
|
+
regsim-in simulate --rules rules/ --input payload.json || exit 1
|
|
270
|
+
```
|
|
271
|
+
|
|
272
|
+
A failing rule causes a non-zero exit code.
|
|
273
|
+
|
|
274
|
+
---
|
|
275
|
+
|
|
276
|
+
## Roadmap (Explicit, Not Promised)
|
|
277
|
+
|
|
278
|
+
Planned future directions include:
|
|
279
|
+
|
|
280
|
+
* Regulatory failure memory & correlation
|
|
281
|
+
* Safer rule authoring workflows
|
|
282
|
+
* Async system modeling hooks
|
|
283
|
+
* Community-contributed rule sets
|
|
284
|
+
|
|
285
|
+
These are **not part of v1**.
|
|
286
|
+
|
|
287
|
+
---
|
|
288
|
+
|
|
289
|
+
## Philosophy
|
|
290
|
+
|
|
291
|
+
* Simulation over certification
|
|
292
|
+
* Explicit rules over implicit assumptions
|
|
293
|
+
* Deterministic behavior over magic
|
|
294
|
+
* Memory over repetition
|
|
295
|
+
|
|
296
|
+
---
|
|
297
|
+
|
|
298
|
+
## Disclaimer
|
|
299
|
+
|
|
300
|
+
RegSim-IN is a **developer simulation tool**.
|
|
301
|
+
It does **not** guarantee legal or regulatory compliance.
|
|
302
|
+
|
|
303
|
+
Always consult qualified professionals for real-world compliance decisions
|
|
304
|
+
|
|
305
|
+
---
|
|
306
|
+
|
|
307
|
+
## Exact Commands
|
|
308
|
+
|
|
309
|
+
# Run against JSON payload
|
|
310
|
+
regsim-in simulate --rules rules/ --input payload.json
|
|
311
|
+
|
|
312
|
+
# Run against Python service
|
|
313
|
+
regsim-in simulate --rules rules/ --input src/
|
|
314
|
+
|
|
315
|
+
# CI usage
|
|
316
|
+
regsim-in simulate --rules rules/ --input src/ --snapshot-date 2024-04-01
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
[build-system]
|
|
2
|
+
requires = ["setuptools>=61.0"]
|
|
3
|
+
build-backend = "setuptools.build_meta"
|
|
4
|
+
|
|
5
|
+
[project]
|
|
6
|
+
name = "regsim-in"
|
|
7
|
+
version = "0.1.0"
|
|
8
|
+
description = "Regulatory Simulation CLI for Indian Backend Systems"
|
|
9
|
+
readme = "README.md"
|
|
10
|
+
requires-python = ">=3.9"
|
|
11
|
+
dependencies = [
|
|
12
|
+
"jsonschema>=4.0.0"
|
|
13
|
+
]
|
|
14
|
+
|
|
15
|
+
[project.scripts]
|
|
16
|
+
regsim-in = "regsim.cli:main"
|
|
17
|
+
|
|
18
|
+
[tool.setuptools.packages.find]
|
|
19
|
+
include = ["regsim*"]
|
|
20
|
+
exclude = ["rules*", "tests*", "examples*", ".github*"]
|
|
21
|
+
|
|
22
|
+
[tool.setuptools]
|
|
23
|
+
include-package-data = true
|
|
24
|
+
|
|
25
|
+
[tool.setuptools.package-data]
|
|
26
|
+
regsim = ["schemas/*.json"]
|
|
File without changes
|